diff mbox

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

Message ID CADnq5_MoThbrDADBHBRXiEGWC8jukwOLyfjfX9-7d0fB0kbpMA@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Alex Deucher Nov. 2, 2015, 3:20 p.m. UTC 
On Sat, Oct 31, 2015 at 5:22 PM, Pavel Machek <pavel@ucw.cz> 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?


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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Pavel Machek Nov. 3, 2015, 10:09 p.m. UTC | #1 
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
> >> >

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

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

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

Patch

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