AMD Carrizo HDMI audio

[Andy Furniss]

João Paulo Rechi Vita wrote:

> Still no sound with the branch you've pointed. Logs can be found here
> in case you're interested:
> https://gist.github.com/jprvita/7966532c7a4b67c74621c9374e20a418

You could try 4.6-wip-dal

https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.6-wip-dal

I don't know about Carrizo but my Tonga was Ok with that but not with 4.7

[radeonsi, regression, bisected] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

[Andy Furniss]

Kai Wasserbäch wrote:
> Kai Wasserbäch wrote on 15.11.2014 22:22:
>> Kai Wasserbäch wrote on 15.11.2014 16:33:
>>> Is there anything besides a bisect you would need to debug this?
>>
>> Ok, I did a bisection, but that time was wasted for sure. My "first
>> bad commit" isn't bad at all. Is there any way to improve that
>> experience? I'm really loathe to go through the dozen boots again,
>> just to get another broken bisection.
>
> Ok, after looking at the changes for radeon I decided to try the HEAD
> of drm-next-3.19 (c81b99423bd9d3fc35ac8752ca5fb4c50eab063c). That was
> still good. Armed with this much smaller bisection range, I came up
> with a result that sounds at least believable:
> 3cd76f3901e73a4a61d78c4526dcbf6d87c9a928 is the first bad commit
> commit 3cd76f3901e73a4a61d78c4526dcbf6d87c9a928 Author: Christian
> König  Date:   Mon Oct 13 12:41:47 2014
> +0200
>
> drm/radeon: update the VM after setting BO address (v2)

Yes, that seems to be it for me also - but just to confuse things I've
been running with that for several weeks without incident, so something
brought in from the recent merges/a new patch doesn't play nicely with it.

If you wanted to test you could get back to how drm-next-3.19-wip was 
last week by

git reset --hard 3.18.0-rc2-gc76c717

and you can see it's there with git log about 6/7 commits down.

[radeonsi, regression] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

[Andy Furniss]

Kai Wasserbäch wrote:
> Kai Wasserbäch wrote on 15.11.2014 16:33:
>> Is there anything besides a bisect you would need to debug this?
>
> Ok, I did a bisection, but that time was wasted for sure. My "first bad 
> commit"
> isn't bad at all. Is there any way to improve that experience? I'm really 
> loathe
> to go through the dozen boots again, just to get another broken bisection.

So you don't have any bads at all on linus kernel?

I agree bisecting kernels is a pain :-)

Of course it's possible our issues aren't the same anyway.

[radeonsi, regression] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

[Andy Furniss]

Andy Furniss wrote:

>> I didn't have time to bisect this yet, but maybe you have an idea
>> what might cause this right away. I'm also not sure if it's a bug
>> in the DRI portion of the kernel.
>>
>> Is there anything besides a bisect you would need to debug this?

I am just a user - but after some testing maybe it would be better if
you can reproduce on similar kernel to your old one and bisect that.

On drm-next-3.19-wip I only have to go back 4 commits to hit ones I've
been running for weeks (and I am still failing if I reset to there) so
for me at least bisecting this tree isn't really an option - I wouldn't
be testing like for like.

> I also see an issue with current drm-next-3.19-wip branch with
> pitcairn and demos line Unigine Valley and Unreal Elemental.
>
> I was running last weeks drm-next-3.19-wip OK with these, so I guess
> the issue is near head, though the way other things get merged in etc
> makes it a bit hard to see what's new just looking at cgit.

Stable for me is drm-next-3.19-wip at 3.18.0-rc2-gc76c717 failing
current = 3.18.0-rc4-gbe762d1 so it seems to be something in the merge
that took rc-2 to rc-4.

[radeonsi, regression] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

[Andy Furniss]

Kai Wasserbäch wrote:
> Dear Alex, I've built your drm-next-3.19-wip branch (commit
> be762d181e130d0e6e630f823400e9e1ba3bafd8) and with that kernel and
> the graphics stack detailed below, I can't run any of my Steam games
> anymore. All of them immediately go into the defunct state, when
> their 3D engine is powered up (ie. I get to see the intro/vendor
> videos but almost nothing after that, including the main menus). When
> I attach gdb to a game process, the games stop on a SIGPWR. If I hit
> c I usually get a SIGXCPU next, sometimes it's another SIGPWR. But
> no matter how often you hit c you always get one of those two signals
> and the game is just dead. Normal desktop with 3D acceleration and
> effects (KDE) is working fine.
>
> This is a regression over my previous kernel
> (Git:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git:v3.18-rc1
>
>
+  and
> ).
>
> I didn't have time to bisect this yet, but maybe you have an idea
> what might cause this right away. I'm also not sure if it's a bug in
> the DRI portion of the kernel.
>
> Is there anything besides a bisect you would need to debug this?

I also see an issue with current drm-next-3.19-wip branch with pitcairn
and demos line Unigine Valley and Unreal Elemental.

I was running last weeks drm-next-3.19-wip OK with these, so I guess the
issue is near head, though the way other things get merged in etc makes
it a bit hard to see what's new just looking at cgit.

This is what I get in dmesg

