Skip to contentSkip to conversation

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

DISCUSSION Pavel Machek 5 participants 17 messages Oct 31, 2015 – Nov 6, 2015

Subsystems (3)
DRM drivers Radeon and amdgpu DRM drivers Framebuffer layer
lore
Share & tools
lore

Pavel Machek

author
#0 lore raw

Hi!

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But my monitor is native 1920x1080, so that mode looks pretty ugly on screen. If I go to 1920x1080, I see colored horizontal lines (often black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
   1920x1080     60.00*+
      1600x1200     60.00
         1680x1050     59.95
	    1280x1024     75.02    60.02
	       1440x900      59.89
	          1024x768      75.08    60.00
		     800x600       75.00    60.32
		        640x480       75.00    60.00
			   720x400       70.08
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
 pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200

This is Acer notebook,

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

Ouch, and power consumption seems to be 8W too high. (25W instead of 17W), I believe it started when I added radeon firmware, but will check. It does not go lower even when I switch to text console.

Any ideas?

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
maintainer
#1 lore raw
Quoted 27 lines · Pavel Machek

Hi!

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But my monitor is native 1920x1080, so that mode looks pretty ugly on screen. If I go to 1920x1080, I see colored horizontal lines (often black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
    1920x1080     60.00*+
       1600x1200     60.00
          1680x1050     59.95
	    1280x1024     75.02    60.02
	       1440x900      59.89
	          1024x768      75.08    60.00
		     800x600       75.00    60.32
		        640x480       75.00    60.00
			   720x400       70.08
  pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
  pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
  pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200

This is Acer notebook,

Quoted 8 lines

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

Ouch, and power consumption seems to be 8W too high. (25W instead of 17W), I believe it started when I added radeon firmware, but will check. It does not go lower even when I switch to text console.

Any ideas?

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.

Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

Power consumption would be totally awkward, but it should help nailing down the problem.

Regards,
Christian.

Quoted 2 lines

Pavel

author
#2 lore raw

Hi!

Quoted 28 lines
Quoted 27 lines

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But my monitor is native 1920x1080, so that mode looks pretty ugly on screen. If I go to 1920x1080, I see colored horizontal lines (often black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
   1920x1080     60.00*+
      1600x1200     60.00
         1680x1050     59.95
	    1280x1024     75.02    60.02
	       1440x900      59.89
	          1024x768      75.08    60.00
		     800x600       75.00    60.32
		        640x480       75.00    60.00
			   720x400       70.08
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
 pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200

This is Acer notebook,

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

Quoted 8 lines
Quoted 1 line

Any ideas?

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.

Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

I tried that, but it still flickers.

pavel@half:~/misc/fgfs$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0
Quoted 2 lines

Power consumption would be totally awkward, but it should help nailing down the problem.

It seems chromium makes the flicker way worse.. even when running on different virtual desktop. I'm not sure which sysfs settings I should tweak (or if I should be tweaking them with .dpm=0). But sysfs says:

pavel@half:/sys/bus/pci/drivers/radeon/0000:01:00.0$ ls
backlight						  drm
irq
resource
boot_vga		  enable	 local_cpulist	resource0
broken_parity_status	    firmware_node  local_cpus	resource0_wc
class			    		   		  graphics
modalias						  resource1
config
 i2c-0		 msi_bus	resource2
 consistent_dma_mask_bits  i2c-1		 power		rom
 d3cold_allowed		   			   i2c-2
 power_method					   subsystem
 device
 i2c-3		 power_profile	subsystem_device
 dma_mask_bits	 		  i2c-4		 remove
 subsystem_vendor
 driver			  i2c-5		 rescan		uevent
 driver_override	  		   i2c-6		 reset
 vendor
 pavel@half:/sys/bus/pci/drivers/radeon/0000:01:00.0$ grep . *
 grep: backlight: Is a directory
 boot_vga:1
 broken_parity_status:0
 class:0x030000
 Binary file config matches
 consistent_dma_mask_bits:40
 d3cold_allowed:1
 device:0x9553
 dma_mask_bits:40
 grep: driver: Is a directory
 driver_override:(null)
 grep: drm: Is a directory
 enable:1
 grep: firmware_node: Is a directory
 grep: graphics: Is a directory
 grep: i2c-0: Is a directory
 grep: i2c-1: Is a directory
 grep: i2c-2: Is a directory
 grep: i2c-3: Is a directory
 grep: i2c-4: Is a directory
 grep: i2c-5: Is a directory
 grep: i2c-6: Is a directory
 irq:16
 local_cpulist:0-3
 local_cpus:f
 modalias:pci:v00001002d00009553sv00001025sd00000212bc03sc00i00
 msi_bus:1
 grep: power: Is a directory
 power_method:profile
 power_profile:default
 grep: remove: Permission denied
 grep: rescan: Permission denied
 grep: reset: Permission denied
 resource:0x00000000c0000000 0x00000000cfffffff 0x0000000000042208
 resource:0x0000000000005000 0x00000000000050ff 0x0000000000040101
 resource:0x00000000d6200000 0x00000000d620ffff 0x0000000000040200
 resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
 resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
 resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
 resource:0x00000000d6220000 0x00000000d623ffff 0x0000000000046202
 grep: resource0: Permission denied
 grep: resource0_wc: Permission denied
 grep: resource1: Permission denied
 grep: resource2: Permission denied
 grep: rom: Permission denied
 grep: subsystem: Is a directory
 subsystem_device:0x0212
 subsystem_vendor:0x1025
 uevent:DRIVER=radeon
 uevent:PCI_CLASS0000
 uevent:PCI_ID02:9553
 uevent:PCI_SUBSYS_ID25:0212
 uevent:PCI_SLOT_NAME00:01:00.0
 uevent:MODALIAS=pci:v00001002d00009553sv00001025sd00000212bc03sc00i00
 vendor:0x1002

Thanks,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#3 lore raw
Quoted 32 lines · Pavel Machek

Hi!

Quoted 30 lines
Quoted 29 lines

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But my monitor is native 1920x1080, so that mode looks pretty ugly on screen. If I go to 1920x1080, I see colored horizontal lines (often black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
   1920x1080     60.00*+
      1600x1200     60.00
         1680x1050     59.95
        1280x1024     75.02    60.02
           1440x900      59.89
              1024x768      75.08    60.00
                 800x600       75.00    60.32
                    640x480       75.00    60.00
                       720x400       70.08
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
 pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200

This is Acer notebook,

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]

Any ideas?

Quoted 8 lines
Quoted 6 lines

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.

Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

I tried that, but it still flickers.

It's probably pll stability. There seem to be a number of regressions since the pll code was rewritten to support matching the hdmi clocks more closely. Does this patch help?

(quoted diff) +0 -0

b/drivers/gpu/drm/radeon/atombios_crtc.c
index dac78ad..b86f06a 100644

drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family = CHIP_RS600) ||
                    (rdev->family = CHIP_RS690) ||
                    (rdev->family = CHIP_RS740))

Unfortunately, it can't be applied as is because we had a similar patch which was reverted because it regressed a bunch of other systems. The actual pll limits probably need to be tweaked.

Alex

Quoted 97 lines
pavel@half:~/misc/fgfs$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0
Quoted 2 lines

Power consumption would be totally awkward, but it should help nailing down the problem.

It seems chromium makes the flicker way worse.. even when running on different virtual desktop. I'm not sure which sysfs settings I should tweak (or if I should be tweaking them with .dpm=0). But sysfs says:

pavel@half:/sys/bus/pci/drivers/radeon/0000:01:00.0$ ls
backlight                                                 drm
irq
resource
boot_vga                  enable         local_cpulist  resource0
broken_parity_status        firmware_node  local_cpus   resource0_wc
class                                                     graphics
modalias                                                  resource1
config
 i2c-0           msi_bus        resource2
 consistent_dma_mask_bits  i2c-1                 power          rom
 d3cold_allowed                                    i2c-2
 power_method                                      subsystem
 device
 i2c-3           power_profile  subsystem_device
 dma_mask_bits                    i2c-4          remove
 subsystem_vendor
 driver                   i2c-5          rescan         uevent
 driver_override                           i2c-6                 reset
 vendor
 pavel@half:/sys/bus/pci/drivers/radeon/0000:01:00.0$ grep . *
 grep: backlight: Is a directory
 boot_vga:1
 broken_parity_status:0
 class:0x030000
 Binary file config matches
 consistent_dma_mask_bits:40
 d3cold_allowed:1
 device:0x9553
 dma_mask_bits:40
 grep: driver: Is a directory
 driver_override:(null)
 grep: drm: Is a directory
 enable:1
 grep: firmware_node: Is a directory
 grep: graphics: Is a directory
 grep: i2c-0: Is a directory
 grep: i2c-1: Is a directory
 grep: i2c-2: Is a directory
 grep: i2c-3: Is a directory
 grep: i2c-4: Is a directory
 grep: i2c-5: Is a directory
 grep: i2c-6: Is a directory
 irq:16
 local_cpulist:0-3
 local_cpus:f
 modalias:pci:v00001002d00009553sv00001025sd00000212bc03sc00i00
 msi_bus:1
 grep: power: Is a directory
 power_method:profile
 power_profile:default
 grep: remove: Permission denied
 grep: rescan: Permission denied
 grep: reset: Permission denied
 resource:0x00000000c0000000 0x00000000cfffffff 0x0000000000042208
 resource:0x0000000000005000 0x00000000000050ff 0x0000000000040101
 resource:0x00000000d6200000 0x00000000d620ffff 0x0000000000040200
 resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
 resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
 resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
 resource:0x00000000d6220000 0x00000000d623ffff 0x0000000000046202
 grep: resource0: Permission denied
 grep: resource0_wc: Permission denied
 grep: resource1: Permission denied
 grep: resource2: Permission denied
 grep: rom: Permission denied
 grep: subsystem: Is a directory
 subsystem_device:0x0212
 subsystem_vendor:0x1025
 uevent:DRIVER=radeon
 uevent:PCI_CLASS0000
 uevent:PCI_ID02:9553
 uevent:PCI_SUBSYS_ID25:0212
 uevent:PCI_SLOT_NAME00:01:00.0
 uevent:MODALIAS=pci:v00001002d00009553sv00001025sd00000212bc03sc00i00
 vendor:0x1002

Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

author
#4 lore raw

Hi!

Quoted 45 lines
Quoted 25 lines
Quoted 25 lines
Quoted 24 lines

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But my monitor is native 1920x1080, so that mode looks pretty ugly on screen. If I go to 1920x1080, I see colored horizontal lines (often black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
   1920x1080     60.00*+
      1600x1200     60.00
         1680x1050     59.95
        1280x1024     75.02    60.02
           1440x900      59.89
              1024x768      75.08    60.00
                 800x600       75.00    60.32
                    640x480       75.00    60.00
                       720x400       70.08
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
 pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200

Any ideas?

Quoted 8 lines
Quoted 6 lines

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.

Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

I tried that, but it still flickers.

It's probably pll stability. There seem to be a number of regressions since the pll code was rewritten to support matching the hdmi clocks more closely. Does this patch help?

drivers/gpu/drm/radeon/atombios_crtc.c +0 -0
index dac78ad..b86f06a 100644

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 8 lines
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family = CHIP_RS600) ||
                    (rdev->family = CHIP_RS690) ||
                    (rdev->family = CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

Quoted 3 lines

Unfortunately, it can't be applied as is because we had a similar patch which was reverted because it regressed a bunch of other systems. The actual pll limits probably need to be tweaked.

Any ideas how to tweak the pll limits?

Thanks,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#5 lore raw
Quoted 48 lines · Pavel Machek

Hi!

Quoted 46 lines
Quoted 25 lines
Quoted 25 lines
Quoted 24 lines

4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But my monitor is native 1920x1080, so that mode looks pretty ugly on screen. If I go to 1920x1080, I see colored horizontal lines (often black) as soon as there's graphics activity.

pavel@half:~$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
axis) 478mm x 268mm
   1920x1080     60.00*+
      1600x1200     60.00
         1680x1050     59.95
        1280x1024     75.02    60.02
           1440x900      59.89
              1024x768      75.08    60.00
                 800x600       75.00    60.32
                    640x480       75.00    60.00
                       720x400       70.08
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
 pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
 pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200

Any ideas?

Quoted 8 lines
Quoted 6 lines

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.

Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

I tried that, but it still flickers.

It's probably pll stability. There seem to be a number of regressions since the pll code was rewritten to support matching the hdmi clocks more closely. Does this patch help?

drivers/gpu/drm/radeon/atombios_crtc.c +0 -0
index dac78ad..b86f06a 100644
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
Quoted 10 lines

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 7 lines
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
        if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family = CHIP_RS600) ||
                    (rdev->family = CHIP_RS690) ||
                    (rdev->family = CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

You could also try the old pll algorithm:

(quoted diff) +0 -0

b/drivers/gpu/drm/radeon/atombios_crtc.c
index dac78ad..8c6e8fa 100644

drivers/gpu/drm/radeon/atombios_crtc.c +0 -0
@@ -1094,8 +1094,8 @@ static void atombios_crtc_set_pll(struct

drm_crtc *crtc, struct drm_display_mode
radeon_compute_pll_legacy(pll,
radeon_crtc->adjusted_clock, &pll_clock,

                                          &fb_div, &frac_fb_div,

&ref_div, &post_div);
else if (ASIC_IS_AVIVO(rdev))
- radeon_compute_pll_avivo(pll,
radeon_crtc->adjusted_clock, &pll_clock,
- &fb_div, &frac_fb_div,
&ref_div, &post_div);
+ radeon_compute_pll_legacy(pll,
radeon_crtc->adjusted_clock, &pll_clock,
+ &fb_div, &frac_fb_div,
&ref_div, &post_div);
else
radeon_compute_pll_legacy(pll,
radeon_crtc->adjusted_clock, &pll_clock,

                                          &fb_div, &frac_fb_div,

&ref_div, &post_div);

Quoted 6 lines
Quoted 4 lines

Unfortunately, it can't be applied as is because we had a similar patch which was reverted because it regressed a bunch of other systems. The actual pll limits probably need to be tweaked.

Any ideas how to tweak the pll limits?

Adjust the the algorithm in radeon_compute_pll_avivo() in radeon_display.c

Alex

author
#6 lore raw

Hi!

Quoted 34 lines
Quoted 23 lines
Quoted 23 lines
Quoted 10 lines
Quoted 8 lines
Quoted 1 line

Any ideas?

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.

Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

I tried that, but it still flickers.

It's probably pll stability. There seem to be a number of regressions since the pll code was rewritten to support matching the hdmi clocks more closely. Does this patch help?

drivers/gpu/drm/radeon/atombios_crtc.c +0 -0
index dac78ad..b86f06a 100644
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
Quoted 10 lines

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 7 lines
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
        if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family = CHIP_RS600) ||
                    (rdev->family = CHIP_RS690) ||
                    (rdev->family = CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

Quoted 1 line

You could also try the old pll algorithm:

I reverted the patch above, and switched to the old algorithm.

The flicker is still there. (But maybe its less horrible, like with RADEON_PLL_PREFER_MINM_OVER_MAXP).

Thanks,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#7 lore raw
Quoted 31 lines · Pavel Machek

Hi!

Quoted 28 lines
Quoted 28 lines
Quoted 18 lines
Quoted 7 lines
Quoted 6 lines
Quoted 1 line

Any ideas?

Alex probably knows more about this, but it sounds like problems with switching the memory clocks on 3D load.
Try to disable power management completely with radeon.dpm=0 on the kernel command line or nailing the hardware at a specific power level using sysfs.

I tried that, but it still flickers.

It's probably pll stability. There seem to be a number of regressions since the pll code was rewritten to support matching the hdmi clocks more closely. Does this patch help?

drivers/gpu/drm/radeon/atombios_crtc.c +0 -0
index dac78ad..b86f06a 100644

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 8 lines
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
         radeon_crtc->pll_flags = 0;
 
         if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                 if ((rdev->family = CHIP_RS600) ||
                     (rdev->family = CHIP_RS690) ||
                     (rdev->family = CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

Quoted 5 lines
Quoted 1 line

You could also try the old pll algorithm:

I reverted the patch above, and switched to the old algorithm.

The flicker is still there. (But maybe its less horrible, like with RADEON_PLL_PREFER_MINM_OVER_MAXP).

The flickering would vanish completely if that's the reason for the issue you are seeing.

Try setting ref_div_min and ref_div_max to 2 in radeon_compute_pll_avivo().

But I'm not 100% convinced that this is actually a PLL problem, try to compile the firmware it complains about into the kernel as well.

Regards,
Christian.

Quoted 4 lines

Thanks,
Pavel

author
#8 lore raw

Hi!

Quoted 18 lines
Quoted 18 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines

index dac78ad..b86f06a 100644

drivers/gpu/drm/radeon/atombios_crtc.c +0 -0
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
Quoted 9 lines

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 7 lines
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
        if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family = CHIP_RS600) ||
                    (rdev->family = CHIP_RS690) ||
                    (rdev->family = CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

Quoted 1 line

You could also try the old pll algorithm:

I reverted the patch above, and switched to the old algorithm.

Quoted 8 lines
Quoted 2 lines

The flicker is still there. (But maybe its less horrible, like with RADEON_PLL_PREFER_MINM_OVER_MAXP).

The flickering would vanish completely if that's the reason for the issue you are seeing.

Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

config.32 +1 -1
index 00e5dd2..4734158 100644
@@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
 CONFIG_FIRMWARE_IN_KERNEL=y
-CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
+CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
 CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
 # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
 CONFIG_ALLOW_DEV_COREDUMP=y
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
index dac78ad..dcc4f4d 100644
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
 	radeon_crtc->pll_flags = 0;
 
 	if (ASIC_IS_AVIVO(rdev)) {
+		//radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
 		if ((rdev->family = CHIP_RS600) ||
 		    (rdev->family = CHIP_RS690) ||
 		    (rdev->family = CHIP_RS740))
drivers/gpu/drm/radeon/radeon_display.c +8 -1
index 6743174..bebaf4f 100644
@@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
 	fb_div_max = pll->max_feedback_div;
 
 	if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
+		printk("radeon: fractional divider\n");
 		fb_div_min *= 10;
 		fb_div_max *= 10;
 	}

@@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
 	else
 		ref_div_max = pll->max_ref_div;
 
+	ref_div_min = 2;
+	ref_div_max = 2;
+
 	/* determine allowed post divider range */
 	if (pll->flags & RADEON_PLL_USE_POST_DIV) {
 		post_div_min = pll->post_div;

@@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
 		diff = abs(target_clock - (pll->reference_freq * fb_div) /
 			(ref_div * post_div));
 
+		printk("post_div = %d, diff = %d\n", post_div, diff);
+
 		if (diff < diff_best || (diff = diff_best &&
 		    !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
 

@@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
 		}
 	}
 	post_div = post_div_best;
+	printk("Selected post_div = %d\n", post_div);
 
 	/* get the feedback and reference divider for the optimal value */
 	avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,

@@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
 	*ref_div_p = ref_div;
 	*post_div_p = post_div;
 
-	DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+	printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
 		      freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
 		      ref_div, post_div);
 }
Quoted 2 lines

But I'm not 100% convinced that this is actually a PLL problem, try to compile the firmware it complains about into the kernel as well.

Did that, too.

Best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#9 lore raw
Quoted 26 lines · Pavel Machek

Hi!

Quoted 23 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 13 lines

index dac78ad..b86f06a 100644

drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family == CHIP_RS600) ||
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

Quoted 5 lines
Quoted 1 line

You could also try the old pll algorithm:

I reverted the patch above, and switched to the old algorithm.

The flicker is still there. (But maybe its less horrible, like with RADEON_PLL_PREFER_MINM_OVER_MAXP).

The flickering would vanish completely if that's the reason for the issue you are seeing.

Quoted 6 lines
Quoted 2 lines

Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0? Sounds more like either memory reclocking happening outside of vblank, or underflow to the display controllers.

Alex

Quoted 80 lines
config.32 +1 -1
index 00e5dd2..4734158 100644
@@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
 CONFIG_FIRMWARE_IN_KERNEL=y
-CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
+CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
 CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
 # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
 CONFIG_ALLOW_DEV_COREDUMP=y
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
index dac78ad..dcc4f4d 100644
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        radeon_crtc->pll_flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                if ((rdev->family == CHIP_RS600) ||
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))
drivers/gpu/drm/radeon/radeon_display.c +8 -1
index 6743174..bebaf4f 100644
@@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
        fb_div_max = pll->max_feedback_div;
 
        if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
+               printk("radeon: fractional divider\n");
                fb_div_min *= 10;
                fb_div_max *= 10;
        }

