from:"Boszormenyi Zoltan"


2017-04-13 18:20 keltezéssel, Ville Syrjälä írta:

On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote:

On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher <alexdeuc...@gmail.com> wrote:

On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote:

2017-04-13 16:05 keltezéssel, Alex Deucher írta:


On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote:


Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.



The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.



I tried adding video=DVI-D-1:d to the kernel command line.

The effect is while the second output is indeed disabled, the
framebuffer console still takes the second output's resolution
into account and the boot splash is still using only the top-left
800x480 part of the 1024x768 primary screen.

Also, the secondary screen got disabled also in X which is not desired.
Can I wake it up under X somehow? This device is using the modesetting
DDX driver.


Can you enable it via randr?


I think the video= based disable forces the connector to be disabled
irrevocably.


# echo detect > /sys/class/drm//status



Thanks, that worked.

I had to regenerate my initramfs to actually include the gma500 driver
so KMS can kick in early. Before that the text mode plugin was used in
plymouth and that doesn't switch dimensions when fbdev took over.

The plymouth boot splash now looks good on the primary screen with
the secondary display disabled from the kernel command line and I can
enable the secondary screen from a boot script before X (a DM) starts
which causes both screens to flash but it's good for me now.

Thanks for everyone who answered.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS question


2017-04-13 17:36 keltezéssel, Alex Deucher írta:

On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote:

2017-04-13 16:05 keltezéssel, Alex Deucher írta:


On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote:


Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.



The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.



I tried adding video=DVI-D-1:d to the kernel command line.

The effect is while the second output is indeed disabled, the
framebuffer console still takes the second output's resolution
into account and the boot splash is still using only the top-left
800x480 part of the 1024x768 primary screen.

Also, the secondary screen got disabled also in X which is not desired.
Can I wake it up under X somehow? This device is using the modesetting
DDX driver.


Can you enable it via randr?


No, "xrandr --output DVI-D-1 --auto" does nothing.



Alex



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

Re: KMS question


2017-04-13 16:05 keltezéssel, Alex Deucher írta:

On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote:

Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.



The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.


I tried adding video=DVI-D-1:d to the kernel command line.

The effect is while the second output is indeed disabled, the
framebuffer console still takes the second output's resolution
into account and the boot splash is still using only the top-left
800x480 part of the 1024x768 primary screen.

Also, the secondary screen got disabled also in X which is not desired.
Can I wake it up under X somehow? This device is using the modesetting
DDX driver.

Thanks,
Zoltán



Alex



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

KMS question


Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.

Thanks in advance,
Zoltán Böszörmenyi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Black screen with KABINI with kernel 4.5 with or without DAL

2016-04-06 Thread Boszormenyi Zoltan

2016-04-05 08:27 keltezÃ©ssel, Michel DÃ¤nzer Ãrta:
> On 05.04.2016 13:07, Boszormenyi Zoltan wrote:
>> 2016-04-05 05:40 keltezÃ©ssel, Michel DÃ¤nzer Ãrta:
>>> On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
>>>> The application is Chromium in kiosk mode. The problem is that
>>>> sometimes the screen stays black after KMS kicks in.
>>> So the problem occurs even without X? Does it affect HDMI or
>>> DisplayPort, or both?
>> It occurs on both but not without X. Ctrl-Alt-F2 gives me the
>> console login prompt. My phrasing was not what I wanted to write
>> and didn't finish the sentence really. X is started very early during
>> boot so I can see the console message only momentarily while
>> the screen is still in 80x25 VGA text mode. Restarting Xorg via
>> systemctl makes it working most of the time.
>>
>> Apparently, it's not Radeon specific. We were also able to reproduce
>> it on an Intel machine, too, with internal LVDS and external VGA outputs.
> I suspect it's a client side problem then.

I have upgraded a bunch of Xorg libraries, the server to 1.18.3
and rebuilt all the drivers for the new server and the problem
doesn't occur anymore. It may be possible that we have hit some
race problems (like the one fixed in libxcb-1.11.1) but I didn't
have the time to test every piece separately. I would have done
this mass upgrade sooner or later anyway.

>   Comparing the good and bad
> dmesg output shows that Xorg is busily updating the screen in the good
> case (visible as radeon_crtc_page_flip gets called by TearFree) but not
> so in the bad case. Since the default Xorg startup behaviour is a black
> screen, it sounds like simply no client connects to Xorg / draws
> anything to the screen in the bad case. Maybe there's a race which can
> result in the client(s) starting up before Xorg, failing to establish
> the display connection, or something like that.
>
>
>> Is Xorg 1.16.4 still a supported version with new kernels?
> There's no direct version inter-dependency between Xorg and the kernel.

Noted.

Thanks for looking into it,
ZoltÃ¡n BÃ¶szÃ¶rmÃ©nyi

Black screen with KABINI with kernel 4.5 with or without DAL

2016-04-05 Thread Boszormenyi Zoltan

2016-04-05 05:40 keltezÃ©ssel, Michel DÃ¤nzer Ãrta:
> On 05.04.2016 00:25, Boszormenyi Zoltan wrote:
>> we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:
>>
>> [2.234372] [drm] initializing kernel modesetting (KABINI
>> 0x1002:0x9832 0x1002:0x0123).
>>
>> For our application, we force 1440x900 resolution via this modeline
>> ("cvt 1440 900"):
>>
>>  Modeline"1440x900"  106.50  1440 1528 1672 1904  900 903 909 934
>> -hsync +vsync
>>
>> The application is Chromium in kiosk mode. The problem is that
>> sometimes the screen stays black after KMS kicks in.
> So the problem occurs even without X? Does it affect HDMI or
> DisplayPort, or both?

It occurs on both but not without X. Ctrl-Alt-F2 gives me the
console login prompt. My phrasing was not what I wanted to write
and didn't finish the sentence really. X is started very early during
boot so I can see the console message only momentarily while
the screen is still in 80x25 VGA text mode. Restarting Xorg via
systemctl makes it working most of the time.

Apparently, it's not Radeon specific. We were also able to reproduce
it on an Intel machine, too, with internal LVDS and external VGA outputs.

Is Xorg 1.16.4 still a supported version with new kernels?
I think I will try to upgrade to 1.18.x.

Thanks in advance,
ZoltÃ¡n BÃ¶szÃ¶rmÃ©nyi

Black screen with KABINI with kernel 4.5 with or without DAL

2016-04-04 Thread Boszormenyi Zoltan

Hi,

we have a bunch of Zotac ZBOX NANO-AQ01 with this APU:

[2.234372] [drm] initializing kernel modesetting (KABINI 0x1002:0x9832 
0x1002:0x0123).

For our application, we force 1440x900 resolution via this modeline ("cvt 1440 
900"):

 Modeline"1440x900"  106.50  1440 1528 1672 1904  900 903 909 934 
-hsync +vsync

The application is Chromium in kiosk mode. The problem is that
sometimes the screen stays black after KMS kicks in.

Currently the kernel is 4.5 with or without the DAL WIP patchset, i.e. a "git 
diff" between
b562e44f507e863c6792946e4e1b1449fbbac85d from Linus's GIT and
629edeae23ba531f6f5ceacf3f1fa71ba5132303 from 
git://people.freedesktop.org/~agd5f/linux :

commit 629edeae23ba531f6f5ceacf3f1fa71ba5132303
Author: Eric Yang 
Date:   Wed Mar 16 16:38:28 2016 -0400

 drm/amd/dal: fix division by 0 on boot for dce80

 DCE80 used to have bandwidth parameters initialized with the dce110
 numbers. This was taken out a while ago, leaving the parameters to
 be uninitialized. This causes division by 0 on boot. This change
 resolves this by skipping bandwidth calculation and displaymark
 programming. For now, we will have dce80 always running safemark

 Reviewed-by: Eagle Yeh 
 Signed-off-by: Eric Yang 
 Signed-off-by: Alex Deucher 

We use Xorg 1.16.4 and xf86-video-ati GIT with TearFree, commit ID
10b7c3def58bb34acc38f076bc230e25b454ab79. The same behaviour
is present with 4693b1bd5b5c381e8b7b68a6f7f0c6696d6a68df.

Attached is the dmesg and Xorg logs from both good and bad booting
with the DAL kernel, with "drm.debug=0x1e log_buf_len=1M" kernel options.

Our extra xorg.conf to force the 1440x900 is this:

Section "Monitor"
 Identifier"HDMI-0"
 Option"AutoServerLayout" "on"
 Option"Position" "0 0"
 Modeline"1440x900"  106.50  1440 1528 1672 1904  900 903 909 934 
-hsync +vsync
EndSection

Section "Monitor"
 Identifier"DisplayPort-0"
 Option"AutoServerLayout" "on"
 Option"Position" "0 0"
 Modeline"1440x900"  106.50  1440 1528 1672 1904  900 903 909 934 
-hsync +vsync
EndSection

Section "Device"
 Identifier"RADEON"
 Driver"radeon"
 Option"AutoServerLayout" "on"
 Option"Monitor-HDMI-0" "HDMI-0"
 Option"Monitor-DisplayPort-0" "DisplayPort-0"
 Option"TearFree" "on"
EndSection
Section "Screen"
 Identifier"SCREEN"
 Option"AutoServerLayout" "on"
 SubSection "Display"
 Viewport   0 0
 Modes"1440x900"
 Depth 24
 EndSubSection
EndSection

Can someone fix this black screen problem?

Thanks in advance,
ZoltÃ¡n BÃ¶szÃ¶rmÃ©nyi

-- next part --
A non-text attachment was scrubbed...
Name: logs-black-screen.tgz
Type: application/x-compressed-tar
Size: 57599 bytes
Desc: not available
URL:

Trying nouveau reclocking

2016-01-27 Thread Boszormenyi Zoltan

Hi,

2016-01-27 14:26 keltezÃ©ssel, Ilia Mirkin Ãrta:
> The warn in question is
>
> static u32
> nvkm_mc_intr_mask(struct nvkm_mc *mc)
> {
> u32 intr = mc->func->intr_mask(mc);
> if (WARN_ON_ONCE(intr == 0x))
> intr = 0; /* likely fallen off the bus */
> return intr;
> }
>
> Which is basically a sign of total death. Is this new with 4.5-rc1, or
> is this the first time you've tried reclocking this chip?

this was the first time I tried reclocking. When the GPU is idle,
reclocking is successful and the same WebGL app runs a lot smoother.
BTW, the machine I tried was a Zotac ZBOX MiniPC ID41 series.

I also have a question related to reclocking on other chips.

Zotac ZBOX ID84 series:

# lspci -s 02:00.0
02:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce GT 520M] 
(rev a1)
# lspci -s 02:00.0 -n
02:00.0 0300: 10de:1050 (rev a1)

Zotac ZBOX ID86 series:

# lspci -s 02:00.0
02:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] 
(rev a1)
# lspci -s 02:00.0 -n
02:00.0 0300: 10de:104a (rev a1)

All three boxes are out of production now, but we're using about
20,000 (really, about twenty thousand) in total of them at my company.
Nouveau supports them just fine, the main application is video decoding/playing
and it works very well for the supported codecs reported via vdpauinfo.
Is there a known roadmap to support reclocking on these latter two?

Thanks,
ZoltÃ¡n BÃ¶szÃ¶rmÃ©nyi

>
>   -ilia
>
>
> On Wed, Jan 27, 2016 at 6:59 AM, Boszormenyi Zoltan  wrote:
>> Hi,
>>
>> I was trying to use re-clocking with nouveau in 4.5.0-rc1 with:
>>
>> # echo "0f" >/sys/kernel/debug/dri/0/pstate
>>
>> while Chromium with a WebGL app already running. (www.playmapscube.com)
>>
>> The video chip in question is:
>>
>> 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
>>
>> or in numbers:
>>
>> 03:00.0 0300: 10de:0a64 (rev a2)
>>
>> It is an integrated chip on the mainboard.
>>
>> The result was:
>>
>> [   77.531009] [ cut here ]
>> [   77.531009] WARNING: CPU: 3 PID: 405 at
>> drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:51 nvkm_mc_intr+0x102/0x110 
>> [nouveau]()
>> [   77.531009] Modules linked in: tun ums_realtek uas usb_storage joydev 
>> input_leds
>> hid_generic usbhid hid cdc_acm snd_hda_codec_hdmi nouveau arc4 mxm_wmi wmi 
>> ath9k
>> i2c_algo_bit iTCO_wdt drm_kms_helper iTCO_vendor_support gpio_ich 
>> ath9k_common
>> snd_hda_codec_realtek ttm snd_hda_codec_generic ath9k_hw drm snd_hda_intel 
>> ath
>> snd_hda_codec mac80211 snd_hwdep syscopyarea lpc_ich snd_hda_core 
>> sysfillrect mfd_core
>> sysimgblt fb_sys_fops coretemp snd_pcm serio_raw i2c_i801 xhci_pci pcspkr 
>> xhci_hcd
>> cfg80211 r8169 snd_timer i2c_core snd mii ehci_pci uhci_hcd rfkill ehci_hcd 
>> soundcore
>> acpi_cpufreq xt_limit xt_multiport xt_recent ip6table_filter xt_conntrack 
>> ip6table_nat
>> iptable_nat nf_conntrack_ipv6 nf_nat_ipv4 nf_defrag_ipv6 nf_conntrack_ipv4 
>> nf_nat_ipv6
>> nf_defrag_ipv4 nf_nat xt_connmark nf_conntrack ip6_tables
>> [   77.531009]  iptable_mangle
>> [   77.531009] CPU: 3 PID: 405 Comm: Xorg.bin Not tainted 4.5.0-rc1 #1
>> [   77.531009] Hardware name: To Be Filled By O.E.M. To Be Filled By 
>> O.E.M./To Be Filled
>> By O.E.M., BIOS 080016  05/05/2011
>> [   77.531009]  a053b6f0 88007fd83cd8 80761604 
>> 
>> [   77.531009]  88007fd83d10 8048e7a2 88007c0ef480 
>> 880037838840
>> [   77.531009]  88007a4b3800  a04fa9a0 
>> 88007fd83d20
>> [   77.531009] Call Trace:
>> [   77.531009][] dump_stack+0x44/0x60
>> [   77.531009]  [] warn_slowpath_common+0x82/0xc0
>> [   77.531009]  [] warn_slowpath_null+0x1a/0x20
>> [   77.531009]  [] nvkm_mc_intr+0x102/0x110 [nouveau]
>> [   77.531009]  [] nvkm_pci_intr+0x44/0x70 [nouveau]
>> [   77.531009]  [] handle_irq_event_percpu+0x75/0x180
>> [   77.531009]  [] handle_irq_event+0x3b/0x60
>> [   77.531009]  [] handle_edge_irq+0x74/0x130
>> [   77.531009]  [] handle_irq+0x1a/0x30
>> [   77.531009]  [] do_IRQ+0x4b/0xd0
>> [   77.531009]  [] common_interrupt+0x82/0x82
>> [   77.531009]  [] ? __do_softirq+0x7b/0x260
>> [   77.531009]  [] irq_exit+0xb1/0xc0
>> [   77.531009]  [] smp_apic_timer_interrupt+0x42/0x50
>> [   77.531009]  [] apic_timer_interrupt+0x82/0x90
>> [   77.531009][] ? nouveau_fence_emit+0xf1/0x1a0 
>> [nouveau]
>> [   77.531009]  [] ? nou

Trying nouveau reclocking

2016-01-27 Thread Boszormenyi Zoltan

Hi,

I was trying to use re-clocking with nouveau in 4.5.0-rc1 with:

# echo "0f" >/sys/kernel/debug/dri/0/pstate

while Chromium with a WebGL app already running. (www.playmapscube.com)

The video chip in question is:

03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)

or in numbers:

03:00.0 0300: 10de:0a64 (rev a2)

It is an integrated chip on the mainboard.

The result was:

[   77.531009] [ cut here ]
[   77.531009] WARNING: CPU: 3 PID: 405 at
drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:51 nvkm_mc_intr+0x102/0x110 
[nouveau]()
[   77.531009] Modules linked in: tun ums_realtek uas usb_storage joydev 
input_leds
hid_generic usbhid hid cdc_acm snd_hda_codec_hdmi nouveau arc4 mxm_wmi wmi ath9k
i2c_algo_bit iTCO_wdt drm_kms_helper iTCO_vendor_support gpio_ich ath9k_common
snd_hda_codec_realtek ttm snd_hda_codec_generic ath9k_hw drm snd_hda_intel ath
snd_hda_codec mac80211 snd_hwdep syscopyarea lpc_ich snd_hda_core sysfillrect 
mfd_core
sysimgblt fb_sys_fops coretemp snd_pcm serio_raw i2c_i801 xhci_pci pcspkr 
xhci_hcd
cfg80211 r8169 snd_timer i2c_core snd mii ehci_pci uhci_hcd rfkill ehci_hcd 
soundcore
acpi_cpufreq xt_limit xt_multiport xt_recent ip6table_filter xt_conntrack 
ip6table_nat
iptable_nat nf_conntrack_ipv6 nf_nat_ipv4 nf_defrag_ipv6 nf_conntrack_ipv4 
nf_nat_ipv6
nf_defrag_ipv4 nf_nat xt_connmark nf_conntrack ip6_tables
[   77.531009]  iptable_mangle
[   77.531009] CPU: 3 PID: 405 Comm: Xorg.bin Not tainted 4.5.0-rc1 #1
[   77.531009] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To 
Be Filled
By O.E.M., BIOS 080016  05/05/2011
[   77.531009]  a053b6f0 88007fd83cd8 80761604 

[   77.531009]  88007fd83d10 8048e7a2 88007c0ef480 
880037838840
[   77.531009]  88007a4b3800  a04fa9a0 
88007fd83d20
[   77.531009] Call Trace:
[   77.531009][] dump_stack+0x44/0x60
[   77.531009]  [] warn_slowpath_common+0x82/0xc0
[   77.531009]  [] warn_slowpath_null+0x1a/0x20
[   77.531009]  [] nvkm_mc_intr+0x102/0x110 [nouveau]
[   77.531009]  [] nvkm_pci_intr+0x44/0x70 [nouveau]
[   77.531009]  [] handle_irq_event_percpu+0x75/0x180
[   77.531009]  [] handle_irq_event+0x3b/0x60
[   77.531009]  [] handle_edge_irq+0x74/0x130
[   77.531009]  [] handle_irq+0x1a/0x30
[   77.531009]  [] do_IRQ+0x4b/0xd0
[   77.531009]  [] common_interrupt+0x82/0x82
[   77.531009]  [] ? __do_softirq+0x7b/0x260
[   77.531009]  [] irq_exit+0xb1/0xc0
[   77.531009]  [] smp_apic_timer_interrupt+0x42/0x50
[   77.531009]  [] apic_timer_interrupt+0x82/0x90
[   77.531009][] ? nouveau_fence_emit+0xf1/0x1a0 
[nouveau]
[   77.531009]  [] ? nouveau_fence_emit+0x13f/0x1a0 [nouveau]
[   77.531009]  [] nouveau_fence_new+0x59/0xa0 [nouveau]
[   77.531009]  [] nouveau_gem_ioctl_pushbuf+0xeb5/0x1730 
[nouveau]
[   77.531009]  [] drm_ioctl+0x152/0x540 [drm]
[   77.531009]  [] ? nouveau_gem_ioctl_new+0x1c0/0x1c0 
[nouveau]
[   77.531009]  [] ? fpu__activate_curr+0x15/0x20
[   77.531009]  [] nouveau_drm_ioctl+0x68/0xc0 [nouveau]
[   77.531009]  [] do_vfs_ioctl+0x92/0x580
[   77.531009]  [] ? security_file_ioctl+0x43/0x60
[   77.531009]  [] SyS_ioctl+0x79/0x90
[   77.531009]  [] entry_SYSCALL_64_fastpath+0x16/0x75
[   77.531009] ---[ end trace 4a0b55289f0a358e ]---
[   78.561529] nouveau :03:00.0: timeout at
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:332/gt215_clk_pre()!
[   90.693743] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
[   90.693743] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY DISPATCH 
VFETCH
CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL 
ENG2D RMASK
TPC_RAST TPC_PROP
]
[   90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH 
CCACHE]
[   90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP]
[   90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP]
[   93.001694] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
[   93.001694] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY DISPATCH 
VFETCH
CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL 
ENG2D RMASK
TPC_RAST TPC_PROP
]
[   93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH 
CCACHE]
[   93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP]
[   93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP]
[   95.137647] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
[   95.137647] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY DISPATCH 
VFETCH
CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL 
ENG2D RMASK
TPC_RAST TPC_PROP
]
[   95.137647] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH 
CCACHE]
[   95.137647] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP]
[   95.137647] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP]
[   98.022424]

[PATCH v2] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-12-04 Thread Boszormenyi Zoltan

2015-12-04 09:53 keltezÃ©ssel, Christian KÃ¶nig Ãrta:
> On 04.12.2015 00:26, cpaul at redhat.com wrote:
>> From: Lyude 
>>
>> HPD signals on DVI ports can be fired off before the pins required for
>> DDC probing actually make contact, due to the pins for HPD making
>> contact first. This results in a HPD signal being asserted but DDC
>> probing failing, resulting in hotplugging occasionally failing.
>>
>> This is somewhat rare on most cards (depending on what angle you plug
>> the DVI connector in), but on some cards it happens constantly. The
>> Radeon R5 on the machine used for testing this patch for instance, runs
>> into this issue just about every time I try to hotplug a DVI monitor and
>> as a result hotplugging almost never works.
>>
>> Rescheduling the hotplug work for a second when we run into an HPD
>> signal with a failing DDC probe usually gives enough time for the rest
>> of the connector's pins to make contact, and fixes this issue.
>>
>> Signed-off-by: Lyude 
>
> I find a second a bit long, but if it works so what?
>
> Looks sane enough to me, patch is Reviewed-by: Christian KÃ¶nig 
> 

Does this patch help in case of the Radeon chip only has HDMI and DP outputs
exposed (Zotac ZBOXNANO-AQ01) but used with DVI or VGA monitors with
converter cables? We have some problems with such scenarios that sounds
eerily similar to this description.

Inquiry-by: ZoltÃ¡n BÃ¶szÃ¶rmÃ©nyi 
;-)

Thanks in advance.

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-12-03 Thread Boszormenyi Zoltan

2015-11-20 16:52 keltezÃ©ssel, cpaul at redhat.com Ãrta:
> From: Stephen Chandler Paul 
>
> HPD signals on DVI ports can be fired off before the pins required for
> DDC probing actually make contact, due to the pins for HPD making
> contact first. This results in a HPD signal being asserted but DDC
> probing failing, resulting in hotplugging occasionally failing.
>
> This is somewhat rare on most cards (depending on what angle you plug
> the DVI connector in), but on some cards it happens constantly. The
> Radeon R5 on the machine used for testing this patch for instance, runs
> into this issue just about every time I try to hotplug a DVI monitor and
> as a result hotplugging almost never works.
>
> Rescheduling the hotplug work for a second when we run into an HPD
> signal with a failing DDC probe usually gives enough time for the rest
> of the connector's pins to make contact, and fixes this issue.
>
> Signed-off-by: Stephen Chandler Paul 
> ---
> So this one has kind of been a tough sell with Jerome, mostly because it's
> somewhat of a hack. Unfortunately however I've managed to find machines where
> DVI hotplugging literally doesn't work without a patch like this. We've 
> already
> tried a couple of ways of handling the situation of retriggering ddc probes:
>
> * Trying the DDC probe in the radeon_dvi_detect() function multiple times.
> * Trying to reschedule the hotplug_work task whenever DDC probing fails on DVI
>   but we got a hpd signal (this ended up being a much more complicated patch
>   then anticipated)
> * Doing what we do right now, which is just triggering userspace to rescan all
>   the ports when the hpd signal is asserted by the DVI port but there's no DDC
>   probe, and repeating until at least a second passes.
>
> All of these actually work, but I guess it's a question of which one is less 
> of
> a hack. If anyone here can think of a cleaner way of handling this feel free 
> to
> let me know.
>
>  drivers/gpu/drm/radeon/radeon.h|  3 +++
>  drivers/gpu/drm/radeon/radeon_connectors.c | 20 +---
>  drivers/gpu/drm/radeon/radeon_irq_kms.c|  2 ++
>  3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b6cbd81..d63f0fe 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2460,6 +2460,9 @@ struct radeon_device {
>   /* amdkfd interface */
>   struct kfd_dev  *kfd;
>  
> + /* last time we received an hpd signal */
> + unsigned long hpd_time;
> +
>   struct mutexmn_lock;
>   DECLARE_HASHTABLE(mn_hash, 7);
>  };
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 5a2cafb..4ee9440 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, 
> bool force)
>   const struct drm_encoder_helper_funcs *encoder_funcs;
>   int i, r;
>   enum drm_connector_status ret = connector_status_disconnected;
> - bool dret = false, broken_edid = false;
> + bool dret = false, broken_edid = false, hpd_unchanged;
>  
>   r = pm_runtime_get_sync(connector->dev->dev);
>   if (r < 0)
>   return connector_status_disconnected;
>  
> - if (!force && radeon_check_hpd_status_unchanged(connector)) {
> + hpd_unchanged = radeon_check_hpd_status_unchanged(connector);
> + if (!force && hpd_unchanged) {
>   ret = connector->status;
>   goto exit;
>   }
>  
> - if (radeon_connector->ddc_bus)
> + if (radeon_connector->ddc_bus) {
>   dret = radeon_ddc_probe(radeon_connector, false);
> +
> + /* Sometimes the pins required for the DDC probe on DVI
> +  * connectors don't make contact at the same time that the ones
> +  * for HPD do. If the DDC probe fails even though we had an HPD
> +  * signal, signal userspace to try again */
> + if (!dret && !hpd_unchanged &&
> + connector->status != connector_status_connected &&
> + time_before(jiffies, rdev->hpd_time + 
> msecs_to_jiffies(1000))) {
> + DRM_DEBUG_KMS("%s: hpd asserted but ddc probe failed, 
> retrying\n",
> +   connector->name);
> + drm_sysfs_hotplug_event(dev);
> + }
> + }
>   if (dret) {
>   radeon_connector->detected_by_load = false;
>   radeon_connector_free_edid(connector);
> diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
> b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> index 171d3e4..579c22c 100644
> --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> @@ -79,6 +79,8 @@ static void radeon_hotplug_work_func(struct work_struct 
> *work)
>

AMD/AMD hybrid graphics

2014-02-21 Thread Boszormenyi Zoltan

2014-02-21 16:12 keltez?ssel, Alex Deucher ?rta:
> On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan  wrote:
>> [zozo at localhost ~]$ DRI_PRIME=1 glxgears
>> Running synchronized to the vertical refresh.  The framerate should be
>> approximately the same as the monitor refresh rate.
>> 5589 frames in 5.0 seconds = 1117.730 FPS
>> 5369 frames in 5.0 seconds = 1073.715 FPS
>> 5699 frames in 5.0 seconds = 1139.670 FPS
>>
>> Obviously, it doesn't sync to the framerate with PRIME.
>> On the other hand, nothing is displayed in the glxgears window.
>> I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.
>>
> Make sure you are running a compositor.

Turning on compositing in MATE fixed it. Thank you very much.
It seems I will have to keep Rawhide on this notebook. :-)

Best regards,
Zolt?n B?sz?rm?nyi

AMD/AMD hybrid graphics

2014-02-21 Thread Boszormenyi Zoltan

2014-02-21 15:32 keltez?ssel, Boszormenyi Zoltan ?rta:
> 2014-02-21 14:37 keltez?ssel, Alex Deucher ?rta:
>>
>> Does the attached patch help?
>>
>> Alex
>
> Yes, it helped, thank you very much.
> The compressed Xorg.0.log is attached as proof.
>
> To others: the patch is against xf86-video-ati.
>
> Two notes, though:
>
> 1. Is it normal that "xrandr --listproviders" lists 3 providers?
>
> [zozo at localhost ~]$ cat xrandr-providers
> Providers: number : 3
> Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, 
> Sink Offload 
> crtcs: 4 outputs: 3 associated providers: 2 name:radeon
> Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, 
> Sink Offload 
> crtcs: 0 outputs: 0 associated providers: 2 name:radeon
> Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, 
> Sink Offload 
> crtcs: 0 outputs: 0 associated providers: 2 name:radeon
>
> 2. I tried glxgears with and without DRI_PRIME=1 as below:
>
> [zozo at localhost ~]$ glxgears
> Running synchronized to the vertical refresh.  The framerate should be
> approximately the same as the monitor refresh rate.
> 299 frames in 5.0 seconds = 59.558 FPS
> [zozo at localhost ~]$ DRI_PRIME=1 glxgears
> Running synchronized to the vertical refresh.  The framerate should be
> approximately the same as the monitor refresh rate.
> 5589 frames in 5.0 seconds = 1117.730 FPS
> 5369 frames in 5.0 seconds = 1073.715 FPS
> 5699 frames in 5.0 seconds = 1139.670 FPS
>
> Obviously, it doesn't sync to the framerate with PRIME.
> On the other hand, nothing is displayed in the glxgears window.
> I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.
>
> I will go back to plain Fedora 20 (Xorg 1.14, llvm 3.3 and Mesa 9.2.5)
> and try the same patch to see if there's any difference.

With Fedora 20 packages X doesn't come up.
The last message on the screen is:

[ 19.016881] pci_pm_runtime_suspend(): radeon_pmops_runtime_suspend+0x0/0xa0 
[radeon] 
return -22

Xorg crashes and Xorg.0.log now contains the backtrace, attached.

Best regards,
Zolt?n B?sz?rm?nyi

-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log-1.14-segfault.gz
Type: application/x-tar
Size: 7917 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/8bd36ad0/attachment.tar>

AMD/AMD hybrid graphics

2014-02-21 Thread Boszormenyi Zoltan

2014-02-21 14:37 keltez?ssel, Alex Deucher ?rta:
>
> Does the attached patch help?
>
> Alex

Yes, it helped, thank you very much.
The compressed Xorg.0.log is attached as proof.

To others: the patch is against xf86-video-ati.

Two notes, though:

1. Is it normal that "xrandr --listproviders" lists 3 providers?

[zozo at localhost ~]$ cat xrandr-providers
Providers: number : 3
Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink 
Offload 
crtcs: 4 outputs: 3 associated providers: 2 name:radeon
Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink 
Offload 
crtcs: 0 outputs: 0 associated providers: 2 name:radeon
Provider 2: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink 
Offload 
crtcs: 0 outputs: 0 associated providers: 2 name:radeon

2. I tried glxgears with and without DRI_PRIME=1 as below:

[zozo at localhost ~]$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
299 frames in 5.0 seconds = 59.558 FPS
[zozo at localhost ~]$ DRI_PRIME=1 glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
5589 frames in 5.0 seconds = 1117.730 FPS
5369 frames in 5.0 seconds = 1073.715 FPS
5699 frames in 5.0 seconds = 1139.670 FPS

Obviously, it doesn't sync to the framerate with PRIME.
On the other hand, nothing is displayed in the glxgears window.
I have llvm 3.4-4 and Mesa 10.1-rc1 from Fedora 21 rawhide.

I will go back to plain Fedora 20 (Xorg 1.14, llvm 3.3 and Mesa 9.2.5)
and try the same patch to see if there's any difference.

Best regards,
Zolt?n B?sz?rm?nyi

-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log.fixed.gz
Type: application/x-tar
Size: 9901 bytes
Desc: not available
URL:

AMD/AMD hybrid graphics

2014-02-20 Thread Boszormenyi Zoltan

2014-02-20 08:44 keltez?ssel, Boszormenyi Zoltan ?rta:
> 2014-02-20 06:47 keltez?ssel, Michel D?nzer ?rta:
>> On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
>>> 2014-02-20 04:20 keltez?ssel, Michel D?nzer ?rta:
>>>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
>>>>> 2014-02-19 10:59 keltez?ssel, Michel D?nzer ?rta:
>>>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
>>>>>>
>>>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time?
>>>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer
>>>>>> though.
>>>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in
>>>>> Fedora 20 at this time, it's not possible unless I compile my own
>>>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
>>>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
>>>>
>>>>
>>>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
>>>> The log files end abruptly, so we need to see the X server stderr
>>>> output. Assuming you're using gdm, it should be captured
>>>> in /var/log/gdm*/:0.log .
>>> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
>> [...]
>>
>>> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion
>>> `key->initialized' failed.
>> Can you get a backtrace for this assertion failure with gdb? See
>> http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
>>
>>
>
> Here it is. I simply started Xorg from my ssh sesion and got the same 
> assertion failed.

The previous log contained unmatched debuginfo. I have updated
everything needed to make the system consistent with the debuginfos
using rawhide's Xorg 1.15.

However, it seems that after the assertion fails, the second attempt
failed to initialize the discrete chip so only RADEON(0) lines were present
in the Xorg.0.log and gdb didn't stop since the server was running.

Then added the Xdbg script from the ServerDebugging link so the system
uses that instead of the plain Xorg binary. The result is attached.

Best regards,
Zolt?n B?sz?rm?nyi

-- next part --
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

X.Org X Server 1.15.0
Release Date: 2013-12-27
X Protocol Version 11, Revision 0
Build Operating System:  3.12.8-300.fc20.x86_64 
Current Operating System: Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 
SMP Fri Feb 14 19:08:32 UTC 2014 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.3-201.fc20.x86_64 
root=UUID=61edc6e4-5eb0-4ec6-869c-f80dd5bd1d93 ro 
vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=hu_HU.UTF-8
Build Date: 18 February 2014  06:25:51AM
Build ID: xorg-x11-server 1.15.0-4.fc21 
Current version of pixman: 0.32.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Feb 20 09:09:35 2014
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension Present
Initializing built-in extension DRI3
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension SELinux
Initializing built-in extension XFree86-VidModeExtension
Initializing built-in extension XFree86-DGA
Initializing built-in extension XFree86-DRI
Initializing built-in extension DRI2
Loading extension GLX
(II) [KMS] Kernel modesetting enabled.
(II) [KMS] Kernel modesetting enabled.
[tcsetpgrp fail

AMD/AMD hybrid graphics

2014-02-20 Thread Boszormenyi Zoltan

2014-02-20 06:47 keltez?ssel, Michel D?nzer ?rta:
> On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
>> 2014-02-20 04:20 keltez?ssel, Michel D?nzer ?rta:
>>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
>>>> 2014-02-19 10:59 keltez?ssel, Michel D?nzer ?rta:
>>>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
>>>>>
>>>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time?
>>>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer
>>>>> though.
>>>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in
>>>> Fedora 20 at this time, it's not possible unless I compile my own
>>>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
>>> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
>>>
>>>
>>>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
>>> The log files end abruptly, so we need to see the X server stderr
>>> output. Assuming you're using gdm, it should be captured
>>> in /var/log/gdm*/:0.log .
>> FC20 has lightdm by default, here's /var/log/lightdm/x-0.log
> [...]
>
>> X: ../../../include/privates.h:122: dixGetPrivateAddr: Assertion
>> `key->initialized' failed.
> Can you get a backtrace for this assertion failure with gdb? See
> http://wiki.x.org/wiki/Development/Documentation/ServerDebugging/
>
>

Here it is. I simply started Xorg from my ssh sesion and got the same assertion 
failed.

[root at localhost ~]# gdb /usr/bin/Xorg
GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
..
Reading symbols from /usr/bin/Xorg...Reading symbols from 
/usr/lib/debug/usr/bin/Xorg.debug...done.
done.
(gdb) run
Starting program: /usr/bin/Xorg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

X.Org X Server 1.15.0
Release Date: 2013-12-27
X Protocol Version 11, Revision 0
Build Operating System:  3.12.8-300.fc20.x86_64
Current Operating System: Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 
SMP Fri 
Feb 14 19:08:32 UTC 2014 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.3-201.fc20.x86_64 
root=UUID=61edc6e4-5eb0-4ec6-869c-f80dd5bd1d93 ro 
vconsole.font=latarcyrheb-sun16 rhgb 
quiet LANG=hu_HU.UTF-8
Build Date: 18 February 2014  06:25:51AM
Build ID: xorg-x11-server 1.15.0-4.fc21
Current version of pixman: 0.32.0
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Feb 20 08:42:04 2014
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension Present
Initializing built-in extension DRI3
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension SELinux
Initializing built-in extension XFree86-VidModeExtension
Init

AMD/AMD hybrid graphics

2014-02-20 Thread Boszormenyi Zoltan

2014-02-20 04:20 keltez?ssel, Michel D?nzer ?rta:
> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
>> 2014-02-19 10:59 keltez?ssel, Michel D?nzer ?rta:
>>> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
>>>
>>>> Can Mesa/Xorg use both r600g and radeonsi at the same time?
>>> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer
>>> though.
>> Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in
>> Fedora 20 at this time, it's not possible unless I compile my own
>> llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?
> I don't think Xorg 1.15 is necessary, but it shouldn't hurt either.
>
>
>> Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), [...]
> The log files end abruptly, so we need to see the X server stderr
> output. Assuming you're using gdm, it should be captured
> in /var/log/gdm*/:0.log .