[  730.830960] BUG: unable to handle kernel paging request at 
eb0400404000
[  730.830993] IP: [] kfree+0x62/0x1c0
[  730.831013] PGD 0
[  730.831019] Oops:  [#1] PREEMPT SMP
[  730.831034] Modules linked in: radeon fbcon bitblit fbcon_rotate 
fbcon_ccw fbcon_ud fbcon_cw softcursor snd_hda_codec_hdmi font 
snd_hda_codec_realtek tileblit snd_hda_codec_generic i2c_algo_bit 
snd_usb_audio snd_hda_intel drm_kms_helper snd_hda_controller 
snd_usbmidi_lib snd_hda_codec snd_rawmidi ttm snd_seq_device snd_hwdep 
snd_pcm drm snd_timer ata_generic r8169 pata_acpi snd xhci_pci xhci_hcd 
plusb soundcore asus_atk0110 pcspkr acpi_cpufreq usbnet mii k10temp 
i2c_piix4 pata_jmicron
[  730.831247] CPU: 0 PID: 576 Comm: RenderThread 1 Not tainted 
3.18.0-rc4-gbe762d1 #1
[  730.831274] Hardware name: System manufacturer System Product 
Name/M4A89GTD-PRO/USB3, BIOS 145605/04/2010
[  730.831308] task: 8802254e60c0 ti: 8801c69a4000 task.ti: 
8801c69a4000
[  730.831333] RIP: 0010:[]  [] 
kfree+0x62/0x1c0
[  730.831360] RSP: 0018:8801c69a7c98  EFLAGS: 00010286
[  730.831377] RAX: eb0400404000 RBX: c9001010 RCX: 
0100
[  730.831400] RDX: ea00 RSI: 88008a528118 RDI: 
c9001010
[  730.831424] RBP: 8801c69a7cd8 R08: c9001010 R09: 
880224d942e8
[  730.831447] R10: 02d0 R11: 880224d941b8 R12: 
8801bf3c9a80
[  730.831471] R13: a030983c R14: 8801c69a7d00 R15: 
8801c69a7dc8
[  730.831495] FS:  7f3911d62700() GS:88022fc0() 
knlGS:
[  730.831523] CS:  0010 DS:  ES:  CR0: 80050033
[  730.831542] CR2: eb0400404000 CR3: 0001d1de8000 CR4: 
07f0
[  730.832968] Stack:
[  730.834373]  8801c69a7ca8 815379c1 8801c69a7cd8 
8801be8796c0
[  730.835811]  8801bf3c9a80 880224d94000 8801c69a7d00 
8801c69a7dc8
[  730.837257]  8801c69a7d78 a030983c c9001010 
c900
[  730.838699] Call Trace:
[  730.840126]  [] ? _raw_spin_unlock+0x11/0x30
[  730.841597]  [] radeon_gem_va_ioctl+0x4fc/0x610 
[radeon]
[  730.843073]  [] drm_ioctl+0x1ac/0x630 [drm]
[  730.844541]  [] ? preempt_count_add+0x55/0xb0
[  730.846007]  [] ? _raw_spin_unlock_irqrestore+0x13/0x30
[  730.847475]  [] ? __pm_runtime_resume+0x56/0x70
[  730.848947]  [] radeon_drm_ioctl+0x53/0x90 [radeon]
[  730.850423]  [] do_vfs_ioctl+0x2d0/0x4b0
[  730.851885]  [] ? __fget+0x74/0xb0
[  730.853347]  [] SyS_ioctl+0x47/0x90
[  730.854812]  [] system_call_fastpath+0x16/0x1b
[  730.856284] Code: 00 00 00 80 ff 77 00 00 48 01 d8 48 0f 42 15 b6 03 
8c 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 
01 d0 <48> 8b 10 80 e6 80 0f 85 2f 01 00 00 49 89 c6 49 8b 06 a8 80 0f
[  730.857914] RIP  [] kfree+0x62/0x1c0
[  730.859465]  RSP 
[  730.861021] CR2: eb0400404000
[  730.872919] ---[ end trace c7fce73a27e29045 ]---

[PATCH 5/5] drm/edid: Parse and handle HDMI deep color modes.

[Andy Furniss]

Alex Deucher wrote:
> From: Mario Kleiner 
>
> Check the HDMI cea block for deep color mode bits. If available,
> assign the highest supported bpc for a hdmi display, corresponding
> to the given deep color modes.

I haven't had time to test further, but with all 5 applied on top of 
deathsimple drm-fixes I loose output to TV as soon as I startx.

It worked in fbcon before starting X, but not switching vt after.

My TV according to edid-decode does support deep colour.

Nothing obvious to see in dmesg/Xorg.0.log and xrandr --verbose looked 
like it was on, tried some different modes, but nothing.

R9 270X

[PATCH] drm/radeon: disable dpm on rv770 by default

[Andy Furniss]

Alex Deucher wrote:

> I ran into similar issues right after dpm support was released.  I'd
> done most of my development on gcc 4.6 and everything worked fine
> and upon upgrading to 4.7 or 4.8, tons of stuff broke.  It ended up
> at least partially being related to indexing variable sized arrays:
> 48fa04c3fcdb4f6ac041976bedaf19ca5bee20c0
> f90555cbe629e14c6af1dcec1933a3833ecd321f
> 607f2c2791ec81e5abca6213ff037e9405378be1
> a7ee824a6255e347ea76e2f00827e81bbe01004e plus some others, but there
> may still be problematic cases.

Ahh, thanks for that, at least I know now there's no point in me
building a whole new LFS.

[PATCH] drm/radeon: disable dpm on rv770 by default

[Andy Furniss]

Alex Deucher wrote:
> There seem to be stability issues on a number of cards.
>
> bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286
> https://bugzilla.redhat.com/show_bug.cgi?id=1085785
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619

Well TBH I don't know whether the following is useful info or not - it
could just be an unrelated waste of your time.

I have run my 4890 with dpm=1 from when it first appeared without issue
till recently.

As in the bug above I can't now use two screens - but the thing is,  I
use a (getting old) LFS, I don't use the TV that much, but when I
noticed the issue I tried to bisect and I reached the commit after my
working start point.

It turned out that my working was the last kernel I compiled with GCC
4.6.3. I had upgraded to GCC 4.8.2 and no kernel built with that can
handle 2 screens without locking, no sysrq, no network but very rarely
may unlock for a short while (did a dmesg when this happened, nothing
unusual logged then it locked again).

I built my GCC 4.6.3 again and built the same recent kernel (I run drm 
next or
fixes) and I have so far not been able to lock it with 2 screens.

Of course it could just be something on my LFS is too old for recent
GCC, or because I don't use TV much I am being lucky with 4.6.3.

I will when I get time build 4.8.2 again and see if dpm=0 works for me.

rv770_restrict_performance_levels_before_switch failed

[Andy Furniss]

Built drm next yesterday was running drm fixes from a couple of weeks 
ago previously, card is rv790.

Have powered up twice since and both times seen logged -

[drm:rv770_dpm_set_power_state] *ERROR* 
rv770_restrict_performance_levels_before_switch failed

Today was 79 sec after boot, though I don't startx automatically so it 
may have been soon after that.

Clock switching does seem to be working OK.

Radeon Rv790 "Forbidden register 0x0030 in cs at 9"

[Andy Furniss]

Noticed this in dmesg today, it doesn't seem to break anything and it's 
not reproducable.

[ 2605.261326] Forbidden register 0x0030 in cs at 9
[ 2605.261335] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

Seems it was triggered by mplayer using vdpau just for display, though 
grepping kern.log only found one other on Oct 22nd.

mplayer has been used far more than just twice in this period.

Running drm-fixes today and drm-next on the 22nd.

[PATCH 000/165] radeon drm-next patches

[Andy Furniss]

Alex Deucher wrote:
> On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss  wrote:
>> Alex Deucher wrote:
>>>
>>> On Wed, Jun 26, 2013 at 9:21 AM,   wrote:
>>>>
>>>> From: Alex Deucher 
>>>>
>>>> These are the radeon patches for 3.11.  Some of these patches
>>>> are huge so, it might be easier to review things here:
>>>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip
>>>
>>>
>>> Updated branch:
>>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-2
>>> Takes into account comments from Jerome a Christian and contains a few
>>> DPM fixes.
>>
>>
>> I see there's a 3 now - I tested that (I guess currently it's the same as 2
>> anyway).
>>
>> On my rv790 there are no regressions so far, but whatever I do it stays low.
>
> This should work much better with with wip-5.

Yes, this works on my rv790 games get high and using vdpau/gl for video 
stays low (which is nice as the fan on my card is too noisy on high).

One thing which I guess 99.999% of people won't notice is that doing any 
thing with plain X + fluxbox (so no compositing) very briefly ramps up 
the speed.

As my fan is just audible on low but very quick to respond I can hear 
every time the screen gets updated eg. switching desktops, 
browsing+scrolling or switching tabs, even typing dmesg in an xterm 
which time shows as taking < 0.1 sec results in a fan change.

Re: [PATCH 000/165] radeon drm-next patches

[Andy Furniss]

Alex Deucher wrote:

On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss adf.li...@gmail.com wrote:

Alex Deucher wrote:


On Wed, Jun 26, 2013 at 9:21 AM,  alexdeuc...@gmail.com wrote:


From: Alex Deucher alexander.deuc...@amd.com

These are the radeon patches for 3.11.  Some of these patches
are huge so, it might be easier to review things here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip



Updated branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-2
Takes into account comments from Jerome a Christian and contains a few
DPM fixes.



I see there's a 3 now - I tested that (I guess currently it's the same as 2
anyway).

On my rv790 there are no regressions so far, but whatever I do it stays low.


This should work much better with with wip-5.


Yes, this works on my rv790 games get high and using vdpau/gl for video 
stays low (which is nice as the fan on my card is too noisy on high).


One thing which I guess 99.999% of people won't notice is that doing any 
thing with plain X + fluxbox (so no compositing) very briefly ramps up 
the speed.


As my fan is just audible on low but very quick to respond I can hear 
every time the screen gets updated eg. switching desktops, 
browsing+scrolling or switching tabs, even typing dmesg in an xterm 
which time shows as taking  0.1 sec results in a fan change.



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

[PATCH 000/165] radeon drm-next patches

[Andy Furniss]

Alex Deucher wrote:
> On Wed, Jun 26, 2013 at 9:21 AM,   wrote:
>> From: Alex Deucher 
>>
>> These are the radeon patches for 3.11.  Some of these patches
>> are huge so, it might be easier to review things here:
>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip
>
> Updated branch:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-2
> Takes into account comments from Jerome a Christian and contains a few
> DPM fixes.

I see there's a 3 now - I tested that (I guess currently it's the same 
as 2 anyway).

On my rv790 there are no regressions so far, but whatever I do it stays low.

echo profile > /sys/class/drm/card0/device/power_method = write error, 
is there a way to go back to manual setting with dpm?

I haven't tried rv670 yet - I couldn't see a new firmware for that, does 
it just not need one?

Re: [PATCH 000/165] radeon drm-next patches

[Andy Furniss]

Alex Deucher wrote:

On Wed, Jun 26, 2013 at 9:21 AM,  alexdeuc...@gmail.com wrote:

From: Alex Deucher alexander.deuc...@amd.com

These are the radeon patches for 3.11.  Some of these patches
are huge so, it might be easier to review things here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip


Updated branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-2
Takes into account comments from Jerome a Christian and contains a few
DPM fixes.


I see there's a 3 now - I tested that (I guess currently it's the same 
as 2 anyway).


On my rv790 there are no regressions so far, but whatever I do it stays low.

echo profile  /sys/class/drm/card0/device/power_method = write error, 
is there a way to go back to manual setting with dpm?


I haven't tried rv670 yet - I couldn't see a new firmware for that, does 
it just not need one?


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

