Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues
2013/7/29 Alex Deucher : > On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf > wrote: >> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote: >>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf >>> wrote: >>> > On my test machine Xorg doesn't start anymore when I kexec into a >>> > 3.11.0-rc3 kernel. >>> >>> With kexec, dpm doesn't get torn down properly which can result in a >>> bad hardware state when the driver loads again. Does the attached >>> patch help? It attempts to disable dpm at startup in case it wasn't >>> torn down properly previously. >> >> dpm initialization now works, but unfortunately GPU acceleration still gets >> disabled: > > Stupid kexec complicates things. We need to make sure dpm is torn > down before we init the rest of the GPU, but dpm needs get initialized > later in the init process since it depends on certain other state from > the driver. I need to think about this for a bit. I'm not sure of a > good way to handle this. > > Alex > >> >> [drm] Initialized drm 1.1.0 20060810 >> >> [135/1104] >> [drm] radeon kernel modesetting enabled. >> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D). >> [drm] register mmio base: 0xFBEE >> [drm] register mmio size: 65536 >> ATOM BIOS: 113 >> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF >> (128M used) >> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF >> [drm] Detected VRAM RAM=128M, BAR=128M >> [drm] RAM width 32bits DDR >> [TTM] Zone kernel: Available graphics memory: 4082356 kiB >> [TTM] Zone dma32: Available graphics memory: 2097152 kiB >> [TTM] Initializing pool allocator >> [TTM] Initializing DMA pool allocator >> [drm] radeon: 128M of VRAM memory ready >> [drm] radeon: 512M of GTT memory ready. >> [drm] GART: num cpu pages 131072, num gpu pages 131072 >> [drm] Loading RS780 Microcode >> [drm] PCIE GART of 512M enabled (table at 0xC004). >> radeon :01:05.0: WB enabled >> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 >> and cpu addr 0x880215c30c00 >> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c >> and cpu addr 0x880215c30c0c >> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). >> [drm] Driver supports precise vblank timestamp query. >> [drm] radeon: irq initialized. >> radeon :01:05.0: setting latency timer to 64 >> [drm] ring test on 0 succeeded in 1 usecs >> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) >> radeon :01:05.0: disabling GPU acceleration >> radeon :01:05.0: 8802161cfc00 unpin not necessary >> [drm] Radeon Display Connectors >> [drm] Connector 0: >> [drm] VGA-1 >> [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c >> [drm] Encoders: >> [drm] CRT1: INTERNAL_KLDSCP_DAC1 >> [drm] Connector 1: >> [drm] DVI-D-1 >> [drm] HPD3 >> [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c >> [drm] Encoders: >> [drm] DFP3: INTERNAL_KLDSCP_LVTMA >> == power state 0 == >> ui class: none >> internal class: boot >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 2 >> power level 1sclk: 5 vddc_index: 2 >> status: c r b >> == power state 1 == >> ui class: performance >> internal class: none >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 1 >> power level 1sclk: 7 vddc_index: 2 >> status: >> == power state 2 == >> ui class: none >> internal class: uvd >> caps: video >> uvdvclk: 53300 dclk: 4 >> power level 0sclk: 5 vddc_index: 1 >> power level 1sclk: 5 vddc_index: 1 >> status: >> switching from power state: >> ui class: none >> internal class: boot >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 2 >> power level 1sclk: 5 vddc_index: 2 >> status: c b >> switching to power state: >> ui class: performance >> internal class: none >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 1 >> power level 1sclk: 7 vddc_index: 2 >> status: r >> [drm] radeon: dpm initialized >> [drm] fb mappable at 0xF0142000 >> [drm] vram apper at 0xF000 >> [drm] size 7299072 >> [drm] fb depth is 24 >> [drm]pitch is 6912 >> fbcon: radeondrmfb (fb0) >> >> -- >> Markus > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/li
Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues
2013/7/30 Markus Trippelsdorf : > > I begin to wonder if: > [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) > is an simple initialization bug that doesn't directly depend on kexec at > all. > > -- > Markus I bet on this (because I see the same error in another context) -- --joshua ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RADEON / DPM: GPU cannot properly up-clock
First of all thank you guys for pushing this out! Great work!
I tried the latest code in drm-next-3.11-wip (up to commit
b3c1e0c3ba885db44 “drm/radeon: fix endian issues in atombios dpm
code”) in connection with the latest radeon_ucode (latest update on
2013-06-26). I also reintroduced the debugfs info so that I can better
observe the gpu-settings. For this I put back the following patch:
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 7ba5d6f..9367234 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev)
ret = device_create_file(rdev->dev, &dev_attr_power_method);
if (ret)
DRM_ERROR("failed to create device file for power method\n");
+
+if (radeon_debugfs_pm_init(rdev)) {
+DRM_ERROR("Failed to register debugfs file for PM!\n");
+}
+
DRM_INFO("radeon: dpm initialized\n");
}
--
1.8.2.1
Everything works fine, however I think that my gpu (ati 6670, see
below) doesn't reclock properly (OR doesn't reclock at all). I
observed the gpu-temps and compared those with the readings when using
“profile” and “dynpm”. Usually (with dynpm) the temps stay low and
jump up when I start glxgears or any HD-movie. With the latest dpm my
temps and the gpu stay in the lowest profile all the time. It doesn't
reclock even if I start any demanding work like HD-Movie. Dmesg shows
this:
***
[1.307529] == power state 0 ==
[1.307530] ui class: none
[1.307531] internal class: boot
[1.307532] caps:
[1.307533] uvdvclk: 0 dclk: 0
[1.307534] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307535] power level 1sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307536] power level 2sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307537] status: c r b
[1.307538] == power state 1 ==
[1.307539] ui class: performance
[1.307539] internal class: none
[1.307540] caps:
[1.307541] uvdvclk: 0 dclk: 0
[1.307542] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307543] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.307544] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307544] status:
[1.307545] == power state 2 ==
[1.307546] ui class: none
[1.307546] internal class: uvd
[1.307547] caps: video
[1.307549] uvdvclk: 7 dclk: 56000
[1.307549] power level 0sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307550] power level 1sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307551] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307552] status:
[1.311858] switching from power state:
[1.311859] ui class: none
[1.311860] internal class: boot
[1.311860] caps:
[1.311861] uvdvclk: 0 dclk: 0
[1.311862] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311863] power level 1sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311864] power level 2sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311865] status: c b
[1.311866] switching to power state:
[1.311866] ui class: performance
[1.311867] internal class: none
[1.311868] caps:
[1.311869] uvdvclk: 0 dclk: 0
[1.311869] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311870] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.311871] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.311872] status: r
and later (other dmesg output is attached)
[1.360509] switching from power state:
[1.360510] ui class: performance
[1.360510] internal class: none
[1.360511] caps:
[1.360511] uvdvclk: 0 dclk: 0
[1.360512] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.360512] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.360513] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.360513] status: c r
[1.360514] switching to power state:
[1.360514] ui class: performance
[1.360515] internal class: none
[1.360515] caps:
[1.360515] uvdvclk: 0 dclk: 0
[1.360516] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.360516] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.360517] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.360517] status: c r
***
The radeon_pm_info shows all the time:
[root@localhost ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 80 kHz
current engine clock: 0 kHz
default memory clock: 100 kHz
current memory clock: 15 kHz
vol
Re: RADEON / DPM: GPU cannot properly up-clock
2013/6/26 Deucher, Alexander :
>
>
>> -Original Message-----
>> From: Joshua C. [mailto:joshua...@gmail.com]
>> Sent: Wednesday, June 26, 2013 1:52 PM
>> To: dri-devel@lists.freedesktop.org
>> Cc: Deucher, Alexander
>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>
>> First of all thank you guys for pushing this out! Great work!
>>
>> I tried the latest code in drm-next-3.11-wip (up to commit
>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>> code") in connection with the latest radeon_ucode (latest update on
>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>> observe the gpu-settings. For this I put back the following patch:
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>> b/drivers/gpu/drm/radeon/radeon_pm.c
>> index 7ba5d6f..9367234 100644
>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>> radeon_device *rdev)
>> ret = device_create_file(rdev->dev, &dev_attr_power_method);
>> if (ret)
>> DRM_ERROR("failed to create device file for power method\n");
>> +
>> +if (radeon_debugfs_pm_init(rdev)) {
>> +DRM_ERROR("Failed to register debugfs file for PM!\n");
>> +}
>> +
>> DRM_INFO("radeon: dpm initialized\n");
>> }
>>
>> --
>> 1.8.2.1
>
> I removed that code for a reason when DPM is active. With DPM the hardware
> changes the power state dynamically internally so that old debugging
> information is completely irrelevant when DPM is active.
>
> Alex
>
>
I see. Do you have any idea why I see those delays when playing a
HD-movie? They do not appear when switching to dynpm. I use the latest
llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
--
--joshua
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RADEON / DPM: GPU cannot properly up-clock
2013/6/27 Alex Deucher :
> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. wrote:
>> 2013/6/26 Deucher, Alexander :
>>>
>>>
>>>> -Original Message-
>>>> From: Joshua C. [mailto:joshua...@gmail.com]
>>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>>> To: dri-devel@lists.freedesktop.org
>>>> Cc: Deucher, Alexander
>>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>>
>>>> First of all thank you guys for pushing this out! Great work!
>>>>
>>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>>> code") in connection with the latest radeon_ucode (latest update on
>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>>> observe the gpu-settings. For this I put back the following patch:
>>>>
>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>>> index 7ba5d6f..9367234 100644
>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>>> radeon_device *rdev)
>>>> ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>> if (ret)
>>>> DRM_ERROR("failed to create device file for power method\n");
>>>> +
>>>> +if (radeon_debugfs_pm_init(rdev)) {
>>>> +DRM_ERROR("Failed to register debugfs file for PM!\n");
>>>> +}
>>>> +
>>>> DRM_INFO("radeon: dpm initialized\n");
>>>> }
>>>>
>>>> --
>>>> 1.8.2.1
>>>
>>> I removed that code for a reason when DPM is active. With DPM the hardware
>>> changes the power state dynamically internally so that old debugging
>>> information is completely irrelevant when DPM is active.
>>>
>>> Alex
>>>
>>>
>>
>> I see. Do you have any idea why I see those delays when playing a
>> HD-movie? They do not appear when switching to dynpm. I use the latest
>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>
> What type of movie is it and what are you using to decode the movie? UVD?
> CPU?
>
> Alex
Here is an example of the information from one of the films:
Stream 0
Type: Video
Codec: H264 - MPEG-4 AVC (part 10) (avc1)
Lang: English
Res: 1280x544
Bitrate: 23.976215
Format: Planar 4:2:0 YVU
Stream 1
Type: Audio
Codec: DTS Audio (dts )
Lang: English
Channels: 3F2R/LFE
Freq: 48000 Hz
Bitrate: 1536 kb/s
I recompiled the whole videostack (mesa, llvm, drm, xserver,
xf86-video-ati, vdpau - all from git) against the patched kernel and
can say that currently there are no visible regressions. The "slow
motion" is almost gone. However I still see it in some frames but I'm
not sure if this is a kernel-part-problem or just a mesa-problem.
However I observe the following:
Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
on all cores on a 4-core cpu, temps when playing the film: up to 42C,
cpu-usage: up to 5% on all 4 cores
Under linux (updated as described above): some discrepences (those
happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
5%, temps when playing the film: no more than 37C, cpu-usage: one core
is constantly spiking up to 40% the other 3 stay below 7%.
When looking through the dmesg I cannot see that dpm is changing the
power state to "uvd". This makes me believe that I'm maybe using a
cpu-decode rather then the dedicated uvd. The gpu-temps are also
staying surpricingly low comapred to windows...
--
--joshua
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RADEON / DPM: GPU cannot properly up-clock
2013/6/28 Joshua C. :
> 2013/6/27 Alex Deucher :
>> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. wrote:
>>> 2013/6/26 Deucher, Alexander :
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Joshua C. [mailto:joshua...@gmail.com]
>>>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>>>> To: dri-devel@lists.freedesktop.org
>>>>> Cc: Deucher, Alexander
>>>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>>>
>>>>> First of all thank you guys for pushing this out! Great work!
>>>>>
>>>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>>>> code") in connection with the latest radeon_ucode (latest update on
>>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>>>> observe the gpu-settings. For this I put back the following patch:
>>>>>
>>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> index 7ba5d6f..9367234 100644
>>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>>>> radeon_device *rdev)
>>>>> ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>>> if (ret)
>>>>> DRM_ERROR("failed to create device file for power method\n");
>>>>> +
>>>>> +if (radeon_debugfs_pm_init(rdev)) {
>>>>> +DRM_ERROR("Failed to register debugfs file for PM!\n");
>>>>> +}
>>>>> +
>>>>> DRM_INFO("radeon: dpm initialized\n");
>>>>> }
>>>>>
>>>>> --
>>>>> 1.8.2.1
>>>>
>>>> I removed that code for a reason when DPM is active. With DPM the
>>>> hardware changes the power state dynamically internally so that old
>>>> debugging information is completely irrelevant when DPM is active.
>>>>
>>>> Alex
>>>>
>>>>
>>>
>>> I see. Do you have any idea why I see those delays when playing a
>>> HD-movie? They do not appear when switching to dynpm. I use the latest
>>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>>
>> What type of movie is it and what are you using to decode the movie? UVD?
>> CPU?
>>
>> Alex
>
> Here is an example of the information from one of the films:
>
> Stream 0
> Type: Video
> Codec: H264 - MPEG-4 AVC (part 10) (avc1)
> Lang: English
> Res: 1280x544
> Bitrate: 23.976215
> Format: Planar 4:2:0 YVU
> Stream 1
> Type: Audio
> Codec: DTS Audio (dts )
> Lang: English
> Channels: 3F2R/LFE
> Freq: 48000 Hz
> Bitrate: 1536 kb/s
>
> I recompiled the whole videostack (mesa, llvm, drm, xserver,
> xf86-video-ati, vdpau - all from git) against the patched kernel and
> can say that currently there are no visible regressions. The "slow
> motion" is almost gone. However I still see it in some frames but I'm
> not sure if this is a kernel-part-problem or just a mesa-problem.
>
> However I observe the following:
>
> Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
> on all cores on a 4-core cpu, temps when playing the film: up to 42C,
> cpu-usage: up to 5% on all 4 cores
>
> Under linux (updated as described above): some discrepences (those
> happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
> 5%, temps when playing the film: no more than 37C, cpu-usage: one core
> is constantly spiking up to 40% the other 3 stay below 7%.
>
> When looking through the dmesg I cannot see that dpm is changing the
> power state to "uvd". This makes me believe that I'm maybe using a
> cpu-decode rather then the dedicated uvd. The gpu-temps are also
> staying surpricingly low comapred to windows...
>
> --
> --joshua
With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de
"drm/radeon/dpm: add debugfs support for SI" from
git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything
works fine here (on TURKS). Under Linux I get the same temps as under
windows. No more tearing when watching videos. The GPU re-clocks as
desired...
--
--joshua
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RADEON / DPM: GPU cannot properly up-clock
2013/6/28 Joshua C. :
> 2013/6/27 Alex Deucher :
>> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. wrote:
>>> 2013/6/26 Deucher, Alexander :
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Joshua C. [mailto:joshuacov at gmail.com]
>>>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>>>> To: dri-devel at lists.freedesktop.org
>>>>> Cc: Deucher, Alexander
>>>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>>>
>>>>> First of all thank you guys for pushing this out! Great work!
>>>>>
>>>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>>>> code") in connection with the latest radeon_ucode (latest update on
>>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>>>> observe the gpu-settings. For this I put back the following patch:
>>>>>
>>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> index 7ba5d6f..9367234 100644
>>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>>>> radeon_device *rdev)
>>>>> ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>>> if (ret)
>>>>> DRM_ERROR("failed to create device file for power method\n");
>>>>> +
>>>>> +if (radeon_debugfs_pm_init(rdev)) {
>>>>> +DRM_ERROR("Failed to register debugfs file for PM!\n");
>>>>> +}
>>>>> +
>>>>> DRM_INFO("radeon: dpm initialized\n");
>>>>> }
>>>>>
>>>>> --
>>>>> 1.8.2.1
>>>>
>>>> I removed that code for a reason when DPM is active. With DPM the
>>>> hardware changes the power state dynamically internally so that old
>>>> debugging information is completely irrelevant when DPM is active.
>>>>
>>>> Alex
>>>>
>>>>
>>>
>>> I see. Do you have any idea why I see those delays when playing a
>>> HD-movie? They do not appear when switching to dynpm. I use the latest
>>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>>
>> What type of movie is it and what are you using to decode the movie? UVD?
>> CPU?
>>
>> Alex
>
> Here is an example of the information from one of the films:
>
> Stream 0
> Type: Video
> Codec: H264 - MPEG-4 AVC (part 10) (avc1)
> Lang: English
> Res: 1280x544
> Bitrate: 23.976215
> Format: Planar 4:2:0 YVU
> Stream 1
> Type: Audio
> Codec: DTS Audio (dts )
> Lang: English
> Channels: 3F2R/LFE
> Freq: 48000 Hz
> Bitrate: 1536 kb/s
>
> I recompiled the whole videostack (mesa, llvm, drm, xserver,
> xf86-video-ati, vdpau - all from git) against the patched kernel and
> can say that currently there are no visible regressions. The "slow
> motion" is almost gone. However I still see it in some frames but I'm
> not sure if this is a kernel-part-problem or just a mesa-problem.
>
> However I observe the following:
>
> Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
> on all cores on a 4-core cpu, temps when playing the film: up to 42C,
> cpu-usage: up to 5% on all 4 cores
>
> Under linux (updated as described above): some discrepences (those
> happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
> 5%, temps when playing the film: no more than 37C, cpu-usage: one core
> is constantly spiking up to 40% the other 3 stay below 7%.
>
> When looking through the dmesg I cannot see that dpm is changing the
> power state to "uvd". This makes me believe that I'm maybe using a
> cpu-decode rather then the dedicated uvd. The gpu-temps are also
> staying surpricingly low comapred to windows...
>
> --
> --joshua
With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de
"drm/radeon/dpm: add debugfs support for SI" from
git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything
works fine here (on TURKS). Under Linux I get the same temps as under
windows. No more tearing when watching videos. The GPU re-clocks as
desired...
--
--joshua
Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues
2013/7/29 Alex Deucher : > On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf > wrote: >> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote: >>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf >>> wrote: >>> > On my test machine Xorg doesn't start anymore when I kexec into a >>> > 3.11.0-rc3 kernel. >>> >>> With kexec, dpm doesn't get torn down properly which can result in a >>> bad hardware state when the driver loads again. Does the attached >>> patch help? It attempts to disable dpm at startup in case it wasn't >>> torn down properly previously. >> >> dpm initialization now works, but unfortunately GPU acceleration still gets >> disabled: > > Stupid kexec complicates things. We need to make sure dpm is torn > down before we init the rest of the GPU, but dpm needs get initialized > later in the init process since it depends on certain other state from > the driver. I need to think about this for a bit. I'm not sure of a > good way to handle this. > > Alex > >> >> [drm] Initialized drm 1.1.0 20060810 >> >> [135/1104] >> [drm] radeon kernel modesetting enabled. >> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D). >> [drm] register mmio base: 0xFBEE >> [drm] register mmio size: 65536 >> ATOM BIOS: 113 >> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF >> (128M used) >> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF >> [drm] Detected VRAM RAM=128M, BAR=128M >> [drm] RAM width 32bits DDR >> [TTM] Zone kernel: Available graphics memory: 4082356 kiB >> [TTM] Zone dma32: Available graphics memory: 2097152 kiB >> [TTM] Initializing pool allocator >> [TTM] Initializing DMA pool allocator >> [drm] radeon: 128M of VRAM memory ready >> [drm] radeon: 512M of GTT memory ready. >> [drm] GART: num cpu pages 131072, num gpu pages 131072 >> [drm] Loading RS780 Microcode >> [drm] PCIE GART of 512M enabled (table at 0xC004). >> radeon :01:05.0: WB enabled >> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 >> and cpu addr 0x880215c30c00 >> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c >> and cpu addr 0x880215c30c0c >> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). >> [drm] Driver supports precise vblank timestamp query. >> [drm] radeon: irq initialized. >> radeon :01:05.0: setting latency timer to 64 >> [drm] ring test on 0 succeeded in 1 usecs >> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) >> radeon :01:05.0: disabling GPU acceleration >> radeon :01:05.0: 8802161cfc00 unpin not necessary >> [drm] Radeon Display Connectors >> [drm] Connector 0: >> [drm] VGA-1 >> [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c >> [drm] Encoders: >> [drm] CRT1: INTERNAL_KLDSCP_DAC1 >> [drm] Connector 1: >> [drm] DVI-D-1 >> [drm] HPD3 >> [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c >> [drm] Encoders: >> [drm] DFP3: INTERNAL_KLDSCP_LVTMA >> == power state 0 == >> ui class: none >> internal class: boot >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 2 >> power level 1sclk: 5 vddc_index: 2 >> status: c r b >> == power state 1 == >> ui class: performance >> internal class: none >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 1 >> power level 1sclk: 7 vddc_index: 2 >> status: >> == power state 2 == >> ui class: none >> internal class: uvd >> caps: video >> uvdvclk: 53300 dclk: 4 >> power level 0sclk: 5 vddc_index: 1 >> power level 1sclk: 5 vddc_index: 1 >> status: >> switching from power state: >> ui class: none >> internal class: boot >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 2 >> power level 1sclk: 5 vddc_index: 2 >> status: c b >> switching to power state: >> ui class: performance >> internal class: none >> caps: video >> uvdvclk: 0 dclk: 0 >> power level 0sclk: 5 vddc_index: 1 >> power level 1sclk: 7 vddc_index: 2 >> status: r >> [drm] radeon: dpm initialized >> [drm] fb mappable at 0xF0142000 >> [drm] vram apper at 0xF000 >> [drm] size 7299072 >> [drm] fb depth is 24 >> [drm]pitch is 6912 >> fbcon: radeondrmfb (fb0) >> >> -- >> Markus > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman
Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues
2013/7/30 Markus Trippelsdorf : > > I begin to wonder if: > [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) > is an simple initialization bug that doesn't directly depend on kexec at > all. > > -- > Markus I bet on this (because I see the same error in another context) -- --joshua
RADEON / DPM: GPU cannot properly up-clock
First of all thank you guys for pushing this out! Great work!
I tried the latest code in drm-next-3.11-wip (up to commit
b3c1e0c3ba885db44 ?drm/radeon: fix endian issues in atombios dpm
code?) in connection with the latest radeon_ucode (latest update on
2013-06-26). I also reintroduced the debugfs info so that I can better
observe the gpu-settings. For this I put back the following patch:
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 7ba5d6f..9367234 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev)
ret = device_create_file(rdev->dev, &dev_attr_power_method);
if (ret)
DRM_ERROR("failed to create device file for power method\n");
+
+if (radeon_debugfs_pm_init(rdev)) {
+DRM_ERROR("Failed to register debugfs file for PM!\n");
+}
+
DRM_INFO("radeon: dpm initialized\n");
}
--
1.8.2.1
Everything works fine, however I think that my gpu (ati 6670, see
below) doesn't reclock properly (OR doesn't reclock at all). I
observed the gpu-temps and compared those with the readings when using
?profile? and ?dynpm?. Usually (with dynpm) the temps stay low and
jump up when I start glxgears or any HD-movie. With the latest dpm my
temps and the gpu stay in the lowest profile all the time. It doesn't
reclock even if I start any demanding work like HD-Movie. Dmesg shows
this:
***
[1.307529] == power state 0 ==
[1.307530] ui class: none
[1.307531] internal class: boot
[1.307532] caps:
[1.307533] uvdvclk: 0 dclk: 0
[1.307534] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307535] power level 1sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307536] power level 2sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307537] status: c r b
[1.307538] == power state 1 ==
[1.307539] ui class: performance
[1.307539] internal class: none
[1.307540] caps:
[1.307541] uvdvclk: 0 dclk: 0
[1.307542] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.307543] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.307544] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307544] status:
[1.307545] == power state 2 ==
[1.307546] ui class: none
[1.307546] internal class: uvd
[1.307547] caps: video
[1.307549] uvdvclk: 7 dclk: 56000
[1.307549] power level 0sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307550] power level 1sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307551] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.307552] status:
[1.311858] switching from power state:
[1.311859] ui class: none
[1.311860] internal class: boot
[1.311860] caps:
[1.311861] uvdvclk: 0 dclk: 0
[1.311862] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311863] power level 1sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311864] power level 2sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311865] status: c b
[1.311866] switching to power state:
[1.311866] ui class: performance
[1.311867] internal class: none
[1.311868] caps:
[1.311869] uvdvclk: 0 dclk: 0
[1.311869] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.311870] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.311871] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.311872] status: r
and later (other dmesg output is attached)
[1.360509] switching from power state:
[1.360510] ui class: performance
[1.360510] internal class: none
[1.360511] caps:
[1.360511] uvdvclk: 0 dclk: 0
[1.360512] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.360512] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.360513] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.360513] status: c r
[1.360514] switching to power state:
[1.360514] ui class: performance
[1.360515] internal class: none
[1.360515] caps:
[1.360515] uvdvclk: 0 dclk: 0
[1.360516] power level 0sclk: 1 mclk: 15000 vddc:
900 vddci: 0
[1.360516] power level 1sclk: 4 mclk: 10
vddc: 1100 vddci: 0
[1.360517] power level 2sclk: 8 mclk: 10
vddc: 1100 vddci: 0
[1.360517] status: c r
***
The radeon_pm_info shows all the time:
[root at localhost ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 80 kHz
current engine clock: 0 kHz
default memory clock: 100 kHz
current memory clock: 15 kHz
RADEON / DPM: GPU cannot properly up-clock
2013/6/26 Deucher, Alexander :
>
>
>> -Original Message-----
>> From: Joshua C. [mailto:joshuacov at gmail.com]
>> Sent: Wednesday, June 26, 2013 1:52 PM
>> To: dri-devel at lists.freedesktop.org
>> Cc: Deucher, Alexander
>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>
>> First of all thank you guys for pushing this out! Great work!
>>
>> I tried the latest code in drm-next-3.11-wip (up to commit
>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>> code") in connection with the latest radeon_ucode (latest update on
>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>> observe the gpu-settings. For this I put back the following patch:
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>> b/drivers/gpu/drm/radeon/radeon_pm.c
>> index 7ba5d6f..9367234 100644
>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>> radeon_device *rdev)
>> ret = device_create_file(rdev->dev, &dev_attr_power_method);
>> if (ret)
>> DRM_ERROR("failed to create device file for power method\n");
>> +
>> +if (radeon_debugfs_pm_init(rdev)) {
>> +DRM_ERROR("Failed to register debugfs file for PM!\n");
>> +}
>> +
>> DRM_INFO("radeon: dpm initialized\n");
>> }
>>
>> --
>> 1.8.2.1
>
> I removed that code for a reason when DPM is active. With DPM the hardware
> changes the power state dynamically internally so that old debugging
> information is completely irrelevant when DPM is active.
>
> Alex
>
>
I see. Do you have any idea why I see those delays when playing a
HD-movie? They do not appear when switching to dynpm. I use the latest
llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
--
--joshua
RADEON / DPM: GPU cannot properly up-clock
2013/6/27 Alex Deucher :
> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. wrote:
>> 2013/6/26 Deucher, Alexander :
>>>
>>>
>>>> -Original Message-
>>>> From: Joshua C. [mailto:joshuacov at gmail.com]
>>>> Sent: Wednesday, June 26, 2013 1:52 PM
>>>> To: dri-devel at lists.freedesktop.org
>>>> Cc: Deucher, Alexander
>>>> Subject: RADEON / DPM: GPU cannot properly up-clock
>>>>
>>>> First of all thank you guys for pushing this out! Great work!
>>>>
>>>> I tried the latest code in drm-next-3.11-wip (up to commit
>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
>>>> code") in connection with the latest radeon_ucode (latest update on
>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better
>>>> observe the gpu-settings. For this I put back the following patch:
>>>>
>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>>>> b/drivers/gpu/drm/radeon/radeon_pm.c
>>>> index 7ba5d6f..9367234 100644
>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
>>>> radeon_device *rdev)
>>>> ret = device_create_file(rdev->dev, &dev_attr_power_method);
>>>> if (ret)
>>>> DRM_ERROR("failed to create device file for power method\n");
>>>> +
>>>> +if (radeon_debugfs_pm_init(rdev)) {
>>>> +DRM_ERROR("Failed to register debugfs file for PM!\n");
>>>> +}
>>>> +
>>>> DRM_INFO("radeon: dpm initialized\n");
>>>> }
>>>>
>>>> --
>>>> 1.8.2.1
>>>
>>> I removed that code for a reason when DPM is active. With DPM the hardware
>>> changes the power state dynamically internally so that old debugging
>>> information is completely irrelevant when DPM is active.
>>>
>>> Alex
>>>
>>>
>>
>> I see. Do you have any idea why I see those delays when playing a
>> HD-movie? They do not appear when switching to dynpm. I use the latest
>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>
> What type of movie is it and what are you using to decode the movie? UVD?
> CPU?
>
> Alex
Here is an example of the information from one of the films:
Stream 0
Type: Video
Codec: H264 - MPEG-4 AVC (part 10) (avc1)
Lang: English
Res: 1280x544
Bitrate: 23.976215
Format: Planar 4:2:0 YVU
Stream 1
Type: Audio
Codec: DTS Audio (dts )
Lang: English
Channels: 3F2R/LFE
Freq: 48000 Hz
Bitrate: 1536 kb/s
I recompiled the whole videostack (mesa, llvm, drm, xserver,
xf86-video-ati, vdpau - all from git) against the patched kernel and
can say that currently there are no visible regressions. The "slow
motion" is almost gone. However I still see it in some frames but I'm
not sure if this is a kernel-part-problem or just a mesa-problem.
However I observe the following:
Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
on all cores on a 4-core cpu, temps when playing the film: up to 42C,
cpu-usage: up to 5% on all 4 cores
Under linux (updated as described above): some discrepences (those
happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
5%, temps when playing the film: no more than 37C, cpu-usage: one core
is constantly spiking up to 40% the other 3 stay below 7%.
When looking through the dmesg I cannot see that dpm is changing the
power state to "uvd". This makes me believe that I'm maybe using a
cpu-decode rather then the dedicated uvd. The gpu-temps are also
staying surpricingly low comapred to windows...
--
--joshua