FC20 has lightdm by default, here's /var/log/lightdm/x-0.log

Thanks,
Zolt?n

-- next part --
A non-text attachment was scrubbed...
Name: x-0.log
Type: text/x-log
Size: 2438 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140220/c2d51790/attachment.bin>

AMD/AMD hybrid graphics

2014-02-19 Thread Boszormenyi Zoltan

2014-02-19 10:59 keltez?ssel, Michel D?nzer ?rta:
> On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote:
>> On second thought, the usage of VESA for installation and then
>> switching to KMS might have caused the mixed behaviour, i.e. that
>> the kernel recognized and initialized both chips but X used only the
>> integrated one. But I don't want to reinstall the system to test
>> this theory.
> I doubt it would make any difference.
>
>
>> Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and
>> RADEON(G0) lines (for HAINAN) are present.
> [...]
>> I would like to have PRIME functional so I will need to set "Switchable
>> Graphics" in the BIOS. What xorg.conf magic should I add to make it
>> use the ARUBA chip for display but still keep HAINAN active for PRIME?
> According to the screen enumeration above, that's already the case.

I see.

> https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for
> troubleshooting the crash.

I looked at it and the symptoms from comment 17 and comment 19
(blank screen with only the cursor visible) looks like it's very similar
to my case. Only when removing the "quiet" kernel command line option,
more is left visible on the screen, not just the cursor.

>> Can Mesa/Xorg use both r600g and radeonsi at the same time?
> Yes, that seems to work fine for others. You may need Mesa 10.1 or newer
> though.

Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in
Fedora 20 at this time, it's not possible unless I compile my own
llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT?

I tried to upgrade to rawhide at least in part:

[zozo at localhost ~]$ rpm -q kernel mesa-libGL xorg-x11-server-Xorg llvm-libs
kernel-3.13.3-201.fc20.x86_64
mesa-libGL-10.1-0.rc1.20140208.fc21.x86_64
mesa-libGL-10.1-0.rc1.20140208.fc21.i686
xorg-x11-server-Xorg-1.15.0-3.fc21.x86_64
llvm-libs-3.4-4.fc21.x86_64
llvm-libs-3.4-4.fc21.i686

I still get the same problem. Attached is the log from both 1.14.4 (FC20)
and 1.15.0 (rawhide), with this change so the timing info is cut off from
the beginning of each line to make it easier to produce a diff between
the two files:

[zozo at localhost ~]$ cat Xorg.0.log.hainan-active | cut -d ']' -f 2- 
 >Xorg.0.log.hainan-active-no-timing
[zozo at localhost ~]$ cat /var/log/Xorg.0.log | cut -d ']' -f 2- 
 >Xorg.0.log.hainan-active-no-timing-1.15

Best regards,
Zolt?n B?sz?rm?nyi

-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log.hainan-active-no-timing.gz
Type: application/x-tar
Size: 6728 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/898dc406/attachment-0002.tar>
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log.hainan-active-no-timing-1.15.gz
Type: application/x-tar
Size: 6738 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/898dc406/attachment-0003.tar>

AMD/AMD hybrid graphics

2014-02-19 Thread Boszormenyi Zoltan

Hi,

I just got a Lenovo Thinkpad Edge E545 notebook and
I have installed Fedora 20/x86_64.

The CPU is Richland A10-5750 (contains ARUBA graphics)
and there is also a discrete HAINAN chip with 2GB dedicated
memory on the mainboard.

The problems started during installation, it looked like the machine
was frozen when using KMS so I had to use VESA during installation.

I was able to install from the network and the latest kernel upgrade
is 3.13.3-201.

So, I was happy at first when I removed "nomodeset" and it booted up
properly in KMS mode and did so after the first few restarts.

Initially lspci showed both cards. dmesg told me that HAINAN was
not posted by the BIOS but the kernel did it and also loaded the
firmware into both cards. Xorg used the integrated ARUBA chip only.

Then I looked up info about PRIME and wanted to test it.
However, "xrandr --listproviders" showed only one line and
"DRI_PRIME=1 glxinfo64 | grep -i renderer" showed that
Mesa is using the ARUBA chip regardless of the DRI_PRIME setting.
I am sorry, I didn't save the xrandr output, so I can't prove it.
Anyway, Xorg.0.log had only traces about the ARUBA, nothing
about the discrete chip. Unfortunately, I didn't save neither dmesg
nor Xorg.0.log at the time.

The UEFI BIOS has a knob to switch between "Integrated Graphics"
and "Switchable Graphics" and switchable was the default. There
is another one for "OS detection for Switchable Graphics: enable/disable"

I started playing with the BIOS settings and this was (or was it?)
a mistake. (But this is how I discovered that the virtualization
enabled/disabled setting in the BIOS is actually reversed and I also
need KVM.)

The result of changing to "Integrated Graphics" in the BIOS and
changing back to "Switchable Graphics" and toggling the
"OS detection" switch to disabled and back to enabled changed
the system behavior.

The symptom is that after systemd loaded all the services, the
machine doesn't seem to do anything at first sight. The systemd
messages are left on the screen but the X greeter (lightdm) doesn't
show up. However, the system reacts to the power button and
shuts down properly. This was encouraging and on the next boot
I tried to ssh into the machine and successfully collect dmesg and
Xorg logs.

It turned out that now, when "Switchable Graphics" is active,
regardless of the state of "OS detection for Switchable Graphics",
Xorg initializes both cards and apparently wants to use the HAINAN
to display the X screen but dies in the process:

[zozo at localhost ~]$ ps auxw | grep Xorg
root   626  0.0  0.0 209748  4320 ?Ss   08:51   0:00 
/usr/bin/abrt-watch-log 
-F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD
zozo  1245  0.0  0.0 112680   976 pts/0S+   08:56   0:00 grep 
--color=auto Xorg
[zozo at localhost ~]$ ps auxw | grep dm
zozo  1247  0.0  0.0 112676   976 pts/0S+   08:57   0:00 grep 
--color=auto dm

Since this is a very new machine it seems footnote 5 from
http://wiki.x.org/wiki/RadeonFeature/ applies and the HAINAN chip
is not connected to the display output.

So, currently I can only get it to display X when I use the "Integrated
Graphics" setting in the BIOS. In this state, the discrete graphics chip
doesn't even show up in lspci:

[zozo at localhost ~]$ cat lspci-hainan-disabled
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) 
Processor Root Complex
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Richland [Radeon 
HD 8650G]
00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio 
Controller
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) 
Processor Root Port
00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) 
Processor Root Port
00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) 
Processor Root Port
00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller (rev 09)
00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller (rev 09)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller 
[AHCI 
mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI 
Controller (rev 11)
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI 
Controller (rev 11)
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI 
Controller (rev 11)
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI 
Controller (rev 11)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 16)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller 
(rev 01)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h

UVD on RS880

2014-01-14 Thread Boszormenyi Zoltan

2014-01-14 07:06 keltez?ssel, Chen Jie ?rta:
> 2014/1/10 Mike Lothian :
>> Fingers crossed this happens soon especially now that BluRays can be played
>> on Linux
>>
>> 1080p VC1 does not play well on a Phenom II X4 even when multi threaded
> It seems UVD based VC1 playback is broken??
>
> With a Radeon 6570 card, neither X86 nor the loongson platform give me
> a correct picture for my VC1 samples:
> * 
> http://dev.lemote.com/files/upload/software/temp/video-test/HDVideoSamples/VC1/Robotica_1080.wmv
> * 
> http://dev.lemote.com/files/upload/software/temp/video-test/HDVideoSamples/VC1/Wildlife.wmv

I just tried these files with Xine under Fedora 20 and I also have a HD6570 in 
my machine.

[zozo at localhost uvd-test-files]$ rpm -q xine-ui xine-lib kernel mesa-libGL 
mesa-vdpau-drivers
xine-ui-0.99.7-9.fc20.x86_64
xine-lib-1.2.4-3.fc20.x86_64
kernel-3.12.5-302.fc20.x86_64
kernel-3.12.6-300.fc20.x86_64
kernel-3.12.7-300.fc20.x86_64
mesa-libGL-9.2.5-1.20131220.fc20.x86_64
mesa-libGL-9.2.5-1.20131220.fc20.i686
mesa-vdpau-drivers-9.2.5-1.20131220.fc20.x86_64
[zozo at localhost uvd-test-files]$ uname -r
3.12.7-300.fc20.x86_64

Xine is set to use VDPAU:

[zozo at localhost uvd-test-files]$ xine Wildlife.wmv
This is xine (X11 gui) - a free video player v0.99.7.
(c) 2000-2010 The xine Team.
vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : G3DVL VDPAU Driver Shared Library 
version 1.0
vo_vdpau: maximum video surface size for chroma type 4:2:2 is 16384x16384
vo_vdpau: maximum video surface size for chroma type 4:2:0 is 16384x16384
vo_vdpau: VideoSurface doesn't support yuy2, sorry.
[zozo at localhost uvd-test-files]$ xine Robotica_1080.wmv
This is xine (X11 gui) - a free video player v0.99.7.
(c) 2000-2010 The xine Team.
vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : G3DVL VDPAU Driver Shared Library 
version 1.0
vo_vdpau: maximum video surface size for chroma type 4:2:2 is 16384x16384
vo_vdpau: maximum video surface size for chroma type 4:2:0 is 16384x16384
vo_vdpau: VideoSurface doesn't support yuy2, sorry.

I didn't see anything broken with these files, Wildlife.wmv had vivid colors
in every scene, the robotic arm and stuff in Robotica was shiny metallic grey.
No garbage anywhere.

UVD on RS880

2014-01-09 Thread Boszormenyi Zoltan

Hi,

according to http://wiki.x.org/wiki/RadeonFeature/#4 UVD on RS880 is a TODO.
I would like to ask about whether there are any plans to implement it and a
vague approximation for the release date, if it's planned.

Thanks in advance,
Zolt?n B?sz?rm?nyi

DPM on Radeon HD6570

2013-08-21 19:55 keltez?ssel, Alex Deucher ?rta:
> On Wed, Aug 21, 2013 at 1:49 PM, Boszormenyi Zoltan  wrote:
>> Hi,
>>
>> thanks for your response.
>>
>> 2013-08-21 17:39 keltez?ssel, Alex Deucher ?rta:
>>
>>> On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan
>>> wrote:
>>>> Hi,
>>>>
>>>> I read this Phoronix article:
>>>> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>>>>
>>>> Congrats to the progress achieved so far.
>>>>
>>>> However, I can see an interesting deviation for HD6570 from the
>>>> observed trend of other chips.
>>>>
>>>> r600g can reach 80+ percent of the performance of Catalyst
>>>> for most HD6xxx chips except for 6570, where the performance
>>>> is around 10-20 percent.
>>>>
>>>> Do you have a theory about this difference?
>>>> Maybe DPM doesn't work as intended on HD6570?
>>>>
>>> Are you seeing the same results on your board?  If so are the results
>>> roughly the same with dpm enabled vs. disabled?  If so I doubt there
>>> is a problem with dpm.  On older dGPUs like this one dpm won't really
>>> improve performance since the cards come up with relatively high
>>> clocks by default.  It's mainly for saving power when the GPU is idle.
>> I have enabled dpm:
>> $ cat /proc/cmdline
>> BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
>> root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1
>> radeon.dpm=1 LANG=hu_HU.UTF-8
>>
>> I have just tried "openarena 0.8.5" again with forced "low" performance.
>> Results is 26.87fps with low performance, 59.40-59.70fps with forced high
>> performance.
>>
> Sounds like you are refresh rate limited.  Try disabling
> swapbufferswait in your xorg.conf:
>
> Section "Device"
>  Identifier  "card0"
>  Driver  "iradeon"
>  Option "SwapbuffersWait" "false"
> EndSection
>
> and disable vsync in the 3D driver, set env var:
> vblank_mode=0

vblank_mode was already 0 before:

[zozo at localhost ~]$ cat .drirc

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


I have added this:

[root at localhost xorg.conf.d]# pwd
/etc/X11/xorg.conf.d
[root at localhost xorg.conf.d]# cat 99-vblank.conf
Section "Device"
 Identifier"card0"
 Driver"radeon"
 Option"SwapbuffersWait" "false"
EndSection

With forced high performance, I got 118.73 fps. Wow. :-)

> Also what does the performance look like with dpm disabled?

Same as forced high with dpm enabled.

> Anyway, it doesn't sound like dpm is an issue.

Indeed, dpm works as intended.
Something was misconfigured at Phoronix then.

Thanks for resolving this for me,
Zolt?n B?sz?rm?nyi

>
> Alex
>
>>>> I have this kind of video card, so I wanted to test it myself.
>>>> The exact model of my card is:
>>>>
>>>> http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#
>>>>
>>> Note that a lot of 6570 cards, including yours use DD3 memory rather
>>> than GDDR5 so they will have fairly limited memory bandwidth.
>> I know. The 6570 tested by Phoronix must be GDDR5
>> but it's not mentioned specifically.
>>
>> Best regards,
>> Zolt?n B?sz?rm?nyi
>>
>>
>>> Alex
>>>
>>>> I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
>>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=457463
>>>>
>>>> I haven't tested Catalyst but my r600g results mostly match
>>>> the ones in the article even with a different CPU.
>>>>
>>>> Best regards,
>>>> Zolt?n B?sz?rm?nyi
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

DPM on Radeon HD6570

2013-08-21 18:30 keltez?ssel, Grigori Goronzy ?rta:
> On 21.08.2013 16:31, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> I read this Phoronix article:
>> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>>
>> Congrats to the progress achieved so far.
>>
>> However, I can see an interesting deviation for HD6570 from the
>> observed trend of other chips.
>>
>> r600g can reach 80+ percent of the performance of Catalyst
>> for most HD6xxx chips except for 6570, where the performance
>> is around 10-20 percent.
>>
>> Do you have a theory about this difference?
>> Maybe DPM doesn't work as intended on HD6570?
>>
>
> There are some ways to check if DPM functions correctly.
>
> The kernel log (dmesg) contains a dump of the PowerPlay tables, search for 
> "power 
> state". It's possible that tables aren't read correctly or flaky to start 
> with.

Here it is:

[2.252567] [drm] Internal thermal controller with fan control
[2.252619] == power state 0 ==
[2.252621]  ui class: none
[2.252622]  internal class: boot
[2.252624]  caps:
[2.252625]  uvdvclk: 0 dclk: 0
[2.252627]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252628]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252629]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252630]  status: c r b
[2.252632] == power state 1 ==
[2.252632]  ui class: performance
[2.252633]  internal class: none
[2.252635]  caps:
[2.252636]  uvdvclk: 0 dclk: 0
[2.252637]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252640]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.252641]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252642]  status:
[2.252643] == power state 2 ==
[2.252644]  ui class: none
[2.252645]  internal class: uvd
[2.252646]  caps: video
[2.252647]  uvdvclk: 7 dclk: 56000
[2.252651]  power level 0sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252652]  power level 1sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252653]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252654]  status:
[2.257099] switching from power state:
[2.257105]  ui class: none
[2.257107]  internal class: boot
[2.257109]  caps:
[2.257111]  uvdvclk: 0 dclk: 0
[2.257113]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257114]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257116]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257117]  status: c b
[2.257129] switching to power state:
[2.257130]  ui class: performance
[2.257132]  internal class: none
[2.257133]  caps:
[2.257135]  uvdvclk: 0 dclk: 0
[2.257137]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257139]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.257140]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.257141]  status: r
[2.258555] [drm] radeon: dpm initialized


>
> You can also monitor the precise runtime power level (clocks and voltages) of 
> the GPU 
> with /sys/kernel/debug/dri/0/radeon_pm_info. Maybe dynamic switching does not 
> work for 
> some reason, and the GPU always uses the lowest level even under load. Just 
> run some 
> demanding OpenGL app and check that file to see if the GPU switches the power 
> level.

Just running this loop:

[root at localhost ~]# while `/bin/true` ; do cat 
/sys/kernel/debug/dri/0/radeon_pm_info ; 
sleep 1 ; done

while the terminal is sufficiently large on the screen results in changing 
power levels:

uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 80

DPM on Radeon HD6570

Hi,

thanks for your response.

2013-08-21 17:39 keltez?ssel, Alex Deucher ?rta:
> On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan  wrote:
>> Hi,
>>
>> I read this Phoronix article:
>> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>>
>> Congrats to the progress achieved so far.
>>
>> However, I can see an interesting deviation for HD6570 from the
>> observed trend of other chips.
>>
>> r600g can reach 80+ percent of the performance of Catalyst
>> for most HD6xxx chips except for 6570, where the performance
>> is around 10-20 percent.
>>
>> Do you have a theory about this difference?
>> Maybe DPM doesn't work as intended on HD6570?
>>
> Are you seeing the same results on your board?  If so are the results
> roughly the same with dpm enabled vs. disabled?  If so I doubt there
> is a problem with dpm.  On older dGPUs like this one dpm won't really
> improve performance since the cards come up with relatively high
> clocks by default.  It's mainly for saving power when the GPU is idle.

I have enabled dpm:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64 
root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1 
radeon.dpm=1 
LANG=hu_HU.UTF-8

I have just tried "openarena 0.8.5" again with forced "low" performance.
Results is 26.87fps with low performance, 59.40-59.70fps with forced high
performance.

>
>> I have this kind of video card, so I wanted to test it myself.
>> The exact model of my card is:
>> http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#
>>
> Note that a lot of 6570 cards, including yours use DD3 memory rather
> than GDDR5 so they will have fairly limited memory bandwidth.

I know. The 6570 tested by Phoronix must be GDDR5
but it's not mentioned specifically.

Best regards,
Zolt?n B?sz?rm?nyi

>
> Alex
>
>> I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=457463
>>
>> I haven't tested Catalyst but my r600g results mostly match
>> the ones in the article even with a different CPU.
>>
>> Best regards,
>> Zolt?n B?sz?rm?nyi
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

DPM on Radeon HD6570

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zolt?n B?sz?rm?nyi

DPM on Radeon HD6570


Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

Re: DPM on Radeon HD6570

Hi,

thanks for your response.

2013-08-21 17:39 keltezéssel, Alex Deucher írta:

On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan zbos...@pr.hu wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

Are you seeing the same results on your board? If so are the results
roughly the same with dpm enabled vs. disabled? If so I doubt there
is a problem with dpm. On older dGPUs like this one dpm won't really
improve performance since the cards come up with relatively high
clocks by default. It's mainly for saving power when the GPU is idle.

I have enabled dpm:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1 radeon.dpm=1
LANG=hu_HU.UTF-8

I have just tried openarena 0.8.5 again with forced low performance.
Results is 26.87fps with low performance, 59.40-59.70fps with forced high
performance.

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

Note that a lot of 6570 cards, including yours use DD3 memory rather
than GDDR5 so they will have fairly limited memory bandwidth.

I know. The 6570 tested by Phoronix must be GDDR5
but it's not mentioned specifically.

Best regards,
Zoltán Böszörményi

Alex

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

Re: DPM on Radeon HD6570


2013-08-21 18:30 keltezéssel, Grigori Goronzy írta:

On 21.08.2013 16:31, Boszormenyi Zoltan wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?



There are some ways to check if DPM functions correctly.

The kernel log (dmesg) contains a dump of the PowerPlay tables, search for power 
state. It's possible that tables aren't read correctly or flaky to start with.


Here it is:

[2.252567] [drm] Internal thermal controller with fan control
[2.252619] == power state 0 ==
[2.252621]  ui class: none
[2.252622]  internal class: boot
[2.252624]  caps:
[2.252625]  uvdvclk: 0 dclk: 0
[2.252627]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252628]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252629]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252630]  status: c r b
[2.252632] == power state 1 ==
[2.252632]  ui class: performance
[2.252633]  internal class: none
[2.252635]  caps:
[2.252636]  uvdvclk: 0 dclk: 0
[2.252637]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252640]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.252641]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252642]  status:
[2.252643] == power state 2 ==
[2.252644]  ui class: none
[2.252645]  internal class: uvd
[2.252646]  caps: video
[2.252647]  uvdvclk: 7 dclk: 56000
[2.252651]  power level 0sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252652]  power level 1sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252653]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252654]  status:
[2.257099] switching from power state:
[2.257105]  ui class: none
[2.257107]  internal class: boot
[2.257109]  caps:
[2.257111]  uvdvclk: 0 dclk: 0
[2.257113]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257114]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257116]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257117]  status: c b
[2.257129] switching to power state:
[2.257130]  ui class: performance
[2.257132]  internal class: none
[2.257133]  caps:
[2.257135]  uvdvclk: 0 dclk: 0
[2.257137]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257139]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.257140]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.257141]  status: r
[2.258555] [drm] radeon: dpm initialized




You can also monitor the precise runtime power level (clocks and voltages) of the GPU 
with /sys/kernel/debug/dri/0/radeon_pm_info. Maybe dynamic switching does not work for 
some reason, and the GPU always uses the lowest level even under load. Just run some 
demanding OpenGL app and check that file to see if the GPU switches the power level.


Just running this loop:

[root@localhost ~]# while `/bin/true` ; do cat /sys/kernel/debug/dri/0/radeon_pm_info ; 
sleep 1 ; done


while the terminal is sufficiently large on the screen results in changing 
power levels:

uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk

Re: DPM on Radeon HD6570

2013-08-21 19:55 keltezéssel, Alex Deucher írta:

On Wed, Aug 21, 2013 at 1:49 PM, Boszormenyi Zoltanzbos...@pr.hu wrote:

Hi,

thanks for your response.

2013-08-21 17:39 keltezéssel, Alex Deucher írta:

On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltanzbos...@pr.hu
wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have enabled dpm:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1
radeon.dpm=1 LANG=hu_HU.UTF-8

I have just tried openarena 0.8.5 again with forced low performance.
Results is 26.87fps with low performance, 59.40-59.70fps with forced high
performance.

Sounds like you are refresh rate limited. Try disabling
swapbufferswait in your xorg.conf:

Section Device
Identifier card0
Driver iradeon
Option SwapbuffersWait false
EndSection

and disable vsync in the 3D driver, set env var:
vblank_mode=0

vblank_mode was already 0 before:

[zozo@localhost ~]$ cat .drirc
driconf
device screen=0 driver=r600
application name=Default
option name=fthrottle_mode value=2 /
option name=pp_celshade value=0 /
option name=pp_jimenezmlaa value=0 /
option name=always_have_depth_buffer value=false /
option name=pp_jimenezmlaa_color value=0 /
option name=pp_nogreen value=0 /
option name=force_glsl_extensions_warn value=false /
option name=pp_nored value=0 /
option name=disable_glsl_line_continuations value=false /
option name=vblank_mode value=0 /
option name=allow_large_textures value=1 /
option name=pp_noblue value=0 /
/application
/device
/driconf

I have added this:

[root@localhost xorg.conf.d]# pwd
/etc/X11/xorg.conf.d
[root@localhost xorg.conf.d]# cat 99-vblank.conf
Section Device
Identifiercard0
Driverradeon
OptionSwapbuffersWait false
EndSection

With forced high performance, I got 118.73 fps. Wow. :-)

Also what does the performance look like with dpm disabled?

Same as forced high with dpm enabled.

Anyway, it doesn't sound like dpm is an issue.

Indeed, dpm works as intended.
Something was misconfigured at Phoronix then.

Thanks for resolving this for me,
Zoltán Böszörményi

Alex

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:

http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

Note that a lot of 6570 cards, including yours use DD3 memory rather
than GDDR5 so they will have fairly limited memory bandwidth.

I know. The 6570 tested by Phoronix must be GDDR5
but it's not mentioned specifically.

Best regards,
Zoltán Böszörményi

Alex

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

New prototype computer problem with S3 suspend

2013-06-07 Thread Boszormenyi Zoltan

2013-06-07 03:17 keltez?ssel, Aaron Lu ?rta:
> On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> we are working on an Intel Atom-based embedded PC and I have to
>> make suspend-to-RAM work but I can't seem to succeed.
>>
>> The symptom is that quite often, the machine resumes immediately
>> after pm-suspend. Sometimes more than 20 times out of 50 attempts.
> Can you please file a bug about this?
> https://bugzilla.kernel.org
>
>> I have tried 3.7.10, 3.9.4, 3.10-rc[234] and the linux-next branch from the
>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git repository.
>> The attached dmesg is from today's linux-pm/linux-next plus the
>> latest drm-fixes patchset posted by Dave Airlie.
>>
>> I have tried disabling wakeup devices via /proc/acpi/wakeup and via sysfs 
>> files.
>> (/sys/devices/.../wakeup)
> >From the dmesg, the following three devices are still armed with wakeup
> capability and might be the cause:
>
> i8042 kbd 00:03: System wakeup enabled by ACPI
> PM: suspend of devices complete after 578.883 msecs
> PM: late suspend of devices complete after 0.279 msecs
> pcieport :00:1c.1: System wakeup enabled by ACPI
> ehci-pci :00:1d.7: System wakeup enabled by ACPI
> PM: noirq suspend of devices complete after 31.946 msecs
>
> Anyway, please file a bug there, thanks.

For the suspend bug:
https://bugzilla.kernel.org/show_bug.cgi?id=59401

For the warnings in i915:
https://bugs.freedesktop.org/show_bug.cgi?id=65497

Best regards,
Zolt?n B?sz?rm?nyi

Re: New prototype computer problem with S3 suspend

2013-06-07 Thread Boszormenyi Zoltan


2013-06-07 03:17 keltezéssel, Aaron Lu írta:

On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote:

Hi,

we are working on an Intel Atom-based embedded PC and I have to
make suspend-to-RAM work but I can't seem to succeed.

The symptom is that quite often, the machine resumes immediately
after pm-suspend. Sometimes more than 20 times out of 50 attempts.

Can you please file a bug about this?
https://bugzilla.kernel.org


I have tried 3.7.10, 3.9.4, 3.10-rc[234] and the linux-next branch from the
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git repository.
The attached dmesg is from today's linux-pm/linux-next plus the
latest drm-fixes patchset posted by Dave Airlie.

I have tried disabling wakeup devices via /proc/acpi/wakeup and via sysfs files.
(/sys/devices/.../wakeup)

From the dmesg, the following three devices are still armed with wakeup
capability and might be the cause:

i8042 kbd 00:03: System wakeup enabled by ACPI
PM: suspend of devices complete after 578.883 msecs
PM: late suspend of devices complete after 0.279 msecs
pcieport :00:1c.1: System wakeup enabled by ACPI
ehci-pci :00:1d.7: System wakeup enabled by ACPI
PM: noirq suspend of devices complete after 31.946 msecs

Anyway, please file a bug there, thanks.


For the suspend bug:
https://bugzilla.kernel.org/show_bug.cgi?id=59401

For the warnings in i915:
https://bugs.freedesktop.org/show_bug.cgi?id=65497

Best regards,
Zoltán Böszörményi

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

New prototype computer problem with S3 suspend

2013-06-06 Thread Boszormenyi Zoltan

Hi,

we are working on an Intel Atom-based embedded PC and I have to
make suspend-to-RAM work but I can't seem to succeed.

The symptom is that quite often, the machine resumes immediately
after pm-suspend. Sometimes more than 20 times out of 50 attempts.

I have tried 3.7.10, 3.9.4, 3.10-rc[234] and the linux-next branch from the
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git repository.
The attached dmesg is from today's linux-pm/linux-next plus the
latest drm-fixes patchset posted by Dave Airlie.

The reason for cross-posting to dri-devel is the warnings that complain
about the video chip, like:

[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to power on

on boot and 4 further warnings appearing after the machine was resumed:

WARNING: at drivers/gpu/drm/i915/intel_display.c:3927 
intel_modeset_check_state+0xbd/0x539()
active connector not linked to encoder

WARNING: at drivers/gpu/drm/i915/intel_display.c:3933 
intel_modeset_check_state+0x119/0x539()

WARNING: at drivers/gpu/drm/i915/intel_display.c:7873 
intel_modeset_check_state+0x4d3/0x539()
encoder's active_connectors set, but no crtc

WARNING: at drivers/gpu/drm/i915/intel_display.c:7892 
intel_modeset_check_state+0x2c8/0x539()
encoder's computed active state doesn't match tracked active state (expected 0, 
found 1)

FYI. the machine does have LVDS and a touchscreen as well.

I have tried disabling wakeup devices via /proc/acpi/wakeup and via sysfs files.
(/sys/devices/.../wakeup)

We have cross-checked suspend-resume using Windows XP and Windows 7
and these OSs are able to properly suspend the machine 50 times out of
50 attempts with Intel's official driver for the GMA3150.

How can I make S3 suspend work reliably? Is there a missing piece from our 
kernel .config?

Best regards,
Zolt?n B?sz?rm?nyi

-- next part --
A non-text attachment was scrubbed...
Name: config-3.10-003.gz
Type: application/x-tar
Size: 18727 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: dmesg-sl20.txt.gz
Type: application/x-tar
Size: 11570 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: lspci-names.txt.gz
Type: application/x-tar
Size: 6484 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: lspci-numeric.txt.gz
Type: application/x-tar
Size: 6106 bytes
Desc: not available
URL:

Radeon GPU lockup with Brütal Legend

2013-05-11 Thread Boszormenyi Zoltan

2013-05-11 13:36 keltez?ssel, Boszormenyi Zoltan ?rta:
> Hi,
>
> I just bought the Humble Bundle Double Fine Bundle and tried Br?tal Legend.
> I got this when the second cutscene started and my Radeon HD6570 locked up.
>
> [18695.779736] radeon :01:00.0: GPU lockup CP stall for more than 
> 1msec
> [18695.779745] radeon :01:00.0: GPU lockup (waiting for 
> 0x001805f9 last 
> fence id 0x001805f0)
> [18695.779759] [drm] Disabling audio support
> [18695.780874] radeon :01:00.0: Saved 631 dwords of commands on ring 0.
> [18695.780911] BUG: unable to handle kernel paging request at c900120b2118
> [18695.781010] IP: [] radeon_fence_process+0x8e/0x160 
> [radeon]
> [18695.781128] PGD 42e00f067 PUD 42e030067 PMD 421d91067 PTE 0
> [18695.781213] Oops:  [#1] SMP
> [18695.781272] Modules linked in: ip6table_filter(F) ip6_tables(F) 
> ebtable_nat(F) 
> ebtables(F) ipt_MASQUERADE(F) iptable_nat(F) nf_nat_ipv4(F) nf_nat(F) 
> nf_conntrack_ipv4(F) nf_defrag_ipv4(F) xt_con
> ntrack(F) nf_conntrack(F) xt_CHECKSUM(F) iptable_mangle(F) fuse(F) 
> be2iscsi(F) bnep(F) 
> iscsi_boot_sysfs(F) bluetooth(F) bnx2i(F) cnic(F) uio(F) bridge(F) stp(F) 
> llc(F) 
> cxgb4i(F) cxgb4(F) cxgb3i(F)
> cxgb3(F) mdio(F) libcxgbi(F) ib_iser(F) rdma_cm(F) ib_addr(F) iw_cm(F) 
> ib_cm(F) ib_sa(F) 
> ib_mad(F) ib_core(F) iscsi_tcp(F) libiscsi_tcp(F) libiscsi(F) it87(F) 
> hwmon_vid(F) 
> scsi_transport_iscsi(F) s
> nd_hda_codec_hdmi(F) snd_hda_codec_realtek(F) snd_hda_intel(F) 
> snd_hda_codec(F) 
> snd_hwdep(F) snd_seq(F) snd_seq_device(F) snd_pcm(F) snd_page_alloc(F) 
> snd_timer(F) 
> r8169(F) edac_core(F) usblp(F) sp
> 5100_tco(F) snd(F) mii(F)
> [18695.782361]  i2c_piix4(F) edac_mce_amd(F) soundcore(F) fam15h_power(F) 
> k10temp(F) 
> eeepc_wmi(F) asus_wmi(F) microcode(F) pcspkr(F) serio_raw(F) sparse_keymap(F) 
> rfkill(F) 
> video(F) nfsd(F) auth_rp
> cgss(F) nfs_acl(F) lockd(F) vhost_net(F) tun(F) macvtap(F) macvlan(F) 
> kvm_amd(F) kvm(F) 
> sunrpc(F) binfmt_misc(F) uinput(F) usb_storage(F) crc32c_intel(F) 
> ghash_clmulni_intel(F) 
> firewire_ohci(F) fir
> ewire_core(F) 3w_9xxx(F) crc_itu_t(F) mxm_wmi(F) radeon(F) i2c_algo_bit(F) 
> drm_kms_helper(F) ttm(F) drm(F) i2c_core(F) wmi(F) [last unloaded: 
> ipmi_msghandler]
> [18695.783094] CPU: 6 PID: 1107 Comm: Xorg Tainted: GF 3.9.0+ #1
> [18695.783172] Hardware name: To be filled by O.E.M. To be filled by 
> O.E.M./M5A99X EVO, 
> BIOS 1604 10/16/2012
> [18695.783281] task: 880421789770 ti: 88040049a000 task.ti: 
> 88040049a000
> [18695.783367] RIP: 0010:[] [] 
> radeon_fence_process+0x8e/0x160 [radeon]
> [18695.783499] RSP: 0018:88040049bbc8  EFLAGS: 00010246
> [18695.783561] RAX: c900120b2118 RBX: 0002 RCX: 
> 
> [18695.783642] RDX: 0041 RSI:  RDI: 
> 880425cde000
> [18695.783724] RBP: 88040049bc28 R08: 880425cdedc0 R09: 
> 880425cde208
> [18695.783805] R10:  R11: 0005 R12: 
> 000c
> [18695.783887] R13: 880425cdee08 R14: 0002 R15: 
> 880425cde000
> [18695.783969] FS:  7fee008b2940() GS:88043ed8() 
> knlGS:f7607780
> [18695.784062] CS:  0010 DS:  ES:  CR0: 8005003b
> [18695.784153] CR2: c900120b2118 CR3: 0004229c3000 CR4: 
> 000407e0
> [18695.784238] DR0:  DR1:  DR2: 
> 
> [18695.784320] DR3:  DR6: 0ff0 DR7: 
> 0400
> [18695.784401] Stack:
> [18695.784427]  8804221a3c48 a0122cb0 88042814fd80 
> 88040049bc30
> [18695.784526]  88040049bc18 813edd5e 880425cde000 
> 880425cde000
> [18695.784624]  0005 880425cdee38 88040049bcf0 
> 88040049bdd0
> [18695.784725] Call Trace:
> [18695.784769]  [] ? __dev_printk+0x5e/0x90
> [18695.784859]  [] radeon_fence_count_emitted+0x20/0x70 
> [radeon]
> [18695.788569]  [] radeon_ring_backup+0x58/0x150 [radeon]
> [18695.792332]  [] radeon_gpu_reset+0x93/0x230 [radeon]
> [18695.796254]  [] radeon_gem_handle_lockup.part.2+0xe/0x20 
> [radeon]
> [18695.800352]  [] radeon_gem_wait_idle_ioctl+0xc8/0xe0 
> [radeon]
> [18695.804731]  [] drm_ioctl+0x4d3/0x570 [drm]
> [18695.806470]  [] ? __set_task_blocked+0x37/0x80
> [18695.808120]  [] ? radeon_gem_busy_ioctl+0x100/0x100 
> [radeon]
> [18695.809764]  [] ? fpu_finit+0x22/0x40
> [18695.811338]  [] ? init_fpu+0x61/0xc0
> [18695.812931]  [] do_vfs_ioctl+0x97/0x580
> [18695.814507]  [] ? 
> inode_has_perm.isra.32.constprop.62+0x2a/0x30
> [18695.816106]  [] ? file_has_perm+0x97/0xb0
> [18695.817

Radeon GPU lockup with Brütal Legend

2013-05-11 Thread Boszormenyi Zoltan

Hi,

I just bought the Humble Bundle Double Fine Bundle and tried Br?tal Legend.
I got this when the second cutscene started and my Radeon HD6570 locked up.

[18695.779736] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[18695.779745] radeon :01:00.0: GPU lockup (waiting for 0x001805f9 
last fence 
id 0x001805f0)
[18695.779759] [drm] Disabling audio support
[18695.780874] radeon :01:00.0: Saved 631 dwords of commands on ring 0.
[18695.780911] BUG: unable to handle kernel paging request at c900120b2118
[18695.781010] IP: [] radeon_fence_process+0x8e/0x160 [radeon]
[18695.781128] PGD 42e00f067 PUD 42e030067 PMD 421d91067 PTE 0
[18695.781213] Oops:  [#1] SMP
[18695.781272] Modules linked in: ip6table_filter(F) ip6_tables(F) 
ebtable_nat(F) 
ebtables(F) ipt_MASQUERADE(F) iptable_nat(F) nf_nat_ipv4(F) nf_nat(F) 
nf_conntrack_ipv4(F) 
nf_defrag_ipv4(F) xt_con
ntrack(F) nf_conntrack(F) xt_CHECKSUM(F) iptable_mangle(F) fuse(F) be2iscsi(F) 
bnep(F) 
iscsi_boot_sysfs(F) bluetooth(F) bnx2i(F) cnic(F) uio(F) bridge(F) stp(F) 
llc(F) cxgb4i(F) 
cxgb4(F) cxgb3i(F)
cxgb3(F) mdio(F) libcxgbi(F) ib_iser(F) rdma_cm(F) ib_addr(F) iw_cm(F) ib_cm(F) 
ib_sa(F) 
ib_mad(F) ib_core(F) iscsi_tcp(F) libiscsi_tcp(F) libiscsi(F) it87(F) 
hwmon_vid(F) 
scsi_transport_iscsi(F) s
nd_hda_codec_hdmi(F) snd_hda_codec_realtek(F) snd_hda_intel(F) snd_hda_codec(F) 
snd_hwdep(F) snd_seq(F) snd_seq_device(F) snd_pcm(F) snd_page_alloc(F) 
snd_timer(F) 
r8169(F) edac_core(F) usblp(F) sp
5100_tco(F) snd(F) mii(F)
[18695.782361]  i2c_piix4(F) edac_mce_amd(F) soundcore(F) fam15h_power(F) 
k10temp(F) 
eeepc_wmi(F) asus_wmi(F) microcode(F) pcspkr(F) serio_raw(F) sparse_keymap(F) 
rfkill(F) 
video(F) nfsd(F) auth_rp
cgss(F) nfs_acl(F) lockd(F) vhost_net(F) tun(F) macvtap(F) macvlan(F) 
kvm_amd(F) kvm(F) 
sunrpc(F) binfmt_misc(F) uinput(F) usb_storage(F) crc32c_intel(F) 
ghash_clmulni_intel(F) 
firewire_ohci(F) fir
ewire_core(F) 3w_9xxx(F) crc_itu_t(F) mxm_wmi(F) radeon(F) i2c_algo_bit(F) 
drm_kms_helper(F) ttm(F) drm(F) i2c_core(F) wmi(F) [last unloaded: 
ipmi_msghandler]
[18695.783094] CPU: 6 PID: 1107 Comm: Xorg Tainted: GF 3.9.0+ #1
[18695.783172] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./M5A99X EVO, 
BIOS 1604 10/16/2012
[18695.783281] task: 880421789770 ti: 88040049a000 task.ti: 
88040049a000
[18695.783367] RIP: 0010:[] [] 
radeon_fence_process+0x8e/0x160 [radeon]
[18695.783499] RSP: 0018:88040049bbc8  EFLAGS: 00010246
[18695.783561] RAX: c900120b2118 RBX: 0002 RCX: 
[18695.783642] RDX: 0041 RSI:  RDI: 880425cde000
[18695.783724] RBP: 88040049bc28 R08: 880425cdedc0 R09: 880425cde208
[18695.783805] R10:  R11: 0005 R12: 000c
[18695.783887] R13: 880425cdee08 R14: 0002 R15: 880425cde000
[18695.783969] FS:  7fee008b2940() GS:88043ed8() 
knlGS:f7607780
[18695.784062] CS:  0010 DS:  ES:  CR0: 8005003b
[18695.784153] CR2: c900120b2118 CR3: 0004229c3000 CR4: 000407e0
[18695.784238] DR0:  DR1:  DR2: 
[18695.784320] DR3:  DR6: 0ff0 DR7: 0400
[18695.784401] Stack:
[18695.784427]  8804221a3c48 a0122cb0 88042814fd80 
88040049bc30
[18695.784526]  88040049bc18 813edd5e 880425cde000 
880425cde000
[18695.784624]  0005 880425cdee38 88040049bcf0 
88040049bdd0
[18695.784725] Call Trace:
[18695.784769]  [] ? __dev_printk+0x5e/0x90
[18695.784859]  [] radeon_fence_count_emitted+0x20/0x70 
[radeon]
[18695.788569]  [] radeon_ring_backup+0x58/0x150 [radeon]
[18695.792332]  [] radeon_gpu_reset+0x93/0x230 [radeon]
[18695.796254]  [] radeon_gem_handle_lockup.part.2+0xe/0x20 
[radeon]
[18695.800352]  [] radeon_gem_wait_idle_ioctl+0xc8/0xe0 
[radeon]
[18695.804731]  [] drm_ioctl+0x4d3/0x570 [drm]
[18695.806470]  [] ? __set_task_blocked+0x37/0x80
[18695.808120]  [] ? radeon_gem_busy_ioctl+0x100/0x100 
[radeon]
[18695.809764]  [] ? fpu_finit+0x22/0x40
[18695.811338]  [] ? init_fpu+0x61/0xc0
[18695.812931]  [] do_vfs_ioctl+0x97/0x580
[18695.814507]  [] ? 
inode_has_perm.isra.32.constprop.62+0x2a/0x30
[18695.816106]  [] ? file_has_perm+0x97/0xb0
[18695.817635]  [] SyS_ioctl+0x91/0xb0
[18695.819150]  [] tracesys+0xdd/0xe2
[18695.820695] Code: 49 87 55 00 48 39 d0 48 89 c3 41 ba 01 00 00 00 73 46 41 
80 bf a0 16 
00 00 00 4d 8b b1 f8 0b 00 00 0f 84 8a 00 00 00 49 8b 40 10 <8b> 00 48 89 da 89 
c0 48 21 
ca 48 09 d0 48 39 c3 76 0b 4c 89 f2
[18695.823912] RIP  [] radeon_fence_process+0x8e/0x160 
[radeon]
[18695.825527]  RSP 
[18695.827077] CR2: c900120b2118
[18695.835008] ---[ end trace 294711b28bfd3975 ]---

Only the GPU locked up, I could ssh in and reboot it.

My system is Fedora 18/x86_64, with some upgraded components:
Kernel 3.9+ (commit

Radeon GPU lockup with Brütal Legend

2013-05-11 Thread Boszormenyi Zoltan


Hi,

I just bought the Humble Bundle Double Fine Bundle and tried Brütal Legend.
I got this when the second cutscene started and my Radeon HD6570 locked up.

[18695.779736] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[18695.779745] radeon :01:00.0: GPU lockup (waiting for 0x001805f9 last fence 
id 0x001805f0)

[18695.779759] [drm] Disabling audio support
[18695.780874] radeon :01:00.0: Saved 631 dwords of commands on ring 0.
[18695.780911] BUG: unable to handle kernel paging request at c900120b2118
[18695.781010] IP: [a009f41e] radeon_fence_process+0x8e/0x160 [radeon]
[18695.781128] PGD 42e00f067 PUD 42e030067 PMD 421d91067 PTE 0
[18695.781213] Oops:  [#1] SMP
[18695.781272] Modules linked in: ip6table_filter(F) ip6_tables(F) ebtable_nat(F) 
ebtables(F) ipt_MASQUERADE(F) iptable_nat(F) nf_nat_ipv4(F) nf_nat(F) nf_conntrack_ipv4(F) 
nf_defrag_ipv4(F) xt_con
ntrack(F) nf_conntrack(F) xt_CHECKSUM(F) iptable_mangle(F) fuse(F) be2iscsi(F) bnep(F) 
iscsi_boot_sysfs(F) bluetooth(F) bnx2i(F) cnic(F) uio(F) bridge(F) stp(F) llc(F) cxgb4i(F) 
cxgb4(F) cxgb3i(F)
cxgb3(F) mdio(F) libcxgbi(F) ib_iser(F) rdma_cm(F) ib_addr(F) iw_cm(F) ib_cm(F) ib_sa(F) 
ib_mad(F) ib_core(F) iscsi_tcp(F) libiscsi_tcp(F) libiscsi(F) it87(F) hwmon_vid(F) 
scsi_transport_iscsi(F) s
nd_hda_codec_hdmi(F) snd_hda_codec_realtek(F) snd_hda_intel(F) snd_hda_codec(F) 
snd_hwdep(F) snd_seq(F) snd_seq_device(F) snd_pcm(F) snd_page_alloc(F) snd_timer(F) 
r8169(F) edac_core(F) usblp(F) sp

5100_tco(F) snd(F) mii(F)
[18695.782361]  i2c_piix4(F) edac_mce_amd(F) soundcore(F) fam15h_power(F) k10temp(F) 
eeepc_wmi(F) asus_wmi(F) microcode(F) pcspkr(F) serio_raw(F) sparse_keymap(F) rfkill(F) 
video(F) nfsd(F) auth_rp
cgss(F) nfs_acl(F) lockd(F) vhost_net(F) tun(F) macvtap(F) macvlan(F) kvm_amd(F) kvm(F) 
sunrpc(F) binfmt_misc(F) uinput(F) usb_storage(F) crc32c_intel(F) ghash_clmulni_intel(F) 
firewire_ohci(F) fir
ewire_core(F) 3w_9xxx(F) crc_itu_t(F) mxm_wmi(F) radeon(F) i2c_algo_bit(F) 
drm_kms_helper(F) ttm(F) drm(F) i2c_core(F) wmi(F) [last unloaded: ipmi_msghandler]

[18695.783094] CPU: 6 PID: 1107 Comm: Xorg Tainted: GF 3.9.0+ #1
[18695.783172] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A99X EVO, 
BIOS 1604 10/16/2012

[18695.783281] task: 880421789770 ti: 88040049a000 task.ti: 
88040049a000
[18695.783367] RIP: 0010:[a009f41e] [a009f41e] 
radeon_fence_process+0x8e/0x160 [radeon]

[18695.783499] RSP: 0018:88040049bbc8  EFLAGS: 00010246
[18695.783561] RAX: c900120b2118 RBX: 0002 RCX: 
[18695.783642] RDX: 0041 RSI:  RDI: 880425cde000
[18695.783724] RBP: 88040049bc28 R08: 880425cdedc0 R09: 880425cde208
[18695.783805] R10:  R11: 0005 R12: 000c
[18695.783887] R13: 880425cdee08 R14: 0002 R15: 880425cde000
[18695.783969] FS:  7fee008b2940() GS:88043ed8() 
knlGS:f7607780
[18695.784062] CS:  0010 DS:  ES:  CR0: 8005003b
[18695.784153] CR2: c900120b2118 CR3: 0004229c3000 CR4: 000407e0
[18695.784238] DR0:  DR1:  DR2: 
[18695.784320] DR3:  DR6: 0ff0 DR7: 0400
[18695.784401] Stack:
[18695.784427]  8804221a3c48 a0122cb0 88042814fd80 
88040049bc30
[18695.784526]  88040049bc18 813edd5e 880425cde000 
880425cde000
[18695.784624]  0005 880425cdee38 88040049bcf0 
88040049bdd0
[18695.784725] Call Trace:
[18695.784769]  [813edd5e] ? __dev_printk+0x5e/0x90
[18695.784859]  [a00a0180] radeon_fence_count_emitted+0x20/0x70 
[radeon]
[18695.788569]  [a00b65f8] radeon_ring_backup+0x58/0x150 [radeon]
[18695.792332]  [a0089e53] radeon_gpu_reset+0x93/0x230 [radeon]
[18695.796254]  [a00b49de] radeon_gem_handle_lockup.part.2+0xe/0x20 
[radeon]
[18695.800352]  [a00b5348] radeon_gem_wait_idle_ioctl+0xc8/0xe0 
[radeon]
[18695.804731]  [a001f493] drm_ioctl+0x4d3/0x570 [drm]
[18695.806470]  [81070f47] ? __set_task_blocked+0x37/0x80
[18695.808120]  [a00b5280] ? radeon_gem_busy_ioctl+0x100/0x100 
[radeon]
[18695.809764]  [8101b462] ? fpu_finit+0x22/0x40
[18695.811338]  [8101b791] ? init_fpu+0x61/0xc0
[18695.812931]  [811b07c7] do_vfs_ioctl+0x97/0x580
[18695.814507]  [812980ea] ? 
inode_has_perm.isra.32.constprop.62+0x2a/0x30
[18695.816106]  [81299717] ? file_has_perm+0x97/0xb0
[18695.817635]  [811b0d41] SyS_ioctl+0x91/0xb0
[18695.819150]  [8166d867] tracesys+0xdd/0xe2
[18695.820695] Code: 49 87 55 00 48 39 d0 48 89 c3 41 ba 01 00 00 00 73 46 41 80 bf a0 16 
00 00 00 4d 8b b1 f8 0b 00 00 0f 84 8a 00 00 00 49 8b 40 10 8b 00 48 89 da 89 c0 48 21 
ca 48 09 d0 48 39 c3 76 0b 4c 89 f2

[18695.823912] RIP

[RFC][PATCH] drm: add helper extracting SADs from EDID

2013-04-07 Thread Boszormenyi Zoltan

Hi,

will there be a followup patch where this function is actually used?

Best regards,
Zolt?n B?sz?rm?nyi

2013-04-07 12:52 keltez?ssel, Rafa? Mi?ecki ?rta:
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardware/firmware does the rest. In such a cases we need to read info
> from SAD blocks and put them in the correct registers.
> ---
>   drivers/gpu/drm/drm_edid.c |   55 
> 
>   include/drm/drm_edid.h |   24 +++
>   2 files changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e2acfdb..7c9e799 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2511,6 +2511,61 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>   EXPORT_SYMBOL(drm_edid_to_eld);
>   
>   /**
> + * drm_edid_to_sad - extracts SADs from EDID
> + * @edid: EDID to parse
> + *
> + * Looks for CEA EDID block and extracts SADs (Short Audio Descriptors) from 
> it.
> + */
> +struct cea_sad *drm_edid_to_sad(struct edid *edid)
> +{
> + struct cea_sad *sads = NULL;
> + int i, start, end, dbl;
> + u8 *db, *cea;
> +
> + cea = drm_find_cea_extension(edid);
> + if (!cea) {
> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> + return NULL;
> + }
> +
> + if (cea_revision(cea) < 3) {
> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> + return NULL;
> + }
> +
> + if (cea_db_offsets(cea, , )) {
> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
> + return NULL;
> + }
> +
> + for_each_cea_db(cea, i, start, end) {
> + db = [i];
> + dbl = cea_db_payload_len(db);
> +
> + if (cea_db_tag(db) == AUDIO_BLOCK) {
> + int count = dbl / 3; /* SAD is 3B */
> + int j;
> +
> + sads = kzalloc(count + 1 * sizeof(*sads), GFP_KERNEL);
> + if (!sads)
> + return NULL;
> +
> + for (j = 0; j < count; j++) {
> + u8 *sad = [1 + j * 3];
> +
> + sads[j].format = (sad[0] & 0x78) >> 3;
> + sads[j].channels = sad[0] & 0x7;
> + sads[j].freq = sad[1] & 0x7F;
> + sads[j].byte2 = sad[2];
> + }
> + }
> + }
> +
> + return sads;
> +}
> +EXPORT_SYMBOL(drm_edid_to_sad);
> +
> +/**
>* drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
>* @connector: connector associated with the HDMI/DP sink
>* @mode: the display mode
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 5da1b4a..b36d052 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -244,12 +244,36 @@ struct edid {
>   
>   #define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] << 8))
>   
> +#define SAD_FORMAT_LPCM  0x01
> +#define SAD_FORMAT_AC3   0x02
> +#define SAD_FORMAT_MPEG1 0x03
> +#define SAD_FORMAT_MP3   0x04
> +#define SAD_FORMAT_MPEG2 0x05
> +#define SAD_FORMAT_AAC   0x06
> +#define SAD_FORMAT_DTS   0x07
> +#define SAD_FORMAT_ATRAC 0x08
> +#define SAD_FORMAT_ONE_BIT_AUDIO 0x09
> +#define SAD_FORMAT_DOLBY_DIGITAL 0x0a
> +#define SAD_FORMAT_DTS_HD0x0b
> +#define SAD_FORMAT_MAT_MLP   0x0c
> +#define SAD_FORMAT_DST   0x0d
> +#define SAD_FORMAT_WMA_PRO   0x0e
> +
> +/* Short Audio Descriptor */
> +struct cea_sad {
> + u8 format;
> + u8 channels; /* max number of channels - 1 */
> + u8 freq;
> + u8 byte2; /* meaning depends on format */
> +};
> +
>   struct drm_encoder;
>   struct drm_connector;
>   struct drm_display_mode;
>   struct hdmi_avi_infoframe;
>   
>   void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
> +struct cea_sad *drm_edid_to_sad(struct edid *edid);
>   int drm_av_sync_delay(struct drm_connector *connector,
> struct drm_display_mode *mode);
>   struct drm_connector *drm_select_eld(struct drm_encoder *encoder,

Re: [RFC][PATCH] drm: add helper extracting SADs from EDID

2013-04-07 Thread Boszormenyi Zoltan


Hi,

will there be a followup patch where this function is actually used?

Best regards,
Zoltán Böszörményi

2013-04-07 12:52 keltezéssel, Rafał Miłecki írta:

Some devices (ATI/AMD cards) don't want passing ELD struct to the
hardware but just require filling specific registers and then
hardware/firmware does the rest. In such a cases we need to read info
from SAD blocks and put them in the correct registers.
---
  drivers/gpu/drm/drm_edid.c |   55 
  include/drm/drm_edid.h |   24 +++
  2 files changed, 79 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2acfdb..7c9e799 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2511,6 +2511,61 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
  EXPORT_SYMBOL(drm_edid_to_eld);
  
  /**

+ * drm_edid_to_sad - extracts SADs from EDID
+ * @edid: EDID to parse
+ *
+ * Looks for CEA EDID block and extracts SADs (Short Audio Descriptors) from 
it.
+ */
+struct cea_sad *drm_edid_to_sad(struct edid *edid)
+{
+   struct cea_sad *sads = NULL;
+   int i, start, end, dbl;
+   u8 *db, *cea;
+
+   cea = drm_find_cea_extension(edid);
+   if (!cea) {
+   DRM_DEBUG_KMS(SAD: no CEA Extension found\n);
+   return NULL;
+   }
+
+   if (cea_revision(cea)  3) {
+   DRM_DEBUG_KMS(SAD: wrong CEA revision\n);
+   return NULL;
+   }
+
+   if (cea_db_offsets(cea, start, end)) {
+   DRM_DEBUG_KMS(SAD: invalid data block offsets\n);
+   return NULL;
+   }
+
+   for_each_cea_db(cea, i, start, end) {
+   db = cea[i];
+   dbl = cea_db_payload_len(db);
+
+   if (cea_db_tag(db) == AUDIO_BLOCK) {
+   int count = dbl / 3; /* SAD is 3B */
+   int j;
+
+   sads = kzalloc(count + 1 * sizeof(*sads), GFP_KERNEL);
+   if (!sads)
+   return NULL;
+
+   for (j = 0; j  count; j++) {
+   u8 *sad = db[1 + j * 3];
+
+   sads[j].format = (sad[0]  0x78)  3;
+   sads[j].channels = sad[0]  0x7;
+   sads[j].freq = sad[1]  0x7F;
+   sads[j].byte2 = sad[2];
+   }
+   }
+   }
+
+   return sads;
+}
+EXPORT_SYMBOL(drm_edid_to_sad);
+
+/**
   * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
   * @connector: connector associated with the HDMI/DP sink
   * @mode: the display mode
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 5da1b4a..b36d052 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -244,12 +244,36 @@ struct edid {
  
  #define EDID_PRODUCT_ID(e) ((e)-prod_code[0] | ((e)-prod_code[1]  8))
  
+#define SAD_FORMAT_LPCM			0x01

+#define SAD_FORMAT_AC3 0x02
+#define SAD_FORMAT_MPEG1   0x03
+#define SAD_FORMAT_MP3 0x04
+#define SAD_FORMAT_MPEG2   0x05
+#define SAD_FORMAT_AAC 0x06
+#define SAD_FORMAT_DTS 0x07
+#define SAD_FORMAT_ATRAC   0x08
+#define SAD_FORMAT_ONE_BIT_AUDIO   0x09
+#define SAD_FORMAT_DOLBY_DIGITAL   0x0a
+#define SAD_FORMAT_DTS_HD  0x0b
+#define SAD_FORMAT_MAT_MLP 0x0c
+#define SAD_FORMAT_DST 0x0d
+#define SAD_FORMAT_WMA_PRO 0x0e
+
+/* Short Audio Descriptor */
+struct cea_sad {
+   u8 format;
+   u8 channels; /* max number of channels - 1 */
+   u8 freq;
+   u8 byte2; /* meaning depends on format */
+};
+
  struct drm_encoder;
  struct drm_connector;
  struct drm_display_mode;
  struct hdmi_avi_infoframe;
  
  void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);

+struct cea_sad *drm_edid_to_sad(struct edid *edid);
  int drm_av_sync_delay(struct drm_connector *connector,
  struct drm_display_mode *mode);
  struct drm_connector *drm_select_eld(struct drm_encoder *encoder,


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

Radeon HDMI question

2013-03-06 Thread Boszormenyi Zoltan

Hi,

2013-03-06 10:50 keltez?ssel, Christian K?nig ?rta:
> Hi,
>
> Am 05.03.2013 19:26, schrieb Boszormenyi Zoltan:
>> OK, a new problem now with 5.1 sound, it can be reproduced.
>>
>> I still have the same setup as described above.
>> I started watching a video. Initially, HDMI audio just works nicely.
>> I had to do something else so I paused Xine.
>> During this time, X went to DPMS blanking.
>> The TV switches itself off  to save power if it sees no input.
>> So, after waking up the monitor from DPMS and turning on the
>> TV again, I pressed play on the video. It continues playing but
>> without the sound.
>>
>> It seems to be the same with Linux 3.8.1 and earlier kernels.
>
> Does that also happen with just plain stereo playback? If yes then this is a 
> bug with 
> restoring the correct audio settings after DPMS blanking.

I will try to test it later, also with mplayer.

>
> If not (and that's what I think is more likely) than that's because DPMS 
> blanking causes 
> a desync between xine and your TV. Unfortunately there isn't much we can do 
> about it 
> (maybe expect disabling DPMS all together), Cause from the hardware point of 
> view it's 
> just not possible to tell the audio codec to stop playback because the 
> display isn't 
> turned on any more.
>
> Does it work when you close xine and restart it? If yes than it might be 
> worth a try to 
> tell xine to close and reopen the audio device on pause/restart of playback.

Unfortunately, after HDMI audio goes away, restarting Xine doesn't help at all.

The audio driver is pulseaudio in Xine, so I can switch between the built-in
audio with stereo speakers and the HDMI output and the speakers produce
the expected sounds.

Also, the vumeter in pavucontrol shows that sound is generated from Xine,
no matter which hardware is selected and even when HDMI is selected
but there is no sound on the TV after it went out.

The sound only comes back when I reboot the computer.

>
>>
>> There is nothing in dmesg, only:
>>
>> ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128
>> ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
>
> That's unrelated, the alsa driver just assumes the standard ELD informations 
> for the 
> HDMI audio codec, but AMD hardware is actually not using it.
>
> The real solution to your problem is to finally implement 8 channel PCM 
> audio, instead 
> of just using this ugly 5.1 pass through workaround. But so far nobody had 
> time to do so.

Thanks for the information.

Best regards,
Zolt?n B?sz?rm?nyi

Re: Radeon HDMI question

2013-03-06 Thread Boszormenyi Zoltan


Hi,

2013-03-06 10:50 keltezéssel, Christian König írta:

Hi,

Am 05.03.2013 19:26, schrieb Boszormenyi Zoltan:

OK, a new problem now with 5.1 sound, it can be reproduced.

I still have the same setup as described above.
I started watching a video. Initially, HDMI audio just works nicely.
I had to do something else so I paused Xine.
During this time, X went to DPMS blanking.
The TV switches itself off  to save power if it sees no input.
So, after waking up the monitor from DPMS and turning on the
TV again, I pressed play on the video. It continues playing but
without the sound.

It seems to be the same with Linux 3.8.1 and earlier kernels.


Does that also happen with just plain stereo playback? If yes then this is a bug with 
restoring the correct audio settings after DPMS blanking.


I will try to test it later, also with mplayer.



If not (and that's what I think is more likely) than that's because DPMS blanking causes 
a desync between xine and your TV. Unfortunately there isn't much we can do about it 
(maybe expect disabling DPMS all together), Cause from the hardware point of view it's 
just not possible to tell the audio codec to stop playback because the display isn't 
turned on any more.


Does it work when you close xine and restart it? If yes than it might be worth a try to 
tell xine to close and reopen the audio device on pause/restart of playback.


Unfortunately, after HDMI audio goes away, restarting Xine doesn't help at all.

The audio driver is pulseaudio in Xine, so I can switch between the built-in
audio with stereo speakers and the HDMI output and the speakers produce
the expected sounds.

Also, the vumeter in pavucontrol shows that sound is generated from Xine,
no matter which hardware is selected and even when HDMI is selected
but there is no sound on the TV after it went out.

The sound only comes back when I reboot the computer.





There is nothing in dmesg, only:

ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0


That's unrelated, the alsa driver just assumes the standard ELD informations for the 
HDMI audio codec, but AMD hardware is actually not using it.


The real solution to your problem is to finally implement 8 channel PCM audio, instead 
of just using this ugly 5.1 pass through workaround. But so far nobody had time to do so.


Thanks for the information.

Best regards,
Zoltán Böszörményi

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

Radeon HDMI question

2013-03-05 Thread Boszormenyi Zoltan

Hi,

2013-01-18 13:04 keltez?ssel, Christian K?nig ?rta:
> Am 17.01.2013 20:35, schrieb Boszormenyi Zoltan:
>> Hi,
>>
>> I experience a strange problem, I don't know whether
>> it's a feature or a bug, and if it's a bug, where.
>>
>> I have a Radeon HD6570. A monitor via DVI and an LCD TV
>> via HDMI are connected. Fedora 18/x86_64 is installed on
>> the computer. (Previously it was F17, F16 and F14.)
>>
>> When playing videos via Xine, all videos with 5.1 sound
>> works nicely via the HDMI, the sound output is on the TV.
>> However, when only stereo or mono sound is present in
>> the video, the sound doesn't go out to the TV.
>>
>> I have an internal soundcard and speakers are connected.
>> Pulseaudio on modern Linuxen has the feature to switch the
>> audio output device on the fly and per-application, so I can
>> switch between the outputs.
>>
>> Is is possible to make mono and stereo audio work via HDMI?
>
> Hi Zolt?n,
>
> that just sounds like a mis configured Xine to me. Xine can be configured to 
> use 
> different outputs for Mono/Stero and 5.1 sounds.
>
> You can also configure ALSA to route the audio differently depending on the 
> number of 
> channels, but that isn't the default and if you configured it like this you 
> probably 
> would remember it :)

I am sure I would remember it. :)

> I can't really see a way how this can be a hardware problem either, cause 5.1 
> audio pass 
> through is handled mostly the same as Stereo.
>
> I suggest that you check your Xine configuration, you should find multiple 
> setting for 
> selection the output device (Mono/Stereo/5.1/7.1 etc...) make sure that they 
> all point 
> to the correct hardware device.
>
> Regards,
> Christian.

OK, a new problem now with 5.1 sound, it can be reproduced.

I still have the same setup as described above.
I started watching a video. Initially, HDMI audio just works nicely.
I had to do something else so I paused Xine.
During this time, X went to DPMS blanking.
The TV switches itself off  to save power if it sees no input.
So, after waking up the monitor from DPMS and turning on the
TV again, I pressed play on the video. It continues playing but
without the sound.

It seems to be the same with Linux 3.8.1 and earlier kernels.

There is nothing in dmesg, only:

ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0

Thanks in advance,
Zolt?n B?sz?rm?nyi

Re: Radeon HDMI question

2013-03-05 Thread Boszormenyi Zoltan


Hi,

2013-01-18 13:04 keltezéssel, Christian König írta:

Am 17.01.2013 20:35, schrieb Boszormenyi Zoltan:

Hi,

I experience a strange problem, I don't know whether
it's a feature or a bug, and if it's a bug, where.

I have a Radeon HD6570. A monitor via DVI and an LCD TV
via HDMI are connected. Fedora 18/x86_64 is installed on
the computer. (Previously it was F17, F16 and F14.)

When playing videos via Xine, all videos with 5.1 sound
works nicely via the HDMI, the sound output is on the TV.
However, when only stereo or mono sound is present in
the video, the sound doesn't go out to the TV.

I have an internal soundcard and speakers are connected.
Pulseaudio on modern Linuxen has the feature to switch the
audio output device on the fly and per-application, so I can
switch between the outputs.

Is is possible to make mono and stereo audio work via HDMI?


Hi Zoltán,

that just sounds like a mis configured Xine to me. Xine can be configured to use 
different outputs for Mono/Stero and 5.1 sounds.


You can also configure ALSA to route the audio differently depending on the number of 
channels, but that isn't the default and if you configured it like this you probably 
would remember it :)


I am sure I would remember it. :)

I can't really see a way how this can be a hardware problem either, cause 5.1 audio pass 
through is handled mostly the same as Stereo.


I suggest that you check your Xine configuration, you should find multiple setting for 
selection the output device (Mono/Stereo/5.1/7.1 etc...) make sure that they all point 
to the correct hardware device.


Regards,
Christian.


OK, a new problem now with 5.1 sound, it can be reproduced.

I still have the same setup as described above.
I started watching a video. Initially, HDMI audio just works nicely.
I had to do something else so I paused Xine.
During this time, X went to DPMS blanking.
The TV switches itself off  to save power if it sees no input.
So, after waking up the monitor from DPMS and turning on the
TV again, I pressed play on the video. It continues playing but
without the sound.

It seems to be the same with Linux 3.8.1 and earlier kernels.

There is nothing in dmesg, only:

ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0

Thanks in advance,
Zoltán Böszörményi

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

Radeon HDMI question

2013-01-17 Thread Boszormenyi Zoltan

Hi,

I experience a strange problem, I don't know whether
it's a feature or a bug, and if it's a bug, where.

I have a Radeon HD6570. A monitor via DVI and an LCD TV
via HDMI are connected. Fedora 18/x86_64 is installed on
the computer. (Previously it was F17, F16 and F14.)

When playing videos via Xine, all videos with 5.1 sound
works nicely via the HDMI, the sound output is on the TV.
However, when only stereo or mono sound is present in
the video, the sound doesn't go out to the TV.

I have an internal soundcard and speakers are connected.
Pulseaudio on modern Linuxen has the feature to switch the
audio output device on the fly and per-application, so I can
switch between the outputs.

Is is possible to make mono and stereo audio work via HDMI?

Thanks in advance,
Zolt?n B?sz?rm?nyi

Radeon HDMI question

2013-01-17 Thread Boszormenyi Zoltan


Hi,

I experience a strange problem, I don't know whether
it's a feature or a bug, and if it's a bug, where.

I have a Radeon HD6570. A monitor via DVI and an LCD TV
via HDMI are connected. Fedora 18/x86_64 is installed on
the computer. (Previously it was F17, F16 and F14.)

When playing videos via Xine, all videos with 5.1 sound
works nicely via the HDMI, the sound output is on the TV.
However, when only stereo or mono sound is present in
the video, the sound doesn't go out to the TV.

I have an internal soundcard and speakers are connected.
Pulseaudio on modern Linuxen has the feature to switch the
audio output device on the fly and per-application, so I can
switch between the outputs.

Is is possible to make mono and stereo audio work via HDMI?

Thanks in advance,
Zoltán Böszörményi

___
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

2013-01-04 Thread Boszormenyi Zoltan

2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
> On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
>> From: Alex Deucher 
>> Date: Wed, 2 Jan 2013 18:30:21 -0500
>> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>>
>> count must be a multiple of 2.
>>
>> Cc: Borislav Petkov 
>> Cc: Markus Trippelsdorf 
>> Signed-off-by: Alex Deucher 
> Thanks, will run it on the box in question next week when I have access.
>
> Btw, you could add the note about count needing to be a multiple of 2 as
> a comment in the code below, for future reference.
>
>> ---
>>   drivers/gpu/drm/radeon/r600.c |4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 2aaf147..9f4ce5e 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>>   
>>  for (i = 0; i < num_loops; i++) {
>>  cur_size_in_dw = size_in_dw;
>> -if (cur_size_in_dw > 0x)
>> -cur_size_in_dw = 0x;
>> +if (cur_size_in_dw > 0xFFFE)
>> +cur_size_in_dw = 0xFFFE;

How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?

   if (cur_size_in_dw & 0x0001)
cur_size_in_dw &= ~1;



>>  size_in_dw -= cur_size_in_dw;
>>  radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
>> cur_size_in_dw));
>>  radeon_ring_write(ring, dst_offset & 0xfffc);
>> -- 
>> 1.7.7.5

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

2013-01-04 Thread Boszormenyi Zoltan


2013-01-04 08:40 keltezéssel, Borislav Petkov írta:

On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:

From: Alex Deucher alexander.deuc...@amd.com
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers

count must be a multiple of 2.

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

Thanks, will run it on the box in question next week when I have access.

Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.


---
  drivers/gpu/drm/radeon/r600.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2aaf147..9f4ce5e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
  
  	for (i = 0; i  num_loops; i++) {

cur_size_in_dw = size_in_dw;
-   if (cur_size_in_dw  0x)
-   cur_size_in_dw = 0x;
+   if (cur_size_in_dw  0xFFFE)
+   cur_size_in_dw = 0xFFFE;


How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?

  if (cur_size_in_dw  0x0001)
   cur_size_in_dw = ~1;




size_in_dw -= cur_size_in_dw;
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, 
cur_size_in_dw));
radeon_ring_write(ring, dst_offset  0xfffc);
--
1.7.7.5


___
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

2013-01-03 Thread Boszormenyi Zoltan

2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta:
> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
>  wrote:
>> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
>>> Please affected people can you test if patch :
>>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
>>>
>>> Fix the issue, you need to make sure you don't have the patch that
>>> disable dma on r6xx ie that line 977-978 & 1061-1062  in radeon_asic.c
>>> is :
>>>   .copy = _copy_dma,
>>>   .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> It fixes the issue for me. Thanks.
> The count is actually the count, not count - 1.  The real fix seems to
> be that r6xx requires 2 dw aligned transfers.  The attached patch
> fixes the issue for me.
>
> Alex

I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage.
Only some text, like "Not on the list?" below the users and small icons are 
visible
but many user names are not rendered. http://tinypic.com/r/33xihit/6
I am on Fedora 18/x86_64, Radeon HD6570.

Best regards,
Zolt?n B?sz?rm?nyi

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

2013-01-03 Thread Boszormenyi Zoltan


2013-01-03 00:37 keltezéssel, Alex Deucher írta:

On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:

On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:

Please affected people can you test if patch :
http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch

Fix the issue, you need to make sure you don't have the patch that
disable dma on r6xx ie that line 977-978  1061-1062  in radeon_asic.c
is :
  .copy = r600_copy_dma,
  .copy_ring_index = R600_RING_TYPE_DMA_INDEX,

It fixes the issue for me. Thanks.

The count is actually the count, not count - 1.  The real fix seems to
be that r6xx requires 2 dw aligned transfers.  The attached patch
fixes the issue for me.

Alex


I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage.
Only some text, like Not on the list? below the users and small icons are 
visible
but many user names are not rendered. http://tinypic.com/r/33xihit/6
I am on Fedora 18/x86_64, Radeon HD6570.

Best regards,
Zoltán Böszörményi

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

[PATCH 1/3] pci_regs: define LNKSTA2 pcie cap + bits.

2012-06-29 Thread Boszormenyi Zoltan

Hi,

2012-06-27 09:35 keltez?ssel, Dave Airlie ?rta:
> From: Dave Airlie 
>
> We need these for detecting the max link speed for drm drivers.
>
> Signed-off-by: Dave Airlie 

I have reported this in March:
http://lists.freedesktop.org/archives/dri-devel/2012-March/019731.html

Since then, this motherboard received 3 BIOS upgrades (latest is
version 1208) and the system was upgraded to Fedora 17.

With kernel 3.5-rc4+ (commit 47b514cd476db2eca066a2ad31501b079d6c9cce)
plus this series of patches, the reported problem doesn't appear anymore.

lspci reports PCIe gen2 speed for my Radeon HD6570 and
gen1 speed for my 3ware 9650SE:

[zozo at localhost ~]$ sudo lspci -vvv -s 01:00.0
01:00.0 VGA compatible controller: ATI Technologies Inc NI Turks [AMD Radeon HD 
6500] 
(prog-if 00 [VGA controller])
 Subsystem: PC Partner Limited Device e193
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- 
FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
 Capabilities: [150 v1] Advanced Error Reporting
 UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- 
MalfTLP- ECRC- 
UnsupReq- ACSViol-
 UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- 
MalfTLP- ECRC- 
UnsupReq- ACSViol-
 UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ 
MalfTLP+ 
ECRC- UnsupReq- ACSViol-
 CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
 CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
 AERCap:First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
 Kernel driver in use: radeon

[zozo at localhost ~]$ sudo lspci -vvv -s 08:00.0
08:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01)
 Subsystem: 3ware Inc 9650SE SATA-II RAID PCIe
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- 
FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

> ---
>   include/linux/pci_regs.h |5 +
>   1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
> index 4b608f5..7f04132 100644
> --- a/include/linux/pci_regs.h
> +++ b/include/linux/pci_regs.h
> @@ -521,6 +521,11 @@
>   #define  PCI_EXP_OBFF_MSGA_EN   0x2000  /* OBFF enable with Message 
> type A */
>   #define  PCI_EXP_OBFF_MSGB_EN   0x4000  /* OBFF enable with Message 
> type B */
>   #define  PCI_EXP_OBFF_WAKE_EN   0x6000  /* OBFF using WAKE# signaling */
> +#define PCI_EXP_LNKCAP2  44  /* Link Capability 2 */
> +#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x01  /* Current Link Speed 2.5GT/s */
> +#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x02  /* Current Link Speed 5.0GT/s */
> +#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x04  /* Current Link Speed 8.0GT/s */
> +#define  PCI_EXP_LNKCAP2_CROSSLINK 0x100 /* Crosslink supported */
>   #define PCI_EXP_LNKCTL2 48  /* Link Control 2 */
>   #define PCI_EXP_SLTCTL2 56  /* Slot Control 2 */
>

Re: [PATCH 1/3] pci_regs: define LNKSTA2 pcie cap + bits.

2012-06-29 Thread Boszormenyi Zoltan


Hi,

2012-06-27 09:35 keltezéssel, Dave Airlie írta:

From: Dave Airlie airl...@redhat.com

We need these for detecting the max link speed for drm drivers.

Signed-off-by: Dave Airlie airl...@redhat.com


I have reported this in March:
http://lists.freedesktop.org/archives/dri-devel/2012-March/019731.html

Since then, this motherboard received 3 BIOS upgrades (latest is
version 1208) and the system was upgraded to Fedora 17.

With kernel 3.5-rc4+ (commit 47b514cd476db2eca066a2ad31501b079d6c9cce)
plus this series of patches, the reported problem doesn't appear anymore.

lspci reports PCIe gen2 speed for my Radeon HD6570 and
gen1 speed for my 3ware 9650SE:

[zozo@localhost ~]$ sudo lspci -vvv -s 01:00.0
01:00.0 VGA compatible controller: ATI Technologies Inc NI Turks [AMD Radeon HD 6500] 
(prog-if 00 [VGA controller])

Subsystem: PC Partner Limited Device e193
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- 
FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- 
SERR- PERR- INTx-

Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 88
Region 0: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at fea2 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at e000 [size=256]
Expansion ROM at fea0 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s 4us, L1 
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap:Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 64ns, 
L1 1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta:Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- 
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable 
De-emphasis: -6dB

 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- 
ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, 
EqualizationPhase1-

 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: feeff00c  Data: 419a
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 
?
Capabilities: [150 v1] Advanced Error Reporting
UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- 
UnsupReq- ACSViol-
UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- 
UnsupReq- ACSViol-
UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ 
ECRC- UnsupReq- ACSViol-

CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap:First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Kernel driver in use: radeon

[zozo@localhost ~]$ sudo lspci -vvv -s 08:00.0
08:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01)
Subsystem: 3ware Inc 9650SE SATA-II RAID PCIe
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- 
FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- 
SERR- PERR- INTx-

Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d000 (64-bit, prefetchable) [size=32M]
Region 2: Memory at fe42 (64-bit, non-prefetchable) [size=4K]
Region 4: I/O ports at 9000 [size=256]
Expansion ROM at fe40 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
Address:   Data: 
Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00
DevCap:MaxPayload 512 bytes, PhantFunc 0, Latency L0s 128ns, L1 
2us
ExtTag- AttnBtn- AttnInd- PwrInd-

[PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

2012-06-11 Thread Boszormenyi Zoltan

Yay, it works on HD6570 (TURKS)! Thanks!

2012-06-11 14:11 keltez?ssel, Christian K?nig ?rta:
> On 11.06.2012 12:34, Rafa? Mi?ecki wrote:
>> After recent changes HDMI code is ready to be enabled on DCE5. This
>> patch just changes conditions to execute already present code on DCE5.
>>
>> Signed-off-by: Rafa? Mi?ecki
>> Reviewed-by: Alex Deucher
> Tested-by: Christian K?nig 

Tested-by: Zolt?n B?sz?rm?nyi 

>
>> ---
>> V2: enable audio engine on Cayman (it uses different startup function).
>> ---
>>   drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
>>   drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
>>   drivers/gpu/drm/radeon/ni.c|5 +
>>   drivers/gpu/drm/radeon/r600_audio.c|2 +-
>>   drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
>>   5 files changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index e7b1ec5..486ccdf 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
>> *encoder,
>>
>>   if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
>>   r600_hdmi_enable(encoder);
>> -if (ASIC_IS_DCE4(rdev))
>> +if (ASIC_IS_DCE6(rdev))
>> +; /* TODO (use pointers instead of if-s?) */
>> +else if (ASIC_IS_DCE4(rdev))
>>   evergreen_hdmi_setmode(encoder, adjusted_mode);
>>   else
>>   r600_hdmi_setmode(encoder, adjusted_mode);
>> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
>> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
>> index a51f880..65c5416 100644
>> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
>> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
>> @@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
>> struct 
>> drm_display_mode
>>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>   uint32_t offset;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> -return;
>> -
>>   /* Silent, r600_hdmi_enable will raise WARN for us */
>>   if (!dig->afmt->enabled)
>>   return;
>> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
>> index 3df4efa..b65fcae 100644
>> --- a/drivers/gpu/drm/radeon/ni.c
>> +++ b/drivers/gpu/drm/radeon/ni.c
>> @@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
>>   if (r)
>>   return r;
>>
>> +r = r600_audio_init(rdev);
>> +if (r)
>> +return r;
>> +
>>   return 0;
>>   }
>>
>> @@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)
>>
>>   int cayman_suspend(struct radeon_device *rdev)
>>   {
>> +r600_audio_fini(rdev);
>>   /* FIXME: we should wait for ring to be empty */
>>   radeon_ib_pool_suspend(rdev);
>>   radeon_vm_manager_suspend(rdev);
>> diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
>> b/drivers/gpu/drm/radeon/r600_audio.c
>> index 7479a5c..79b5591 100644
>> --- a/drivers/gpu/drm/radeon/r600_audio.c
>> +++ b/drivers/gpu/drm/radeon/r600_audio.c
>> @@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
>>*/
>>   static int r600_audio_chipset_supported(struct radeon_device *rdev)
>>   {
>> -return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE5(rdev))
>> +return (rdev->family>= CHIP_R600&&  !ASIC_IS_DCE6(rdev))
>>   || rdev->family == CHIP_RS600
>>   || rdev->family == CHIP_RS690
>>   || rdev->family == CHIP_RS740;
>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
>> b/drivers/gpu/drm/radeon/r600_hdmi.c
>> index 969c275..82a0a4c 100644
>> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
>> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
>> @@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, 
>> struct 
>> drm_display_mode *mod
>>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>   uint32_t offset;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> -return;
>> -
>>   /* Silent, r600_hdmi_enable will raise WARN for us */
>>   if (!dig->afmt->enabled)
>>   return;
>> @@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
>>   uint32_t offset;
>>   u32 hdmi;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> +if (ASIC_IS_DCE6(rdev))
>>   return;
>>
>>   /* Silent, r600_hdmi_enable will raise WARN for us */
>> @@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
>>   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>   uint32_t offset;
>>
>> -if (ASIC_IS_DCE5(rdev))
>> +if (ASIC_IS_DCE6(rdev))
>>   return;
>>
>>   /* Called for ATOM_ENCODER_MODE_HDMI only */
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2][drm-fixes?] drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)

2012-06-11 Thread Boszormenyi Zoltan


Yay, it works on HD6570 (TURKS)! Thanks!

2012-06-11 14:11 keltezéssel, Christian König írta:

On 11.06.2012 12:34, Rafał Miłecki wrote:

After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.

Signed-off-by: Rafał Miłeckizaj...@gmail.com
Reviewed-by: Alex Deucheralexander.deuc...@amd.com

Tested-by: Christian König christian.koe...@amd.com


Tested-by: Zoltán Böszörményi zbos...@pr.hu




---
V2: enable audio engine on Cayman (it uses different startup function).
---
  drivers/gpu/drm/radeon/atombios_encoders.c |4 +++-
  drivers/gpu/drm/radeon/evergreen_hdmi.c|3 ---
  drivers/gpu/drm/radeon/ni.c|5 +
  drivers/gpu/drm/radeon/r600_audio.c|2 +-
  drivers/gpu/drm/radeon/r600_hdmi.c |7 ++-
  5 files changed, 11 insertions(+), 10 deletions(-)

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

index e7b1ec5..486ccdf 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1926,7 +1926,9 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,

  if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
  r600_hdmi_enable(encoder);
-if (ASIC_IS_DCE4(rdev))
+if (ASIC_IS_DCE6(rdev))
+; /* TODO (use pointers instead of if-s?) */
+else if (ASIC_IS_DCE4(rdev))
  evergreen_hdmi_setmode(encoder, adjusted_mode);
  else
  r600_hdmi_setmode(encoder, adjusted_mode);
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c

index a51f880..65c5416 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -156,9 +156,6 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode

  struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
  uint32_t offset;

-if (ASIC_IS_DCE5(rdev))
-return;
-
  /* Silent, r600_hdmi_enable will raise WARN for us */
  if (!dig-afmt-enabled)
  return;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3df4efa..b65fcae 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1290,6 +1290,10 @@ static int cayman_startup(struct radeon_device *rdev)
  if (r)
  return r;

+r = r600_audio_init(rdev);
+if (r)
+return r;
+
  return 0;
  }

@@ -1316,6 +1320,7 @@ int cayman_resume(struct radeon_device *rdev)

  int cayman_suspend(struct radeon_device *rdev)
  {
+r600_audio_fini(rdev);
  /* FIXME: we should wait for ring to be empty */
  radeon_ib_pool_suspend(rdev);
  radeon_vm_manager_suspend(rdev);
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 7479a5c..79b5591 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -57,7 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
   */
  static int r600_audio_chipset_supported(struct radeon_device *rdev)
  {
-return (rdev-family= CHIP_R600  !ASIC_IS_DCE5(rdev))
+return (rdev-family= CHIP_R600  !ASIC_IS_DCE6(rdev))
  || rdev-family == CHIP_RS600
  || rdev-family == CHIP_RS690
  || rdev-family == CHIP_RS740;
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 969c275..82a0a4c 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -322,9 +322,6 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod

  struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
  uint32_t offset;

-if (ASIC_IS_DCE5(rdev))
-return;
-
  /* Silent, r600_hdmi_enable will raise WARN for us */
  if (!dig-afmt-enabled)
  return;
@@ -483,7 +480,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
  uint32_t offset;
  u32 hdmi;

-if (ASIC_IS_DCE5(rdev))
+if (ASIC_IS_DCE6(rdev))
  return;

  /* Silent, r600_hdmi_enable will raise WARN for us */
@@ -543,7 +540,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
  struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
  uint32_t offset;

-if (ASIC_IS_DCE5(rdev))
+if (ASIC_IS_DCE6(rdev))
  return;

  /* Called for ATOM_ENCODER_MODE_HDMI only */


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


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

[PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

2012-06-09 Thread Boszormenyi Zoltan

2012-06-09 16:57 keltez?ssel, j.glisse at gmail.com ?rta:
> From: Jerome Glisse
>
> Fix regresson since the introduction of command stream checking on
> evergreen (thread referenced below). Issue is cause by ddx allocating
> bo with formula width*height*bpp while programming the GPU command
> stream with ALIGN(height, 8). In some case (where page alignment does
> not hide the extra size bo should be according to height alignment)
> the kernel will reject the command stream.
>
> This patch reprogram the command stream to slice - 1 (slice is
> a derivative value from height) which avoid rejecting the command
> stream while keeping the value of command stream checking from a
> security point of view.
>
> This patch also fix wrong computation of layer size for 2D tiled
> surface. Which should fix issue when 2D color tiling is enabled.
> This dump the radeon KMS_DRIVER_MINOR so userspace can know if
> they are on a fixed kernel or not.
>
> https://lkml.org/lkml/2012/6/3/80
> https://bugs.freedesktop.org/show_bug.cgi?id=50892
> https://bugs.freedesktop.org/show_bug.cgi?id=50857
>
> !!! STABLE need a custom version of this patch for 3.4 !!!
>
> v2: actually bump the minor version and add comment about stable
> v3: do compute the height the ddx was trying to use
>
> Signed-off-by: Jerome Glisse
> ---
>   drivers/gpu/drm/radeon/evergreen_cs.c |   50 
> ++---
>   drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
>   2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 4e7dd2b..29c43c6 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -52,6 +52,7 @@ struct evergreen_cs_track {
>   u32 cb_color_view[12];
>   u32 cb_color_pitch[12];
>   u32 cb_color_slice[12];
> + u32 cb_color_slice_idx[12];
>   u32 cb_color_attrib[12];
>   u32 cb_color_cmask_slice[8];/* unused */
>   u32 cb_color_fmask_slice[8];/* unused */
> @@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct 
> evergreen_cs_track *track)
>   track->cb_color_info[i] = 0;
>   track->cb_color_view[i] = 0x;
>   track->cb_color_pitch[i] = 0;
> - track->cb_color_slice[i] = 0;
> + track->cb_color_slice[i] = 0xfff;
> + track->cb_color_slice_idx[i] = 0;
>   }
>   track->cb_target_mask = 0x;
>   track->cb_shader_mask = 0x;
>   track->cb_dirty = true;
>
> + track->db_depth_slice = 0x;
>   track->db_depth_view = 0xC000;
>   track->db_depth_size = 0x;
>   track->db_depth_control = 0x;
> @@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct 
> radeon_cs_parser *p,
>   {
>   struct evergreen_cs_track *track = p->track;
>   unsigned palign, halign, tileb, slice_pt;
> + unsigned mtile_pr, mtile_ps, mtileb;
>
>   tileb = 64 * surf->bpe * surf->nsamples;
> - palign = track->group_size / (8 * surf->bpe * surf->nsamples);
> - palign = MAX(8, palign);
>   slice_pt = 1;
>   if (tileb>  surf->tsplit) {
>   slice_pt = tileb / surf->tsplit;
> @@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct 
> radeon_cs_parser *p,
>   /* macro tile width&  height */
>   palign = (8 * surf->bankw * track->npipes) * surf->mtilea;
>   halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea;
> - surf->layer_size = surf->nbx * surf->nby * surf->bpe * slice_pt;
> + mtileb = (palign / 8) * (halign / 8) * tileb;;
> + mtile_pr = surf->nbx / palign;
> + mtile_ps = (mtile_pr * surf->nby) / halign;
> + surf->layer_size = mtile_ps * mtileb * slice_pt;
>   surf->base_align = (palign / 8) * (halign / 8) * tileb;
>   surf->palign = palign;
>   surf->halign = halign;
> @@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct 
> radeon_cs_parser *p, unsigned i
>
>   offset += surf.layer_size * mslice;
>   if (offset>  radeon_bo_size(track->cb_color_bo[id])) {
> + /* old ddx are broken they allocate bo with w*h*bpp but
> +  * program slice with ALIGN(h, 8), catch this and patch
> +  * command stream.
> +  */
> + if (!surf.mode) {
> + volatile u32 *ib = p->ib.ptr;
> + unsigned long tmp, nby, bsize, size, min = 0;
> +
> + /* find the height the ddx wants */
> + if (surf.nby>  8) {
> + min = surf.nby - 8;
> + }
> + bsize = radeon_bo_size(track->cb_color_bo[id]);
> + tmp = track->cb_color_bo_offset[id]<<  8;
> + for (nby = surf.nby;

Re: [PATCH] drm/radeon: fix tiling and command stream checking on evergreen v3

2012-06-09 Thread Boszormenyi Zoltan


2012-06-09 16:57 keltezéssel, j.gli...@gmail.com írta:

From: Jerome Glissejgli...@redhat.com

Fix regresson since the introduction of command stream checking on
evergreen (thread referenced below). Issue is cause by ddx allocating
bo with formula width*height*bpp while programming the GPU command
stream with ALIGN(height, 8). In some case (where page alignment does
not hide the extra size bo should be according to height alignment)
the kernel will reject the command stream.

This patch reprogram the command stream to slice - 1 (slice is
a derivative value from height) which avoid rejecting the command
stream while keeping the value of command stream checking from a
security point of view.

This patch also fix wrong computation of layer size for 2D tiled
surface. Which should fix issue when 2D color tiling is enabled.
This dump the radeon KMS_DRIVER_MINOR so userspace can know if
they are on a fixed kernel or not.

https://lkml.org/lkml/2012/6/3/80
https://bugs.freedesktop.org/show_bug.cgi?id=50892
https://bugs.freedesktop.org/show_bug.cgi?id=50857

!!! STABLE need a custom version of this patch for 3.4 !!!

v2: actually bump the minor version and add comment about stable
v3: do compute the height the ddx was trying to use

Signed-off-by: Jerome Glissejgli...@redhat.com
---
  drivers/gpu/drm/radeon/evergreen_cs.c |   50 ++---
  drivers/gpu/drm/radeon/radeon_drv.c   |3 +-
  2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 4e7dd2b..29c43c6 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -52,6 +52,7 @@ struct evergreen_cs_track {
u32 cb_color_view[12];
u32 cb_color_pitch[12];
u32 cb_color_slice[12];
+   u32 cb_color_slice_idx[12];
u32 cb_color_attrib[12];
u32 cb_color_cmask_slice[8];/* unused */
u32 cb_color_fmask_slice[8];/* unused */
@@ -127,12 +128,14 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track-cb_color_info[i] = 0;
track-cb_color_view[i] = 0x;
track-cb_color_pitch[i] = 0;
-   track-cb_color_slice[i] = 0;
+   track-cb_color_slice[i] = 0xfff;
+   track-cb_color_slice_idx[i] = 0;
}
track-cb_target_mask = 0x;
track-cb_shader_mask = 0x;
track-cb_dirty = true;

+   track-db_depth_slice = 0x;
track-db_depth_view = 0xC000;
track-db_depth_size = 0x;
track-db_depth_control = 0x;
@@ -250,10 +253,9 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
  {
struct evergreen_cs_track *track = p-track;
unsigned palign, halign, tileb, slice_pt;
+   unsigned mtile_pr, mtile_ps, mtileb;

tileb = 64 * surf-bpe * surf-nsamples;
-   palign = track-group_size / (8 * surf-bpe * surf-nsamples);
-   palign = MAX(8, palign);
slice_pt = 1;
if (tileb  surf-tsplit) {
slice_pt = tileb / surf-tsplit;
@@ -262,7 +264,10 @@ static int evergreen_surface_check_2d(struct 
radeon_cs_parser *p,
/* macro tile width  height */
palign = (8 * surf-bankw * track-npipes) * surf-mtilea;
halign = (8 * surf-bankh * surf-nbanks) / surf-mtilea;
-   surf-layer_size = surf-nbx * surf-nby * surf-bpe * slice_pt;
+   mtileb = (palign / 8) * (halign / 8) * tileb;;
+   mtile_pr = surf-nbx / palign;
+   mtile_ps = (mtile_pr * surf-nby) / halign;
+   surf-layer_size = mtile_ps * mtileb * slice_pt;
surf-base_align = (palign / 8) * (halign / 8) * tileb;
surf-palign = palign;
surf-halign = halign;
@@ -434,6 +439,39 @@ static int evergreen_cs_track_validate_cb(struct 
radeon_cs_parser *p, unsigned i

offset += surf.layer_size * mslice;
if (offset  radeon_bo_size(track-cb_color_bo[id])) {
+   /* old ddx are broken they allocate bo with w*h*bpp but
+* program slice with ALIGN(h, 8), catch this and patch
+* command stream.
+*/
+   if (!surf.mode) {
+   volatile u32 *ib = p-ib.ptr;
+   unsigned long tmp, nby, bsize, size, min = 0;
+
+   /* find the height the ddx wants */
+   if (surf.nby  8) {
+   min = surf.nby - 8;
+   }
+   bsize = radeon_bo_size(track-cb_color_bo[id]);
+   tmp = track-cb_color_bo_offset[id]  8;
+   for (nby = surf.nby; nby  min; nby--) {
+   size = nby * surf.nbx * surf.bpe * 
surf.nsamples;
+

DVI/VGA/HDI mess on Radeon HD 6570

2012-04-30 Thread Boszormenyi Zoltan

2011-12-19 19:31 keltez?ssel, Adam Jackson ?rta:
> On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:
>
>> Thanks. As I am logged in as my user, there's no such button.
>> How can I set it as the system default? It was a long time ago
>> when GNOME allowed a root login.
> Ideally, gnome would implement that button.
>
> Failing that you can set Option "Primary" for the appropriate monitor
> section in xorg.conf.
>
> - ajax

I have found a way to match GDM's behaviour to what I have
set in my session. This is embarrassingly simple. After setting
up the monitors in the GNOME display applet:

sudo cp ~/.config/monitors.xml /var/lib/gdm/.config/

Next time GDM restarted, it behaved the way I set up.

Best regards,
Zolt?n B?sz?rm?nyi

Re: DVI/VGA/HDI mess on Radeon HD 6570

2012-04-30 Thread Boszormenyi Zoltan


2011-12-19 19:31 keltezéssel, Adam Jackson írta:

On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:


Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.

Ideally, gnome would implement that button.

Failing that you can set Option Primary for the appropriate monitor
section in xorg.conf.

- ajax


I have found a way to match GDM's behaviour to what I have
set in my session. This is embarrassingly simple. After setting
up the monitors in the GNOME display applet:

sudo cp ~/.config/monitors.xml /var/lib/gdm/.config/

Next time GDM restarted, it behaved the way I set up.

Best regards,
Zoltán Böszörményi

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

radeon.pcie_gen2=1 unusable with AMD 990X chipset

2012-03-05 Thread Boszormenyi Zoltan

Hi,

last week I bought a new ASUS M5A99X EVO AM3+ mainboard.
It supports PCIe 2.0. I also have a Radeon 6570 videocard (PCIe 2.0)
and a 3ware 9650SE 8LPML RAID card (PCIe 1.0).

There are 3 PCIe x16 slots on the mainboard, two of them share x16
wiring so single card x16 or dual card x8/x8 is possible. The 3rd slot
is PCIe x16 slot with dedicated x4 wiring, no sharing with the first 2 slots.
The RAID card is sitting in the 3rd slot.

I am running Fedora 16 with the latest 3.2.7-1.fc16.x86_64 kernel.

I have set radeon.pcie_gen2=1 in grub2 config to test PCIe 2.0 speed with
the videocard. It reliably locks up on boot. As a result, the mainboard
gets confused so much that it needs CMOS clear, otherwise even after
hard reset it cannot boot up successfully. I tried it a couple of times,
the symptoms (without CMOS clear) are mysteriously different. From the
few attempts, I experienced these:

- the mainboard reports faulty videocard, no image on display
- the mainboard passes the videocard test but reports faulty boot drive
  (I guess it cannot initialize the RAID card as it's the primary boot drive)
  and still no image on display
- the first few screens appear on the display but e.g. the onboard SATA
  controller cannot find the DVD drive and the BIOS initialization sequence
  stops somewhere, it doesn't reach the GRUB menu

The motherboard has an AMD 990X chipset.

Without radeon.pcie_gen2=1, the system works and is stable.

I don't know what to blame. The chipset, BIOS bugs, or the mix of
PCIe 1.0 and 2.0 devices. Anyway, I thought it would be an interesting
detail for Radeon developers.

Best regards,
Zolt?n B?sz?rm?nyi

radeon.pcie_gen2=1 unusable with AMD 990X chipset

2012-03-05 Thread Boszormenyi Zoltan

Hi,

last week I bought a new ASUS M5A99X EVO AM3+ mainboard.
It supports PCIe 2.0. I also have a Radeon 6570 videocard (PCIe 2.0)
and a 3ware 9650SE 8LPML RAID card (PCIe 1.0).

There are 3 PCIe x16 slots on the mainboard, two of them share x16
wiring so single card x16 or dual card x8/x8 is possible. The 3rd slot
is PCIe x16 slot with dedicated x4 wiring, no sharing with the first 2 slots.
The RAID card is sitting in the 3rd slot.

I am running Fedora 16 with the latest 3.2.7-1.fc16.x86_64 kernel.

I have set radeon.pcie_gen2=1 in grub2 config to test PCIe 2.0 speed with
the videocard. It reliably locks up on boot. As a result, the mainboard
gets confused so much that it needs CMOS clear, otherwise even after
hard reset it cannot boot up successfully. I tried it a couple of times,
the symptoms (without CMOS clear) are mysteriously different. From the
few attempts, I experienced these:

- the mainboard reports faulty videocard, no image on display
- the mainboard passes the videocard test but reports faulty boot drive
  (I guess it cannot initialize the RAID card as it's the primary boot drive)
  and still no image on display
- the first few screens appear on the display but e.g. the onboard SATA
  controller cannot find the DVD drive and the BIOS initialization sequence
  stops somewhere, it doesn't reach the GRUB menu

The motherboard has an AMD 990X chipset.

Without radeon.pcie_gen2=1, the system works and is stable.

I don't know what to blame. The chipset, BIOS bugs, or the mix of
PCIe 1.0 and 2.0 devices. Anyway, I thought it would be an interesting
detail for Radeon developers.

Best regards,
Zoltán Böszörményi

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

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:42 keltez?ssel, Adam Jackson ?rta:
> On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:
>
>> Thanks.
>> Is this setting permanent after reboot and applies to GDM, too?
> It's stored in the session, so if there's not a "Make system default"
> button in the UI, then no it won't affect gdm.

Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:14 keltez?ssel, David Airlie ?rta:
>> about two months ago I bought a Radeon HD 6570 with
>> 2GB memory for my main computer and I have a single
>> monitor connected to it, until now via VGA D-Sub.
>>
>> Last week our secondary TV died (it was 15 years old, R.I.P.)
>> so I bought a nice 32" LED TV which has 3 external HDMI
>> connectors.
>>
>> The HD 6570 has one DVI-D, one HDMI and one VGA connectors
>> so I thought it would be fun to allow the family to watch videos
>> while I can also work on the computer.
>>
>> Here comes my problem: no matter which connectors I use
>> for the monitor (DVI-D or D-Sub), if the TV is switched on,
>> HDMI comes up as primary display. The result: GNOME 3
>> workspaces are switchable on the TV but a single workspace
>> is visible on my monitor. This would be the perfect setup
>> if I can reverse the roles of the TV and the monitor.
>>
>> "man radeon" had an option which I tried but didn't help:
>> Option "ZaphodHeads" "DVI-0,HDMI-0"
> xrandr --output DVI-0 --primary
>
> or open the gnome display applet and drag the bar from one monitor to another.

Thanks.
Is this setting permanent after reboot and applies to GDM, too?

>
> Dave.
>

DVI/VGA/HDI mess on Radeon HD 6570

Hi,

about two months ago I bought a Radeon HD 6570 with
2GB memory for my main computer and I have a single
monitor connected to it, until now via VGA D-Sub.

Last week our secondary TV died (it was 15 years old, R.I.P.)
so I bought a nice 32" LED TV which has 3 external HDMI
connectors.

The HD 6570 has one DVI-D, one HDMI and one VGA connectors
so I thought it would be fun to allow the family to watch videos
while I can also work on the computer.

Here comes my problem: no matter which connectors I use
for the monitor (DVI-D or D-Sub), if the TV is switched on,
HDMI comes up as primary display. The result: GNOME 3
workspaces are switchable on the TV but a single workspace
is visible on my monitor. This would be the perfect setup
if I can reverse the roles of the TV and the monitor.

"man radeon" had an option which I tried but didn't help:
Option "ZaphodHeads" "DVI-0,HDMI-0"

Is there any other option that does what I want?

Thanks in advance,
Zolt?n B?sz?rm?nyi

DVI/VGA/HDI mess on Radeon HD 6570

Hi,

about two months ago I bought a Radeon HD 6570 with
2GB memory for my main computer and I have a single
monitor connected to it, until now via VGA D-Sub.

Last week our secondary TV died (it was 15 years old, R.I.P.)
so I bought a nice 32 LED TV which has 3 external HDMI
connectors.

The HD 6570 has one DVI-D, one HDMI and one VGA connectors
so I thought it would be fun to allow the family to watch videos
while I can also work on the computer.

Here comes my problem: no matter which connectors I use
for the monitor (DVI-D or D-Sub), if the TV is switched on,
HDMI comes up as primary display. The result: GNOME 3
workspaces are switchable on the TV but a single workspace
is visible on my monitor. This would be the perfect setup
if I can reverse the roles of the TV and the monitor.

man radeon had an option which I tried but didn't help:
Option ZaphodHeads DVI-0,HDMI-0

Is there any other option that does what I want?

Thanks in advance,
Zoltán Böszörményi

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

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:14 keltezéssel, David Airlie írta:
 about two months ago I bought a Radeon HD 6570 with
 2GB memory for my main computer and I have a single
 monitor connected to it, until now via VGA D-Sub.

 Last week our secondary TV died (it was 15 years old, R.I.P.)
 so I bought a nice 32 LED TV which has 3 external HDMI
 connectors.

 The HD 6570 has one DVI-D, one HDMI and one VGA connectors
 so I thought it would be fun to allow the family to watch videos
 while I can also work on the computer.

 Here comes my problem: no matter which connectors I use
 for the monitor (DVI-D or D-Sub), if the TV is switched on,
 HDMI comes up as primary display. The result: GNOME 3
 workspaces are switchable on the TV but a single workspace
 is visible on my monitor. This would be the perfect setup
 if I can reverse the roles of the TV and the monitor.

 man radeon had an option which I tried but didn't help:
 Option ZaphodHeads DVI-0,HDMI-0
 xrandr --output DVI-0 --primary

 or open the gnome display applet and drag the bar from one monitor to another.

Thanks.
Is this setting permanent after reboot and applies to GDM, too?


 Dave.


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

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:42 keltezéssel, Adam Jackson írta:
 On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:

 Thanks.
 Is this setting permanent after reboot and applies to GDM, too?
 It's stored in the session, so if there's not a Make system default
 button in the UI, then no it won't affect gdm.

Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.

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

Black screen with AMD A4-3300 support

2011-12-14 15:02 keltez?ssel, Alex Deucher ?rta:
> 2011/12/14 Boszormenyi Zoltan :
>> 2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta:
>>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
>>>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
>>>> and an extra Radeon HD6550M. I installed Fedora 16 on it but
>>>> I get only black screen even during installation unless booted
>>>> with nomodeset. But it's only VESA so there's no acceleration
>>>> and there's no native LCD 1366x768 resolution, only 1024x768,
>>>> so it's a bit blurry.
>>>>
>>> Hello,
>>>
>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 .  (The HP 
>>> G4-1215DX also
>>> has a AMD A4-3300.)  After making the f16 kernel work, I ended up 
>>> installing a
>>> f17/rawhide kernel from 
>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to
>>> fix other bugs, which will probably be the easiest solution for you.
>> YES! Thankyouthankyouthankyou! :-) Now I have KMS.
>>
>>>   I would be interested to hear if, after installing a newer kernel, 
>>> suspend/resume
>>> worked for you.
>> No, that doesn't work. I mean suspend works but not resume.
>> There are a lot of reports in dmesg that looks like an Oops.
>> Where should I report it? Here on the list or in RHBZ?
> Please file a bug:
> https://bugs.freedesktop.org
> and select DRI, then DRM/Radeon.
>
> Alex

Done, bug #43829

Best regards,
Zolt?n B?sz?rm?nyi

Black screen with AMD A4-3300 support

2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta:
> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU
>> and an extra Radeon HD6550M. I installed Fedora 16 on it but
>> I get only black screen even during installation unless booted
>> with nomodeset. But it's only VESA so there's no acceleration
>> and there's no native LCD 1366x768 resolution, only 1024x768,
>> so it's a bit blurry.
>>
>
> Hello,
>
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 .  (The HP 
> G4-1215DX also
> has a AMD A4-3300.)  After making the f16 kernel work, I ended up installing a
> f17/rawhide kernel from 
> http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to
> fix other bugs, which will probably be the easiest solution for you.

YES! Thankyouthankyouthankyou! :-) Now I have KMS.

>   I would be interested to hear if, after installing a newer kernel, 
> suspend/resume
> worked for you.

No, that doesn't work. I mean suspend works but not resume.
There are a lot of reports in dmesg that looks like an Oops.
Where should I report it? Here on the list or in RHBZ?

Best regards,
Zolt?n B?sz?rm?nyi

Re: Black screen with AMD A4-3300 support

2011-12-13 14:03 keltezéssel, Joshua Roys írta:
 On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote:
 I have a new ASUS K53TA notebook with AMD A4-3300 CPU
 and an extra Radeon HD6550M. I installed Fedora 16 on it but
 I get only black screen even during installation unless booted
 with nomodeset. But it's only VESA so there's no acceleration
 and there's no native LCD 1366x768 resolution, only 1024x768,
 so it's a bit blurry.


 Hello,

 Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 .  (The HP 
 G4-1215DX also
 has a AMD A4-3300.)  After making the f16 kernel work, I ended up installing a
 f17/rawhide kernel from 
 http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to
 fix other bugs, which will probably be the easiest solution for you.

YES! Thankyouthankyouthankyou! :-) Now I have KMS.

   I would be interested to hear if, after installing a newer kernel, 
 suspend/resume
 worked for you.

No, that doesn't work. I mean suspend works but not resume.
There are a lot of reports in dmesg that looks like an Oops.
Where should I report it? Here on the list or in RHBZ?

Best regards,
Zoltán Böszörményi

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

Re: Black screen with AMD A4-3300 support