date:20100922

Correct function being needlessly visible outside compilation unit
when the only users are internal.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index b87569e..f366f96 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -598,7 +598,7 @@ static inline void
vga_update_device_decodes(struct vga_device *vgadev,
 pr_debug("vgaarb: decoding count now is: %d\n", vga_decode_count);
 }

-void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned int
decodes, bool userspace)
+static void __vga_set_legacy_decoding(struct pci_dev *pdev, unsigned
int decodes, bool userspace)
 {
 struct vga_device *vgadev;
 unsigned long flags;
-- 
Daniel J Blueman

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

2010-09-22 Thread Jon Smirl

On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls  wrote:
> On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
>> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher  
>> wrote:
>> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls  
>> > wrote:
>> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> >>> 2010/9/20 Andy Walls :
>> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafa? Mi?ecki wrote:
>> >>> >> 2010/9/20 Andy Walls :
>
>> >> The real problem to me is that the radeon and drm modules have a single,
>> >> standard way of dealing with EDID errors. ?However, EDID errors can
>> >> happen due to a number of different causes, some of which are external
>> >> (i.e. in the LCD or CRT monitor). ?Given that, there really is no "right
>> >> thing" the drivers can do without input from the user on what the policy
>> >> should be when a bad EDID is detected.
>>
>> Andy, this sure looks like a broken VBIOS to me.
>
> Well sure.
>
> But that problem causes other problems in error handling code paths to
> surface. ?It also brings to light that there are some cases that are
> undecidable, or not worth the effort, for the error handling code paths
> on what the proper action should be.
>
>
>> ?First thing would be
>> to update your VBIOS if possible to get a correct table for your
>> hardware.
>
> Um, no.
>
> I will not risk taking an operational machine down due to flash write
> failure, however small the probability, due to the high impact.
> The reward of shutting up kernel error messages, is not worth the risk.
>
>
>> ?Second would be to add a quirk in the kernel.
>
> I have expressed my thoughts on quirks in a previous post.
>
>
>> There are lots of cases where the kernel does odd things when the BIOS
>> feeds it bad information. Do we really want hundreds of switches in
>> sysfs allowing adjustments for broken BIOS features?
>
> I see very little downside in giving the user more control over his
> system. ?A thousand knobs and switches are worth it for the user, for
> the one switch that is there when the user needs it to solve a problem.
>
> To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver
> to dump the ROM. ?That would have consumed a lot of time. ?Luckily for
> me, there was a switch to turn on the ROM and dump it:

The ROM is turned off by default due to a provision in the PCI spec
that allows the address space of it to be reused after boot. A few old
PCI devices make use of this feature. If you turn the ROM on in those
machines they will crash.

>
> ? ? ? ?# echo 1 > /sys/class/drm/card0/device/rom
> ? ? ? ?# dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
> ? ? ? ?# echo 0 > /sys/class/drm/card0/device/rom
>
> I never used it before and will likely never use it again. ?But when I
> had a problem I needed to solve, its availability made the solution
> simple and efficient. ?Time to accomplish tasks is my scarcest resource;
> time efficiency is very important to me.
>
>
> The only downside to hundreds of switches and control knobs I can really
> think of is possibly complexity for the end user. ?But it turns out,
> that ignoring the available controls, or ignoring large subsets of the
> available controls, is how people are going to deal with that
> complexity. ?Heck, I ignore most of sysfs almost all the time. ?I also
> ignore almost every module option available. ?My system runs fine
> without me caring about a majority of the existing switches.
>
>
> BTW, we already have thousands of switches and controls for kernel
> internals in linux without sysfs and ioctl()'s:
>
> $ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} \; | grep 
> '^parm:' | wc -l
> 3387
>
> Why do we have that many? ?They are low cost in complexity, as they can
> easily be ignored. ?They are high value in utility, as they give the
> user control over his system to deal with unusual circumstances.
>
> 
>
>
>
>
>> ?We already have
>> the quirk scheme for addressing this.
>>
>> A simpler solution for reducing the log spam would be to only report
>> the error once, instead of every 10 seconds. The driver could remember
>> it has made the error report and then log another message later if the
>> error was cleared.
>
> My sysfs implementation was only 69 changed lines in one file:
>
> ? ? ? ?drivers/gpu/drm/drm_sysfs.c ? ? ? ? | ? 69 +++
>
> I doubt a solution to add logic to the error paths, to try and divine
> all the sources of EDID errors by saving state and applying rules to
> take the correct action, is going to be less change than that. ?I know
> more than one file will have to change.
>
> Regards,
> Andy
>
>



-- 
Jon Smirl
jonsmirl at gmail.com

[2.6.36-rc5] radeon fixes...

Fix string interpreted as trigraph and typo.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 1bc72c3..fe359a2 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -4999,7 +4999,7 @@ typedef struct _SW_I2C_IO_DATA_PARAMETERS
 #define SW_I2C_CNTL_WRITE1BIT 6

 //==VESA definition
Portion===
-#define VESA_OEM_PRODUCT_REV   '01.00'
+#define VESA_OEM_PRODUCT_REV   "01.00"
 #define VESA_MODE_ATTRIBUTE_MODE_SUPPORT0xBB   //refer to VBE
