15-rc1: radeon modesetting fails

2014-04-16 Thread Borislav Petkov 
On Wed, Apr 16, 2014 at 12:07:20PM +0200, Christian K?nig wrote:
> Hi Borislav,
> 
> thanks for the logs, those were indeed quite helpful.
> 
> Attached are two patches, the first one tries to solve the problem by
> increasing the accuracy of the parameters if we don't match exactly and the
> second improves the logging of the calculation process by dumping a bunch of
> intermediate values used.
> 
> Please apply both on top of my drm-fixes-3.15-wip branch you are already
> using, if the first one doesn't solve the problem then please provide new
> dmesg logs with drm.debug=0xE.

Yes, it works fine!

Tested-by: Borislav Petkov 

Thanks for fixing it.

[3.634510] [drm] Initialized drm 1.1.0 20060810
[6.146795] [drm] radeon kernel modesetting enabled.
[6.157513] [drm] initializing kernel modesetting (RV635 0x1002:0x9598 
0x1043:0x01DA).
[6.165881] [drm] register mmio base: 0xFEA2
[6.170632] [drm] register mmio size: 65536
[6.195783] [drm] Detected VRAM RAM=512M, BAR=256M
[6.200632] [drm] RAM width 128bits DDR
[6.245839] [drm] radeon: 512M of VRAM memory ready
[6.250935] [drm] radeon: 512M of GTT memory ready.
[6.255995] [drm] Loading RV635 Microcode
[6.285403] [drm] Internal thermal controller without fan control
[7.256600] [drm] radeon: power management initialized
[7.261872] [drm] GART: num cpu pages 131072, num gpu pages 131072
[7.268795] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[7.312314] [drm] PCIE GART of 512M enabled (table at 0x0004).
[7.334860] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.341562] [drm] Driver supports precise vblank timestamp query.
[7.358166] [drm] radeon: irq initialized.
[7.394139] [drm] ring test on 0 succeeded in 0 usecs
[7.400078] [drm] ib test on ring 0 succeeded in 0 usecs
[7.406302] [drm] Radeon Display Connectors
[7.410553] [drm] Connector 0:
[7.413654] [drm]   DVI-I-1
[7.416528] [drm]   HPD1
[7.419120] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 
0x7e5c
[7.426580] [drm]   Encoders:
[7.429621] [drm] DFP1: INTERNAL_UNIPHY
[7.433862] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[7.438526] [drm] Connector 1:
[7.441622] [drm]   DIN-1
[7.444333] [drm]   Encoders:
[7.447346] [drm] TV1: INTERNAL_KLDSCP_DAC2
[7.451919] [drm] Connector 2:
[7.455031] [drm]   DVI-I-2
[7.457890] [drm]   HPD2
[7.460469] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 
0x7e4c
[7.467926] [drm]   Encoders:
[7.470940] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[7.475602] [drm] DFP2: INTERNAL_KLDSCP_LVTMA
[7.557323] [drm] fb mappable at 0xC0141000
[7.561555] [drm] vram apper at 0xC000
[7.565716] [drm] size 9216000
[7.568825] [drm] fb depth is 24
[7.572103] [drm]pitch is 7680
[7.576458] fbcon: radeondrmfb (fb0) is primary device
[7.842341] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[7.854344] [drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on 
minor 0

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

15-rc1: radeon modesetting fails

2014-04-16 Thread Christian König 
Hi Borislav,

thanks for the logs, those were indeed quite helpful.

Attached are two patches, the first one tries to solve the problem by 
increasing the accuracy of the parameters if we don't match exactly and 
the second improves the logging of the calculation process by dumping a 
bunch of intermediate values used.

Please apply both on top of my drm-fixes-3.15-wip branch you are already 
using, if the first one doesn't solve the problem then please provide 
new dmesg logs with drm.debug=0xE.

Thanks in advance,
Christian.

Am 15.04.2014 16:24, schrieb Borislav Petkov:
> On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian K?nig wrote:
>>> Does reverting:
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
>>> fix the issue?  We may need to tweak the pll parameters for older asics.
>> Yeah, indeed the most likely cause. Please provide dmesg outputs created
>> with drm.ebug=0xe for the old and the new kernel.
> Hey, I finally haz 15-rc1+ running here. And I can even see something!
>
> :-)
>
> Ok, so I reverted 32167016076f ontop of Christian's drm-fixes-3.15-wip
> branch which didn't apply cleanly. So I ended up fixing the conflicts
> and got the revert below.
>
> With it, the machine booted fine, so it looks like the revert worked.
>
> Christian, I'm sending dmesg outputs in another private mail to you
> guys.
>
> Thanks.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-improve-PLL-params-if-we-don-t-match-exac.patch
Type: text/x-diff
Size: 2003 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-improve-logging-of-PLL-parameter-calculat.patch
Type: text/x-diff
Size: 2403 bytes
Desc: not available
URL:

15-rc1: radeon modesetting fails

2014-04-16 Thread Kertesz Laszlo 
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
>> Turning off modesetting basically disables the driver.
>
> Well, in my case, I was using the radeon.modeset=0 variant to rule out
> issues in x.org. And in my case x.org did start still, albeit with a
> jacked-up resolution.
>
> But in Laszlo's case, x.org gets "puzzled" too.
>

Maybe your distro's xorg has some generic vga fallback method. I am not aware 
that mine (Debian Testing) has one.
BTW I use Debian Testing (xfce) and glamor (compiled from git) so i need a 
specific xorg.conf.

15-rc1: radeon modesetting fails

2014-04-16 Thread Christian König 
Am 16.04.2014 10:32, schrieb Kertesz Laszlo:
> Borislav Petkov wrote:
>> On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
>>> Turning off modesetting basically disables the driver.
>>
>> Well, in my case, I was using the radeon.modeset=0 variant to rule out
>> issues in x.org. And in my case x.org did start still, albeit with a
>> jacked-up resolution.
>>
>> But in Laszlo's case, x.org gets "puzzled" too.
>>
>
> Maybe your distro's xorg has some generic vga fallback method. I am 
> not aware that mine (Debian Testing) has one.
> BTW I use Debian Testing (xfce) and glamor (compiled from git) so i 
> need a specific xorg.conf.
>

Using "nomodeset" or radeon.modeset=0 tries to use the deprecated user 
mode setting, which in your case isn't even supported by the driver.

Please provide dmesg logs with drm-debug=0xe instead.

Thanks in advance,
Christian.

15-rc1: radeon modesetting fails

2014-04-16 Thread Kertesz Laszlo 
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
>> Honestly didnt try that but i assume yes, since the screens go black
>> when it should change resolution.
>
> Pls try it and let us know whether you see the machine booting further,
> albeit without modesetting.
>
> Thanks.
>

Yes, it is working that way. But no X, i assume this is expected.

