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.
Alexandr
---
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_COLO
---
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
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
&g
PP" 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: ..
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. Th
n someone who would already be interested in doing so.
Any comments on the matter? Any missunderstood thing?
Cheers!
--
Alexandre Demers
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
mask() is
about.
Is this patch linked to a specific bug?
Alexandre Demers
or lower than expected or the value
would have been nonsense).
Thanks,
Alexandre Demers
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 "Test
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
n 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/gp
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
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 pat
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
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
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
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
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 deletio
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
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-
I suppose I can stop bisecting kernel about this possible lock and close
the bug then?
--
Alexandre Demers
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
ug.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>
ug.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
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.
etly without X?
Cheers,
--
Alexandre Demers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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.
>
>&g
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.
>
>&g
*/
> + 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
*/
> + 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 t
Already tracking it here: https://bugzilla.kernel.org/show_bug.cgi?id=33012
Same problem, same culprit commit.
--
Alexandre Demers
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
iner 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
bly 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 acce
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
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-
38 matches
Mail list logo
