Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver
As a follow up, I've been away for quite some time now (long overdue vacations), but I'm back home now. This will be my main project, so we may get something working if I'm lucky. I'll soon be posting a link to my repository where things will be worked on. Cheers. Alexandre Demers On 2016-01-20 20:21, Alexandre Demers wrote: > Thanks to all your feedback. Well, it seems achievable. I may ask some > questions here and there, but I think I'll give it a try. > > Alexandre Demers > > On 2016-01-19 07:58, Christian König wrote: >>> I think Graham summed it up pretty well :) >> Indeed, but there is a detail missing. The main problem for moving SI >> and CIK support from radeon to amdgpu is that we can't break existing >> userspace. >> >> Fortunately amdgpu wasn't designed from scratch, instead it's rather >> a evaluational successor of radeon. Because of that a lot of the >> internal interfaces are still the same. >> >> Additional to that I made the IOCTL numbers from Radeon and Amdgpu >> intentional disjoint. Amdgpu is using 0x00-0x12 and KMS on Radeon is >> using 0x1c-0x2d (we never supported UMS for SI/CIK). >> >> So in theory it would be possible that somebody implements a >> compatibility mode which provides the old Radeon IOCTLs for SI and >> CIK hardware generation in Amdgpu. >> >> This way we could support SI on Amdgpu as well and remove the support >> for SI and CIK from Radeon. >> >> The biggest differences are indeed in the multimedia area, e.g. UVD >> and VCE. But it's still mostly copying the Radeon code to Amdgpu (if >> somebody cares we could even move that into an independent module >> shared by both). >> >> Regards, >> Christian. >> >> Am 18.01.2016 um 23:19 schrieb Deucher, Alexander: >>>> -Original Message- >>>> From: Sellers, Graham >>>> Sent: Monday, January 18, 2016 10:38 AM >>>> To: alexandre.f.demers at gmail.com; Deucher, Alexander >>>> Cc: dri-devel >>>> Subject: RE: Porting GCN pre-1.2 parts from radeon to amdgpu kernel >>>> driver >>>> >>>> Hi Alexandre, >>>> >>>> Yes, your understanding is correct. >>>> >>>> Frankly, Alex or one of the other guys on the open source team >>>> would be >>>> best positioned to answer your questions as to what would >>>> specifically need >>>> to be done. However, yes, the gap we have here is in the amdgpu kernel >>>> driver. I pretty much only work on the user-mode side of things. Think >>>> "libVulkan.so" or "vulkan.dll" - the bit that applications link to. >>>> We talk to our >>>> kernel drivers through standard interfaces. It's the kernel driver >>>> that deals >>>> with a lot of the differences between different parts of hardware. >>>> amdgpu is >>>> a ground-up redesign of our kernel solution for Linux. The >>>> closed-source >>>> kernel driver that we were using in our Catalyst packages has been >>>> put out to >>>> pasture. For the amdgpu project, given the number of engineers we >>>> have, >>>> we have to make a tough decision between supporting interesting new >>>> features of new GPUs, or sticking with pretty basic support but >>>> backporting >>>> to older GPUs. >>>> >>>> The differences in the graphics core itself between SI, CI and VI >>>> are actually >>>> pretty minimal (as far as the kernel driver is concerned, anyway). >>>> Where >>>> there are bigger differences are in things like the multimedia >>>> (video) engines, >>>> display controller, power management and so on. The radeon KMD has >>>> full >>>> support for all SI and CI (and earlier) "un-core" parts of the GPU. >>>> amdgpu has >>>> VI product support and some minimal (albeit disabled) support for >>>> CI, and >>>> basically nothing from SI. >>>> >>>> Our user-mode Vulkan driver (and closed source OpenGL driver, for that >>>> matter) can talk to the amdgpu kernel driver, but not to the radeon >>>> kernel >>>> driver. The interfaces are quite different, and honestly, the >>>> radeon kernel >>>> interface isn't a great fit for Vulkan. We had considered trying to >>>> support >>>> radeon K
[PATCH] radeon: Define SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP for consistency and readability - libdrm
---
include/drm/radeon_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index cd31794..e57640a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -1026,6 +1026,7 @@ struct drm_radeon_info {
#define SI_TILE_MODE_COLOR_2D_16BPP15
#define SI_TILE_MODE_COLOR_2D_32BPP16
#define SI_TILE_MODE_COLOR_2D_64BPP17
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP 10
#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP11
#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP12
#define SI_TILE_MODE_DEPTH_STENCIL_1D 4
--
2.7.1
[PATCH] radeon: Define SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP for consistency and readability
---
drivers/gpu/drm/radeon/atombios_crtc.c | 2 +-
include/uapi/drm/radeon_drm.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 801dd60..c88f9fe 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1287,7 +1287,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
} else {
switch (target_fb->bits_per_pixel) {
case 8:
- index = 10;
+ index =
SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP;
break;
case 16:
index =
SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index ccb9bcd..407a092 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -1057,6 +1057,7 @@ struct drm_radeon_info {
#define SI_TILE_MODE_COLOR_2D_16BPP15
#define SI_TILE_MODE_COLOR_2D_32BPP16
#define SI_TILE_MODE_COLOR_2D_64BPP17
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP 10
#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP11
#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP12
#define SI_TILE_MODE_DEPTH_STENCIL_1D 4
--
2.7.1
radeon_drm.h: missing TILE_MODE definition?
On Thu, 11 Feb 2016 at 10:30 Alex Deucher wrote: > On Thu, Feb 11, 2016 at 12:23 AM, Alexandre Demers > wrote: > > I was looking at /drivers/gpu/drm/radeon/atombios_crtc.c and at > radeon_drm.h > > (both under kernel and libdrm). I noticed that there seems to be a > missing > > TILE_MODE definition: under atombios_crtc, line 1289 > > (/drivers/gpu/drm/radeon/atombios_crtc.c#L1289), an unexplained value is > > being used (index = 10;) compared to the rest of the code around where > > defined variables are being used. > > > > Looking at the defined variables under radeon_drm.h, there is a missing > > value in the tile index. Index 10 is missing. If it was defined, it > could be > > used in place of the numerical value at line 1289 under atombios_crtc.c. > > According to the other names and usages, shouldn't there be a #define > > SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP 10? In fact, the equivalent of > > SI_TILE_MODE_COLORD_2D_8BPP is CIK_TILE_MODE_COLOR_2D under CIK; under > CIK, > > there is a variable defined for index 10, which is > > CIK_TILE_MODE_COLOR_2D_SCANOUT. Thus, I'd be inclined to think there > should > > really be a SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP variable defined. > > > > I've been searching in the SI 3D register documentation and I couldn't > find > > a tile index table to relate to. > > > > Lastly, based on how the other "X_2D_SCANOUT_YBPP" variables are covered > > under si_surface_sanity() (libdrm's radeon_surface.c), is it expected > that > > this index value (10) is not covered specifically. Should there be a > "case > > 1: *tile_mode = SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP; break;" at line 1362, > > before "case 2: ..."? Would it make sense? > > > > I don't think it's a particularly useful case. In practice I doubt it > would ever be hit. I guess it's for 8bpp greyscale. The 3D engine > can't render to indexed color or 332 surfaces. If you aren't using > the 3D engine, there's not much point in using tiling to begin with. > > Alex > Thanks for the answer. At least, I'd like to add a "#define SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP 10;" (if that variable name makes sense, I'm open to any other more meaningful name) just so we don't have a "index = 10" right there in the middle of the code while other cases use defined variables: it is mostly about consistency and readability of the code. Any objection? Your comment is more about if this case/index value should be covered under si_surface_sanity(). I'll trust you on the fact that it shouldn't be encountered. Cheers Alexandre Demers -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160211/4a793d92/attachment-0001.html>
radeon_drm.h: missing TILE_MODE definition?
I was looking at /drivers/gpu/drm/radeon/atombios_crtc.c and at radeon_drm.h (both under kernel and libdrm). I noticed that there seems to be a missing TILE_MODE definition: under atombios_crtc, line 1289 (/drivers/gpu/drm/radeon/atombios_crtc.c#L1289), an unexplained value is being used (index = 10;) compared to the rest of the code around where defined variables are being used. Looking at the defined variables under radeon_drm.h, there is a missing value in the tile index. Index 10 is missing. If it was defined, it could be used in place of the numerical value at line 1289 under atombios_crtc.c. According to the other names and usages, shouldn't there be a #define SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP 10? In fact, the equivalent of SI_TILE_MODE_COLORD_2D_8BPP is CIK_TILE_MODE_COLOR_2D under CIK; under CIK, there is a variable defined for index 10, which is CIK_TILE_MODE_COLOR_2D_SCANOUT. Thus, I'd be inclined to think there should really be a SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP variable defined. I've been searching in the SI 3D register documentation and I couldn't find a tile index table to relate to. Lastly, based on how the other "X_2D_SCANOUT_YBPP" variables are covered under si_surface_sanity() (libdrm's radeon_surface.c), is it expected that this index value (10) is not covered specifically. Should there be a "case 1: *tile_mode = SI_TILE_MODE_COLOR_2D_SCANOUT_8BPP; break;" at line 1362, before "case 2: ..."? Would it make sense? Cheers, Alexandre Demers -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160211/0ea3f9e7/attachment.html>
Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver
Thanks to all your feedback. Well, it seems achievable. I may ask some questions here and there, but I think I'll give it a try. Alexandre Demers On 2016-01-19 07:58, Christian König wrote: >> I think Graham summed it up pretty well :) > Indeed, but there is a detail missing. The main problem for moving SI > and CIK support from radeon to amdgpu is that we can't break existing > userspace. > > Fortunately amdgpu wasn't designed from scratch, instead it's rather a > evaluational successor of radeon. Because of that a lot of the > internal interfaces are still the same. > > Additional to that I made the IOCTL numbers from Radeon and Amdgpu > intentional disjoint. Amdgpu is using 0x00-0x12 and KMS on Radeon is > using 0x1c-0x2d (we never supported UMS for SI/CIK). > > So in theory it would be possible that somebody implements a > compatibility mode which provides the old Radeon IOCTLs for SI and CIK > hardware generation in Amdgpu. > > This way we could support SI on Amdgpu as well and remove the support > for SI and CIK from Radeon. > > The biggest differences are indeed in the multimedia area, e.g. UVD > and VCE. But it's still mostly copying the Radeon code to Amdgpu (if > somebody cares we could even move that into an independent module > shared by both). > > Regards, > Christian. > > Am 18.01.2016 um 23:19 schrieb Deucher, Alexander: >>> -Original Message- >>> From: Sellers, Graham >>> Sent: Monday, January 18, 2016 10:38 AM >>> To: alexandre.f.demers at gmail.com; Deucher, Alexander >>> Cc: dri-devel >>> Subject: RE: Porting GCN pre-1.2 parts from radeon to amdgpu kernel >>> driver >>> >>> Hi Alexandre, >>> >>> Yes, your understanding is correct. >>> >>> Frankly, Alex or one of the other guys on the open source team would be >>> best positioned to answer your questions as to what would >>> specifically need >>> to be done. However, yes, the gap we have here is in the amdgpu kernel >>> driver. I pretty much only work on the user-mode side of things. Think >>> "libVulkan.so" or "vulkan.dll" - the bit that applications link to. >>> We talk to our >>> kernel drivers through standard interfaces. It's the kernel driver >>> that deals >>> with a lot of the differences between different parts of hardware. >>> amdgpu is >>> a ground-up redesign of our kernel solution for Linux. The >>> closed-source >>> kernel driver that we were using in our Catalyst packages has been >>> put out to >>> pasture. For the amdgpu project, given the number of engineers we have, >>> we have to make a tough decision between supporting interesting new >>> features of new GPUs, or sticking with pretty basic support but >>> backporting >>> to older GPUs. >>> >>> The differences in the graphics core itself between SI, CI and VI >>> are actually >>> pretty minimal (as far as the kernel driver is concerned, anyway). >>> Where >>> there are bigger differences are in things like the multimedia >>> (video) engines, >>> display controller, power management and so on. The radeon KMD has full >>> support for all SI and CI (and earlier) "un-core" parts of the GPU. >>> amdgpu has >>> VI product support and some minimal (albeit disabled) support for >>> CI, and >>> basically nothing from SI. >>> >>> Our user-mode Vulkan driver (and closed source OpenGL driver, for that >>> matter) can talk to the amdgpu kernel driver, but not to the radeon >>> kernel >>> driver. The interfaces are quite different, and honestly, the radeon >>> kernel >>> interface isn't a great fit for Vulkan. We had considered trying to >>> support >>> radeon KMD in our Vulkan driver, but it doesn't seem practical. So, >>> it seems >>> that the options would be really to port the non-core support from >>> radeon >>> KMD into amdgpu, or somehow port the new KMD interfaces to radeon >>> KMD, which would allow our Vulkan drivers to run on it, but seems >>> like a bit >>> of a backwards step. >>> >>> There are other complications - such as it being frowned upon to >>> have two >>> kernel drivers for the same piece of hardware, so you'd need to port >>> SI and >>> CI stuff from radeon to amdgpu, and then somehow disable (or remove >>> it) in >>> the radeon KMD such that
Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver
Hello to both of you, I've been following the development mostly of the radeon driver for some time (with some small commits here and there as you may know). I was waiting to hear some news about the coming support of Vulkan API. And I have been wondering for sometime now if it would be a good think to have all GCN parts moved from the radeon driver to the amdgpu kernel driver (I had figured out it would be possible, but would it be of any use was still unanswered). I was also curious to know if the new Crimson software would support the radeon driver at some point. Now, I may have had a clear answer: I just read from Phoronix' editor Michael Larabel (http://www.phoronix.com/scan.php?page=news_item&px=Help-Bring-Older-GCN-To-AMDGPU) that Vulkan would come to the amdgpu driver only, that the blob (which should eventually be opened) would support all GCN parts and that the only missing part to support GCN pre-1.2 parts with both Vulkan and Crimson would be to have them ported from the radeon driver to the amdgpu driver. Am I understanding correctly? I'd be interested to know a bit more about the task and I may try to start the work or join someone who would already be interested in doing so. Any comments on the matter? Any missunderstood thing? Cheers! -- Alexandre Demers
[PATCH] drm/radeon: fix trivial typo in warning message
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index c566993..4197ca1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1150,7 +1150,7 @@ static void radeon_check_arguments(struct radeon_device
*rdev)
}
if (radeon_vm_size < 1) {
- dev_warn(rdev->dev, "VM size (%d) to small, min is 1GB\n",
+ dev_warn(rdev->dev, "VM size (%d) too small, min is 1GB\n",
radeon_vm_size);
radeon_vm_size = 4;
}
--
2.6.4
[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes
Technical reminder about this patch: usually, for electronic stability, you'll have to raise the voltage BEFORE increasing the clock speed; on the other, you'll have to lower the voltage AFTER lowering the clock speed. You may encounter stability problem if you don't follow this order. The patch fixes the first case, but you may end up creating the opposite problem by only moving ci_apply_disp_minimum_voltage_request(rdev) earlier in the process. But it may actually be covered by ci_send_msg_to_smc_with_parameter() or it may not be actually what ci_upload_dpm_level_enable_mask() is about. Is this patch linked to a specific bug? Alexandre Demers
[PATCH 00/22] new radeon info queries
May I suggest something more to add if available? It would be great to have the core and memory voltages. As an example of a specific application where it would have been usefull: it would have been easier to debug the problem with Cayman when vddci was not correctly set (it would have been higher or lower than expected or the value would have been nonsense). Thanks, Alexandre Demers
[PATCH] drm/radeon: Remove limitation on clock speeds
It seems good to me.
For the serie
Reviewed-by: Alexandre Demers
For for 1 and 5
Tested-by: Alexandre Demers on kernel 3.17-rc6
On Tue, Sep 23, 2014 at 9:52 AM, Alex Deucher wrote:
> On Tue, Sep 23, 2014 at 1:08 AM, Alexandre Demers
> wrote:
>> Typo: this should be "Tested on kernel 3.17-rc6 on..."
>>
>> Alexandre Demers
>>
>>
>> On 23/09/14 12:42 AM, Alexandre Demers wrote:
>>>
>>> Now that vddci has been fixed for dpm, we can let the GPUs
>>> use their maximum values when not using the reference ones.
>>>
>>> Fixes bug 69721: Can't reach maximum memory speed (or core
>>> speed) when using dpm=1 on r600g on cards not sticking to
>>> reference board
>>>
>>> Tested on kernel 3.17-rc7 on a cayman gpu.
>>>
>>> Signed-off-by: Alexandre Demers
>
> Thanks for testing this. I'd rather split this up into multiple
> patches in case we need to revert it on a specific asic family if
> problems arise. How about the attached patches?
>
> Alex
>
>>>
>>> ---
>>> drivers/gpu/drm/radeon/btc_dpm.c | 51
>>>
>>> drivers/gpu/drm/radeon/btc_dpm.h | 2 --
>>> drivers/gpu/drm/radeon/ci_dpm.c | 26
>>> drivers/gpu/drm/radeon/ni_dpm.c | 24 ---
>>> drivers/gpu/drm/radeon/si_dpm.c | 24 ---
>>> 5 files changed, 127 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/btc_dpm.c
>>> b/drivers/gpu/drm/radeon/btc_dpm.c
>>> index f81d7ca..300d971 100644
>>> --- a/drivers/gpu/drm/radeon/btc_dpm.c
>>> +++ b/drivers/gpu/drm/radeon/btc_dpm.c
>>> @@ -1170,23 +1170,6 @@ static const struct radeon_blacklist_clocks
>>> btc_blacklist_clocks[] =
>>> { 25000, 3, RADEON_SCLK_UP }
>>> };
>>> -void btc_get_max_clock_from_voltage_dependency_table(struct
>>> radeon_clock_voltage_dependency_table *table,
>>> -u32 *max_clock)
>>> -{
>>> - u32 i, clock = 0;
>>> -
>>> - if ((table == NULL) || (table->count == 0)) {
>>> - *max_clock = clock;
>>> - return;
>>> - }
>>> -
>>> - for (i = 0; i < table->count; i++) {
>>> - if (clock < table->entries[i].clk)
>>> - clock = table->entries[i].clk;
>>> - }
>>> - *max_clock = clock;
>>> -}
>>> -
>>> void btc_apply_voltage_dependency_rules(struct
>>> radeon_clock_voltage_dependency_table *table,
>>> u32 clock, u16 max_voltage, u16
>>> *voltage)
>>> {
>>> @@ -2099,7 +2082,6 @@ static void btc_apply_state_adjust_rules(struct
>>> radeon_device *rdev,
>>> bool disable_mclk_switching;
>>> u32 mclk, sclk;
>>> u16 vddc, vddci;
>>> - u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
>>> if ((rdev->pm.dpm.new_active_crtc_count > 1) ||
>>> btc_dpm_vblank_too_short(rdev))
>>> @@ -2141,39 +2123,6 @@ static void btc_apply_state_adjust_rules(struct
>>> radeon_device *rdev,
>>> ps->low.vddci = max_limits->vddci;
>>> }
>>> - /* limit clocks to max supported clocks based on voltage
>>> dependency tables */
>>> -
>>> btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk,
>>> - &max_sclk_vddc);
>>> -
>>> btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk,
>>> - &max_mclk_vddci);
>>> -
>>> btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk,
>>> - &max_mclk_vddc);
>>> -
>>> - if (max_sclk_vddc) {
>>> - if (ps->low.sclk > max_sclk_vddc)
>>> - ps->low.sclk = max_sclk_vddc;
>>> - if (ps->medium.sclk > max_sclk_vddc)
>>> - ps->medium.sclk = max_sclk_vddc;
>>> - if (ps->high.sclk > max_sclk_vddc)
>>> - ps->high.sclk =
[PATCH] drm/radeon: Remove limitation on clock speeds
Typo: this should be "Tested on kernel 3.17-rc6 on..."
Alexandre Demers
On 23/09/14 12:42 AM, Alexandre Demers wrote:
> Now that vddci has been fixed for dpm, we can let the GPUs
> use their maximum values when not using the reference ones.
>
> Fixes bug 69721: Can't reach maximum memory speed (or core
> speed) when using dpm=1 on r600g on cards not sticking to
> reference board
>
> Tested on kernel 3.17-rc7 on a cayman gpu.
>
> Signed-off-by: Alexandre Demers
>
> ---
> drivers/gpu/drm/radeon/btc_dpm.c | 51
>
> drivers/gpu/drm/radeon/btc_dpm.h | 2 --
> drivers/gpu/drm/radeon/ci_dpm.c | 26
> drivers/gpu/drm/radeon/ni_dpm.c | 24 ---
> drivers/gpu/drm/radeon/si_dpm.c | 24 ---
> 5 files changed, 127 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/btc_dpm.c
> b/drivers/gpu/drm/radeon/btc_dpm.c
> index f81d7ca..300d971 100644
> --- a/drivers/gpu/drm/radeon/btc_dpm.c
> +++ b/drivers/gpu/drm/radeon/btc_dpm.c
> @@ -1170,23 +1170,6 @@ static const struct radeon_blacklist_clocks
> btc_blacklist_clocks[] =
> { 25000, 3, RADEON_SCLK_UP }
> };
>
> -void btc_get_max_clock_from_voltage_dependency_table(struct
> radeon_clock_voltage_dependency_table *table,
> - u32 *max_clock)
> -{
> - u32 i, clock = 0;
> -
> - if ((table == NULL) || (table->count == 0)) {
> - *max_clock = clock;
> - return;
> - }
> -
> - for (i = 0; i < table->count; i++) {
> - if (clock < table->entries[i].clk)
> - clock = table->entries[i].clk;
> - }
> - *max_clock = clock;
> -}
> -
> void btc_apply_voltage_dependency_rules(struct
> radeon_clock_voltage_dependency_table *table,
> u32 clock, u16 max_voltage, u16
> *voltage)
> {
> @@ -2099,7 +2082,6 @@ static void btc_apply_state_adjust_rules(struct
> radeon_device *rdev,
> bool disable_mclk_switching;
> u32 mclk, sclk;
> u16 vddc, vddci;
> - u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
>
> if ((rdev->pm.dpm.new_active_crtc_count > 1) ||
> btc_dpm_vblank_too_short(rdev))
> @@ -2141,39 +2123,6 @@ static void btc_apply_state_adjust_rules(struct
> radeon_device *rdev,
> ps->low.vddci = max_limits->vddci;
> }
>
> - /* limit clocks to max supported clocks based on voltage dependency
> tables */
> -
> btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk,
> - &max_sclk_vddc);
> -
> btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk,
> - &max_mclk_vddci);
> -
> btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk,
> - &max_mclk_vddc);
> -
> - if (max_sclk_vddc) {
> - if (ps->low.sclk > max_sclk_vddc)
> - ps->low.sclk = max_sclk_vddc;
> - if (ps->medium.sclk > max_sclk_vddc)
> - ps->medium.sclk = max_sclk_vddc;
> - if (ps->high.sclk > max_sclk_vddc)
> - ps->high.sclk = max_sclk_vddc;
> - }
> - if (max_mclk_vddci) {
> - if (ps->low.mclk > max_mclk_vddci)
> - ps->low.mclk = max_mclk_vddci;
> - if (ps->medium.mclk > max_mclk_vddci)
> - ps->medium.mclk = max_mclk_vddci;
> - if (ps->high.mclk > max_mclk_vddci)
> - ps->high.mclk = max_mclk_vddci;
> - }
> - if (max_mclk_vddc) {
> - if (ps->low.mclk > max_mclk_vddc)
> - ps->low.mclk = max_mclk_vddc;
> - if (ps->medium.mclk > max_mclk_vddc)
> - ps->medium.mclk = max_mclk_vddc;
> - if (ps->high.mclk > max_mclk_vddc)
> - ps->high.mclk = max_mclk_vddc;
> - }
> -
> /* XXX validate the min clocks required for display */
>
> if (disable_mclk_switching) {
> diff --git a/drivers/gpu/drm/radeon/btc_dpm.h
> b/drivers/gpu/drm/radeon/btc_dpm.h
> index 3b6f12b..1a15e0e 100644
> --- a/drivers/gpu/drm/radeon/btc_dpm.h
> +++ b/drivers/gpu/drm/radeon/btc_dpm.h
> @@ -46,8 +46,6 @@ v
[PATCH] drm/radeon: Remove limitation on clock speeds
Now that vddci has been fixed for dpm, we can let the GPUs
use their maximum values when not using the reference ones.
Fixes bug 69721: Can't reach maximum memory speed (or core
speed) when using dpm=1 on r600g on cards not sticking to
reference board
Tested on kernel 3.17-rc7 on a cayman gpu.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/btc_dpm.c | 51
drivers/gpu/drm/radeon/btc_dpm.h | 2 --
drivers/gpu/drm/radeon/ci_dpm.c | 26
drivers/gpu/drm/radeon/ni_dpm.c | 24 ---
drivers/gpu/drm/radeon/si_dpm.c | 24 ---
5 files changed, 127 deletions(-)
diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index f81d7ca..300d971 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.c
+++ b/drivers/gpu/drm/radeon/btc_dpm.c
@@ -1170,23 +1170,6 @@ static const struct radeon_blacklist_clocks
btc_blacklist_clocks[] =
{ 25000, 3, RADEON_SCLK_UP }
};
-void btc_get_max_clock_from_voltage_dependency_table(struct
radeon_clock_voltage_dependency_table *table,
-u32 *max_clock)
-{
- u32 i, clock = 0;
-
- if ((table == NULL) || (table->count == 0)) {
- *max_clock = clock;
- return;
- }
-
- for (i = 0; i < table->count; i++) {
- if (clock < table->entries[i].clk)
- clock = table->entries[i].clk;
- }
- *max_clock = clock;
-}
-
void btc_apply_voltage_dependency_rules(struct
radeon_clock_voltage_dependency_table *table,
u32 clock, u16 max_voltage, u16
*voltage)
{
@@ -2099,7 +2082,6 @@ static void btc_apply_state_adjust_rules(struct
radeon_device *rdev,
bool disable_mclk_switching;
u32 mclk, sclk;
u16 vddc, vddci;
- u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
if ((rdev->pm.dpm.new_active_crtc_count > 1) ||
btc_dpm_vblank_too_short(rdev))
@@ -2141,39 +2123,6 @@ static void btc_apply_state_adjust_rules(struct
radeon_device *rdev,
ps->low.vddci = max_limits->vddci;
}
- /* limit clocks to max supported clocks based on voltage dependency
tables */
-
btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk,
- &max_sclk_vddc);
-
btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk,
- &max_mclk_vddci);
-
btc_get_max_clock_from_voltage_dependency_table(&rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk,
- &max_mclk_vddc);
-
- if (max_sclk_vddc) {
- if (ps->low.sclk > max_sclk_vddc)
- ps->low.sclk = max_sclk_vddc;
- if (ps->medium.sclk > max_sclk_vddc)
- ps->medium.sclk = max_sclk_vddc;
- if (ps->high.sclk > max_sclk_vddc)
- ps->high.sclk = max_sclk_vddc;
- }
- if (max_mclk_vddci) {
- if (ps->low.mclk > max_mclk_vddci)
- ps->low.mclk = max_mclk_vddci;
- if (ps->medium.mclk > max_mclk_vddci)
- ps->medium.mclk = max_mclk_vddci;
- if (ps->high.mclk > max_mclk_vddci)
- ps->high.mclk = max_mclk_vddci;
- }
- if (max_mclk_vddc) {
- if (ps->low.mclk > max_mclk_vddc)
- ps->low.mclk = max_mclk_vddc;
- if (ps->medium.mclk > max_mclk_vddc)
- ps->medium.mclk = max_mclk_vddc;
- if (ps->high.mclk > max_mclk_vddc)
- ps->high.mclk = max_mclk_vddc;
- }
-
/* XXX validate the min clocks required for display */
if (disable_mclk_switching) {
diff --git a/drivers/gpu/drm/radeon/btc_dpm.h b/drivers/gpu/drm/radeon/btc_dpm.h
index 3b6f12b..1a15e0e 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.h
+++ b/drivers/gpu/drm/radeon/btc_dpm.h
@@ -46,8 +46,6 @@ void btc_adjust_clock_combinations(struct radeon_device *rdev,
struct rv7xx_pl *pl);
void btc_apply_voltage_dependency_rules(struct
radeon_clock_voltage_dependency_table *table,
u32 clock, u16 max_voltage, u16
*voltage);
-void btc_get_max_clock_from_voltage_dependency_table(struct
radeon_clock_voltage_dependency_table *table,
-u32 *max_clock);
void btc_apply_voltage_delta_rules(struct radeon_device *rdev,
u16 max_vddc, u16 max_vddci,
[PATCH] Reenabling SS on Cayman
It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that
Cayman is stable since VDDCI fix. Spread spectrum was not the culprit.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/rv770_dpm.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rv770_dpm.c
b/drivers/gpu/drm/radeon/rv770_dpm.c
index da041a4..3c76e1d 100644
--- a/drivers/gpu/drm/radeon/rv770_dpm.c
+++ b/drivers/gpu/drm/radeon/rv770_dpm.c
@@ -2329,12 +2329,6 @@ void rv770_get_engine_memory_ss(struct radeon_device
*rdev)
pi->mclk_ss = radeon_atombios_get_asic_ss_info(rdev, &ss,
ASIC_INTERNAL_MEMORY_SS,
0);
- /* disable ss, causes hangs on some cayman boards */
- if (rdev->family == CHIP_CAYMAN) {
- pi->sclk_ss = false;
- pi->mclk_ss = false;
- }
-
if (pi->sclk_ss || pi->mclk_ss)
pi->dynamic_ss = true;
else
--
2.0.1
Reenable Spread Spectrum on Cayman
Since vddci was the real culprit behind Cayman's dpm problem and now that it is fixed, I've been playing around with kernel 3.16-RC4 and spread spectrum reenabled. So far, no problem and I think it's safe to reenable it for good. Alex, if you share my impression, could you push the following patch? Thanks.
[PATCH] drm/radeon: Cayman - add missing registers
OK, I see. Thanks for the info. Alexandre Demers On Mon 02 Dec 2013 06:45:04 AM EST, Marek Ol??k wrote: > The registers aren't listed because they are not safe and they need to > be checked by the CS checker. > > NAK. > > Marek > > On Mon, Dec 2, 2013 at 8:34 AM, Alexandre Demers > wrote: >> Added some missing registers listed in documentation. >> >> Signed-off-by: Alexandre Demers >> --- >> drivers/gpu/drm/radeon/reg_srcs/cayman | 78 >> +- >> 1 file changed, 67 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman >> b/drivers/gpu/drm/radeon/reg_srcs/cayman >> index ca8896d..596cd62 100644 >> --- a/drivers/gpu/drm/radeon/reg_srcs/cayman >> +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman >> @@ -559,50 +559,106 @@ cayman 0x9400 >> 0x00028C34 PA_SC_AA_SAMPLE_LOCS_PIXEL_X1_Y1_3 >> 0x00028C38 PA_SC_AA_MASK_X0_Y0_X1_Y0 >> 0x00028C3C PA_SC_AA_MASK_X0_Y1_X1_Y1 >> +0x00028C70 CB_COLOR0_INFO >> +0x00028C74 CB_COLOR0_ATTRIB >> 0x00028C78 CB_COLOR0_DIM >> -0x00028CB4 CB_COLOR1_DIM >> -0x00028CF0 CB_COLOR2_DIM >> -0x00028D2C CB_COLOR3_DIM >> -0x00028D68 CB_COLOR4_DIM >> -0x00028DA4 CB_COLOR5_DIM >> -0x00028DE0 CB_COLOR6_DIM >> -0x00028E1C CB_COLOR7_DIM >> -0x00028E58 CB_COLOR8_DIM >> -0x00028E74 CB_COLOR9_DIM >> -0x00028E90 CB_COLOR10_DIM >> -0x00028EAC CB_COLOR11_DIM >> +0x00028C7C CB_COLOR0_CMASK >> +0x00028C80 CB_COLOR0_CMAKS_SLICE >> +0x00028C84 CB_COLOR0_FMASK >> +0x00028C88 CB_COLOR0_FMASK_SLICE >> 0x00028C8C CB_COLOR0_CLEAR_WORD0 >> 0x00028C90 CB_COLOR0_CLEAR_WORD1 >> 0x00028C94 CB_COLOR0_CLEAR_WORD2 >> 0x00028C98 CB_COLOR0_CLEAR_WORD3 >> +0x00028CAC CB_COLOR1_INFO >> +0x00028CB0 CB_COLOR1_ATTRIB >> +0x00028CB4 CB_COLOR1_DIM >> +0x00028CB8 CB_COLOR1_CMASK >> +0x00028CBC CB_COLOR1_CMAKS_SLICE >> +0x00028CC0 CB_COLOR1_FMASK >> +0x00028CC4 CB_COLOR1_FMASK_SLICE >> 0x00028CC8 CB_COLOR1_CLEAR_WORD0 >> 0x00028CCC CB_COLOR1_CLEAR_WORD1 >> 0x00028CD0 CB_COLOR1_CLEAR_WORD2 >> 0x00028CD4 CB_COLOR1_CLEAR_WORD3 >> +0x00028CE8 CB_COLOR2_INFO >> +0x00028CEC CB_COLOR2_ATTRIB >> +0x00028CF0 CB_COLOR2_DIM >> +0x00028CF4 CB_COLOR2_CMASK >> +0x00028CF8 CB_COLOR2_CMAKS_SLICE >> +0x00028CFC CB_COLOR2_FMASK >> +0x00028D00 CB_COLOR2_FMASK_SLICE >> 0x00028D04 CB_COLOR2_CLEAR_WORD0 >> 0x00028D08 CB_COLOR2_CLEAR_WORD1 >> 0x00028D0C CB_COLOR2_CLEAR_WORD2 >> 0x00028D10 CB_COLOR2_CLEAR_WORD3 >> +0x00028D24 CB_COLOR3_INFO >> +0x00028D28 CB_COLOR3_ATTRIB >> +0x00028D2C CB_COLOR3_DIM >> +0x00028D30 CB_COLOR3_CMASK >> +0x00028D34 CB_COLOR3_CMAKS_SLICE >> +0x00028D38 CB_COLOR3_FMASK >> +0x00028D3C CB_COLOR3_FMASK_SLICE >> 0x00028D40 CB_COLOR3_CLEAR_WORD0 >> 0x00028D44 CB_COLOR3_CLEAR_WORD1 >> 0x00028D48 CB_COLOR3_CLEAR_WORD2 >> 0x00028D4C CB_COLOR3_CLEAR_WORD3 >> +0x00028D60 CB_COLOR4_INFO >> +0x00028D64 CB_COLOR4_ATTRIB >> +0x00028D68 CB_COLOR4_DIM >> +0x00028D6C CB_COLOR4_CMASK >> +0x00028D70 CB_COLOR4_CMAKS_SLICE >> +0x00028D74 CB_COLOR4_FMASK >> +0x00028D78 CB_COLOR4_FMASK_SLICE >> 0x00028D7C CB_COLOR4_CLEAR_WORD0 >> 0x00028D80 CB_COLOR4_CLEAR_WORD1 >> 0x00028D84 CB_COLOR4_CLEAR_WORD2 >> 0x00028D88 CB_COLOR4_CLEAR_WORD3 >> +0x00028D9C CB_COLOR5_INFO >> +0x00028DA0 CB_COLOR5_ATTRIB >> +0x00028DA4 CB_COLOR5_DIM >> +0x00028DA8 CB_COLOR5_CMASK >> +0x00028DAC CB_COLOR5_CMAKS_SLICE >> +0x00028DB0 CB_COLOR5_FMASK >> +0x00028DB4 CB_COLOR5_FMASK_SLICE >> 0x00028DB8 CB_COLOR5_CLEAR_WORD0 >> 0x00028DBC CB_COLOR5_CLEAR_WORD1 >> 0x00028DC0 CB_COLOR5_CLEAR_WORD2 >> 0x00028DC4 CB_COLOR5_CLEAR_WORD3 >> +0x00028DD8 CB_COLOR6_INFO >> +0x00028DDC CB_COLOR6_ATTRIB >> +0x00028DE0 CB_COLOR6_DIM >> +0x00028DE4 CB_COLOR6_CMASK >> +0x00028DE8 CB_COLOR6_CMAKS_SLICE >> +0x00028DEC CB_COLOR6_FMASK >> +0x00028DF0 CB_COLOR6_FMASK_SLICE >> 0x00028DF4 CB_COLOR6_CLEAR_WORD0 >> 0x00028DF8 CB_COLOR6_CLEAR_WORD1 >> 0x00028DFC CB_COLOR6_CLEAR_WORD2 >> 0x00028E00 CB_COLOR6_CLEAR_WORD3 >> +0x00028E14 CB_COLOR7_INFO >> +0x00028E18 CB_COLOR7_ATTRIB >> +0x00028E1C CB_COLOR7_DIM >> +0x00028E20 CB_COLOR7_CMASK >> +0x00028E24 CB_COLOR7_CMAKS_SLICE >> +0x00028E28 CB_COLOR7_FMASK >> +0x00028E2C CB_COLOR7_FMASK_SLICE >> 0x00028E30 CB_COLOR7_CLEAR_WORD0 >> 0x00028E34 CB_COLOR7_CLEAR_WORD1 >> 0x00028E38 CB_COLOR7_CLEAR_WORD2 >>
[PATCH] drm/radeon: Cayman - add missing registers
Added some missing registers listed in documentation. Signed-off-by: Alexandre Demers --- drivers/gpu/drm/radeon/reg_srcs/cayman | 78 +- 1 file changed, 67 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index ca8896d..596cd62 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -559,50 +559,106 @@ cayman 0x9400 0x00028C34 PA_SC_AA_SAMPLE_LOCS_PIXEL_X1_Y1_3 0x00028C38 PA_SC_AA_MASK_X0_Y0_X1_Y0 0x00028C3C PA_SC_AA_MASK_X0_Y1_X1_Y1 +0x00028C70 CB_COLOR0_INFO +0x00028C74 CB_COLOR0_ATTRIB 0x00028C78 CB_COLOR0_DIM -0x00028CB4 CB_COLOR1_DIM -0x00028CF0 CB_COLOR2_DIM -0x00028D2C CB_COLOR3_DIM -0x00028D68 CB_COLOR4_DIM -0x00028DA4 CB_COLOR5_DIM -0x00028DE0 CB_COLOR6_DIM -0x00028E1C CB_COLOR7_DIM -0x00028E58 CB_COLOR8_DIM -0x00028E74 CB_COLOR9_DIM -0x00028E90 CB_COLOR10_DIM -0x00028EAC CB_COLOR11_DIM +0x00028C7C CB_COLOR0_CMASK +0x00028C80 CB_COLOR0_CMAKS_SLICE +0x00028C84 CB_COLOR0_FMASK +0x00028C88 CB_COLOR0_FMASK_SLICE 0x00028C8C CB_COLOR0_CLEAR_WORD0 0x00028C90 CB_COLOR0_CLEAR_WORD1 0x00028C94 CB_COLOR0_CLEAR_WORD2 0x00028C98 CB_COLOR0_CLEAR_WORD3 +0x00028CAC CB_COLOR1_INFO +0x00028CB0 CB_COLOR1_ATTRIB +0x00028CB4 CB_COLOR1_DIM +0x00028CB8 CB_COLOR1_CMASK +0x00028CBC CB_COLOR1_CMAKS_SLICE +0x00028CC0 CB_COLOR1_FMASK +0x00028CC4 CB_COLOR1_FMASK_SLICE 0x00028CC8 CB_COLOR1_CLEAR_WORD0 0x00028CCC CB_COLOR1_CLEAR_WORD1 0x00028CD0 CB_COLOR1_CLEAR_WORD2 0x00028CD4 CB_COLOR1_CLEAR_WORD3 +0x00028CE8 CB_COLOR2_INFO +0x00028CEC CB_COLOR2_ATTRIB +0x00028CF0 CB_COLOR2_DIM +0x00028CF4 CB_COLOR2_CMASK +0x00028CF8 CB_COLOR2_CMAKS_SLICE +0x00028CFC CB_COLOR2_FMASK +0x00028D00 CB_COLOR2_FMASK_SLICE 0x00028D04 CB_COLOR2_CLEAR_WORD0 0x00028D08 CB_COLOR2_CLEAR_WORD1 0x00028D0C CB_COLOR2_CLEAR_WORD2 0x00028D10 CB_COLOR2_CLEAR_WORD3 +0x00028D24 CB_COLOR3_INFO +0x00028D28 CB_COLOR3_ATTRIB +0x00028D2C CB_COLOR3_DIM +0x00028D30 CB_COLOR3_CMASK +0x00028D34 CB_COLOR3_CMAKS_SLICE +0x00028D38 CB_COLOR3_FMASK +0x00028D3C CB_COLOR3_FMASK_SLICE 0x00028D40 CB_COLOR3_CLEAR_WORD0 0x00028D44 CB_COLOR3_CLEAR_WORD1 0x00028D48 CB_COLOR3_CLEAR_WORD2 0x00028D4C CB_COLOR3_CLEAR_WORD3 +0x00028D60 CB_COLOR4_INFO +0x00028D64 CB_COLOR4_ATTRIB +0x00028D68 CB_COLOR4_DIM +0x00028D6C CB_COLOR4_CMASK +0x00028D70 CB_COLOR4_CMAKS_SLICE +0x00028D74 CB_COLOR4_FMASK +0x00028D78 CB_COLOR4_FMASK_SLICE 0x00028D7C CB_COLOR4_CLEAR_WORD0 0x00028D80 CB_COLOR4_CLEAR_WORD1 0x00028D84 CB_COLOR4_CLEAR_WORD2 0x00028D88 CB_COLOR4_CLEAR_WORD3 +0x00028D9C CB_COLOR5_INFO +0x00028DA0 CB_COLOR5_ATTRIB +0x00028DA4 CB_COLOR5_DIM +0x00028DA8 CB_COLOR5_CMASK +0x00028DAC CB_COLOR5_CMAKS_SLICE +0x00028DB0 CB_COLOR5_FMASK +0x00028DB4 CB_COLOR5_FMASK_SLICE 0x00028DB8 CB_COLOR5_CLEAR_WORD0 0x00028DBC CB_COLOR5_CLEAR_WORD1 0x00028DC0 CB_COLOR5_CLEAR_WORD2 0x00028DC4 CB_COLOR5_CLEAR_WORD3 +0x00028DD8 CB_COLOR6_INFO +0x00028DDC CB_COLOR6_ATTRIB +0x00028DE0 CB_COLOR6_DIM +0x00028DE4 CB_COLOR6_CMASK +0x00028DE8 CB_COLOR6_CMAKS_SLICE +0x00028DEC CB_COLOR6_FMASK +0x00028DF0 CB_COLOR6_FMASK_SLICE 0x00028DF4 CB_COLOR6_CLEAR_WORD0 0x00028DF8 CB_COLOR6_CLEAR_WORD1 0x00028DFC CB_COLOR6_CLEAR_WORD2 0x00028E00 CB_COLOR6_CLEAR_WORD3 +0x00028E14 CB_COLOR7_INFO +0x00028E18 CB_COLOR7_ATTRIB +0x00028E1C CB_COLOR7_DIM +0x00028E20 CB_COLOR7_CMASK +0x00028E24 CB_COLOR7_CMAKS_SLICE +0x00028E28 CB_COLOR7_FMASK +0x00028E2C CB_COLOR7_FMASK_SLICE 0x00028E30 CB_COLOR7_CLEAR_WORD0 0x00028E34 CB_COLOR7_CLEAR_WORD1 0x00028E38 CB_COLOR7_CLEAR_WORD2 0x00028E3C CB_COLOR7_CLEAR_WORD3 +0x00028E50 CB_COLOR8_INFO +0x00028E54 CB_COLOR8_ATTRIB +0x00028E58 CB_COLOR8_DIM +0x00028E6C CB_COLOR9_INFO +0x00028E70 CB_COLOR9_ATTRIB +0x00028E74 CB_COLOR9_DIM +0x00028E88 CB_COLOR10_INFO +0x00028E8C CB_COLOR10_ATTRIB +0x00028E90 CB_COLOR10_DIM +0x00028EA4 CB_COLOR11_INFO +0x00028EA8 CB_COLOR11_ATTRIB +0x00028EAC CB_COLOR11_DIM 0x00028F80 SQ_ALU_CONST_BUFFER_SIZE_HS_0 0x00028F84 SQ_ALU_CONST_BUFFER_SIZE_HS_1 0x00028F88 SQ_ALU_CONST_BUFFER_SIZE_HS_2 -- 1.8.4.2
[PATCH] drm/radeon: Fix a typo in Cayman and Evergreen registers
According to documentation, 0x8A60 should be PA_SU_LINE_STIPPLE_VALUE. Signed-off-by: Alexandre Demers --- drivers/gpu/drm/radeon/reg_srcs/cayman| 2 +- drivers/gpu/drm/radeon/reg_srcs/evergreen | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index a072fa8..ca8896d 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -21,7 +21,7 @@ cayman 0x9400 0x89AC VGT_COMPUTE_THREAD_GOURP_SIZE 0x89B0 VGT_HS_OFFCHIP_PARAM 0x8A14 PA_CL_ENHANCE -0x8A60 PA_SC_LINE_STIPPLE_VALUE +0x8A60 PA_SU_LINE_STIPPLE_VALUE 0x8B10 PA_SC_LINE_STIPPLE_STATE 0x8BF0 PA_SC_ENHANCE 0x8D8C SQ_DYN_GPR_CNTL_PS_FLUSH_REQ diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen b/drivers/gpu/drm/radeon/reg_srcs/evergreen index b912a37..2513cb2 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen @@ -22,7 +22,7 @@ evergreen 0x9400 0x89A4 VGT_COMPUTE_START_Z 0x89AC VGT_COMPUTE_THREAD_GOURP_SIZE 0x8A14 PA_CL_ENHANCE -0x8A60 PA_SC_LINE_STIPPLE_VALUE +0x8A60 PA_SU_LINE_STIPPLE_VALUE 0x8B10 PA_SC_LINE_STIPPLE_STATE 0x8BF0 PA_SC_ENHANCE 0x8D8C SQ_DYN_GPR_CNTL_PS_FLUSH_REQ -- 1.8.4.2
[PATCH v2] drm/radeon/dpm: simplifying low state adjustment's logic for NI
While working on a dpm bug
(https://bugs.freedesktop.org/show_bug.cgi?id=69723), I stumbled upon a couple
of lines in NI dpm where we were reading and setting back the same values for
no obvious reason. Simplified the logic.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/ni_dpm.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index f263390..2a10bbe 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -841,21 +841,12 @@ static void ni_apply_state_adjust_rules(struct
radeon_device *rdev,
if (disable_mclk_switching) {
mclk = ps->performance_levels[ps->performance_level_count -
1].mclk;
- sclk = ps->performance_levels[0].sclk;
- vddc = ps->performance_levels[0].vddc;
vddci = ps->performance_levels[ps->performance_level_count -
1].vddci;
- } else {
- sclk = ps->performance_levels[0].sclk;
- mclk = ps->performance_levels[0].mclk;
- vddc = ps->performance_levels[0].vddc;
- vddci = ps->performance_levels[0].vddci;
- }
- /* adjusted low state */
- ps->performance_levels[0].sclk = sclk;
- ps->performance_levels[0].mclk = mclk;
- ps->performance_levels[0].vddc = vddc;
- ps->performance_levels[0].vddci = vddci;
+ /* adjusted low state */
+ ps->performance_levels[0].mclk = mclk;
+ ps->performance_levels[0].vddci = vddci;
+ }
btc_skip_blacklist_clocks(rdev, max_limits->sclk, max_limits->mclk,
&ps->performance_levels[0].sclk,
--
1.8.4
[PATCH] simplifying low state adjustment's logic
While working on a dpm bug
(https://bugs.freedesktop.org/show_bug.cgi?id=69723), I stumbled on a couple of
lines where we were reading and setting back the same values for no obvious
reason.
---
drivers/gpu/drm/radeon/ni_dpm.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index f263390..2a10bbe 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -841,21 +841,12 @@ static void ni_apply_state_adjust_rules(struct
radeon_device *rdev,
if (disable_mclk_switching) {
mclk = ps->performance_levels[ps->performance_level_count -
1].mclk;
- sclk = ps->performance_levels[0].sclk;
- vddc = ps->performance_levels[0].vddc;
vddci = ps->performance_levels[ps->performance_level_count -
1].vddci;
- } else {
- sclk = ps->performance_levels[0].sclk;
- mclk = ps->performance_levels[0].mclk;
- vddc = ps->performance_levels[0].vddc;
- vddci = ps->performance_levels[0].vddci;
- }
- /* adjusted low state */
- ps->performance_levels[0].sclk = sclk;
- ps->performance_levels[0].mclk = mclk;
- ps->performance_levels[0].vddc = vddc;
- ps->performance_levels[0].vddci = vddci;
+ /* adjusted low state */
+ ps->performance_levels[0].mclk = mclk;
+ ps->performance_levels[0].vddci = vddci;
+ }
btc_skip_blacklist_clocks(rdev, max_limits->sclk, max_limits->mclk,
&ps->performance_levels[0].sclk,
--
1.8.4
anongit.freedesktop.org not available?
Hi, I've been trying all day to sync sources from anongit.freedesktop.org (dri and mesa) and it always ends up by a time out. Is there a problem with the server or the address? Cheers, -- Alexandre Demers
anongit.freedesktop.org not available?
Hi, I've been trying all day to sync sources from anongit.freedesktop.org (dri and mesa) and it always ends up by a time out. Is there a problem with the server or the address? Cheers, -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: silence out possible lock dependency warning
I suppose I can stop bisecting kernel about this possible lock and close the bug then? -- Alexandre Demers
Re: [PATCH] drm/radeon: silence out possible lock dependency warning
I suppose I can stop bisecting kernel about this possible lock and close the bug then? -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec
My two cents here: I'm experiencing the same problem. I've noticed there was a problem earlier in the boot process where the kernel was crying about a deadlock in radeon power management. I opened a bug and I'm bisecting the kernel right now ( https://bugzilla.kernel.org/show_bug.cgi?id=42639). It may or may not be related, but both problems appeared when moving to 3.3-rc1. -- Alexandre Demers -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120123/8d55bb2d/attachment.html>
Re: [3.3-rc1]radeon 0000:07:00.0: GPU lockup CP stall for more than 10000msec
My two cents here: I'm experiencing the same problem. I've noticed there was a problem earlier in the boot process where the kernel was crying about a deadlock in radeon power management. I opened a bug and I'm bisecting the kernel right now ( https://bugzilla.kernel.org/show_bug.cgi?id=42639). It may or may not be related, but both problems appeared when moving to 3.3-rc1. -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Why does libdrm-intel needs libpciaccess?
Here is a simple question I couldn't find an answer for: why does libdrm-intel needs libpciaccess to be build? It is the only drm driver requiering it.
Why does libdrm-intel needs libpciaccess?
Here is a simple question I couldn't find an answer for: why does libdrm-intel needs libpciaccess to be build? It is the only drm driver requiering it. >From what I understand, and correct me if I'm wrong, but libpciaccess is related to X. And drm should be able to live without X. So why would libdrm-intel rely on libpciaccess/X to be build? I'm sure we could do without it, since all other drivers do. As things are right now, would that imply using a X lib to build libdrm-intel and then use it with Wayland for instance? Isn't Wayland supposed to be able to run completly without X? Cheers, -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 2.6.39-rc3
On 11-04-15 10:27 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of >> the other patches? > Yes, apply it just on -rc3 without any other patch. > >> BTW, may I suggest adding the info under bug 33012 in kernel bugzilla? >> This could be useful in the future. > Cool, thanks > > > Joerg The patch was applied and tested. It looks fine, I'm able to boot without problem. -- Alexandre Demers
Re: Linux 2.6.39-rc3
On 11-04-15 10:27 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of >> the other patches? > Yes, apply it just on -rc3 without any other patch. > >> BTW, may I suggest adding the info under bug 33012 in kernel bugzilla? >> This could be useful in the future. > Cool, thanks > > > Joerg The patch was applied and tested. It looks fine, I'm able to boot without problem. -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 2.6.39-rc3
On 11-04-15 09:11 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
>> we definitely want to also understand the reason for things not
>> working, even if we do revert..
> Okay, here it is.
>
> After experimenting with different configurations for the north-bridge
> it turned out that a GART related MCE fires at the time the machine
> reboots. BIOSes configure the machine to sync-flood in that case which
> causes a reboot.
>
> After decoding the MCE it turned out to be a GART TBL Wlk Error. Such
> errors can happen if devices (speculativly) access GART ranges mapped
> invalid. The AMD BKDG for Fam10h CPUs recommends to disable these errors
> at all. But unfortunatly some BIOSes (including the one on my laptop)
> forget to do this.
>
> Below is a patch which disables these errors if the BIOS didn't do it.
> It fixes the problem on my site.
>
> Alexandre, can you try this patch on your machine too, please?
>
> Regards,
>
> Joerg
>
> From aaacff8db50b6ed4345e337ecbe53e505699c7e5 Mon Sep 17 00:00:00 2001
> From: Joerg Roedel
> Date: Fri, 15 Apr 2011 14:47:40 +0200
> Subject: [PATCH] x86/amd: Disable GartTlbWlkErr when BIOS forgets it
>
> This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
> the BIOS forgets to do is (or is just too old). Letting
> these errors enabled can cause a sync-flood on the CPU
> causing a reboot.
>
> This patch is the fix for
>
> https://bugzilla.kernel.org/show_bug.cgi?id=33012
>
> on my machine.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/msr-index.h |4
> arch/x86/kernel/cpu/amd.c| 19 +++
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index fd5a1f3..3cce714 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -96,11 +96,15 @@
> #define MSR_IA32_MC0_ADDR0x0402
> #define MSR_IA32_MC0_MISC0x0403
>
> +#define MSR_AMD64_MC0_MASK 0xc0010044
> +
> #define MSR_IA32_MCx_CTL(x) (MSR_IA32_MC0_CTL + 4*(x))
> #define MSR_IA32_MCx_STATUS(x) (MSR_IA32_MC0_STATUS + 4*(x))
> #define MSR_IA32_MCx_ADDR(x) (MSR_IA32_MC0_ADDR + 4*(x))
> #define MSR_IA32_MCx_MISC(x) (MSR_IA32_MC0_MISC + 4*(x))
>
> +#define MSR_AMD64_MCx_MASK(x)(MSR_AMD64_MC0_MASK + (x))
> +
> /* These are consecutive and not in the normal 4er MCE bank block */
> #define MSR_IA32_MC0_CTL20x0280
> #define MSR_IA32_MCx_CTL2(x) (MSR_IA32_MC0_CTL2 + (x))
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 3ecece0..3532d3b 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -615,6 +615,25 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> /* As a rule processors have APIC timer running in deep C states */
> if (c->x86 >= 0xf && !cpu_has_amd_erratum(amd_erratum_400))
> set_cpu_cap(c, X86_FEATURE_ARAT);
> +
> + /*
> + * Disable GART TLB Walk Errors on Fam10h. We do this here
> + * because this is always needed when GART is enabled, even in a
> + * kernel which has no MCE support built in.
> + */
> + if (c->x86 == 0x10) {
> + /*
> + * BIOS should disable GartTlbWlk Errors themself. If
> + * it doesn't do it here as suggested by the BKDG.
> + *
> + * Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33012
> + */
> + u64 mask;
> +
> + rdmsrl(MSR_AMD64_MCx_MASK(4), mask);
> + mask |= (1 << 10);
> + wrmsrl(MSR_AMD64_MCx_MASK(4), mask);
> + }
> }
>
> #ifdef CONFIG_X86_32
Ok, I'll test it today. Should I apply it on a clean rc3 without any of
the other patches?
BTW, may I suggest adding the info under bug 33012 in kernel bugzilla?
This could be useful in the future.
I'll keep you up to date.
--
Alexandre Demers
Re: Linux 2.6.39-rc3
On 11-04-15 09:11 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
>> we definitely want to also understand the reason for things not
>> working, even if we do revert..
> Okay, here it is.
>
> After experimenting with different configurations for the north-bridge
> it turned out that a GART related MCE fires at the time the machine
> reboots. BIOSes configure the machine to sync-flood in that case which
> causes a reboot.
>
> After decoding the MCE it turned out to be a GART TBL Wlk Error. Such
> errors can happen if devices (speculativly) access GART ranges mapped
> invalid. The AMD BKDG for Fam10h CPUs recommends to disable these errors
> at all. But unfortunatly some BIOSes (including the one on my laptop)
> forget to do this.
>
> Below is a patch which disables these errors if the BIOS didn't do it.
> It fixes the problem on my site.
>
> Alexandre, can you try this patch on your machine too, please?
>
> Regards,
>
> Joerg
>
> From aaacff8db50b6ed4345e337ecbe53e505699c7e5 Mon Sep 17 00:00:00 2001
> From: Joerg Roedel
> Date: Fri, 15 Apr 2011 14:47:40 +0200
> Subject: [PATCH] x86/amd: Disable GartTlbWlkErr when BIOS forgets it
>
> This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
> the BIOS forgets to do is (or is just too old). Letting
> these errors enabled can cause a sync-flood on the CPU
> causing a reboot.
>
> This patch is the fix for
>
> https://bugzilla.kernel.org/show_bug.cgi?id=33012
>
> on my machine.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/msr-index.h |4
> arch/x86/kernel/cpu/amd.c| 19 +++
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index fd5a1f3..3cce714 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -96,11 +96,15 @@
> #define MSR_IA32_MC0_ADDR0x0402
> #define MSR_IA32_MC0_MISC0x0403
>
> +#define MSR_AMD64_MC0_MASK 0xc0010044
> +
> #define MSR_IA32_MCx_CTL(x) (MSR_IA32_MC0_CTL + 4*(x))
> #define MSR_IA32_MCx_STATUS(x) (MSR_IA32_MC0_STATUS + 4*(x))
> #define MSR_IA32_MCx_ADDR(x) (MSR_IA32_MC0_ADDR + 4*(x))
> #define MSR_IA32_MCx_MISC(x) (MSR_IA32_MC0_MISC + 4*(x))
>
> +#define MSR_AMD64_MCx_MASK(x)(MSR_AMD64_MC0_MASK + (x))
> +
> /* These are consecutive and not in the normal 4er MCE bank block */
> #define MSR_IA32_MC0_CTL20x0280
> #define MSR_IA32_MCx_CTL2(x) (MSR_IA32_MC0_CTL2 + (x))
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 3ecece0..3532d3b 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -615,6 +615,25 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> /* As a rule processors have APIC timer running in deep C states */
> if (c->x86 >= 0xf && !cpu_has_amd_erratum(amd_erratum_400))
> set_cpu_cap(c, X86_FEATURE_ARAT);
> +
> + /*
> + * Disable GART TLB Walk Errors on Fam10h. We do this here
> + * because this is always needed when GART is enabled, even in a
> + * kernel which has no MCE support built in.
> + */
> + if (c->x86 == 0x10) {
> + /*
> + * BIOS should disable GartTlbWlk Errors themself. If
> + * it doesn't do it here as suggested by the BKDG.
> + *
> + * Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33012
> + */
> + u64 mask;
> +
> + rdmsrl(MSR_AMD64_MCx_MASK(4), mask);
> + mask |= (1 << 10);
> + wrmsrl(MSR_AMD64_MCx_MASK(4), mask);
> + }
> }
>
> #ifdef CONFIG_X86_32
Ok, I'll test it today. Should I apply it on a clean rc3 without any of
the other patches?
BTW, may I suggest adding the info under bug 33012 in kernel bugzilla?
This could be useful in the future.
I'll keep you up to date.
--
Alexandre Demers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 2.6.39-rc3
Already tracking it here: https://bugzilla.kernel.org/show_bug.cgi?id=33012 Same problem, same culprit commit. -- Alexandre Demers
Re: Linux 2.6.39-rc3
Already tracking it here: https://bugzilla.kernel.org/show_bug.cgi?id=33012 Same problem, same culprit commit. -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Radeon support state in libkms
On 11-02-11 06:21 AM, Jakob Bornecrantz wrote: > On Wed, Feb 9, 2011 at 7:35 PM, Corbin Simpson > wrote: >> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons >> wrote: >>>> I was looking at the radeon support state in libkms and I found out the >>>> following patch was proposed back in September, but never commented nor >>>> merged. The patch was submitted by nobled. >>>> >>>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html >>>> >>>> I applied it on the latest drm git version without any problem and >>>> compilation looks fine. Is there a reason preventing it from being merged? >>>> >>>> If it needs testing, make your suggestion, I'll gladly make my best to >>>> test it. >>> Good point. Is KMS dead? Anyone? >> I was seriously hoping that Dave's dumb buffer API would go upstream >> and that libkms would be able to use that generic path for all KMS >> drivers, rather than needing shim code for every driver it supports. >> >> That said, yeah, the libkms maintainer probably should pull that code >> in. Who is that, anyway? >> >> ~ C. > That would probably be me. > > The "core" libkms changes are rb/acked and the radeon changes looks > good so just go ahead and commit them anyways. Nobled do you have > commit access to the drm repo? > > Cheers Jakob. I don't think Nobled has commit access. But to be sure, I'm adding it to the conversation. ;) -- Alexandre Demers
Re: Radeon support state in libkms
On 11-02-11 06:21 AM, Jakob Bornecrantz wrote: > On Wed, Feb 9, 2011 at 7:35 PM, Corbin Simpson > wrote: >> On Wed, Feb 9, 2011 at 6:49 AM, James Simmons wrote: >>>> I was looking at the radeon support state in libkms and I found out the >>>> following patch was proposed back in September, but never commented nor >>>> merged. The patch was submitted by nobled. >>>> >>>> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html >>>> >>>> I applied it on the latest drm git version without any problem and >>>> compilation looks fine. Is there a reason preventing it from being merged? >>>> >>>> If it needs testing, make your suggestion, I'll gladly make my best to >>>> test it. >>> Good point. Is KMS dead? Anyone? >> I was seriously hoping that Dave's dumb buffer API would go upstream >> and that libkms would be able to use that generic path for all KMS >> drivers, rather than needing shim code for every driver it supports. >> >> That said, yeah, the libkms maintainer probably should pull that code >> in. Who is that, anyway? >> >> ~ C. > That would probably be me. > > The "core" libkms changes are rb/acked and the radeon changes looks > good so just go ahead and commit them anyways. Nobled do you have > commit access to the drm repo? > > Cheers Jakob. I don't think Nobled has commit access. But to be sure, I'm adding it to the conversation. ;) -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Radeon support state in libkms
Hi, I was looking at the radeon support state in libkms and I found out the following patch was proposed back in September, but never commented nor merged. The patch was submitted by nobled. http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html I applied it on the latest drm git version without any problem and compilation looks fine. Is there a reason preventing it from being merged? If it needs testing, make your suggestion, I'll gladly make my best to test it. -- Alexandre Demers
Radeon support state in libkms
Hi, I was looking at the radeon support state in libkms and I found out the following patch was proposed back in September, but never commented nor merged. The patch was submitted by nobled. http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html I applied it on the latest drm git version without any problem and compilation looks fine. Is there a reason preventing it from being merged? If it needs testing, make your suggestion, I'll gladly make my best to test it. -- Alexandre Demers ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