-- 
O zi buna,
Kertesz Laszlo
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.15.0-rc1-00012-g55101e2-dirty (laca at 
laca-desktop) (gcc version 4.8.2 (Debian 4.8.2-16) ) #2 SMP Tue Apr 15 23:50:45 
EEST 2014
[0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-3.15.0-rc1-00012-g55101e2-dirty 
root=UUID=89d577ec-47b9-4aa7-96a1-ad1f5092ead6 ro 
resume=UUID=bafe38cf-553c-433b-ae37-118bdeebbfac ignore_loglevel radeon.dpm=1 
it87.force_id=0x8728 radeon.modeset=0
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7cce] usable
[0.00] BIOS-e820: [mem 0x7ccf-0x7cd1] reserved
[0.00] BIOS-e820: [mem 0x7cd2-0x7cfe2fff] usable
[0.00] BIOS-e820: [mem 0x7cfe3000-0x7d0aefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7d0af000-0x7e1c4fff] reserved
[0.00] BIOS-e820: [mem 0x7e1c5000-0x7e1c5fff] usable
[0.00] BIOS-e820: [mem 0x7e1c6000-0x7e3cbfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7e3cc000-0x7e84] usable
[0.00] BIOS-e820: [mem 0x7e85-0x7efe0fff] reserved
[0.00] BIOS-e820: [mem 0x7efe1000-0x7eff] usable
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023eff] usable
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. To be filled by 
O.E.M./F2A88X-D3H, BIOS F3 11/18/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x23f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B write-through
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00023f00 aka 9200M
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820: update [mem 0x8000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0x7f000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fd7b0-0x000fd7bf] mapped at 
[880fd7b0]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [88098000] 98000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01a69000, 0x01a69fff] PGTABLE
[0.00] BRK [0x01a6a000, 0x01a6afff] PGTABLE
[0.00] BRK [0x01a6b000, 0x01a6bfff] PGTABLE
[0.00] init_memory_mapping: [mem 0x23ee0-0x23eff]
[0.00]  [mem 0x23ee0-0x23eff] page 2M
[0.00] BRK [0x01a6c000, 0x01a6cfff] PGTABLE
[0.00] init_memory_mapping: [mem 0x23c00-0x23edf]
[0.00]  [mem 0x23c00-0x23edf] page 2M
[0.00] init_memory_mapping: [mem 0x2-0x23bff]
[0.00]  [mem 0x2-0x23bff] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x7cce]
[

15-rc1: radeon modesetting fails

2014-04-16 Thread Borislav Petkov 
On Tue, Apr 15, 2014 at 10:32:56PM +, Deucher, Alexander wrote:
> Turning off modesetting basically disables the driver.

Well, in my case, I was using the radeon.modeset=0 variant to rule out
issues in x.org. And in my case x.org did start still, albeit with a
jacked-up resolution.

But in Laszlo's case, x.org gets "puzzled" too.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

15-rc1: radeon modesetting fails

2014-04-15 Thread Deucher, Alexander 
> -Original Message-
> From: Kertesz Laszlo [mailto:laszlo.kertesz at gmail.com]
> Sent: Tuesday, April 15, 2014 5:50 PM
> To: Borislav Petkov
> Cc: Alex Deucher; Deucher, Alexander; Koenig, Christian; Maling list - DRI
> developers; lkml
> Subject: Re: 15-rc1: radeon modesetting fails
> 
> Borislav Petkov wrote:
> > On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
> >> Honestly didnt try that but i assume yes, since the screens go black
> >> when it should change resolution.
> >
> > Pls try it and let us know whether you see the machine booting further,
> > albeit without modesetting.
> >
> > Thanks.
> >
> 
> Yes, it is working that way. But no X, i assume this is expected.

Turning off modesetting basically disables the driver.

Alex

15-rc1: radeon modesetting fails

2014-04-15 Thread Kertesz Laszlo 
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
>> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel,
>> drm, mesa built from git today. I see nothing and receive no message
>> on the monitors (i have 2 identical ones, one on the DVI andother on
>> HDMI), but the system is running fine otherwise it seems, i could
>> switch to the console, log in and reboot blindly. Cristian's branch
>> didnt help.
>>
>> Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
>
> Does booting with "radeon.modeset=0" help?
>
Honestly didnt try that but i assume yes, since the screens go black when it 
should change resolution.

-- 
O zi buna,
Kertesz Laszlo

15-rc1: radeon modesetting fails

2014-04-15 Thread Kertesz Laszlo 
Alex Deucher wrote:
> On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov  wrote:
>> Hi Christian,
>>
>> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
>>> Hi Borislav,
>>>
>>> that's a known issue and should be fixed in the next rc, see this
>>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>>
>>> You might also want to try my branch with 3.15 fixes which includes
>>> the necessary patch for this: 
>>> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>>
>>> Let me know if that branch works for you or not.
>>
>> so I went and merged your branch as you suggested. Btw, on its tip it
>> has:
>>
>> commit ec02666dd0791312b5820e1a9a023681d99d07ec
>> Author: Quentin Casasnovas 
>> Date:   Tue Mar 18 17:16:52 2014 +0100
>>
>>  drm/radeon: memory leak on bo reservation failure. v2
>>
>> (just checking whether I got the right one)
>>
>> and, unfortunately, no change - same problem. Let me know if I should
>> bisect the subset of 59 radeon patches which went in during the merge
>> window...
>>
>> Btw, just in case, I went and updated radeon firmware in
>> /lib/firmware/radeon/ from upstream but it didn't change anything.
>
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue?  We may need to tweak the pll parameters for older asics.
>
> Alex
>
>>

Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, drm, mesa 
built from git today. I see nothing and receive no message on the monitors (i 
have 2 identical ones, one on the DVI andother on HDMI), but the system is 
running fine  otherwise it seems, i could switch to the console, log in and 
reboot blindly. Cristian's branch didnt help.

Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.

Attached dmesg (booted the unmodified rc1 kernel, switched to tty1 and rebooted 
blindly).

-- 
O zi buna,
Kertesz Laszlo
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.15.0-rc1 (laca at laca-desktop) (gcc version 
4.8.2 (Debian 4.8.2-16) ) #2 SMP Mon Apr 14 19:27:37 EEST 2014
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.15.0-rc1 
root=UUID=89d577ec-47b9-4aa7-96a1-ad1f5092ead6 ro 
resume=UUID=bafe38cf-553c-433b-ae37-118bdeebbfac ignore_loglevel radeon.dpm=1 
it87.force_id=0x8728
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7cce] usable
[0.00] BIOS-e820: [mem 0x7ccf-0x7cd1] reserved
[0.00] BIOS-e820: [mem 0x7cd2-0x7cfe2fff] usable
[0.00] BIOS-e820: [mem 0x7cfe3000-0x7d0aefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7d0af000-0x7e1c4fff] reserved
[0.00] BIOS-e820: [mem 0x7e1c5000-0x7e1c5fff] usable
[0.00] BIOS-e820: [mem 0x7e1c6000-0x7e3cbfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7e3cc000-0x7e84] usable
[0.00] BIOS-e820: [mem 0x7e85-0x7efe0fff] reserved
[0.00] BIOS-e820: [mem 0x7efe1000-0x7eff] usable
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023eff] usable
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. To be filled by 
O.E.M./F2A88X-D3H, BIOS F3 11/18/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x23f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B write-through
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1

15-rc1: radeon modesetting fails

2014-04-15 Thread Borislav Petkov 
On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
> Honestly didnt try that but i assume yes, since the screens go black
> when it should change resolution.

Pls try it and let us know whether you see the machine booting further,
albeit without modesetting.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

15-rc1: radeon modesetting fails

2014-04-15 Thread Borislav Petkov 
On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel,
> drm, mesa built from git today. I see nothing and receive no message
> on the monitors (i have 2 identical ones, one on the DVI andother on
> HDMI), but the system is running fine otherwise it seems, i could
> switch to the console, log in and reboot blindly. Cristian's branch
> didnt help.
>
> Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.

Does booting with "radeon.modeset=0" help?

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

15-rc1: radeon modesetting fails

2014-04-15 Thread Borislav Petkov 
On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian K?nig wrote:
> >Does reverting:
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> >fix the issue?  We may need to tweak the pll parameters for older asics.
> 
> Yeah, indeed the most likely cause. Please provide dmesg outputs created
> with drm.ebug=0xe for the old and the new kernel.

Hey, I finally haz 15-rc1+ running here. And I can even see something!

:-)

Ok, so I reverted 32167016076f ontop of Christian's drm-fixes-3.15-wip
branch which didn't apply cleanly. So I ended up fixing the conflicts
and got the revert below.

With it, the machine booted fine, so it looks like the revert worked.

Christian, I'm sending dmesg outputs in another private mail to you
guys.

Thanks.

---
From: Borislav Petkov 
Date: Tue, 15 Apr 2014 16:00:58 +0200
Subject: [PATCH] Revert "drm/radeon: rework finding display PLL numbers v2"

This reverts commit 32167016076f714f0e35e287fbead7de0f1fb179.

Conflicts:
drivers/gpu/drm/radeon/radeon_display.c
---
 drivers/gpu/drm/radeon/radeon_display.c | 246 
 1 file changed, 90 insertions(+), 156 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 2f42912031ac..83891923ac2d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -34,8 +34,6 @@
 #include 
 #include 

-#include 
-
 static void avivo_crtc_load_lut(struct drm_crtc *crtc)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
@@ -802,57 +800,66 @@ int radeon_ddc_get_modes(struct radeon_connector 
*radeon_connector)
 }

 /* avivo */
+static void avivo_get_fb_div(struct radeon_pll *pll,
+u32 target_clock,
+u32 post_div,
+u32 ref_div,
+u32 *fb_div,
+u32 *frac_fb_div)
+{
+   u32 tmp = post_div * ref_div;

-/**
- * avivo_reduce_ratio - fractional number reduction
- *
- * @nom: nominator
- * @den: denominator
- * @nom_min: minimum value for nominator
- * @den_min: minimum value for denominator
- *
- * Find the greatest common divisor and apply it on both nominator and
- * denominator, but make nominator and denominator are at least as large
- * as their minimum values.
- */
-static void avivo_reduce_ratio(unsigned *nom, unsigned *den,
-  unsigned nom_min, unsigned den_min)
+   tmp *= target_clock;
+   *fb_div = tmp / pll->reference_freq;
+   *frac_fb_div = tmp % pll->reference_freq;
+
+if (*fb_div > pll->max_feedback_div)
+   *fb_div = pll->max_feedback_div;
+else if (*fb_div < pll->min_feedback_div)
+*fb_div = pll->min_feedback_div;
+}
+
+static u32 avivo_get_post_div(struct radeon_pll *pll,
+ u32 target_clock)
 {
-   unsigned tmp;
-
-   /* reduce the numbers to a simpler ratio */
-   tmp = gcd(*nom, *den);
-   *nom /= tmp;
-   *den /= tmp;
-
-   /* make sure nominator is large enough */
-if (*nom < nom_min) {
-   tmp = (nom_min + *nom - 1) / *nom;
-   *nom *= tmp;
-   *den *= tmp;
+   u32 vco, post_div, tmp;
+
+   if (pll->flags & RADEON_PLL_USE_POST_DIV)
+   return pll->post_div;
+
+   if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
+   if (pll->flags & RADEON_PLL_IS_LCD)
+   vco = pll->lcd_pll_out_min;
+   else
+   vco = pll->pll_out_min;
+   } else {
+   if (pll->flags & RADEON_PLL_IS_LCD)
+   vco = pll->lcd_pll_out_max;
+   else
+   vco = pll->pll_out_max;
}

-   /* make sure the denominator is large enough */
-   if (*den < den_min) {
-   tmp = (den_min + *den - 1) / *den;
-   *nom *= tmp;
-   *den *= tmp;
+   post_div = vco / target_clock;
+   tmp = vco % target_clock;
+
+   if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
+   if (tmp)
+   post_div++;
+   } else {
+   if (!tmp)
+   post_div--;
}
+
+   if (post_div > pll->max_post_div)
+   post_div = pll->max_post_div;
+   else if (post_div < pll->min_post_div)
+   post_div = pll->min_post_div;
+
+   return post_div;
 }

-/**
- * radeon_compute_pll_avivo - compute PLL paramaters
- *
- * @pll: information about the PLL
- * @dot_clock_p: resulting pixel clock
- * fb_div_p: resulting feedback divider
- * frac_fb_div_p: fractional part of the feedback divider
- * ref_div_p: resulting reference divider
- * post_div_p: resulting reference divider
- *
- * Try to calculate the PLL parameters to generate the given frequency:
- *

15-rc1: radeon modesetting fails

2014-04-15 Thread Christian König 
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue?  We may need to tweak the pll parameters for older asics.

Yeah, indeed the most likely cause. Please provide dmesg outputs created 
with drm.ebug=0xe for the old and the new kernel.

Christian.

Am 15.04.2014 15:06, schrieb Alex Deucher:
> On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov  wrote:
>> Hi Christian,
>>
>> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
>>> Hi Borislav,
>>>
>>> that's a known issue and should be fixed in the next rc, see this
>>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>>
>>> You might also want to try my branch with 3.15 fixes which includes
>>> the necessary patch for this: 
>>> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>>
>>> Let me know if that branch works for you or not.
>> so I went and merged your branch as you suggested. Btw, on its tip it
>> has:
>>
>> commit ec02666dd0791312b5820e1a9a023681d99d07ec
>> Author: Quentin Casasnovas 
>> Date:   Tue Mar 18 17:16:52 2014 +0100
>>
>>  drm/radeon: memory leak on bo reservation failure. v2
>>
>> (just checking whether I got the right one)
>>
>> and, unfortunately, no change - same problem. Let me know if I should
>> bisect the subset of 59 radeon patches which went in during the merge
>> window...
>>
>> Btw, just in case, I went and updated radeon firmware in
>> /lib/firmware/radeon/ from upstream but it didn't change anything.
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue?  We may need to tweak the pll parameters for older asics.
>
> Alex
>
>> Thanks.
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

15-rc1: radeon modesetting fails

2014-04-15 Thread Borislav Petkov 
Hi Christian,

On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
> Hi Borislav,
> 
> that's a known issue and should be fixed in the next rc, see this
> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
> 
> You might also want to try my branch with 3.15 fixes which includes
> the necessary patch for this: 
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
> 
> Let me know if that branch works for you or not.

so I went and merged your branch as you suggested. Btw, on its tip it
has:

commit ec02666dd0791312b5820e1a9a023681d99d07ec
Author: Quentin Casasnovas 
Date:   Tue Mar 18 17:16:52 2014 +0100

drm/radeon: memory leak on bo reservation failure. v2

(just checking whether I got the right one)

and, unfortunately, no change - same problem. Let me know if I should
bisect the subset of 59 radeon patches which went in during the merge
window...

Btw, just in case, I went and updated radeon firmware in
/lib/firmware/radeon/ from upstream but it didn't change anything.

Thanks.

15-rc1: radeon modesetting fails

2014-04-15 Thread Christian König 
Hi Borislav,

that's a known issue and should be fixed in the next rc, see this 
bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009

You might also want to try my branch with 3.15 fixes which includes the 
necessary patch for this: 
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip

Let me know if that branch works for you or not.

Regards,
Christian.

Am 15.04.2014 09:02, schrieb Borislav Petkov:
> Hi guys,
>
> so I'm booting 15-rc1 + tip/master and around the time modesetting gets
> initialized, the screen blanks and on it appears a message from the
> monitors:
>
> "The current input timing is not supported by the monitor display.
> Please change your input timing to 1920x1200 at 60Hz or any other monitor
> listed timing as per the monitor specifications."
>
> The box is still responsive, I can reboot it with Ctrl-Alt-Del but
> screens are blank.
>
> If I boot with radeon.modeset=0, I see the normal nomodeset big letters
> on the console and not very optimal screen resolution.
>
> Diffing drm init chatter from dmesg shows only this:
>
> --- /tmp/working2014-04-15 08:40:21.979985352 +0200
> +++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200
> @@ -44,4 +44,5 @@
>   [drm]pitch is 7680
>   fbcon: radeondrmfb (fb0) is primary device
>   radeon :01:00.0: fb0: radeondrmfb frame buffer device
> -[drm] Initialized radeon 2.37.0 20080528 for :01:00.0 on minor 0
> +[drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0
> +
>
> Below is the whole thing, btw.
>
> Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick
> bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?
>
> git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l
> 59
>
> Thanks.
>
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA).
> [drm] register mmio base: 0xFEA2
> [drm] register mmio size: 65536
> [drm] Detected VRAM RAM=512M, BAR=256M
> [drm] RAM width 128bits DDR
> [drm] radeon: 512M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Loading RV635 Microcode
> [drm] Internal thermal controller without fan control
> [drm] radeon: power management initialized
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
> [drm] PCIE GART of 512M enabled (table at 0x0004).
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> [drm] ring test on 0 succeeded in 0 usecs
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   DVI-I-1
> [drm]   HPD1
> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY
> [drm] CRT2: INTERNAL_KLDSCP_DAC2
> [drm] Connector 1:
> [drm]   DIN-1
> [drm]   Encoders:
> [drm] TV1: INTERNAL_KLDSCP_DAC2
> [drm] Connector 2:
> [drm]   DVI-I-2
> [drm]   HPD2
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] DFP2: INTERNAL_KLDSCP_LVTMA
> [drm] fb mappable at 0xC0141000
> [drm] vram apper at 0xC000
> [drm] size 9216000
> [drm] fb depth is 24
> [drm]pitch is 7680
> fbcon: radeondrmfb (fb0) is primary device
> radeon :01:00.0: fb0: radeondrmfb frame buffer device
> [drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0
>

15-rc1: radeon modesetting fails

2014-04-15 Thread Alex Deucher 
On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov  wrote:
> Hi Christian,
>
> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
>> Hi Borislav,
>>
>> that's a known issue and should be fixed in the next rc, see this
>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>
>> You might also want to try my branch with 3.15 fixes which includes
>> the necessary patch for this: 
>> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>
>> Let me know if that branch works for you or not.
>
> so I went and merged your branch as you suggested. Btw, on its tip it
> has:
>
> commit ec02666dd0791312b5820e1a9a023681d99d07ec
> Author: Quentin Casasnovas 
> Date:   Tue Mar 18 17:16:52 2014 +0100
>
> drm/radeon: memory leak on bo reservation failure. v2
>
> (just checking whether I got the right one)
>
> and, unfortunately, no change - same problem. Let me know if I should
> bisect the subset of 59 radeon patches which went in during the merge
> window...
>
> Btw, just in case, I went and updated radeon firmware in
> /lib/firmware/radeon/ from upstream but it didn't change anything.

Does reverting:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
fix the issue?  We may need to tweak the pll parameters for older asics.

Alex

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

15-rc1: radeon modesetting fails

2014-04-15 Thread Borislav Petkov 
Hi guys,

so I'm booting 15-rc1 + tip/master and around the time modesetting gets
initialized, the screen blanks and on it appears a message from the
monitors:

"The current input timing is not supported by the monitor display.
Please change your input timing to 1920x1200 at 60Hz or any other monitor
listed timing as per the monitor specifications."

The box is still responsive, I can reboot it with Ctrl-Alt-Del but
screens are blank.

If I boot with radeon.modeset=0, I see the normal nomodeset big letters
on the console and not very optimal screen resolution.

Diffing drm init chatter from dmesg shows only this:

--- /tmp/working2014-04-15 08:40:21.979985352 +0200
+++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200
@@ -44,4 +44,5 @@
 [drm]pitch is 7680
 fbcon: radeondrmfb (fb0) is primary device
 radeon :01:00.0: fb0: radeondrmfb frame buffer device
-[drm] Initialized radeon 2.37.0 20080528 for :01:00.0 on minor 0
+[drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0
+

Below is the whole thing, btw.

Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick
bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?

git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l
59

Thanks.

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA).
[drm] register mmio base: 0xFEA2
[drm] register mmio size: 65536
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Loading RV635 Microcode
[drm] Internal thermal controller without fan control
[drm] radeon: power management initialized
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 512M enabled (table at 0x0004).
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD1
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm]   DIN-1
[drm]   Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I-2
[drm]   HPD2
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] fb mappable at 0xC0141000
[drm] vram apper at 0xC000
[drm] size 9216000
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
radeon :01:00.0: fb0: radeondrmfb frame buffer device
[drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--