@@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
        else
                ref_div_max = pll->max_ref_div;
 
+       ref_div_min = 2;
+       ref_div_max = 2;
+
        /* determine allowed post divider range */
        if (pll->flags & RADEON_PLL_USE_POST_DIV) {
                post_div_min = pll->post_div;

@@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
                diff = abs(target_clock - (pll->reference_freq * fb_div) /
                        (ref_div * post_div));
 
+               printk("post_div = %d, diff = %d\n", post_div, diff);
+
                if (diff < diff_best || (diff == diff_best &&
                    !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
 

@@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
                }
        }
        post_div = post_div_best;
+       printk("Selected post_div = %d\n", post_div);
 
        /* get the feedback and reference divider for the optimal value */
        avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,

@@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
        *ref_div_p = ref_div;
        *post_div_p = post_div;
 
-       DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+       printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
                      freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
                      ref_div, post_div);
 }
Quoted 4 lines

But I'm not 100% convinced that this is actually a PLL problem, try to compile the firmware it complains about into the kernel as well.

Quoted 7 lines

Did that, too.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

#10 lore raw
Quoted 27 lines · Alex Deucher
Quoted 26 lines · Pavel Machek

Hi!

Quoted 24 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines

drivers/gpu/drm/radeon/atombios_crtc.c static u32 atombios_adjust_pll(struct drm_crtc *crtc, · line 576

Quoted 13 lines

index dac78ad..b86f06a 100644

drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
         radeon_crtc->pll_flags = 0;
 
         if (ASIC_IS_AVIVO(rdev)) {
+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                 if ((rdev->family = CHIP_RS600) ||
                     (rdev->family = CHIP_RS690) ||
                     (rdev->family = CHIP_RS740))

Help.. maybe... it is tricky to tell. It definitely does _not_ fix the issue completely.

Quoted 5 lines
Quoted 1 line

You could also try the old pll algorithm:

I reverted the patch above, and switched to the old algorithm.

The flicker is still there. (But maybe its less horrible, like with RADEON_PLL_PREFER_MINM_OVER_MAXP).

The flickering would vanish completely if that's the reason for the issue you are seeing.
Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Quoted 6 lines
Quoted 3 lines

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0? Sounds more like either memory reclocking happening outside of vblank, or underflow to the display controllers.

Sounds like my suspicion was right, that doesn't seem to be a PLL issue after all.

Just to rule out the obvious your system works fine with windows and you don't have a extra long cable for the monitor or something like this?

Regards,
Christian.

Quoted 88 lines

Alex

Quoted 85 lines
config.32 +1 -1
index 00e5dd2..4734158 100644
@@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
  CONFIG_PREVENT_FIRMWARE_BUILD=y
  CONFIG_FW_LOADER=y
  CONFIG_FIRMWARE_IN_KERNEL=y
-CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
+CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
  CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
  # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
  CONFIG_ALLOW_DEV_COREDUMP=y
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
index dac78ad..dcc4f4d 100644
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
         radeon_crtc->pll_flags = 0;
 
         if (ASIC_IS_AVIVO(rdev)) {
+               //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
                 if ((rdev->family = CHIP_RS600) ||
                     (rdev->family = CHIP_RS690) ||
                     (rdev->family = CHIP_RS740))
drivers/gpu/drm/radeon/radeon_display.c +8 -1
index 6743174..bebaf4f 100644
@@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
         fb_div_max = pll->max_feedback_div;
 
         if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
+               printk("radeon: fractional divider\n");
                 fb_div_min *= 10;
                 fb_div_max *= 10;
         }

@@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
         else
                 ref_div_max = pll->max_ref_div;
 
+       ref_div_min = 2;
+       ref_div_max = 2;
+
         /* determine allowed post divider range */
         if (pll->flags & RADEON_PLL_USE_POST_DIV) {
                 post_div_min = pll->post_div;

@@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
                 diff = abs(target_clock - (pll->reference_freq * fb_div) /
                         (ref_div * post_div));
 
+               printk("post_div = %d, diff = %d\n", post_div, diff);
+
                 if (diff < diff_best || (diff = diff_best &&
                     !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
 

@@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
                 }
         }
         post_div = post_div_best;
+       printk("Selected post_div = %d\n", post_div);
 
         /* get the feedback and reference divider for the optimal value */
         avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,

@@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
         *ref_div_p = ref_div;
         *post_div_p = post_div;
 
-       DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+       printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
                       freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
                       ref_div, post_div);
  }
Quoted 4 lines

But I'm not 100% convinced that this is actually a PLL problem, try to compile the firmware it complains about into the kernel as well.

Did that, too.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

author
#11 lore raw
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

RADEON_PLL_PREFER_MINM_OVER_MAXP).

The flickering would vanish completely if that's the reason for the issue you are seeing.
Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Quoted 6 lines
Quoted 3 lines

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0? Sounds more like either memory reclocking happening outside of vblank, or underflow to the display controllers.

Quoted 6 lines

Sounds like my suspicion was right, that doesn't seem to be a PLL issue after all.

Just to rule out the obvious your system works fine with windows and you don't have a extra long cable for the monitor or something like this?

Cable is something like 2 meters. It does not seem to be EMI, because it only happens when the display is being updated.

The system had some thermal issues before, but a) there's big fan cooling it now and b) it does not get worse with more usage. I don't think its heat.

I don't have Windows for a test, sorry.

Best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
author
#12 lore raw
In reply to Alex Deucher

Hi!

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

The flickering would vanish completely if that's the reason for the issue you are seeing.

Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Quoted 7 lines
Quoted 3 lines

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0? Sounds more like either memory reclocking happening outside of vblank, or underflow to the display controllers.

No, it does not:

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0

..and same issue. And yes, it looks like an underflow to me. How can I debug reclocking / underflows?

Best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#13 lore raw
Quoted 16 lines · Pavel Machek

Hi!

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

The flickering would vanish completely if that's the reason for the issue you are seeing.

Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Quoted 7 lines
Quoted 3 lines

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0? Sounds more like either memory reclocking happening outside of vblank, or underflow to the display controllers.

Quoted 8 lines

No, it does not:

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0

..and same issue. And yes, it looks like an underflow to me. How can I debug reclocking / underflows?

Does radeon.disp_priority=2 help?

Signature · 2 lines
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
author
#14 lore raw
Quoted 19 lines · Michel Dänzer
Quoted 18 lines · Pavel Machek

Hi!

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

The flickering would vanish completely if that's the reason for the issue you are seeing.

Try setting ref_div_min and ref_div_max to 2 in
radeon_compute_pll_avivo().

Quoted 7 lines
Quoted 3 lines

Ok, I did this, but no luck, still flickers. But the flicker only happens when something changes on screen, like dragging a big window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0? Sounds more like either memory reclocking happening outside of vblank, or underflow to the display controllers.

No, it does not:

Quoted 8 lines
Quoted 6 lines
pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0

..and same issue. And yes, it looks like an underflow to me. How can I debug reclocking / underflows?

Does radeon.disp_priority=2 help?

Tried this, and no change, still flickers.

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
pavel@half:~$

I searched for some more config options, and tried:

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
radeon.amdgpu_runtime_pm=0 radeon.bapm=0 radeon.sched_hw_submission=0
radeon.enable_semaphores=0
pavel@half:~$

..still flickers.

Best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
author
#15 lore raw
In reply to Alex Deucher

Hi!

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

Unfortunately, it can't be applied as is because we had a similar patch which was reverted because it regressed a bunch of other systems. The actual pll limits probably need to be tweaked.

Any ideas how to tweak the pll limits?

Adjust the the algorithm in radeon_compute_pll_avivo() in radeon_display.c

Hmm. Two values have diff = 0, I guess that leaves little room for improvement, as we already tried both with the PREFER_... setting.

[    1.236229] Linux agpgart interface v0.103
[    1.236829] [drm] Initialized drm 1.1.0 20060810
[    1.237013] [drm] radeon kernel modesetting enabled.
[    1.238284] [drm] initializing kernel modesetting (RV710
0x1002:0x9553 0x1025:0x0212)
.
[    1.238362] [drm] register mmio base: 0xD6200000
[    1.238417] [drm] register mmio size: 65536
[    1.238622] ATOM BIOS: BR34582.001
[    1.238789] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 -
0x000000001FFFFFFF (
512M used)
[    1.238856] radeon 0000:01:00.0: GTT: 1024M 0x0000000020000000 -
0x000000005FFFFFFF
[    1.238915] [drm] Detected VRAM RAMQ2M, BAR%6M
[    1.238970] [drm] RAM width 64bits DDR
[    1.239266] [TTM] Zone  kernel: Available graphics memory: 431276
kiB
[    1.239323] [TTM] Zone highmem: Available graphics memory: 1546602
kiB
[    1.239380] [TTM] Initializing pool allocator
[    1.240936] [TTM] Initializing DMA pool allocator
[    1.241174] [drm] radeon: 512M of VRAM memory ready
[    1.241231] [drm] radeon: 1024M of GTT memory ready.
[    1.241345] [drm] Loading RV710 Microcode
[    1.241483] radeon 0000:01:00.0: Direct firmware load for
radeon/RV710_smc.bin failed
 with error -2
 [    1.241553] smc: error loading firmware "radeon/RV710_smc.bin"
 [    1.241638] [drm] radeon: power management initialized
 [    1.241754] radeon 0000:01:00.0: Direct firmware load for
 radeon/RV710_uvd.bin failed
  with error -2
  [    1.241823] radeon 0000:01:00.0: radeon_uvd: Can't load firmware
  "radeon/RV710_uvd.bi
n"
[    1.241885] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    1.257273] [drm] PCIE GART of 1024M enabled (table at
0x0000000000040000).
[    1.257456] radeon 0000:01:00.0: WB enabled
[    1.257514] radeon 0000:01:00.0: fence driver on ring 0 use gpu
addr 0x0000000020000c
00 and cpu addr 0xffc01c00
[    1.257582] radeon 0000:01:00.0: fence driver on ring 3 use gpu
addr 0x0000000020000c0c and cpu addr 0xffc01c0c
[    1.257655] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[    1.257713] [drm] Driver supports precise vblank timestamp query.
[    1.257770] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[    1.257921] [drm] radeon: irq initialized.
[    1.304343] [drm] ring test on 0 succeeded in 1 usecs
[    1.304403] [drm] ring test on 3 succeeded in 2 usecs
[    1.304835] [drm] ib test on ring 0 succeeded in 0 usecs
[    1.304912] [drm] ib test on ring 3 succeeded in 0 usecs
[    1.307453] [drm] Radeon Display Connectors
[    1.307511] [drm] Connector 0:
[    1.307565] [drm]   VGA-1
[    1.307619] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48
0x7e4c 0x7e4c
[    1.307677] [drm]   Encoders:
[    1.307730] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    1.336107] ACPI: Deprecated procfs I/F for battery is loaded,
please retry with CONFIG_ACPI_PROCFS_POWER cleared
[    1.336209] ACPI: Battery Slot [BAT0] (battery absent)
[    1.342090] [drm] fb mappable at 0xC0241000
[    1.342146] [drm] vram apper at 0xC0000000
[    1.342201] [drm] size 8294400
[    1.342254] [drm] fb depth is 24
[    1.342307] [drm]    pitch is 7680
[    1.342777] fbcon: radeondrmfb (fb0) is primary device
[    1.344374] post_div = 5, diff = 270
[    1.344375] post_div = 6, diff = 0
[    1.344375] post_div = 7, diff = 192
[    1.344376] post_div = 8, diff = 0
[    1.344377] Selected post_div = 8
[    1.344378] 148500 - 148500, pll dividers - fb: 88.0 ref: 2, post 8
[    1.381561] Console: switching to colour frame buffer device 192x60
[    1.391454] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer
device
[    1.404499] [drm] Initialized radeon 2.43.0 20080528 for
0000:01:00.0 on minor 0
[    1.404669] [drm] amdgpu kernel modesetting enabled.
[    1.416219] loop: module loaded
[    1.418413] nbd: registered device at major 43

The "error loading firmware" messages confuse me a bit, but I do have some firmware built into kernel, and 3D acceleration seems to work.

pavel@half:/data/l/linux$ grep FIRMWARE .config
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
# CONFIG_CYPRESS_FIRMWARE is not set
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_FIRMWARE_EDID=y
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_GOOGLE_FIRMWARE is not set
# CONFIG_TEST_FIRMWARE is not set
pavel@half:/data/l/linux$

Best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
author
#16 lore raw

Re: Mobility Radeon HD 4530/4570/545v: warnings

In reply to Christian König

Hi!

One more thing: in my config, I get ton of warnings. I'm not using modules, so everything is built-in.

Best regards,
Pavel

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:24:0:
drivers/gpu/drm/amd/amdgpu/amdgpu.h:1754:12: warning: ‘amdgpu_mn_register’ defined but not used [-Wunused-function]
static int amdgpu_mn_register(struct amdgpu_bo *bo, unsigned long addr)

            ^
drivers/gpu/drm/amd/amdgpu/amdgpu.h:1758:13: warning: ‘amdgpu_mn_unregister’ defined but not used [-Wunused-function]
 static void amdgpu_mn_unregister(struct amdgpu_bo *bo) {}
             ^

CC drivers/gpu/drm/amd/amdgpu/atombios_dp.o
In file included from drivers/gpu/drm/amd/amdgpu/atombios_dp.c:29:0:
drivers/gpu/drm/amd/amdgpu/amdgpu.h:1754:12: warning: ‘amdgpu_mn_register’ defined but not used [-Wunused-function]
static int amdgpu_mn_register(struct amdgpu_bo *bo, unsigned long addr)

            ^
drivers/gpu/drm/amd/amdgpu/amdgpu.h:1758:13: warning: ‘amdgpu_mn_unregister’ defined but not used [-Wunused-function]
 static void amdgpu_mn_unregister(struct amdgpu_bo *bo) {}
             ^
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html