spec p.32, no TTY support
 #define VESA_MODE_WIN_ATTRIBUTE
 7
 #define VESA_WIN_SIZE  
 64
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index bfdfa3e..e3b47a5 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2727,7 +2727,7 @@ int r600_ib_test(struct radeon_device *rdev)
if (i < rdev->usec_timeout) {
DRM_INFO("ib test succeeded in %u usecs\n", i);
} else {
-   DRM_ERROR("radeon: ib test failed (sracth(0x%04X)=0x%08X)\n",
+   DRM_ERROR("radeon: ib test failed (scratch(0x%04X)=0x%08X)\n",
  scratch, tmp);
r = -EINVAL;
}
-- 
Daniel J Blueman

[PATCH] DRM: ignore invalid EDID extensions

2010-09-22 Thread Adam Jackson

On Wed, 2010-09-22 at 22:42 +0100, Sam Tygier wrote:
> On 22/09/10 21:59, Adam Jackson wrote:
> > On Tue, 2010-09-21 at 23:02 +0100, Sam Tygier wrote:
> >> Currently an invalid EDID extension will cause the whole EDID to be
> >> considered invalid. Instead just drop the extension, and return the
> >> valid base block. The base block is modified to not claim to have
> >> extensions, and update the checksum.
> >
> > This does not appear to be what your patch does.  I mean, yes, if
> > there's only one extension block, that's what it does, but if there's
> > more than one...
> 
> I could modify it to skip the only invalid extension blocks. As my
> monitor only claims to have 1 extension block, i could not test this
> properly. I also spotted that I should make sure that my fix is not
> run when the base block fails the checksum 4 times. May it should be
> put within the for loop, replacing "goto carp;".

Yeah, I hate to just drop extension blocks, but it's better than the
alternative.  They're optional for a reason I suppose.

> >> For my EIZO S2242W the base block is fine, but the extension block is
> >> all zeros. Without this patch I get no X and no VTs.
> >
> > I suspect what's actually happening there is that we're failing to get
> > the extension block, not that it's being returned as zeros.
> 
> Could this be fixed? Anything I could try?

Depends on what your driver is, I suspect.  Did it ever work?

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100922/d9dd08b5/attachment-0001.pgp>

[2.6.36-rc5] DRM fixes...

Correct function storage class, and correct assignment type.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/drm/drm_buffer.c b/drivers/gpu/drm/drm_buffer.c
index 55d03ed..687de5f 100644
--- a/drivers/gpu/drm/drm_buffer.c
+++ b/drivers/gpu/drm/drm_buffer.c
@@ -98,7 +98,7 @@ EXPORT_SYMBOL(drm_buffer_alloc);
  *   user_data: A pointer the data that is copied to the buffer.
  *   size: The Number of bytes to copy.
  */
-extern int drm_buffer_copy_from_user(struct drm_buffer *buf,
+int drm_buffer_copy_from_user(struct drm_buffer *buf,
 void __user *user_data, int size)
 {
 int nr_pages = size / PAGE_SIZE + 1;
@@ -163,7 +163,7 @@ void *drm_buffer_read_object(struct drm_buffer *buf,
 {
 int idx = drm_buffer_index(buf);
 int page = drm_buffer_page(buf);
-void *obj = 0;
+void *obj = NULL;

 if (idx + objsize <= PAGE_SIZE) {
 obj = >data[page][idx];
-- 
Daniel J Blueman

[2.6.36-rc5] TTM fixes...

Correct allocation flags type and function prototype for ANSI C compliance.

Signed-off-by: Daniel J Blueman 
Reviewed-by: Alex Deucher 

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index ca90479..b1e02ff 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -69,7 +69,7 @@ struct ttm_page_pool {
 spinlock_tlock;
 boolfill_lock;
 struct list_headlist;
-intgfp_flags;
+gfp_tgfp_flags;
 unsignednpages;
 char*name;
 unsigned longnfrees;
@@ -475,7 +475,7 @@ static void
ttm_handle_caching_state_failure(struct list_head *pages,
  * This function is reentrant if caller updates count depending on number of
  * pages returned in pages array.
  */
-static int ttm_alloc_new_pages(struct list_head *pages, int gfp_flags,
+static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
 int ttm_flags, enum ttm_caching_state cstate, unsigned count)
 {
 struct page **caching_array;
@@ -666,7 +666,7 @@ int ttm_get_pages(struct list_head *pages, int flags,
 {
 struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
 struct page *p = NULL;
-int gfp_flags = GFP_USER;
+gfp_t gfp_flags = GFP_USER;
 int r;

 /* set zero flag for page allocation if required */
@@ -818,7 +818,7 @@ int ttm_page_alloc_init(struct ttm_mem_global
*glob, unsigned max_pages)
 return 0;
 }

-void ttm_page_alloc_fini()
+void ttm_page_alloc_fini(void)
 {
 int i;
 --
Daniel J Blueman

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher  
> wrote:
> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls  
> > wrote:
> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
> >>> 2010/9/20 Andy Walls :
> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafa? Mi?ecki wrote:
> >>> >> 2010/9/20 Andy Walls :

> >> The real problem to me is that the radeon and drm modules have a single,
> >> standard way of dealing with EDID errors.  However, EDID errors can
> >> happen due to a number of different causes, some of which are external
> >> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
> >> thing" the drivers can do without input from the user on what the policy
> >> should be when a bad EDID is detected.
> 
> Andy, this sure looks like a broken VBIOS to me.

Well sure.

But that problem causes other problems in error handling code paths to
surface.  It also brings to light that there are some cases that are
undecidable, or not worth the effort, for the error handling code paths
on what the proper action should be.

>  First thing would be
> to update your VBIOS if possible to get a correct table for your
> hardware.

Um, no.

I will not risk taking an operational machine down due to flash write
failure, however small the probability, due to the high impact.
The reward of shutting up kernel error messages, is not worth the risk.

>  Second would be to add a quirk in the kernel.

I have expressed my thoughts on quirks in a previous post.

> There are lots of cases where the kernel does odd things when the BIOS
> feeds it bad information. Do we really want hundreds of switches in
> sysfs allowing adjustments for broken BIOS features?

I see very little downside in giving the user more control over his
system.  A thousand knobs and switches are worth it for the user, for
the one switch that is there when the user needs it to solve a problem.

To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver
to dump the ROM.  That would have consumed a lot of time.  Luckily for
me, there was a switch to turn on the ROM and dump it:

# echo 1 > /sys/class/drm/card0/device/rom
# dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
# echo 0 > /sys/class/drm/card0/device/rom

I never used it before and will likely never use it again.  But when I
had a problem I needed to solve, its availability made the solution
simple and efficient.  Time to accomplish tasks is my scarcest resource;
time efficiency is very important to me.

The only downside to hundreds of switches and control knobs I can really
think of is possibly complexity for the end user.  But it turns out,
that ignoring the available controls, or ignoring large subsets of the
available controls, is how people are going to deal with that
complexity.  Heck, I ignore most of sysfs almost all the time.  I also
ignore almost every module option available.  My system runs fine
without me caring about a majority of the existing switches.

BTW, we already have thousands of switches and controls for kernel
internals in linux without sysfs and ioctl()'s:

$ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} \; | grep '^parm:' 
| wc -l
3387

Why do we have that many?  They are low cost in complexity, as they can
easily be ignored.  They are high value in utility, as they give the
user control over his system to deal with unusual circumstances.

>  We already have
> the quirk scheme for addressing this.
> 
> A simpler solution for reducing the log spam would be to only report
> the error once, instead of every 10 seconds. The driver could remember
> it has made the error report and then log another message later if the
> error was cleared.

My sysfs implementation was only 69 changed lines in one file:

drivers/gpu/drm/drm_sysfs.c |   69 +++

I doubt a solution to add logic to the error paths, to try and divine
all the sources of EDID errors by saving state and applying rules to
take the correct action, is going to be less change than that.  I know
more than one file will have to change.

Regards,
Andy

[PATCH] DRM: ignore invalid EDID extensions

2010-09-22 Thread Adam Jackson

On Tue, 2010-09-21 at 23:02 +0100, Sam Tygier wrote:
> Currently an invalid EDID extension will cause the whole EDID to be
> considered invalid. Instead just drop the extension, and return the
> valid base block. The base block is modified to not claim to have
> extensions, and update the checksum.

This does not appear to be what your patch does.  I mean, yes, if
there's only one extension block, that's what it does, but if there's
more than one...

> For my EIZO S2242W the base block is fine, but the extension block is
> all zeros. Without this patch I get no X and no VTs.

I suspect what's actually happening there is that we're failing to get
the extension block, not that it's being returned as zeros.

Also, we shouldn't be converting "checksum failure" to "display
disconnected".  That's the real bug here.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100922/fdf0bb28/attachment.pgp>

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

On Wed, 2010-09-22 at 08:31 -0400, Andy Walls wrote:
> On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:

> > It appears to be incorrect.  If you send me a copy of the vbios, I can
> > easily add a quirk. I suspect your board oem may offer several boards
> > with different output configurations and neglected to update the table
> > in some configurations.
> 
> Do you have a pointer to a set of steps to follow for extracting that
> vbios information?

Never mind, I figured it out.

# echo 1 > /sys/class/drm/card0/device/rom
# dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
# echo 0 > /sys/class/drm/card0/device/rom

I will send it via private email.

Regards,
Andy

[PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry

On Wed, 2010-09-22 at 08:06 -0700, Greg KH wrote:
> On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
> > +Where: /sys/devices/<...>/drm/cardN/cardN-C-M/polled
> > +   For N a decimal system graphics adapter number: 0, 1, 2, ...
> > +   For C a connector type name (including spaces) from the set:
> 
> Spaces?  Really?  Yeah, I know it will work just fine, but why go out of
> your way to make it hard for people?

Not my fault.
It was like that when I got here.


$ ls -d /sys/devices/pci\:00/\:00\:01.0/\:01\:05.0/drm//card0/card0*
/sys/devices/pci:00/:00:01.0/:01:05.0/drm//card0/card0-DVI-D-1
/sys/devices/pci:00/:00:01.0/:01:05.0/drm//card0/card0-HDMI Type A-1
/sys/devices/pci:00/:00:01.0/:01:05.0/drm//card0/card0-VGA-1

I only added one entry, "polled", in those existing directories.

BTW, Jon Smirl, IBM Corp, and you have Copyright credit in the
drm_sysfs.c file that creates those directories with spaces.  ;)


I'll also gripe that PCI's colons are pretty annoying on the command
line too, since they have to be escaped as well.


> > +   HDMI Type A
> > +   HDMI Type B
> > +   TV
> > +   Embedded DisplayPort
> 
> You could always just use a '_' instead of a space for those that need
> it.

A trivial patch here would do that:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_crtc.c;h=37e0b4fa482a810afc9eded6fda136a90bcc5cc0;hb=refs/heads/drm-fixes#l146

but I have no idea what that might break.

Regards,
Andy

[stable] regression in 2.6.35.4 'load is to heavy (video subsystem?)'

On Wed, 22 Sep 2010 11:42:41 +0200
Karsten Mehrhoff  wrote:

> [Am 22.09.2010, 02:01 Uhr, schrieb Greg KH ]
> 

> >>> Difference between 2.6.35.1/2/3 and 2.6.35.4 while watching some  
> >> videos:
> >>> 2.6.35.4 switches the cpu for flash videos in the browser (opera or
> >>> iceweasel) or other video outputs to 2200/2400/2600 MHz meanwhile  
> >> 2.6.35.3
> >>> (or older) stays at 1000 Mhz. That results in a higher cpu  
> >> temperature,
> >>> more power consumption and so one.
> >>>
> >>> Using other GUI program results in nearly the same problems with  
> >> 2.6.35.4,
> >>> so this kernel is unusable for me.
> >>>
> >>> Results to see the difference for the same action
> >>> 2.6.35.4
> >>> Core0 Temp:  +45.0__C
> >>> Core1 Temp:  +43.0__C
> >>> cpu MHz:  2200.000 or higher
> >>>
> >>> 2.6.35.3
> >>> Core0 Temp:  +32.0__C
> >>> Core1 Temp:  +31.0__C
> >>> cpu MHz:  1000.000 (max. 1800, but falling back to 1000)
> >
> > Can you run 'git bisect' between 2.6.35.3 and 2.6.35.4 to try to find
> > out the offending patch that caused this issue?
> >
> > thanks,
> >
> > greg k-h
> 
> Same for 2.6.35.5 using 256.53
> 
> For your info, I did run some tests today using a nVidia 9500GT
> 
> Kernel   |   Performance with NVIDIA-Linux-x86_64-
>  |   256.53  |260.19.04 (BETA)
> --
>   2.6.35.3   |  good |  good
> --
>   2.6.35.4   |   bad | not tested
> --

What would be tremendously more interesting is if you can
reproduce the issue with the in-kernel nouveau driver or just without
the binary driver. As we have no sourcecode for the binary driver, we
can not tell what it does and are thus unable to debug any issues.

If it is an issue that is not reproducible without the binary driver,
please contact the vendor of that driver. 

It it is reproducible even without that driver, it would help if you
could tell exactly which patch in 2.6.35.4 makes the difference
between good and bad in your test below.

There are 114 patches between 2.6.35.3 and 2.6.35.4. If you test
between them, you can pinpoint the exact patch with about 7 tests. 

git bisect does this for you, just do 

$ git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.35.y.git
$ cd linux-2.6.35.y 
$ git bisect bad v2.6.35.4
$ git bisect good v2.6.35.3

Git then checks out a testcandidate for you, which you should compile
and test. If it's good , type 
$ git bisect good
, if its bad
$ git bisect bad

If all goes well, after about 7 tests, it will tell you
what patch did introduce the regression.

Regards,
Flo

> 
> Karsten

[PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry

2010-09-22 Thread Greg KH

On Wed, Sep 22, 2010 at 12:36:06PM -0400, Andy Walls wrote:
> On Wed, 2010-09-22 at 08:06 -0700, Greg KH wrote:
> > On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
> > > +Where:   /sys/devices/<...>/drm/cardN/cardN-C-M/polled
> > > + For N a decimal system graphics adapter number: 0, 1, 2, ...
> > > + For C a connector type name (including spaces) from the set:
> > 
> > Spaces?  Really?  Yeah, I know it will work just fine, but why go out of
> > your way to make it hard for people?
> 
> Not my fault.
> It was like that when I got here.

Ah, ok, sorry about that, I didn't realize it.  No objection from me
then, thanks for the documentation.

greg k-h

[Bug 29732] r300g + google-earth: no images in pop-up windows (panoramio etc.)

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

--- Comment #3 from zandgreen  2010-09-22 12:21:59 PDT 
---
Created an attachment (id=38887)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38887)
Segfault 11 crash

Must be something different from the primary matter but might give a hint.

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

[Bug 29732] r300g + google-earth: no images in pop-up windows (panoramio etc.)

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

--- Comment #2 from zandgreen  2010-09-22 12:17:11 PDT 
---
Got new results in Xorg.0.log, see attachment.

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

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

[cc'd chris wilson]

Hi Andy!

On Mon, 20 Sep 2010 19:02:30 -0400
Andy Walls  wrote:

> BTW, I found that Chris Wilson recently committed a change to inhibit
> all drm connector polling globally for a different reason:
> 
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
> 
> That commit message shows a case where the driver decides polling needs
> to happen, but the human knows differently and manual control over
> connector polling mitigates the problem.


On Mon, 20 Sep 2010 17:11:48 -0400
Andy Walls  wrote:

> On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
> > On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
>  
> > > This change allows the root user to disable (and re-enable) DRM KMS
> > > connector polling on a per connector basis via sysfs, like so:
> > > 
> > > # cat /sys/class/drm/card0/card0-DVI-D-1/polled
> > > [hotplug_detectable] connect disconnect
> 
> > You are adding a sysfs file, yet you forgot to add a file in
> > Documentation/ABI.  Please fix that and resend the patch.
> 
> Oops, process failure, sorry.
> Will do.
> 
> Regards,
> Andy
> 

I thought sysfs files should be one thing per file... so, maybe
card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1
content would be easier to manipulate and parse? 

I have to defer to the drm maintainers for the usecases. But how is
having a monitor with a broken edid handled right now? While the output
is connected and used, it probably just stops polling?

cheers,
Flo

regression in 2.6.35.4 'load is to heavy (video subsystem?)'

2010-09-22 Thread Dave Airlie

On Tue, 2010-09-21 at 16:50 -0700, Andrew Morton wrote:
> On Mon, 30 Aug 2010 10:02:36 +0200
> Karsten Mehrhoff  wrote:
> 
> > Using the same .config from 2.6.35.3 to compile 2.5.36.4 results in a  
> > heavy load with 2.6.35.4.
> 
> A regression within -stable is rather bad.
> 
> > Example:
> > 
> > Difference between 2.6.35.1/2/3 and 2.6.35.4 while watching some videos:
> > 2.6.35.4 switches the cpu for flash videos in the browser (opera or  
> > iceweasel) or other video outputs to 2200/2400/2600 MHz meanwhile 2.6.35.3  
> > (or older) stays at 1000 Mhz. That results in a higher cpu temperature,  
> > more power consumption and so one.
> > 
> > Using other GUI program results in nearly the same problems with 2.6.35.4,  
> > so this kernel is unusable for me.
> > 
> > Results to see the difference for the same action
> > 2.6.35.4
> > Core0 Temp:  +45.0__C
> > Core1 Temp:  +43.0__C
> > cpu MHz:2200.000 or higher
> > 
> > 2.6.35.3
> > Core0 Temp:  +32.0__C
> > Core1 Temp:  +31.0__C
> > cpu MHz:1000.000 (max. 1800, but falling back to 1000)
> > 
> > kernel compiled with 'CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y'
> > results for me in 1000, 1800, 2000, 2200, 2400, 2600 MHz.
> > 
> > I'm not the only one with this problem, other users experienced the same  
> > behavior on other systems on 386 systems, i.e. a regression for glxgears  
> > about 30% on slower systems. We all uses differnet AMD cpus and nNida  
> > graphic controllers. Same results for the nvidia-kernel from the repos or  
> > the nVidia driver from nvidia.com.
> > 
> > There must something be wrong in the video subsystem, which is causing  
> > this regression.
> > 
> > My system (overview using 2.5.35.3):
> > =
> > Processor:  2x AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
> > Memory:  4060MB
> > 
> > Display
> > Resolution:   1920x1080 pixels
> > OpenGL Renderer:  GeForce 9500 GT/PCI/SSE2
> > X11 Vendor:   The X.Org Foundation
> > Version:  1.7.7
> > 
> > Version
> > Kernel: Linux 2.6.35.3-kmt (x86_64)
> > Compiled:   SMP Mon Aug 23 00:58:37 CEST 2010
> > C Library:  GNU C Library version 2.11.2 (stable)
> > Default C Compiler: GNU C Compiler version 4.4.5 20100824 (prerelease)  
> > (Debian 4.4.4-11)
> > Distribution:   Debian GNU/Linux squeeze/sid
> > 
> > OpenGL
> > Vendor:NVIDIA Corporation
> > Renderer:  GeForce 9500 GT/PCI/SSE2
> > Version:   3.3.0 NVIDIA 256.44
> > Direct Rendering: Yes
> 
> I'm not seeing any relevant cpufreq changes in 2.6.35.3 -> 2.6.35.4
> (ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35.4).  There
> were a lot of DRM changes.

No us, he's using a binary driver.

Dave.

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

2010-09-22 Thread Jon Smirl

On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher  wrote:
> On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls  
> wrote:
>> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>>> 2010/9/20 Andy Walls :
>>> > On Mon, 2010-09-20 at 20:29 +0200, Rafa? Mi?ecki wrote:
>>> >> 2010/9/20 Andy Walls :
>>> >> > DRM KMS polling of connections providing errant EDID responses, or
>>> >> > polling of "connectors" that have chips responding on DDC I2C bus
>>> >> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
>>> >> > will create perpetual noise in dmesg and the system log every 10
>>> >> > seconds. ?Currently the user has apparently little recourse to silence
>>> >> > these messages aside from replacing the offending cable, monitor, or
>>> >> > graphics adapter. ?That recourse is impossible for an unused DVI-D
>>> >> > "connector" of an internal graphics processor on a motherboard that
>>> >> > provides no physical DVI-D connector.
>>> >> >
>>> >> > This change allows the root user to disable (and re-enable) DRM KMS
>>> >> > connector polling on a per connector basis via sysfs, like so:
>>> >>
>>> >> Huh, I didn't imagine solution of this issue that way.
>>> >
>>> > The problems with my initial patch, and related approaches, were:
>>> >
>>> > 1. They didn't get rid of all the spam in the logs, just the most
>>> > verbose portion of it.
>>> >
>>> > 2. They didn't deal with the root cause of the log spam and all the
>>> > related, but unneeded, I/O and processing that was still occurring.
>>> >
>>> >
>>> >
>>> >> ?AFAIR previous
>>> >> thread, something else was suggested, it was about storing the fact
>>> >> that user already received warning/info about error.
>>> >
>>> > Yes, that was the discussion.
>>> >
>>> > I went with this patch because:
>>> >
>>> > 1. It deals with the root cause: unneeded DRM KMS connector polling
>>> >
>>> > 2. It eliminates all my DRM KMS connector polling related log spam, not
>>> > just the hex dump.
>>> >
>>> > 3. The existing sysfs structure was already exposing 'struct
>>> > drm_connector' members to user-space at per connector granularity
>>> >
>>> >
>>> > The real root cause of the polling spew is that the radeon module, based
>>> > on the best information it has (BIOS connector tables, I2C bus probes,
>>> > etc.), makes a decision on if a connector should be polled and how it
>>> > should be polled.
>>> >
>>> > Given incorrect BIOS tables, and strange I2C setups, the radeon module
>>> > is bound to make the wrong decision about polling in some cases. ?This
>>> > change is a way for the human to step in a correct things, when the
>>> > radeon driver gets it wrong.
>>> >
>>>
>>> I'd rather fix the bug for real rather than providing users with an
>>> out so that the bug never gets reported.
>>
>> There is already "an out" on it's way upstream:
>>
>> http://lkml.org/lkml/2010/9/6/375
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
>>
>> I noticed it after I submitted this patch. ?If I'm reading it right, the
>> module parameter fix is very coarse: it applies to all drm adapters and
>> connectors in the system.
>>
>>> ? What's the actual problem
>>> you have?
>>
>> The actual problem I have is that the radeon driver reports three
>> connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only
>> one physical connector (VGA). ?Polling of the HDMI appears to be
>> inhibited by the radeon module code. ?Polling of the (non-existent?)
>> DVI-D interface yields a lot of log messages and useless I2C
>> transactions.
>>
>> My precise gripe is with this code path
>>
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_connectors.c;h=ecc1a8fafbfd3eb3c12c0c4d45b4b091a1bee03b;hb=refs/heads/drm-fixes#l772
>>
>> which is being polled every 10 seconds. ?It is bad for me because this
>> function is noisy:
>>
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l136
>>
>> and this (insane?) loop multiplies the noise by a factor of 4:
>>
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l264
>>
>>
>> In a different user's operational context, all that noise may be
>> beneficial.
>>
>>
>> The real problem to me is that the radeon and drm modules have a single,
>> standard way of dealing with EDID errors. ?However, EDID errors can
>> happen due to a number of different causes, some of which are external
>> (i.e. in the LCD or CRT monitor). ?Given that, there really is no "right
>> thing" the drivers can do without input from the user on what the policy
>> should be when a bad EDID is detected.

Andy, this sure looks like a broken VBIOS to me. First thing would be
to update your VBIOS if possible to get a correct table for your

[Bug 30329] [r600c/evergreen] KWin Present Windows effect extremely slow and has graphical glitches

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

--- Comment #3 from Jure Repinc  2010-09-22 09:27:02 PDT 
---
Created an attachment (id=38882)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38882)
lspci

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

[Bug 30329] [r600c/evergreen] KWin Present Windows effect extremely slow and has graphical glitches

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

--- Comment #2 from Jure Repinc  2010-09-22 09:19:23 PDT 
---
Created an attachment (id=38881)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38881)
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.

[Bug 30329] [r600c/evergreen] KWin Present Windows effect extremely slow and has graphical glitches

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

--- Comment #1 from Jure Repinc  2010-09-22 09:18:16 PDT 
---
Created an attachment (id=38880)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38880)
dmesg

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

[Bug 30329] New: [r600c/evergreen] KWin Present Windows effect extremely slow and has graphical glitches

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

   Summary: [r600c/evergreen] KWin Present Windows effect
extremely slow and has graphical glitches
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: jlp.bugs at gmail.com


I've just tried the opensource Mesa driver on this eMachines E640G laptop with
integrated ATI Mobility Radeon HD 5470. I'm using Linux kernel 2.6.36 RC5. The
problem is, that desktop effects in KDE Kwin 4.5.1 work quite OK (a bit slow)
but one effect is extremely slow: the Present Windows onw. When I trigger it,
it takes about two minutes until all open windows on the current desktop are
shrinked so they are simulatinusly shown. This was with only two Konqueror
windows open. After the windows were shrinked there was also a problem that
they had a lot of red dots all over them.

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

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

On Wed, 2010-09-22 at 11:44 +0200, Florian Mickler wrote:
> [cc'd chris wilson]

Oops.  Thanks!

> Hi Andy!
> 
> On Mon, 20 Sep 2010 19:02:30 -0400
> Andy Walls  wrote:
> 
> > BTW, I found that Chris Wilson recently committed a change to inhibit
> > all drm connector polling globally for a different reason:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
> > 
> > That commit message shows a case where the driver decides polling needs
> > to happen, but the human knows differently and manual control over
> > connector polling mitigates the problem.
> 
> 
> On Mon, 20 Sep 2010 17:11:48 -0400
> Andy Walls  wrote:
> 
> > On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
> > > On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
> >  
> > > > This change allows the root user to disable (and re-enable) DRM KMS
> > > > connector polling on a per connector basis via sysfs, like so:
> > > > 
> > > > # cat /sys/class/drm/card0/card0-DVI-D-1/polled
> > > > [hotplug_detectable] connect disconnect
> > 
> > > You are adding a sysfs file, yet you forgot to add a file in
> > > Documentation/ABI.  Please fix that and resend the patch.
> > 
> > Oops, process failure, sorry.
> > Will do.
> > 
> > Regards,
> > Andy
> > 
> 
> I thought sysfs files should be one thing per file... so, maybe
> card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1
> content would be easier to manipulate and parse? 

If precedent matters, the sysfs nodes for setting

the IO scheduler
the active trigger function on an LED
the active IR remote control protocols

all use the same sort of paradigm as I did.

The IO scheduler and LED trigger ones allow the user to set 1 of N
choices.  The IR protocol one allows the user to set M of N choices.
They all uses brackets to differentiate [set] vs unset.

> I have to defer to the drm maintainers for the usecases. But how is
> having a monitor with a broken edid handled right now? While the output
> is connected and used, it probably just stops polling?

Not from what I can see.  I could very well be wrong on that, so please
someone double check me.

This error message sequence, and from what I saw in the code, indicates
to me that the gripe for a constantly bad EDID will never end:

Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon :01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed 
a monitor but no|invalid EDID
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon :01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed 
a monitor but no|invalid EDID

This time around we 

"probed a monitor but no|invalid EDID"

so lets do it again later, and maybe we'll get a different result.

That's legitimate to do once or twice because of transient conditions:
one may get a bad EDID due to monitor power on/off or cable
connect/disconnect.

To keep doing it for persistent error conditions, when the user fully
understands the source of the error and has assessed the impact as
inconsequential, is annoying.

By now, I guess everyone can tell at least I'm annoyed by it. :) 

Regards,
Andy

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:
> On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls  
> wrote:

> > In a larger sense it's about user policy for error reporting by the drm
> > and radeon drivers, and error response by both the drivers and the user.
> >
> > In the face of EDID errors, a user may want to take the following
> > actions:
> >
> >ignore the errors
> >supress the errors
> >continue to monitor the errors for a time
> >replace cables
> >replace graphics adapter
> >replace monitor
> >report a bug
> >
> > All of those end user actions are possible right now, except the one to
> > supress the errors (and the I2C transactions associated with them).
> >
> > A monitor, cable, and graphics adapter set that is currently
> > experiencing EDID errors, may be otherwise working just fine.
> >
> > "Because we want to ensure people report bugs," does not seem like a
> > good reason to prevent a user from turning off bogus error messages, for
> > an otherwise working monitor that is providing broken EDID data.  What
> > is the resolution of a bug report for a monitor providing bad EDID data
> > going to look like?
> 
> I wasn't talking about the broken EDID messages, I was talking about
> the bogus connector table entries on your board.  Those should be
> properly quirked in the driver in which case, which would avoid the
> problem all together in your case.

The problem with in-kernel quirk databases are

- you'll always end up lagging behind what's being fielded,

- the number of stale entries will grow over the years,

- the scope of the fix for a single quirk entry for the total installed
user base is small; each quirk table entry itself has little value

- quirks for working around unreliable attributes still need a 
reliable system identification method (no big deal for PCI)

- fixing by quirk is a reactionary mode for kernel developers
(it's also job security, so sysadmins are stuck coming back for
 help)

- it increases time to resolve problems for end users.

I don't think it's a good to plan to continually react to manufacturers
that have cycle times of 6 months to a year.  Quirk tables should be a
solution of last resort, when there's nothing else that can be done,
IMO.  


I understood.  A quirk database solves the immediate problem for me and
for owners of that MSI motherboard.

My current problem also highlights undesirable behavior that will occur
with broken EDIDs.  This undesirable behavior will likely resurface in
another bug report.


> >>  or does the board have a bug in the connector table?
> >
> > I have not dug into the BIOS connector table bits and bytes to verify,
> > but I'm assuming the connector table is incorrect.
> >
> 
> It appears to be incorrect.  If you send me a copy of the vbios, I can
> easily add a quirk. I suspect your board oem may offer several boards
> with different output configurations and neglected to update the table
> in some configurations.

Do you have a pointer to a set of steps to follow for extracting that
vbios information?




> >>   What
> >> physical connectors does the board have what does the driver report in
> >> dmesg?
> >
> > The board only has a physical VGA connector.  The graphics adapter is an
> > IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302).  Here are the
> > PCI IDs on the graphics adapter:
> >
> > 01:05.0 VGA compatible controller [0300]:
> >ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA 
> > controller])
> >Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
> >
> >
> > Below is the dmesg output from the unmodified drm and radeon modules
> > which includes samples of drm module log spam for the first 30 seconds
> > or so after boot.

> > [drm] Radeon Display Connectors
> > [drm] Connector 0:
> > [drm]   VGA
> > [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
> > [drm]   Encoders:
> > [drm] CRT1: INTERNAL_KLDSCP_DAC1
> > [drm] Connector 1:
> > [drm]   DVI-D
> > [drm]   HPD2
> > [drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
> > [drm]   Encoders:
> > [drm] DFP2: INTERNAL_DDI
> > [drm] Connector 2:
> > [drm]   HDMI-A
> > [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
> > [drm]   Encoders:
> > [drm] DFP3: INTERNAL_LVTM1
> 
> FWIW, it's actually the HDMI connector that is generating the errors
> due to the lack of a hpd pin assignment.

Are you sure?  My /var/log/messages spam insists it is DVI-D-1 (hex
dumps omitted):

Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon :01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel:

[PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry

2010-09-22 Thread Greg KH

On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
> +Where:   /sys/devices/<...>/drm/cardN/cardN-C-M/polled
> + For N a decimal system graphics adapter number: 0, 1, 2, ...
> + For C a connector type name (including spaces) from the set:

Spaces?  Really?  Yeah, I know it will work just fine, but why go out of
your way to make it hard for people?

> + Unknown
> + VGA
> + DVI-I
> + DVI-D
> + DVI-A
> + Composite
> + SVIDEO
> + LVDS
> + Component
> + 9-pin DIN
> + DisplayPort
> + HDMI Type A
> + HDMI Type B
> + TV
> + Embedded DisplayPort

You could always just use a '_' instead of a space for those that need
it.

thanks,

greg k-h

[Bug 30325] New: video=1280x720@50 no longer works

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

   Summary: video=1280x720 at 50 no longer works
   Product: DRI
   Version: DRI CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: marius.groeger at web.de


With the current drm-radeon-testing my grub cmdline option video=1280x720 at 50 
no
longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is
enabled, but the TV doen't get a displayable picture anymore. Booting with
d-r-t from 6 weeks ago works and correctly uses the EDID reported 1280x720 at 50
mode.

I did ask the same thing on the dri-devel mailing list and received no answer
so I'm filing this bug both as another humble nudge to the authors of the drm
video= code, and as a more persistent reminder of the issue.

Thanks
Marius

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

[PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

2010-09-22 Thread Alex Deucher

On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls  wrote:
> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> 2010/9/20 Andy Walls :
>> > On Mon, 2010-09-20 at 20:29 +0200, Rafa? Mi?ecki wrote:
>> >> 2010/9/20 Andy Walls :
>> >> > DRM KMS polling of connections providing errant EDID responses, or
>> >> > polling of "connectors" that have chips responding on DDC I2C bus
>> >> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
>> >> > will create perpetual noise in dmesg and the system log every 10
>> >> > seconds. ?Currently the user has apparently little recourse to silence
>> >> > these messages aside from replacing the offending cable, monitor, or
>> >> > graphics adapter. ?That recourse is impossible for an unused DVI-D
>> >> > "connector" of an internal graphics processor on a motherboard that
>> >> > provides no physical DVI-D connector.
>> >> >
>> >> > This change allows the root user to disable (and re-enable) DRM KMS
>> >> > connector polling on a per connector basis via sysfs, like so:
>> >>
>> >> Huh, I didn't imagine solution of this issue that way.
>> >
>> > The problems with my initial patch, and related approaches, were:
>> >
>> > 1. They didn't get rid of all the spam in the logs, just the most
>> > verbose portion of it.
>> >
>> > 2. They didn't deal with the root cause of the log spam and all the
>> > related, but unneeded, I/O and processing that was still occurring.
>> >
>> >
>> >
>> >> ?AFAIR previous
>> >> thread, something else was suggested, it was about storing the fact
>> >> that user already received warning/info about error.
>> >
>> > Yes, that was the discussion.
>> >
>> > I went with this patch because:
>> >
>> > 1. It deals with the root cause: unneeded DRM KMS connector polling
>> >
>> > 2. It eliminates all my DRM KMS connector polling related log spam, not
>> > just the hex dump.
>> >
>> > 3. The existing sysfs structure was already exposing 'struct
>> > drm_connector' members to user-space at per connector granularity
>> >
>> >
>> > The real root cause of the polling spew is that the radeon module, based
>> > on the best information it has (BIOS connector tables, I2C bus probes,
>> > etc.), makes a decision on if a connector should be polled and how it
>> > should be polled.
>> >
>> > Given incorrect BIOS tables, and strange I2C setups, the radeon module
>> > is bound to make the wrong decision about polling in some cases. ?This
>> > change is a way for the human to step in a correct things, when the
>> > radeon driver gets it wrong.
>> >
>>
>> I'd rather fix the bug for real rather than providing users with an
>> out so that the bug never gets reported.
>
> There is already "an out" on it's way upstream:
>
> http://lkml.org/lkml/2010/9/6/375
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
>
> I noticed it after I submitted this patch. ?If I'm reading it right, the
> module parameter fix is very coarse: it applies to all drm adapters and
> connectors in the system.
>
>> ? What's the actual problem
>> you have?
>
> The actual problem I have is that the radeon driver reports three
> connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only
> one physical connector (VGA). ?Polling of the HDMI appears to be
> inhibited by the radeon module code. ?Polling of the (non-existent?)
> DVI-D interface yields a lot of log messages and useless I2C
> transactions.
>
> My precise gripe is with this code path
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_connectors.c;h=ecc1a8fafbfd3eb3c12c0c4d45b4b091a1bee03b;hb=refs/heads/drm-fixes#l772
>
> which is being polled every 10 seconds. ?It is bad for me because this
> function is noisy:
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l136
>
> and this (insane?) loop multiplies the noise by a factor of 4:
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l264
>
>
> In a different user's operational context, all that noise may be
> beneficial.
>
>
> The real problem to me is that the radeon and drm modules have a single,
> standard way of dealing with EDID errors. ?However, EDID errors can
> happen due to a number of different causes, some of which are external
> (i.e. in the LCD or CRT monitor). ?Given that, there really is no "right
> thing" the drivers can do without input from the user on what the policy
> should be when a bad EDID is detected.
>
>
>
>
>> ? Do you just want to turn polling off for an unused
>> connecter,
>
> Yes, that's what I would use my proposed patch for.
>
> (If a solution that avoids sysfs is required, I can work up a patch
> using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with
> a patch for some

[PATCH] drm/radeon/kms: don't enable underscan with interlaced modes

2010-09-22 Thread Alex Deucher

2010/9/21 Marius Gr?ger :
> On 10.09.2010 17:20 Alex Deucher wrote:
>>
>> The scaler doesn't appear to work with interlaced modes as you've
>> noticed; I don't off hand know whether it can be made to or not.
>> Unfortunately, I won't have time to dig into this more for a while.
>
> Is there public documentation available wrt this matter? www.x.org/docs/AMD/
> appears to focus on 3D stuff primarily...
>

Not at the moment, however, you could implement underscan using the 3D
engine to do the scaling rather than the display scalers.  I think you
could even do it with randr crtc transforms (which use the 3d engine).

Alex

> Regards,
> Marius
>

[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed

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

--- Comment #9 from Gustavo Guillermo Perez  2010-09-22 
00:34:55 PDT ---
> If someone wants to test this, please do so ! If you find bugs, send me a mail
> with reproduction scenario (and gdb backtrace if you can), thanks. Especially
> if you can crash it with something smaller than KDE ! ;)
Hello, Best regards in advance, I'm trying to get it to work too on kde, got
the error of this bug, grab your patch and now there is another error:
/usr/bin/X: symbol lookup error: /usr/lib/dri/unichrome_dri.so: undefined
symbol: _mesa_free

tuxi686 ~ # startx
xauth:  creating new authority file /root/.serverauth.3805


X.Org X Server 1.9.0
Release Date: 2010-08-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-gentoo-tux i686 Gentoo
Current Operating System: Linux tuxi686 2.6.35.4-smp #1 SMP Mon Sep 13 16:37:28
CDT 2010 i686
Kernel command line: root=0805 vga=0x317 splash=silent mtrr:1 driversonly pause
Build Date: 13 September 2010  10:18:31PM

Current version of pixman: 0.18.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Sep 21 23:51:52 2010
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Fulfilled via DRI at 20976640
Freed 20976640 (pool 2)
which: no keychain in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.4:/usr/lib/subversion/bin)
/etc/X11/xinit/xinitrc: l?nea 59: xclock: no se encontr? la orden
/usr/bin/X: symbol lookup error: /usr/lib/dri/unichrome_dri.so: undefined
symbol: _mesa_free
login:  fatal IO error 11 (Recurso no disponible temporalmente) or KillClient
on X server ":0.0"
xterm:  fatal IO error 11 (Recurso no disponible temporalmente) or KillClient
on X server ":0.0"
xterm:  fatal IO error 104 (Conexi?n reinicializada por la m?quina remota) or
KillClient on X server ":0.0"
xinit:  connection to X server lost.
tuxi686 ~ #

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

[PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry

This is the initial addition of documentation for the drm module's sysfs
entries.  It provides a drm sysfs entries overview, and a detailed
description of the new drm per output connector "polled" entry in sysfs.

Signed-of-by: Andy Walls 

diff --git a/Documentation/ABI/testing/sysfs-drm 
b/Documentation/ABI/testing/sysfs-drm
new file mode 100644
index 000..18a017a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-drm
@@ -0,0 +1,208 @@
+Direct Rendering Infrastructure (DRI) Direct Rendering Manager (drm) module
+and Translation Table Manager (ttm) module sysfs entries
+
+Example class view showing a single graphics adapter with three output
+connectors, a special control device node for the graphics adapter, and the
+Translation Table Manager (ttm) graphics memory manager virtual device:
+
+/sys/class/drm/
+??? card0   -> ../../devices/<...>/drm/card0
+??? card0-DVI-D-1   -> ../../devices/<...>/drm/card0/card0-DVI-D-1
+??? card0-HDMI Type A-1 -> ../../devices/<...>/drm/card0/card0-HDMI Type 
A-1
+??? card0-VGA-1 -> ../../devices/<...>/drm/card0/card0-VGA-1
+??? controlD64  -> ../../devices/<...>/drm/controlD64
+??? ttm -> ../../devices/virtual/drm/ttm
+??? version
+
+6 directories, 1 file
+
+
+Corresponding DRI device nodes for the example graphics adapter, with
+additional ACL properties on card0 granting rw perms to the X/console user:
+
+crw-rw+ 1 root video 226,  0 2010-09-21 20:52 /dev/dri/card0
+crw-rw-rw-. 1 root video 226, 64 2010-09-21 20:51 /dev/dri/controlD64
+
+
+Example physical device view for a single graphics adapter with three output
+connectors and a special control device node for the graphics adapter:
+
+/sys/devices/<...>/drm
+??? card0
+?   ??? card0-DVI-D-1
+?   ?   ??? device -> ../../card0
+?   ?   ??? dpms
+?   ?   ??? edid
+?   ?   ??? enabled
+?   ?   ??? modes
+?   ?   ??? polled
+?   ?   ??? power
+?   ?   ?   ??? control
+?   ?   ?   ??? runtime_active_time
+?   ?   ?   ??? runtime_status
+?   ?   ?   ??? runtime_suspended_time
+?   ?   ?   ??? wakeup
+?   ?   ?   ??? wakeup_count
+?   ?   ??? status
+?   ?   ??? subsystem -> ../../../../../../../class/drm
+?   ?   ??? uevent
+?   ??? card0-HDMI Type A-1
+?   ?   ??? device -> ../../card0
+?   ?   ??? dpms
+?   ?   ??? edid
+?   ?   ??? enabled
+?   ?   ??? modes
+?   ?   ??? polled
+?   ?   ??? power
+?   ?   ?   ??? control
+?   ?   ?   ??? runtime_active_time
+?   ?   ?   ??? runtime_status
+?   ?   ?   ??? runtime_suspended_time
+?   ?   ?   ??? wakeup
+?   ?   ?   ??? wakeup_count
+?   ?   ??? status
+?   ?   ??? subsystem -> ../../../../../../../class/drm
+?   ?   ??? uevent
+?   ??? card0-VGA-1
+?   ?   ??? device -> ../../card0
+?   ?   ??? dpms
+?   ?   ??? edid
+?   ?   ??? enabled
+?   ?   ??? modes
+?   ?   ??? polled
+?   ?   ??? power
+?   ?   ?   ??? control
+?   ?   ?   ??? runtime_active_time
+?   ?   ?   ??? runtime_status
+?   ?   ?   ??? runtime_suspended_time
+?   ?   ?   ??? wakeup
+?   ?   ?   ??? wakeup_count
+?   ?   ??? status
+?   ?   ??? subsystem -> ../../../../../../../class/drm
+?   ?   ??? uevent
+?   ??? dev
+?   ??? device -> ../../../:01:05.0
+?   ??? power
+?   ?   ??? control
+?   ?   ??? runtime_active_time
+?   ?   ??? runtime_status
+?   ?   ??? runtime_suspended_time
+?   ?   ??? wakeup
+?   ?   ??? wakeup_count
+?   ??? subsystem -> ../../../../../../class/drm
+?   ??? uevent
+??? controlD64
+??? dev
+??? device -> ../../../:01:05.0
+??? power
+?   ??? control
+?   ??? runtime_active_time
+?   ??? runtime_status
+?   ??? runtime_suspended_time
+?   ??? wakeup
+?   ??? wakeup_count
+??? subsystem -> ../../../../../../class/drm
+??? uevent
+
+20 directories, 55 files
+
+
+Example virtual device view view showing the Translation Table Manager (ttm)
+graphics memory manager virtual device:
+
+/sys/devices/virtual/drm
+??? ttm
+??? buffer_objects
+?   ??? bo_count
+??? memory_accounting
+?   ??? kernel
+?   ?   ??? available_memory
+?   ?   ??? emergency_memory
+?   ?   ??? swap_limit
+?   ?   ??? used_memory
+?   ?   ??? zone_memory
+?   ??? pool
+?   ??? pool_allocation_size
+?   ??? pool_max_size
+?   ??? pool_small_allocation
+??? power
+?   ??? control
+?   ??? runtime_active_time
+?   ??? runtime_status
+?   ??? runtime_suspended_time
+?   ??? wakeup
+?   ??? wakeup_count
+??? subsystem -> ../../../../class/drm
+??? uevent
+
+7

[PATCH v2 1/2] drm/sysfs: Provide per connector control of DRM KMS polling

DRM KMS polling of connections providing errant EDID responses, or
polling of "connectors" that have chips responding on DDC I2C bus
address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
will create perpetual noise in dmesg and the system log every 10
seconds.  Currently the user has apparently little recourse to silence
these messages aside from replacing the offending cable, monitor, or
graphics adapter.  That recourse is impossible for an unused DVI-D
"connector" of an internal graphics processor on a motherboard that
provides no physical DVI-D connector.

This change allows the root user to disable (and re-enable) DRM KMS
connector polling on a per connector basis via sysfs, like so:

# cat /sys/class/drm/card0/card0-DVI-D-1/polled
[hotplug_detectable] connect disconnect

# echo > /sys/class/drm/card0/card0-DVI-D-1/polled
# cat /sys/class/drm/card0/card0-DVI-D-1/polled
hotplug_detectable connect disconnect

# echo " connect  hotplug_detectable " > \
/sys/class/drm/card0/card0-DVI-D-1/polled
# cat /sys/class/drm/card0/card0-DVI-D-1/polled
[hotplug_detectable] [connect] disconnect

# echo > /sys/class/drm/card0/card0-DVI-D-1/polled
# cat /sys/class/drm/card0/card0-DVI-D-1/polled
hotplug_detectable connect disconnect

with the enabled poll types for the connector denoted in brackets: [].
This allows the root user to silence DRM KMS log spam for locally known
uncorrectable conditions.

Signed-off-by Andy Walls 

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 86118a7..8e0807d 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -318,11 +318,80 @@ static ssize_t select_subconnector_show(struct device 
*device,
drm_get_dvi_i_select_name((int)subconnector));
 }

+static const struct {
+   uint8_t mask;
+   const char *name;
+} polled_bit_names[] = {
+   { DRM_CONNECTOR_POLL_HPD,"hotplug_detectable" },
+   { DRM_CONNECTOR_POLL_CONNECT,"connect"},
+   { DRM_CONNECTOR_POLL_DISCONNECT, "disconnect" },
+};
+
+/*
+ * Return the decoded contents of connector->polled, using the names of the
+ * all the bit masks.  Bits that are set, have their names enclosed in 
brackets.
+ */
+static ssize_t polled_show(struct device *dev, struct device_attribute *attr,
+  char *buf)
+{
+   struct drm_connector *connector = to_drm_connector(dev);
+   char *tmp;
+   int i;
+
+   tmp = buf;
+   for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) {
+   if (connector->polled & polled_bit_names[i].mask)
+   tmp += sprintf(tmp, "[%s] ", polled_bit_names[i].name);
+   else
+   tmp += sprintf(tmp, "%s ", polled_bit_names[i].name);
+   }
+
+   if (tmp != buf)
+   *(tmp - 1) = '\n';
+   return tmp - buf;
+}
+
+/*
+ * Change the state of connector->polled, given input bit-mask name-strings
+ * that are separated by space or newline.
+ */
+static ssize_t polled_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct drm_connector *connector = to_drm_connector(dev);
+   const char *tmp;
+   int i;
+   uint8_t polled;
+
+   /* Polling of this connector will cease, if no match is made below */
+   polled = 0;
+
+   /* Incrementally split and parse the input */
+   while ((tmp = strsep((char **) , " \n")) != NULL) {
+
+   /* Don't waste effort on multiple adjacent separators */
+   if (*tmp == '\0')
+   continue;
+
+   /* Check for a match with a connector poll type name */
+   for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) {
+   if (!strncasecmp(tmp, polled_bit_names[i].name,
+strlen(polled_bit_names[i].name))) {
+   polled |= polled_bit_names[i].mask;
+   break;
+   }
+   }
+   }
+   connector->polled = polled;
+   return count;
+}
+
 static struct device_attribute connector_attrs[] = {
__ATTR_RO(status),
__ATTR_RO(enabled),
__ATTR_RO(dpms),
__ATTR_RO(modes),
+   __ATTR(polled, 0644, polled_show, polled_store),
 };

 /* These attributes are for both DVI-I connectors and all types of tv-out. */

[PATCH v2 0/2] drm/sysfs: Provide per connector control of DRM KMS polling

Per Greg's request, here is a resend of my previous patch to add sysfs
entries to allow manual override of DRM KMS connector polling actions,
with accompanying documentation.

Only documentation has been added.
No code has changed from the previous patch submission.

diffstat:

Documentation/ABI/testing/sysfs-drm |  208 
 drivers/gpu/drm/drm_sysfs.c |   69 +++
 2 files changed, 277 insertions(+)

Regards,
Andy

[PATCH] DRM: ignore invalid EDID extensions

2010-09-22 Thread Sam Tygier

Currently an invalid EDID extension will cause the whole EDID to be considered 
invalid. Instead just drop the extension, and return the valid base block. The 
base block is modified to not claim to have extensions, and update the checksum.

For my EIZO S2242W the base block is fine, but the extension block is all 
zeros. Without this patch I get no X and no VTs.

Signed-off-by: Sam Tygier 
---
  drivers/gpu/drm/drm_edid.c |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f87bf10..5ade343 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -285,6 +285,15 @@ carp:
dev_warn(connector->dev->dev, "%s: EDID block %d invalid.\n",
 drm_get_connector_name(connector), j);

+   /* Invalid extension, so set block[0x7e] to zero, and return
+* the base block */
+   block[EDID_LENGTH-1] += block[0x7e];
+   block[0x7e] = 0;
+   new = krealloc(block, EDID_LENGTH, GFP_KERNEL);
+   if (!new)
+   goto out;
+   block = new;
+   return block;
  out:
kfree(block);
return NULL;
-- 
1.7.1

[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb-Magic == 0xaabbccdd' failed

2010-09-22 Thread bugzilla-daemon

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

--- Comment #9 from Gustavo Guillermo Perez mad...@gmail.com 2010-09-22 
00:34:55 PDT ---
 If someone wants to test this, please do so ! If you find bugs, send me a mail
 with reproduction scenario (and gdb backtrace if you can), thanks. Especially
 if you can crash it with something smaller than KDE ! ;)
Hello, Best regards in advance, I'm trying to get it to work too on kde, got
the error of this bug, grab your patch and now there is another error:
/usr/bin/X: symbol lookup error: /usr/lib/dri/unichrome_dri.so: undefined
symbol: _mesa_free

tuxi686 ~ # startx
xauth:  creating new authority file /root/.serverauth.3805


X.Org X Server 1.9.0
Release Date: 2010-08-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-gentoo-tux i686 Gentoo
Current Operating System: Linux tuxi686 2.6.35.4-smp #1 SMP Mon Sep 13 16:37:28
CDT 2010 i686
Kernel command line: root=0805 vga=0x317 splash=silent mtrr:1 driversonly pause
Build Date: 13 September 2010  10:18:31PM

Current version of pixman: 0.18.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Tue Sep 21 23:51:52 2010
(==) Using config file: /etc/X11/xorg.conf
(==) Using system config directory /usr/share/X11/xorg.conf.d
Fulfilled via DRI at 20976640
Freed 20976640 (pool 2)
which: no keychain in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.4:/usr/lib/subversion/bin)
/etc/X11/xinit/xinitrc: línea 59: xclock: no se encontró la orden
/usr/bin/X: symbol lookup error: /usr/lib/dri/unichrome_dri.so: undefined
symbol: _mesa_free
login:  fatal IO error 11 (Recurso no disponible temporalmente) or KillClient
on X server :0.0
xterm:  fatal IO error 11 (Recurso no disponible temporalmente) or KillClient
on X server :0.0
xterm:  fatal IO error 104 (Conexión reinicializada por la máquina remota) or
KillClient on X server :0.0
xinit:  connection to X server lost.
tuxi686 ~ #

-- 
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 30325] New: video=1280x...@50 no longer works

2010-09-22 Thread bugzilla-daemon

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

   Summary: video=1280x...@50 no longer works
   Product: DRI
   Version: DRI 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: marius.groe...@web.de


With the current drm-radeon-testing my grub cmdline option video=1280x...@50 no
longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is
enabled, but the TV doen't get a displayable picture anymore. Booting with
d-r-t from 6 weeks ago works and correctly uses the EDID reported 1280x...@50
mode.

I did ask the same thing on the dri-devel mailing list and received no answer
so I'm filing this bug both as another humble nudge to the authors of the drm
video= code, and as a more persistent reminder of the issue.

Thanks
Marius

-- 
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/sysfs: Provide per connector control of DRM KMS polling

[cc'd chris wilson]

Hi Andy!

On Mon, 20 Sep 2010 19:02:30 -0400
Andy Walls awa...@md.metrocast.net wrote:

BTW, I found that Chris Wilson recently committed a change to inhibit
all drm connector polling globally for a different reason:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9

That commit message shows a case where the driver decides polling needs
to happen, but the human knows differently and manual control over
connector polling mitigates the problem.

On Mon, 20 Sep 2010 17:11:48 -0400
Andy Walls awa...@md.metrocast.net wrote:

On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:

This change allows the root user to disable (and re-enable) DRM KMS
connector polling on a per connector basis via sysfs, like so:

# cat /sys/class/drm/card0/card0-DVI-D-1/polled
[hotplug_detectable] connect disconnect

You are adding a sysfs file, yet you forgot to add a file in
Documentation/ABI. Please fix that and resend the patch.

Oops, process failure, sorry.
Will do.

Regards,
Andy

I thought sysfs files should be one thing per file... so, maybe
card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1
content would be easier to manipulate and parse?

I have to defer to the drm maintainers for the usecases. But how is
having a monitor with a broken edid handled right now? While the output
is connected and used, it probably just stops polling?

cheers,
Flo

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

Re: [stable] regression in 2.6.35.4 'load is to heavy (video subsystem?)'

On Wed, 22 Sep 2010 11:42:41 +0200
Karsten Mehrhoff kaw...@gmx.de wrote:

 [Am 22.09.2010, 02:01 Uhr, schrieb Greg KH g...@kroah.com]
 

  Difference between 2.6.35.1/2/3 and 2.6.35.4 while watching some  
  videos:
  2.6.35.4 switches the cpu for flash videos in the browser (opera or
  iceweasel) or other video outputs to 2200/2400/2600 MHz meanwhile  
  2.6.35.3
  (or older) stays at 1000 Mhz. That results in a higher cpu  
  temperature,
  more power consumption and so one.
 
  Using other GUI program results in nearly the same problems with  
  2.6.35.4,
  so this kernel is unusable for me.
 
  Results to see the difference for the same action
  2.6.35.4
  Core0 Temp:  +45.0__C
  Core1 Temp:  +43.0__C
  cpu MHz:  2200.000 or higher
 
  2.6.35.3
  Core0 Temp:  +32.0__C
  Core1 Temp:  +31.0__C
  cpu MHz:  1000.000 (max. 1800, but falling back to 1000)
 
  Can you run 'git bisect' between 2.6.35.3 and 2.6.35.4 to try to find
  out the offending patch that caused this issue?
 
  thanks,
 
  greg k-h
 
 Same for 2.6.35.5 using 256.53
 
 For your info, I did run some tests today using a nVidia 9500GT
 
 Kernel   |   Performance with NVIDIA-Linux-x86_64-
  |   256.53  |260.19.04 (BETA)
 --
   2.6.35.3   |  good |  good
 --
   2.6.35.4   |   bad | not tested
 --

What would be tremendously more interesting is if you can
reproduce the issue with the in-kernel nouveau driver or just without
the binary driver. As we have no sourcecode for the binary driver, we
can not tell what it does and are thus unable to debug any issues.

If it is an issue that is not reproducible without the binary driver,
please contact the vendor of that driver. 

It it is reproducible even without that driver, it would help if you
could tell exactly which patch in 2.6.35.4 makes the difference
between good and bad in your test below.

There are 114 patches between 2.6.35.3 and 2.6.35.4. If you test
between them, you can pinpoint the exact patch with about 7 tests. 

git bisect does this for you, just do 

$ git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.35.y.git
$ cd linux-2.6.35.y 
$ git bisect bad v2.6.35.4
$ git bisect good v2.6.35.3

Git then checks out a testcandidate for you, which you should compile
and test. If it's good , type 
$ git bisect good
, if its bad
$ git bisect bad

If all goes well, after about 7 tests, it will tell you
what patch did introduce the regression.

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

Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:
 On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awa...@md.metrocast.net wrote:

  In a larger sense it's about user policy for error reporting by the drm
  and radeon drivers, and error response by both the drivers and the user.
 
  In the face of EDID errors, a user may want to take the following
  actions:
 
 ignore the errors
 supress the errors
 continue to monitor the errors for a time
 replace cables
 replace graphics adapter
 replace monitor
 report a bug
 
  All of those end user actions are possible right now, except the one to
  supress the errors (and the I2C transactions associated with them).
 
  A monitor, cable, and graphics adapter set that is currently
  experiencing EDID errors, may be otherwise working just fine.
 
  Because we want to ensure people report bugs, does not seem like a
  good reason to prevent a user from turning off bogus error messages, for
  an otherwise working monitor that is providing broken EDID data.  What
  is the resolution of a bug report for a monitor providing bad EDID data
  going to look like?
 
 I wasn't talking about the broken EDID messages, I was talking about
 the bogus connector table entries on your board.  Those should be
 properly quirked in the driver in which case, which would avoid the
 problem all together in your case.

The problem with in-kernel quirk databases are

- you'll always end up lagging behind what's being fielded,

- the number of stale entries will grow over the years,

- the scope of the fix for a single quirk entry for the total installed
user base is small; each quirk table entry itself has little value

- quirks for working around unreliable attributes still need a 
reliable system identification method (no big deal for PCI)

- fixing by quirk is a reactionary mode for kernel developers
(it's also job security, so sysadmins are stuck coming back for
 help)

- it increases time to resolve problems for end users.

I don't think it's a good to plan to continually react to manufacturers
that have cycle times of 6 months to a year.  Quirk tables should be a
solution of last resort, when there's nothing else that can be done,
IMO.  


I understood.  A quirk database solves the immediate problem for me and
for owners of that MSI motherboard.

My current problem also highlights undesirable behavior that will occur
with broken EDIDs.  This undesirable behavior will likely resurface in
another bug report.


   or does the board have a bug in the connector table?
 
  I have not dug into the BIOS connector table bits and bytes to verify,
  but I'm assuming the connector table is incorrect.
 
 
 It appears to be incorrect.  If you send me a copy of the vbios, I can
 easily add a quirk. I suspect your board oem may offer several boards
 with different output configurations and neglected to update the table
 in some configurations.

Do you have a pointer to a set of steps to follow for extracting that
vbios information?




What
  physical connectors does the board have what does the driver report in
  dmesg?
 
  The board only has a physical VGA connector.  The graphics adapter is an
  IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302).  Here are the
  PCI IDs on the graphics adapter:
 
  01:05.0 VGA compatible controller [0300]:
 ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA 
  controller])
 Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
 
 
  Below is the dmesg output from the unmodified drm and radeon modules
  which includes samples of drm module log spam for the first 30 seconds
  or so after boot.

  [drm] Radeon Display Connectors
  [drm] Connector 0:
  [drm]   VGA
  [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
  [drm]   Encoders:
  [drm] CRT1: INTERNAL_KLDSCP_DAC1
  [drm] Connector 1:
  [drm]   DVI-D
  [drm]   HPD2
  [drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
  [drm]   Encoders:
  [drm] DFP2: INTERNAL_DDI
  [drm] Connector 2:
  [drm]   HDMI-A
  [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
  [drm]   Encoders:
  [drm] DFP3: INTERNAL_LVTM1
 
 FWIW, it's actually the HDMI connector that is generating the errors
 due to the lack of a hpd pin assignment.

Are you sure?  My /var/log/messages spam insists it is DVI-D-1 (hex
dumps omitted):

Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon :01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed 
a monitor but no|invalid EDID
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw

Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling