On Sat, Oct 31, 2015 at 5:22 PM, Pavel Machek <pavel@xxxxxx> wrote:
> 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]
>
>> >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?
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index dac78ad..b86f06a 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -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
>
> 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
>
>> 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_CLASS=30000
> uevent:PCI_ID=1002:9553
> uevent:PCI_SUBSYS_ID=1025:0212
> uevent:PCI_SLOT_NAME=0000: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
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