drm-next build fail with gcc 4.6.3

[Andy Furniss]

   CC  drivers/video/console/vgacon.o
drivers/video/console/vgacon.c: In function ?vgacon_do_font_op?:
drivers/video/console/vgacon.c:1129:5: error: implicit declaration of 
function ?cond_resched? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/video/console/vgacon.o] Error 1

drm-next build fail with gcc 4.6.3

[Andy Furniss]

  CC  drivers/video/console/vgacon.o
drivers/video/console/vgacon.c: In function ‘vgacon_do_font_op’:
drivers/video/console/vgacon.c:1129:5: error: implicit declaration of 
function ‘cond_resched’ [-Werror=implicit-function-declaration]

cc1: some warnings being treated as errors
make[3]: *** [drivers/video/console/vgacon.o] Error 1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Alex Deucher wrote:
> On Sat, Jun 1, 2013 at 5:13 AM, Andy Furniss  wrote:
>> Daniel Vetter wrote:
>>
>>> Interlaced modes are supported on all intel platforms (except i8xx, hw
>>> can't do it there) and we have full support for CEA modes.
>>> -Daniel
>>
>>
>> OK, thanks, I guess it's an AMD driver issue rather than a more generic drm
>> thing then.
>
> You might try removing this chunk of code in radeon_atom_mode_fixup()
> in atombios_encoders.c
>
>  /* hw bug */
>  if ((mode->flags & DRM_MODE_FLAG_INTERLACE)
>  && (mode->crtc_vsync_start < (mode->crtc_vdisplay + 2)))
>  adjusted_mode->crtc_vsync_start =
> adjusted_mode->crtc_vdisplay + 2;

Thanks, but it doesn't make any difference.

To slightly correct what I said earlier when describing what I see -

at 1920x1080i the right quarter of the bottom line is rendering repeated 
x4 as the top line.

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Alex Deucher wrote:

On Sat, Jun 1, 2013 at 5:13 AM, Andy Furniss adf.li...@gmail.com wrote:

Daniel Vetter wrote:


Interlaced modes are supported on all intel platforms (except i8xx, hw
can't do it there) and we have full support for CEA modes.
-Daniel



OK, thanks, I guess it's an AMD driver issue rather than a more generic drm
thing then.


You might try removing this chunk of code in radeon_atom_mode_fixup()
in atombios_encoders.c

 /* hw bug */
 if ((mode-flags  DRM_MODE_FLAG_INTERLACE)
  (mode-crtc_vsync_start  (mode-crtc_vdisplay + 2)))
 adjusted_mode-crtc_vsync_start =
adjusted_mode-crtc_vdisplay + 2;


Thanks, but it doesn't make any difference.

To slightly correct what I said earlier when describing what I see -

at 1920x1080i the right quarter of the bottom line is rendering repeated 
x4 as the top line.


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

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Ville Syrj?l? wrote:
> On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
>> ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrj?l? 
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the video framerate exactly, and the audio and video clocks come
>>> from the same source, you should be able to avoid dropped/repeated
>>> frames without expensive operations such as resampling the audio to
>>> match video output rate.
>>>
>>> Rather than add both variants based on the CEA extension short video
>>> descriptors in do_cea_modes(), add only one variant there. Once all
>>> the EDID has been fully probed, do a loop over the entire probed mode
>>> list, during which we add the other variants for all modes that match
>>> CEA modes. This allows us to match modes that didn't come via the CEA
>>> short video descriptors. For example one Samsung TV here doesn't have
>>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>>> timing descriptor.
>>>
>>> Signed-off-by: Ville Syrj?l? 
>>> ---
>>> A few people requested this. Originally I was a bit opposed to it, but
>>> when I thought about it a bit more I figured if the audio and video
>>> clocks come from the same source (or happen to be close enough w/o
>>> significant drift), this could provide a better A/V sync w/o resampling
>>> tricks.
>>
>> I see this has gone in now, one thing I notice is that xorg/apps/xrandr
>> only prints Hz to 1dp so you can't see which mode is which for the 24p
>> and 30i cases.
>>
>> Maybe someone reading has commit access for xorg?
>
> Not sure if you noticed but I posted some relevant xrandr patches to
> xorg-devel. Unfortunately I got no response, and I've been too lazy
> to figure out who I need to pester.
>

Ahh, sorry I didn't see those, I just has a look at the current code to 
check it was still the same.

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
>
> Having both modes can be beneficial for video playback cases. If you can
> match the video framerate exactly, and the audio and video clocks come
> from the same source, you should be able to avoid dropped/repeated
> frames without expensive operations such as resampling the audio to
> match video output rate.
>
> Rather than add both variants based on the CEA extension short video
> descriptors in do_cea_modes(), add only one variant there. Once all
> the EDID has been fully probed, do a loop over the entire probed mode
> list, during which we add the other variants for all modes that match
> CEA modes. This allows us to match modes that didn't come via the CEA
> short video descriptors. For example one Samsung TV here doesn't have
> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
> timing descriptor.
>
> Signed-off-by: Ville Syrj?l? 
> ---
> A few people requested this. Originally I was a bit opposed to it, but
> when I thought about it a bit more I figured if the audio and video
> clocks come from the same source (or happen to be close enough w/o
> significant drift), this could provide a better A/V sync w/o resampling
> tricks.

I see this has gone in now, one thing I notice is that xorg/apps/xrandr 
only prints Hz to 1dp so you can't see which mode is which for the 24p 
and 30i cases.

Maybe someone reading has commit access for xorg?

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.


I see this has gone in now, one thing I notice is that xorg/apps/xrandr 
only prints Hz to 1dp so you can't see which mode is which for the 24p 
and 30i cases.


Maybe someone reading has commit access for xorg?



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

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Ville Syrjälä wrote:

On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:

ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.


I see this has gone in now, one thing I notice is that xorg/apps/xrandr
only prints Hz to 1dp so you can't see which mode is which for the 24p
and 30i cases.

Maybe someone reading has commit access for xorg?


Not sure if you noticed but I posted some relevant xrandr patches to
xorg-devel. Unfortunately I got no response, and I've been too lazy
to figure out who I need to pester.



Ahh, sorry I didn't see those, I just has a look at the current code to 
check it was still the same.


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

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Daniel Vetter wrote:

> Interlaced modes are supported on all intel platforms (except i8xx, hw
> can't do it there) and we have full support for CEA modes.
> -Daniel

OK, thanks, I guess it's an AMD driver issue rather than a more generic 
drm thing then.

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Daniel Vetter wrote:


Interlaced modes are supported on all intel platforms (except i8xx, hw
can't do it there) and we have full support for CEA modes.
-Daniel


OK, thanks, I guess it's an AMD driver issue rather than a more generic 
drm thing then.


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

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Daniel Vetter wrote:
> On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrjala at linux.intel.com 
> wrote:
>> From: Ville Syrj?l? 
>>
>> Having both modes can be beneficial for video playback cases. If you can
>> match the video framerate exactly, and the audio and video clocks come
>> from the same source, you should be able to avoid dropped/repeated
>> frames without expensive operations such as resampling the audio to
>> match video output rate.
>>
>> Rather than add both variants based on the CEA extension short video
>> descriptors in do_cea_modes(), add only one variant there. Once all
>> the EDID has been fully probed, do a loop over the entire probed mode
>> list, during which we add the other variants for all modes that match
>> CEA modes. This allows us to match modes that didn't come via the CEA
>> short video descriptors. For example one Samsung TV here doesn't have
>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>> timing descriptor.
>>
>> Signed-off-by: Ville Syrj?l? 
>> ---
>> A few people requested this. Originally I was a bit opposed to it, but
>> when I thought about it a bit more I figured if the audio and video
>> clocks come from the same source (or happen to be close enough w/o
>> significant drift), this could provide a better A/V sync w/o resampling
>> tricks.
>
> Yeah, I think this should be useful for a bunch of people. I've recently
> chatted with a few xbmc folks on #irc and one thing they've requested is
> mode fine-tuning. For DP we should have plenty of precision, but for HDMI
> we'd need to (slightly) frob the vtotal ever so often to compensate. With
> some runtime-tuning a la npt we should have perfect a/v sync without any
> audio resampling.

Apologies, for jumping in here, but assuming I haven't missed anything 
you've done already: do you have any plans for supporting CEA interlaced 
modes?

That's assuming they actually need any more support - I only know that 
they are slightly wrong for me testing with radeon + my TV - are they 
tested and known to work / not work on intel hw?

The symptom I get is not instantly obvious - the second half of the 
bottom line gets rendered and repeated as the top line.

For me the reason that proper support could in theory be useful, is that 
were there in future a way to sync up properly,  my TV will do a nice 
"free" deinterlace. Even on a fast quad core PC doing one as good on cpu 
is not possible for HD 50i.

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Daniel Vetter wrote:

On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.


Yeah, I think this should be useful for a bunch of people. I've recently
chatted with a few xbmc folks on #irc and one thing they've requested is
mode fine-tuning. For DP we should have plenty of precision, but for HDMI
we'd need to (slightly) frob the vtotal ever so often to compensate. With
some runtime-tuning a la npt we should have perfect a/v sync without any
audio resampling.


Apologies, for jumping in here, but assuming I haven't missed anything 
you've done already: do you have any plans for supporting CEA interlaced 
modes?


That's assuming they actually need any more support - I only know that 
they are slightly wrong for me testing with radeon + my TV - are they 
tested and known to work / not work on intel hw?


The symptom I get is not instantly obvious - the second half of the 
bottom line gets rendered and repeated as the top line.


For me the reason that proper support could in theory be useful, is that 
were there in future a way to sync up properly,  my TV will do a nice 
free deinterlace. Even on a fast quad core PC doing one as good on cpu 
is not possible for HD 50i.




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

UVD fails to init on rv790

[Andy Furniss]

Christian K?nig wrote:
> Hi Andy,
>
> crap! I feared that something like this would happen. IIRC we never
> tested UVD on an rv790, and this hardware isn't easy to get any more.
>
> RV770/RV790 have a separate UVD hardware generation (that's why they
> have their own firmware) and there possible is some bug or something
> like this that we haven't implemented. You couldn't give me SSH access
> to that system?

I can if you still need it this evening.

My stupid ISP has taken to blocking lots of things for their home users 
like git:// svn and nntp and I suspect it maybe the same for ssh.

The blocks are lifted at 20:00 local time (19:00 UTC) so I can mail you 
off list around then.

In the meantime I'll remember how to use iptables :-) and also repeat 
UVD patching/testing on a different boot in case I messed up.

UVD fails to init on rv790

[Andy Furniss]

Thanks AMD for getting this out :-)

I have an issue, though.

On HD4890 drm-fixes kernel (before yesterdays updates) got the new

R700_rlc.bin
RV770_uvd.bin

but on boot I get -

[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
ATOM BIOS: Wekiva
radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF 
(1024M used)
radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 436936 kiB
[TTM] Zone highmem: Available graphics memory: 1685484 kiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: irq 51 for MSI/MSI-X
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading RV770 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00257000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0xff893c00
radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0xff893c0c
radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005632c and cpu addr 0xfbb9632c
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
[drm] Enabling audio support
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[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]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0359000
[drm] vram apper at 0xD000
[drm] size 8294400
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 240x67
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0

UVD fails to init on rv790

[Andy Furniss]

Thanks AMD for getting this out :-)

I have an issue, though.

On HD4890 drm-fixes kernel (before yesterdays updates) got the new

R700_rlc.bin
RV770_uvd.bin

but on boot I get -

[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
ATOM BIOS: Wekiva
radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF 
(1024M used)

radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 436936 kiB
[TTM] Zone highmem: Available graphics memory: 1685484 kiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: irq 51 for MSI/MSI-X
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading RV770 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00257000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0xff893c00
radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0xff893c0c
radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005632c and cpu addr 0xfbb9632c

[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
[drm] Enabling audio support
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[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]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0359000
[drm] vram apper at 0xD000
[drm] size 8294400
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 240x67
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Andy Furniss]

Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 11:01:37AM +0000, Andy Furniss wrote:
>> no_wb=1 should work.
>
> Yeah, maybe all those radeon and other GPU module parameters' syntax
> should be documented somewhere - Documentation/kernel-parameters.txt for
> example, or a GPU-specific file, whatever - so that we can save us all
> the time and confusion. Provided this hasn't happened yet, of course.

modinfo radeon

will give a list assuming you use modules, I think all of them need =.

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Andy Furniss]

Borislav Petkov wrote:

> [   28.191072] radeon: `0' invalid for parameter `wb'
>
> although the whole driver blubber didn't appear on the console fterwards
> aso something got turned off allright.
>
> Then, I went and tried "radeon.no_wb" where the driver blubber appeared
> but AGP writeback was still enabled:

no_wb=1 should work.

GPU lockup CP stall for more than 10000msec on latest vanilla git

[Andy Furniss]

Markus Trippelsdorf wrote:

>> Does booting with radeon.wb=0 fix the issue?  Please make sure your
>> kernel has this patch:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246
>
> My kernel has this patch and radeon.wb=0 doesn't help.

I think that should be no_wb=1

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

[Andy Furniss]

Markus Trippelsdorf wrote:


Does booting with radeon.wb=0 fix the issue?  Please make sure your
kernel has this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246


My kernel has this patch and radeon.wb=0 doesn't help.


I think that should be no_wb=1



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

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Andy Furniss]

Borislav Petkov wrote:


[   28.191072] radeon: `0' invalid for parameter `wb'

although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.

Then, I went and tried radeon.no_wb where the driver blubber appeared
but AGP writeback was still enabled:


no_wb=1 should work.


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

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[Andy Furniss]

Borislav Petkov wrote:

On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:

no_wb=1 should work.


Yeah, maybe all those radeon and other GPU module parameters' syntax
should be documented somewhere - Documentation/kernel-parameters.txt for
example, or a GPU-specific file, whatever - so that we can save us all
the time and confusion. Provided this hasn't happened yet, of course.


modinfo radeon

will give a list assuming you use modules, I think all of them need =num.


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

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

Alex Deucher wrote:
> On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss  wrote:
>> Alex Deucher wrote:
>>>
>>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss  wrote:
>>>>
>>>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
>>>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
>>>> and then turn TV on and -
>>>>
>>>> xrandr --output DVI-0 --auto
>>>>
>>>> to bring up the the TV and get a clone of monitor.
>>>>
>>>> This still works with drm-core-next but not with drm-fixes (todays or
>>>> from a
>>>> few days ago).
>>>>
>>>> With df I now loose the monitor with signal out of range when doing
>>>> above,
>>>> the TV output is OK. To get the monitor back I need to turn off TV, then
>>>> off/auto the monitor.
>>>>
>>>> xrandr --output DVI-0 --off
>>>> xrandr --output DVI-1 --off
>>>> xrandr --output DVI-1 --auto
>>>>
>>>> The output from xrandr while the monitor is showing signal out of range
>>>> looks normal.
>>>>
>>>> If I boot with the TV on it works OK.
>>>
>>>
>>> Can you bisect?
>>
>>
>> 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
>> commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
>> Author: Alex Deucher 
>> Date:   Fri Oct 5 10:22:02 2012 -0400
>>
>>  drm/radeon: allocate PPLLs from low to high
>>
>>  The order shouldn't matter, but there have been problems
>>  reported on certain older asics.  This behaves more
>>  like the original code before the PPLL allocation
>>  rework.
>>
>>  Signed-off-by: Alex Deucher 
>>  Cc:  Markus Trippelsdorf 
>>
>>
>
> That's bizarre.  That patch reverts the behavior back to the 3.6 and
> earlier kernel behavior.  I guess it's some issue with the ordering of
> the modesetting programming sequence.  I've attached a couple of
> things to try.
>
> The first patch is a simple fix.  It just reverts back to the previous
> pll allocation order for discrete cards like yours:
> 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch
>
> The second set of patches implements a more complex fix which may help
> regardless of the order in which plls are allocated:
> 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
> 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
> 0003-drm-radeon-disable-the-pll-before-a-modeset.patch
>
> Can you see if the second set helps?  If not, please try the first patch.

The second set doesn't fix it.

The first patch does.

Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

Alex Deucher wrote:

On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss andy...@ukfsn.org wrote:

Alex Deucher wrote:


On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote:


For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
and then turn TV on and -

xrandr --output DVI-0 --auto

to bring up the the TV and get a clone of monitor.

This still works with drm-core-next but not with drm-fixes (todays or
from a
few days ago).

With df I now loose the monitor with signal out of range when doing
above,
the TV output is OK. To get the monitor back I need to turn off TV, then
off/auto the monitor.

xrandr --output DVI-0 --off
xrandr --output DVI-1 --off
xrandr --output DVI-1 --auto

The output from xrandr while the monitor is showing signal out of range
looks normal.

If I boot with the TV on it works OK.



Can you bisect?



29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Fri Oct 5 10:22:02 2012 -0400

 drm/radeon: allocate PPLLs from low to high

 The order shouldn't matter, but there have been problems
 reported on certain older asics.  This behaves more
 like the original code before the PPLL allocation
 rework.

 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc:  Markus Trippelsdorf mar...@trippelsdorf.de




That's bizarre.  That patch reverts the behavior back to the 3.6 and
earlier kernel behavior.  I guess it's some issue with the ordering of
the modesetting programming sequence.  I've attached a couple of
things to try.

The first patch is a simple fix.  It just reverts back to the previous
pll allocation order for discrete cards like yours:
0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch

The second set of patches implements a more complex fix which may help
regardless of the order in which plls are allocated:
0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
0003-drm-radeon-disable-the-pll-before-a-modeset.patch

Can you see if the second set helps?  If not, please try the first patch.


The second set doesn't fix it.

The first patch does.

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

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

Alex Deucher wrote:
> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss  wrote:
>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
>> and then turn TV on and -
>>
>> xrandr --output DVI-0 --auto
>>
>> to bring up the the TV and get a clone of monitor.
>>
>> This still works with drm-core-next but not with drm-fixes (todays or from a
>> few days ago).
>>
>> With df I now loose the monitor with signal out of range when doing above,
>> the TV output is OK. To get the monitor back I need to turn off TV, then
>> off/auto the monitor.
>>
>> xrandr --output DVI-0 --off
>> xrandr --output DVI-1 --off
>> xrandr --output DVI-1 --auto
>>
>> The output from xrandr while the monitor is showing signal out of range
>> looks normal.
>>
>> If I boot with the TV on it works OK.
>
> Can you bisect?

29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
Author: Alex Deucher 
Date:   Fri Oct 5 10:22:02 2012 -0400

 drm/radeon: allocate PPLLs from low to high

 The order shouldn't matter, but there have been problems
 reported on certain older asics.  This behaves more
 like the original code before the PPLL allocation
 rework.

 Signed-off-by: Alex Deucher 
 Cc:  Markus Trippelsdorf 

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

For the last 2 years when running a DVI 60Hz monitor with a radeon 
HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with 
the TV off and then turn TV on and -

xrandr --output DVI-0 --auto

to bring up the the TV and get a clone of monitor.

This still works with drm-core-next but not with drm-fixes (todays or 
from a few days ago).

With df I now loose the monitor with signal out of range when doing 
above, the TV output is OK. To get the monitor back I need to turn off 
TV, then off/auto the monitor.

xrandr --output DVI-0 --off
xrandr --output DVI-1 --off
xrandr --output DVI-1 --auto

The output from xrandr while the monitor is showing signal out of range 
looks normal.

If I boot with the TV on it works OK.

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

For the last 2 years when running a DVI 60Hz monitor with a radeon 
HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with 
the TV off and then turn TV on and -


xrandr --output DVI-0 --auto

to bring up the the TV and get a clone of monitor.

This still works with drm-core-next but not with drm-fixes (todays or 
from a few days ago).


With df I now loose the monitor with signal out of range when doing 
above, the TV output is OK. To get the monitor back I need to turn off 
TV, then off/auto the monitor.


xrandr --output DVI-0 --off
xrandr --output DVI-1 --off
xrandr --output DVI-1 --auto

The output from xrandr while the monitor is showing signal out of range 
looks normal.


If I boot with the TV on it works OK.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

Alex Deucher wrote:

On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote:

For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
and then turn TV on and -

xrandr --output DVI-0 --auto

to bring up the the TV and get a clone of monitor.

This still works with drm-core-next but not with drm-fixes (todays or from a
few days ago).

With df I now loose the monitor with signal out of range when doing above,
the TV output is OK. To get the monitor back I need to turn off TV, then
off/auto the monitor.

xrandr --output DVI-0 --off
xrandr --output DVI-1 --off
xrandr --output DVI-1 --auto

The output from xrandr while the monitor is showing signal out of range
looks normal.

If I boot with the TV on it works OK.


Can you bisect?


29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Fri Oct 5 10:22:02 2012 -0400

drm/radeon: allocate PPLLs from low to high

The order shouldn't matter, but there have been problems
reported on certain older asics.  This behaves more
like the original code before the PPLL allocation
rework.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc:  Markus Trippelsdorf mar...@trippelsdorf.de


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

Bogus video resolution in Linux 3.5-rc4

[Andy Furniss]

Andy Furniss wrote:

> HDMI TV - lots of new modes but it already advertised all the CVT that
> it supports and all the new are bogus.

Oops CEA not CVT.

Bogus video resolution in Linux 3.5-rc4

[Andy Furniss]

Takashi Iwai wrote:

>> The xrandr command shows various bogus modes.
>
> Can't these values be displayed on your monitor at all?
> If they can be displayed, they are valid modes, not really bogus.
> After all, they are values that EDID of your montor advertises as
> available ranges.

I have already commented on bogus modes when the patch first went into 
dcn, but to repeat -

HDMI TV - lots of new modes but it already advertised all the CVT that 
it supports and all the new are bogus.

DVI 120Hz 1920x1080 monitor many bogus modes as it won't display > it's 
res and won't scale up some of the new modes.

Even some of the new ones that are not "out of range" will actually end 
up setting something different and show some distortion.

Maybe gained a couple.

Re: Bogus video resolution in Linux 3.5-rc4

[Andy Furniss]

Takashi Iwai wrote:


The xrandr command shows various bogus modes.


Can't these values be displayed on your monitor at all?
If they can be displayed, they are valid modes, not really bogus.
After all, they are values that EDID of your montor advertises as
available ranges.


I have already commented on bogus modes when the patch first went into 
dcn, but to repeat -


HDMI TV - lots of new modes but it already advertised all the CVT that 
it supports and all the new are bogus.


DVI 120Hz 1920x1080 monitor many bogus modes as it won't display  it's 
res and won't scale up some of the new modes.


Even some of the new ones that are not out of range will actually end 
up setting something different and show some distortion.


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

Re: Bogus video resolution in Linux 3.5-rc4

[Andy Furniss]

Andy Furniss wrote:


HDMI TV - lots of new modes but it already advertised all the CVT that
it supports and all the new are bogus.


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

[PATCH] drm_edid: support CEA video modes

[Andy Furniss]

Daniel Vetter wrote:
> On Fri, May 18, 2012 at 12:37:51PM +0100, Andy Furniss wrote:
>> Joakim Plate wrote:
>>> Joakim Plate<elupus   ecce.se>   writes:
>>>
>>>>
>>>> Christian Schmidt<schmidt   digadd.de>   writes:
>>>>
>>>>>
>>>>> TFT/plasma televisions and projectors have become commonplace, and so
>>>>> has the use of PCs to drive them. Add the video modes specified by an
>>>>> EDID's CEA extension to the mode database for a connector.
>>>>
>>>> /Joakim
>>>>
>>>
>>> Shameless bump on the subject. Would be nice if we could
>>> get this list complete when connecting to HDTV's.
>>
>> Yea, it would be nice.
>>
>> UK bluray seems to use 24/1.001 - not that it's that bad watching
>> with TV at 24Hz.
>>
>> I do have issues with interlaced modes on my TV. I don't know how
>> DRM handles interlaced, but CEA says that the number of vblank lines
>> alternates per field. If that isn't happening then I guess that's
>> why.
>
> If this is on an intel gpu, you need kernel 3.4 to make interlaced work.
> If that doesn't help, please file a bug on bugs.freedesktop.org.
> -Daniel

Thanks, but it's AMD I do have a bug open for it.
https://bugs.freedesktop.org/show_bug.cgi?id=35970

Which reminds me - another issue with CEA modes is that the ones that 
should be double clocked are not.

Re: [PATCH] drm_edid: support CEA video modes

[Andy Furniss]

Daniel Vetter wrote:

On Fri, May 18, 2012 at 12:37:51PM +0100, Andy Furniss wrote:

Joakim Plate wrote:

Joakim Plateelupusat   ecce.se   writes:



Christian Schmidtschmidtat   digadd.de   writes:



TFT/plasma televisions and projectors have become commonplace, and so
has the use of PCs to drive them. Add the video modes specified by an
EDID's CEA extension to the mode database for a connector.


/Joakim



Shameless bump on the subject. Would be nice if we could
get this list complete when connecting to HDTV's.


Yea, it would be nice.

UK bluray seems to use 24/1.001 - not that it's that bad watching
with TV@24Hz.

I do have issues with interlaced modes on my TV. I don't know how
DRM handles interlaced, but CEA says that the number of vblank lines
alternates per field. If that isn't happening then I guess that's
why.


If this is on an intel gpu, you need kernel 3.4 to make interlaced work.
If that doesn't help, please file a bug on bugs.freedesktop.org.
-Daniel


Thanks, but it's AMD I do have a bug open for it.
https://bugs.freedesktop.org/show_bug.cgi?id=35970

Which reminds me - another issue with CEA modes is that the ones that 
should be double clocked are not.




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

[PATCH] drm_edid: support CEA video modes

[Andy Furniss]

Joakim Plate wrote:
> Joakim Plate  writes:
>
>>
>> Christian Schmidt  writes:
>>
>>>
>>> TFT/plasma televisions and projectors have become commonplace, and so
>>> has the use of PCs to drive them. Add the video modes specified by an
>>> EDID's CEA extension to the mode database for a connector.
>>
>> /Joakim
>>
>
> Shameless bump on the subject. Would be nice if we could
> get this list complete when connecting to HDTV's.

Yea, it would be nice.

UK bluray seems to use 24/1.001 - not that it's that bad watching with 
TV at 24Hz.

I do have issues with interlaced modes on my TV. I don't know how DRM 
handles interlaced, but CEA says that the number of vblank lines 
alternates per field. If that isn't happening then I guess that's why.

Re: [PATCH] drm_edid: support CEA video modes

[Andy Furniss]

Joakim Plate wrote:

Joakim Plateelupusat  ecce.se  writes:



Christian Schmidtschmidtat  digadd.de  writes:



TFT/plasma televisions and projectors have become commonplace, and so
has the use of PCs to drive them. Add the video modes specified by an
EDID's CEA extension to the mode database for a connector.


/Joakim



Shameless bump on the subject. Would be nice if we could
get this list complete when connecting to HDTV's.


Yea, it would be nice.

UK bluray seems to use 24/1.001 - not that it's that bad watching with 
TV@24Hz.


I do have issues with interlaced modes on my TV. I don't know how DRM 
handles interlaced, but CEA says that the number of vblank lines 
alternates per field. If that isn't happening then I guess that's why.


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

extra mainly non working modes with drm-core next

[Andy Furniss]

I guess the extra modes with the new code in drm-core-next are crucial 
for some, but it does generate a lot of extra non working modes for me.

With the previous behavior xrandr would list modes that all worked - 
although there are a few new ones that work on my monitor there are a 
lot that don't and for my TV I don't think any new one works.

I see from xorg log that the old DDC gethered modes are still listed - 
maybe if all these extra modes are needed/not being listed in error a 
new xrandr option to list "safe" modes or one to list the new modes with 
safe being default would be more user friendly.

Attached are xrandr --verbose before and after in case anyone is interested.

DVI-0 is a plasma 1920x1080 TV via hdmi (dvi adapter)

DVI-1 is a lcd 1920x1080 120Hz monitor.



-- next part --
Screen 0: minimum 320 x 200, current 1920 x 2160, maximum 8192 x 8192
DVI-0 connected 1920x1080+0+1080 (0x165) normal (normal left inverted right x 
axis y axis) 698mm x 392mm
Identifier: 0x51
Timestamp:  453168
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   1
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000034a9a6a001010101
0014010380780adaffa3584aa229
17494b0001010101010101010101
010101010101023a80d072382d40102c
4580ba88211e023a801871382d40
582c4500ba88211e00fc0050
616e61736f6e69632d54560a00fd
00173d0f440f000a20202020202001d1
02032672509f90140520130412031102
16071506012309070168030c003000b8
260fe3051f01011d80d0721c1620102c
2580ba88219e011d8018711c1620
582c2500ba88219e011d00bc52d0
1e20b8285540ba88211e011d0072
51d01e206e285500ba88211e
00a1
load detection: 1 (0x0001)  range:  (0,1)
underscan vborder: 0 (0x)   range:  (0,128)
underscan hborder: 0 (0x)   range:  (0,128)
underscan:  off
supported: off  on   auto
coherent: 1 (0x0001)range:  (0,1)
  1920x1080 (0x165)  148.5MHz +HSync +VSync *current +preferred
h: width  1920 start 2448 end 2492 total 2640 skew0 clock   56.2KHz
v: height 1080 start 1084 end 1089 total 1125   clock   50.0Hz
  1920x1080 (0x54)  148.5MHz +HSync +VSync
h: width  1920 start 2008 end 2052 total 2200 skew0 clock   67.5KHz
v: height 1080 start 1084 end 1089 total 1125   clock   60.0Hz
  1920x1080 (0x166)   74.2MHz +HSync +VSync
h: width  1920 start 2558 end 2602 total 2750 skew0 clock   27.0KHz
v: height 1080 start 1084 end 1089 total 1125   clock   24.0Hz
  1920x1080 (0x167)   74.2MHz +HSync +VSync Interlace
h: width  1920 start 2008 end 2052 total 2200 skew0 clock   33.8KHz
v: height 1080 start 1084 end 1094 total 1125   clock   30.0Hz
  1920x1080 (0x168)   74.2MHz +HSync +VSync Interlace
h: width  1920 start 2448 end 2492 total 2640 skew0 clock   28.1KHz
v: height 1080 start 1084 end 1094 total 1125   clock   25.0Hz
  1280x720 (0x169)   74.2MHz +HSync +VSync
h: width  1280 start 1390 end 1430 total 1650 skew0 clock   45.0KHz
v: height  720 start  725 end  730 total  750   clock   60.0Hz
  1280x720 (0x16a)   74.2MHz +HSync +VSync
h: width  1280 start 1720 end 1760 total 1980 skew0 clock   37.5KHz
v: height  720 start  725 end  730 total  750   clock   50.0Hz
  1440x576 (0x16b)   27.0MHz -HSync -VSync Interlace
h: width  1440 start 1464 end 1590 total 1728 skew0 clock   15.6KHz
v: height  576 start  580 end  586 total  625   clock   25.0Hz
  1440x480 (0x16c)   27.0MHz -HSync -VSync Interlace
h: width  1440 start 1478 end 1602 total 1716 skew0 clock   15.7KHz
v: height  480 start  488 end  494 total  525   clock   30.0Hz
  720x576 (0x16d)   27.0MHz -HSync -VSync
h: width   720 start  732 end  796 total  864 skew0 clock   31.2KHz
v: height  576 start  581 end  586 total  625   clock   50.0Hz
  720x480 (0x16e)   27.0MHz -HSync -VSync
h: width   720 start  736 end  798 total  858 skew0 clock   31.5KHz
v: height  480 start  489 end  495 total  525   clock   59.9Hz
  640x480 (0x16f)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz

extra mainly non working modes with drm-core next

[Andy Furniss]

I guess the extra modes with the new code in drm-core-next are crucial 
for some, but it does generate a lot of extra non working modes for me.


With the previous behavior xrandr would list modes that all worked - 
although there are a few new ones that work on my monitor there are a 
lot that don't and for my TV I don't think any new one works.


I see from xorg log that the old DDC gethered modes are still listed - 
maybe if all these extra modes are needed/not being listed in error a 
new xrandr option to list safe modes or one to list the new modes with 
safe being default would be more user friendly.


Attached are xrandr --verbose before and after in case anyone is interested.

DVI-0 is a plasma 1920x1080 TV via hdmi (dvi adapter)

DVI-1 is a lcd 1920x1080 120Hz monitor.



Screen 0: minimum 320 x 200, current 1920 x 2160, maximum 8192 x 8192
DVI-0 connected 1920x1080+0+1080 (0x165) normal (normal left inverted right x 
axis y axis) 698mm x 392mm
Identifier: 0x51
Timestamp:  453168
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   1
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000034a9a6a001010101
0014010380780adaffa3584aa229
17494b0001010101010101010101
010101010101023a80d072382d40102c
4580ba88211e023a801871382d40
582c4500ba88211e00fc0050
616e61736f6e69632d54560a00fd
00173d0f440f000a20202020202001d1
02032672509f90140520130412031102
16071506012309070168030c003000b8
260fe3051f01011d80d0721c1620102c
2580ba88219e011d8018711c1620
582c2500ba88219e011d00bc52d0
1e20b8285540ba88211e011d0072
51d01e206e285500ba88211e
00a1
load detection: 1 (0x0001)  range:  (0,1)
underscan vborder: 0 (0x)   range:  (0,128)
underscan hborder: 0 (0x)   range:  (0,128)
underscan:  off
supported: off  on   auto
coherent: 1 (0x0001)range:  (0,1)
  1920x1080 (0x165)  148.5MHz +HSync +VSync *current +preferred
h: width  1920 start 2448 end 2492 total 2640 skew0 clock   56.2KHz
v: height 1080 start 1084 end 1089 total 1125   clock   50.0Hz
  1920x1080 (0x54)  148.5MHz +HSync +VSync
h: width  1920 start 2008 end 2052 total 2200 skew0 clock   67.5KHz
v: height 1080 start 1084 end 1089 total 1125   clock   60.0Hz
  1920x1080 (0x166)   74.2MHz +HSync +VSync
h: width  1920 start 2558 end 2602 total 2750 skew0 clock   27.0KHz
v: height 1080 start 1084 end 1089 total 1125   clock   24.0Hz
  1920x1080 (0x167)   74.2MHz +HSync +VSync Interlace
h: width  1920 start 2008 end 2052 total 2200 skew0 clock   33.8KHz
v: height 1080 start 1084 end 1094 total 1125   clock   30.0Hz
  1920x1080 (0x168)   74.2MHz +HSync +VSync Interlace
h: width  1920 start 2448 end 2492 total 2640 skew0 clock   28.1KHz
v: height 1080 start 1084 end 1094 total 1125   clock   25.0Hz
  1280x720 (0x169)   74.2MHz +HSync +VSync
h: width  1280 start 1390 end 1430 total 1650 skew0 clock   45.0KHz
v: height  720 start  725 end  730 total  750   clock   60.0Hz
  1280x720 (0x16a)   74.2MHz +HSync +VSync
h: width  1280 start 1720 end 1760 total 1980 skew0 clock   37.5KHz
v: height  720 start  725 end  730 total  750   clock   50.0Hz
  1440x576 (0x16b)   27.0MHz -HSync -VSync Interlace
h: width  1440 start 1464 end 1590 total 1728 skew0 clock   15.6KHz
v: height  576 start  580 end  586 total  625   clock   25.0Hz
  1440x480 (0x16c)   27.0MHz -HSync -VSync Interlace
h: width  1440 start 1478 end 1602 total 1716 skew0 clock   15.7KHz
v: height  480 start  488 end  494 total  525   clock   30.0Hz
  720x576 (0x16d)   27.0MHz -HSync -VSync
h: width   720 start  732 end  796 total  864 skew0 clock   31.2KHz
v: height  576 start  581 end  586 total  625   clock   50.0Hz
  720x480 (0x16e)   27.0MHz -HSync -VSync
h: width   720 start  736 end  798 total  858 skew0 clock   31.5KHz
v: height  480 start  489 end  495 total  525   clock   59.9Hz
  640x480 (0x16f)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz
DIN disconnected (normal left inverted 

[PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

[Andy Furniss]

Christian Schmidt wrote:

Tested with all three applied and they work well on my TV all modes 
work, which was not the case previously if I added manually the modes 
listed in xorg log (I have three bogus/not working modes logged by xorg).

I do have a small problem with the interlaced modes - I assumed this was 
a radeon driver issue (the audio part obviously is - but the top line 
part is independent of audio)

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

I mention it just in case there is some link to the cae spec interlaced 
timings interpretation/implementation.

Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

[Andy Furniss]

Christian Schmidt wrote:

Tested with all three applied and they work well on my TV all modes 
work, which was not the case previously if I added manually the modes 
listed in xorg log (I have three bogus/not working modes logged by xorg).


I do have a small problem with the interlaced modes - I assumed this was 
a radeon driver issue (the audio part obviously is - but the top line 
part is independent of audio)


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

I mention it just in case there is some link to the cae spec interlaced 
timings interpretation/implementation.

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

Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Andy Furniss]

Michel D?nzer wrote:

>>> That does sound like the GPU locks up. Do you get any messages in dmesg
>>> about lockups and attempts to reset the GPU at any time?
>>
>> No.
>
> Hmm, I guess the constant SIGALRMs might prevent the lockup detection
> from kicking in... Maybe you can try starting the X server with
> -dumbSched to see if that gets things along any further, but in the end
> there's probably no way around figuring out what causes the lockup and
> fixing that anyway.

I have an old AGP box that locks with 600g + agpgart - It used to give 
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't 
anymore. I can still sysrq OK.

I wonder if something changed in recent months in the drm/whatever code 
that has changed/blocked the logging.

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

[Andy Furniss]

Michel Dänzer wrote:


That does sound like the GPU locks up. Do you get any messages in dmesg
about lockups and attempts to reset the GPU at any time?


No.


Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.


I have an old AGP box that locks with 600g + agpgart - It used to give 
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't 
anymore. I can still sysrq OK.


I wonder if something changed in recent months in the drm/whatever code 
that has changed/blocked the logging.

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

[PATCH] drm/radeon/kms: only warn on mipmap size checks in r600 cs checker

[Andy Furniss]

Alex Deucher wrote:
> The texture base address registers are in units of 256 bytes.
> The original CS checker treated these offsets as bytes, so the
> original check was wrong.  I fixed the units in a patch during
> the 2.6.36 cycle, but this ended up breaking some existing
> userspace (probably due to a bug in either userspace texture allocation
> or the drm texture mipmap checker).  So for now, until we come
> up with a better fix, just warn if the mipmap size it too large.
> This will keep existing userspace working and it should be just
> as safe as before when we were checking the wrong units.  These
> are GPU MC addresses, so if they fall outside of the VRAM or
> GART apertures, they end up at the GPU default page, so this should
> be safe from a security perspective.
>
> Signed-off-by: Alex Deucher
> Cc: Jerome Glisse
> ---
>   drivers/gpu/drm/radeon/r600_cs.c |1 -
>   1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index d886494..27023a3 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -1172,7 +1172,6 @@ static inline int r600_check_texture_resource(struct 
> radeon_cs_parser *p,  u32 i
>   if ((mipmap_size + word0)>  radeon_bo_size(mipmap)) {
>   dev_warn(p->dev, "mipmap bo too small (%d %d %d %d %d %d ->  %d 
> have %ld)\n",
>   w0, h0, bpe, blevel, nlevels, word0, mipmap_size, 
> radeon_bo_size(texture));
> - return -EINVAL;
>   }
>   return 0;
>   }

It fixes ut2004 demo OK, but it spams the logs with 000s of errors.

Re: [PATCH] drm/radeon/kms: only warn on mipmap size checks in r600 cs checker

[Andy Furniss]

Alex Deucher wrote:

The texture base address registers are in units of 256 bytes.
The original CS checker treated these offsets as bytes, so the
original check was wrong.  I fixed the units in a patch during
the 2.6.36 cycle, but this ended up breaking some existing
userspace (probably due to a bug in either userspace texture allocation
or the drm texture mipmap checker).  So for now, until we come
up with a better fix, just warn if the mipmap size it too large.
This will keep existing userspace working and it should be just
as safe as before when we were checking the wrong units.  These
are GPU MC addresses, so if they fall outside of the VRAM or
GART apertures, they end up at the GPU default page, so this should
be safe from a security perspective.

Signed-off-by: Alex Deucheralexdeuc...@gmail.com
Cc: Jerome Glissegli...@freedesktop.org
---
  drivers/gpu/drm/radeon/r600_cs.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index d886494..27023a3 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -1172,7 +1172,6 @@ static inline int r600_check_texture_resource(struct 
radeon_cs_parser *p,  u32 i
if ((mipmap_size + word0)  radeon_bo_size(mipmap)) {
dev_warn(p-dev, mipmap bo too small (%d %d %d %d %d %d -  %d have 
%ld)\n,
w0, h0, bpe, blevel, nlevels, word0, mipmap_size, 
radeon_bo_size(texture));
-   return -EINVAL;
}
return 0;
  }


It fixes ut2004 demo OK, but it spams the logs with 000s of errors.

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

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Alex Deucher wrote:

> Does this patch help?
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index d886494..e83fc88 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -1046,7 +1046,6 @@ static void r600_texture_size(unsigned nfaces,
> unsigned blevel, unsigned nlevels
>  rowstride = ALIGN((width * bpe), pitch_align);
>  size = height * rowstride * depth;
>  offset += size;
> -   offset = (offset + 0x1f)&  ~0x1f;
>  }
>  }
>  *l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;

No. it's still the same with this.

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Alex Deucher wrote:
> On Wed, Aug 18, 2010 at 7:45 AM, Andy Furniss  wrote:
>> Andy Furniss wrote:
>>
>>> No, it does make the nunbers bigger, though -
>>>
>>> radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 ->
>>> 1048576 have 1409024)
>>
>> Further (non exhaustive) testing shows it regresses some mesa demos as well
>> - lodbias,reflect&  shadowtex -
>>
>>   mipmap bo too small (256 256 4 0 0 262144 ->  262144 have 360448)
>>
>
> The initial patch or the partial revert I just had you try?
>
> Alex
>
The partial revert.

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Andy Furniss wrote:

> No, it does make the nunbers bigger, though -
>
> radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 ->
> 1048576 have 1409024)

Further (non exhaustive) testing shows it regresses some mesa demos as 
well - lodbias,reflect & shadowtex -

  mipmap bo too small (256 256 4 0 0 262144 -> 262144 have 360448)

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Alex Deucher wrote:

> Does reverting this part of the patch fix it?
>
> @@ -1055,10 +1055,10 @@ static void r600_texture_size(unsigned nfaces,
> unsigned blevel, unsigned nlevels
> }
> *l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;
> *mipmap_size = offset;
> -   if (!blevel)
> -   *mipmap_size -= *l0_size;
> if (!nlevels)
> *mipmap_size = *l0_size;
> +   if (!blevel)
> +   *mipmap_size -= *l0_size;
>   }

No, it does make the nunbers bigger, though -

radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 -> 
1048576 have 1409024)

Just as a double check this is my diff against current d-r-t for this test.

diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
b/drivers/gpu/drm/radeon/r600_cs.c
index d886494..f6580ca 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -1051,10 +1051,10 @@ static void r600_texture_size(unsigned nfaces, 
unsigned blevel, unsigned nlevels
 }
 *l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;
 *mipmap_size = offset;
-   if (!nlevels)
-   *mipmap_size = *l0_size;
 if (!blevel)
 *mipmap_size -= *l0_size;
+   if (!nlevels)
+   *mipmap_size = *l0_size;
  }

  /**

Re: [PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Alex Deucher wrote:


Does reverting this part of the patch fix it?

@@ -1055,10 +1055,10 @@ static void r600_texture_size(unsigned nfaces,
unsigned blevel, unsigned nlevels
}
*l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;
*mipmap_size = offset;
-   if (!blevel)
-   *mipmap_size -= *l0_size;
if (!nlevels)
*mipmap_size = *l0_size;
+   if (!blevel)
+   *mipmap_size -= *l0_size;
  }


No, it does make the nunbers bigger, though -

radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 - 
1048576 have 1409024)


Just as a double check this is my diff against current d-r-t for this test.

diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
b/drivers/gpu/drm/radeon/r600_cs.c

index d886494..f6580ca 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -1051,10 +1051,10 @@ static void r600_texture_size(unsigned nfaces, 
unsigned blevel, unsigned nlevels

}
*l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;
*mipmap_size = offset;
-   if (!nlevels)
-   *mipmap_size = *l0_size;
if (!blevel)
*mipmap_size -= *l0_size;
+   if (!nlevels)
+   *mipmap_size = *l0_size;
 }

 /**


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

Re: [PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Andy Furniss wrote:


No, it does make the nunbers bigger, though -

radeon :01:00.0: mipmap bo too small (512 512 4 0 0 1048576 -
1048576 have 1409024)


Further (non exhaustive) testing shows it regresses some mesa demos as 
well - lodbias,reflect  shadowtex -


 mipmap bo too small (256 256 4 0 0 262144 - 262144 have 360448)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Jon Sturm wrote:

> ut2004 has been having issues for a while so I wouldn't blame this
> patch 100%, Then again my issues seem to be similar to
> https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
> not be related.

Only having the demo and not seriously playing all levels (or much at 
all) I haven't hit that one.

This one does seem to be down to the patch. If you have the full game it 
could be things are different, as it's actually the nvidia ad that the 
demo starts with the provokes this. Doom3 demo I can get into a saved 
game, but it dies with the same error after about 10 secs.

Both work with the same d-r-t without the patch.

Re: [PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Jon Sturm wrote:


ut2004 has been having issues for a while so I wouldn't blame this
patch 100%, Then again my issues seem to be similar to
https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
not be related.


Only having the demo and not seriously playing all levels (or much at 
all) I haven't hit that one.


This one does seem to be down to the patch. If you have the full game it 
could be things are different, as it's actually the nvidia ad that the 
demo starts with the provokes this. Doom3 demo I can get into a saved 
game, but it dies with the same error after about 10 secs.


Both work with the same d-r-t without the patch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Andy Furniss]

Alex Deucher wrote:
> - buffer offsets in the base regs are 256b aligned so
> shift properly when comparing, fixed by Andre Maasikas
> - mipmap size was calculated wrong when nlevel=0
> - texture bo offsets were used after the bo base address was added
> - vertex resource size register is size - 1, not size

I tried this patch on a d-r-t from 100805 (todays d-r-t seems to have 
reverted to a month ago and doesn't work well with tiling)

The patch, while fixing mesa demos lodbias and cubemap, seems to regress 
ut2004 and doom3 demos -

radeon :01:00.0: mipmap bo too small (128 128 4 0 7 393216 -> 458816 
have 655360)

[PATCH 0/9] drm/radeon/kms: update pm code

[Andy Furniss]

Alex Deucher wrote:

> Send me a copy of your vbios, I may need to adjust the profile table
> for rv670.  As root:
> cd /sys/bus/pci/devices/
> echo 1>  rom
> cat rom>  /tmp/vbios.rom
> echo 0>  rom

Sent


>> One separate question - do I need to use the module param dynclks=1 or is it
>> the default?
>>
>
> The module parameter is obsolete. you can enable it dynamically via
> sysfs (power_method).  The default pm method is profile.

OK, I know dynpm was removed - but this is dynclks are the two the same?

[PATCH 0/9] drm/radeon/kms: update pm code

[Andy Furniss]

Alex Deucher wrote:

> The "profile" method exposes 4 profiles that can be selected from:
> 1. "default"
> 2. "auto"
> 3. "low"
> 4. "high"
> Select the profile by echoing the selected profile to
> /sys/class/drm/card-0/device/power_profile.

Testing on a rv670 desktop it seems that low does not force the card to 
low clock.

Before these patches went in I could force low by

echo 2.0 > /sys/class/drm/card0/device/power_state for 2 screens or
echo 1.0 > /sys/class/drm/card0/device/power_state for one screen.

Though dmesg didn't always report setting it did work (using bench mark 
to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then 
echo 2.0.

Running current drt with the info -> debug patch reverted I can't get

echo low >  /sys/class/drm/card0/device/power_profile

to lower the clock whatever I try - one screen, two screens forcing high 
then low etc. (nothing in dmesg and benchmark gives full clock results)

dynpm works as before and I do get low clock in dpms with profile.

One separate question - do I need to use the module param dynclks=1 or 
is it the default?

Re: [PATCH 0/9] drm/radeon/kms: update pm code

[Andy Furniss]

Alex Deucher wrote:


The profile method exposes 4 profiles that can be selected from:
1. default
2. auto
3. low
4. high
Select the profile by echoing the selected profile to
/sys/class/drm/card-0/device/power_profile.


Testing on a rv670 desktop it seems that low does not force the card to 
low clock.


Before these patches went in I could force low by

echo 2.0  /sys/class/drm/card0/device/power_state for 2 screens or
echo 1.0  /sys/class/drm/card0/device/power_state for one screen.

Though dmesg didn't always report setting it did work (using bench mark 
to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then 
echo 2.0.


Running current drt with the info - debug patch reverted I can't get

echo low   /sys/class/drm/card0/device/power_profile

to lower the clock whatever I try - one screen, two screens forcing high 
then low etc. (nothing in dmesg and benchmark gives full clock results)


dynpm works as before and I do get low clock in dpms with profile.

One separate question - do I need to use the module param dynclks=1 or 
is it the default?

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

Re: [PATCH 0/9] drm/radeon/kms: update pm code

[Andy Furniss]

Alex Deucher wrote:


Send me a copy of your vbios, I may need to adjust the profile table
for rv670.  As root:
cd /sys/bus/pci/devices/pci bus id
echo 1  rom
cat rom  /tmp/vbios.rom
echo 0  rom


Sent



One separate question - do I need to use the module param dynclks=1 or is it
the default?



The module parameter is obsolete. you can enable it dynamically via
sysfs (power_method).  The default pm method is profile.


OK, I know dynpm was removed - but this is dynclks are the two the same?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel