On Wed, May 20, 2015 at 3:53 PM, Martin Peres wrote:
> On 20/05/15 08:11, Alexandre Courbot wrote:
>>
>> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
>> wrote:
>>>
>>> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
Re-pinging Marteen on an email address that still exists :P
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectur
On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote:
> On 21 May 2015 at 15:49, Alexandre Courbot wrote:
>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
>>> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
Add a module option allowing to enable staging/unstable APIs. This will
al
On Fri, May 15, 2015 at 2:37 PM, Ben Skeggs wrote:
> On 12 May 2015 at 19:04, Alexandre Courbot wrote:
>> Hi Ben,
>>
>> On Fri, May 1, 2015 at 8:01 AM, Ben Skeggs wrote:
>>> On 13 April 2015 at 20:42, Alexandre Courbot wrote:
Ben, I guess our main remaining concern with this patch is how i
On 21 May 2015 at 15:49, Alexandre Courbot wrote:
> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
>> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
>>> Add a module option allowing to enable staging/unstable APIs. This will
>>> allow us to experiment freely with experimental APIs for a w
On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
>> Add a module option allowing to enable staging/unstable APIs. This will
>> allow us to experiment freely with experimental APIs for a while before
>> setting them in stone.
>>
>> Signed-off-b
https://bugs.freedesktop.org/show_bug.cgi?id=89558
--- Comment #32 from Ben Skeggs ---
(In reply to Ben Skeggs from comment #31)
> (In reply to Ben Skeggs from comment #30)
> > (In reply to SMF from comment #27)
> > > I have noticed that if the nouveau module is removed and re-added the
> > > se
https://bugs.freedesktop.org/show_bug.cgi?id=89558
--- Comment #31 from Ben Skeggs ---
(In reply to Ben Skeggs from comment #30)
> (In reply to SMF from comment #27)
> > I have noticed that if the nouveau module is removed and re-added the second
> > instance calculated the VRAM size correctly:
>
https://bugs.freedesktop.org/show_bug.cgi?id=89558
--- Comment #30 from Ben Skeggs ---
(In reply to SMF from comment #27)
> I have noticed that if the nouveau module is removed and re-added the second
> instance calculated the VRAM size correctly:
>
> modprobe nouveau;rmmod nouveau;modprobe nouv
On 20 May 2015 at 15:56, Alexandre Courbot wrote:
> Add a module option allowing to enable staging/unstable APIs. This will
> allow us to experiment freely with experimental APIs for a while before
> setting them in stone.
>
> Signed-off-by: Alexandre Courbot
> ---
> drm/nouveau/nouveau_drm.c
On 21 May 2015 at 06:01, Ilia Mirkin wrote:
> Some newer chips have trouble coming up, and we get bad MMIO reads from
> them, like 0xbadf100. This ends up translating into crazy amounts of
> VRAM, which destroys all sorts of other logic down the line. Instead,
> fail device init.
Hrm, I'm not sure
On 21 May 2015 at 11:04, Lars Seipel wrote:
> Commit 3740c82590d8 ("drm/nouveau/gr/gf100-: add symbolic names for
> classes") introduced a wrong macro definition causing acceleration setup
> to fail. Fix it.
Oops, my apologies. I've merged the patch.
Thanks,
Ben.
>
> Signed-off-by: Lars Seipel
On 21 May 2015 at 03:26, Samuel Pitoiset wrote:
>
>
> On 05/20/2015 07:13 PM, Ilia Mirkin wrote:
>>
>> This is obviously a bug, but one that has been there for some time.
>> Please figure out what this is guarding, and confirm that the feature
>> continues to work.
>
>
> Sure, but do you have any
Commit 3740c82590d8 ("drm/nouveau/gr/gf100-: add symbolic names for
classes") introduced a wrong macro definition causing acceleration setup
to fail. Fix it.
Signed-off-by: Lars Seipel
Fixes: 3740c82590d8 ("drm/nouveau/gr/gf100-: add symbolic names for classes")
---
drivers/gpu/drm/nouveau/inclu
https://bugs.freedesktop.org/show_bug.cgi?id=90306
--- Comment #6 from Lars Seipel ---
Turns out the issue was introduced with:
commit 3740c82590d87714b41b8b48bd3062178cbe0b17
Author: Ben Skeggs
Date: Thu Mar 26 09:18:32 2015 +1000
drm/nouveau/gr/gf100-: add symbolic names for classes
2015-05-20 17:00 GMT-06:00 Ilia Mirkin :
> On Wed, May 20, 2015 at 4:24 PM, Alex Henrie wrote:
>> Greetings Nouveau developers,
>>
>> It's been a while since I've sent any hardware your way. I feel that
>> Nouveau is one of the most important pieces of software holding Linux
>> back,
>
> That's ce
On Wed, May 20, 2015 at 4:24 PM, Alex Henrie wrote:
> Greetings Nouveau developers,
>
> It's been a while since I've sent any hardware your way. I feel that
> Nouveau is one of the most important pieces of software holding Linux
> back,
That's certainly a funny way of putting it. If that were tru
There is no such list. There was a page a long while ago on the wiki
which had people's descriptions of how nouveau worked on their hw. It
was in a constant state of extreme out-of-dateness. I wanted to create
a "trusted tester" list somewhere, but... ran out of steam. That was
like 1.5y ago. (I wa
I haven't something which looks like a nouveau tester mailing list here
http://lists.freedesktop.org/mailman/listinfo
If such mailing list exists, could you give me a link of it?
Cheers.
Caocoa
> Hello,
>
>> On 20 May 2015, at 22:57, cao...@mail2tor.com wrote:
>>
>> By the way,
>> Is there any pl
Someone will have to trudge through a mmiotrace and figure out what
magic bit we need to set in order to bring it out of deep sleep. Or
perhaps NVIDIA will graciously tell us, which they eventually did for
GK104/GK106 (but their instructions appear to be insufficient for at
least some GK106's).
Bu
Any idea on how to solve the problem. other than just reporting it?
But for now this adds a helpful error message... you may add my R-b.
On 20.05.2015 22:01, Ilia Mirkin wrote:
Some newer chips have trouble coming up, and we get bad MMIO reads from
them, like 0xbadf100. This ends up translating
Hello,
> On 20 May 2015, at 22:57, cao...@mail2tor.com wrote:
>
> By the way,
> Is there any place where nouveau users can show their configuration (or at
> least their GPU)? It might be useful if developers need to know how a
> given GPU responds to their code.
What has be done so far, is that
By the way,
Is there any place where nouveau users can show their configuration (or at
least their GPU)? It might be useful if developers need to know how a
given GPU responds to their code.
> Greetings Nouveau developers,
>
> It's been a while since I've sent any hardware your way. I feel that
>
Greetings Nouveau developers,
It's been a while since I've sent any hardware your way. I feel that
Nouveau is one of the most important pieces of software holding Linux
back, and I'm happy to support you. If you send me a very specific
list of cards, boards, etc. that you want or need, I'll see wh
Some newer chips have trouble coming up, and we get bad MMIO reads from
them, like 0xbadf100. This ends up translating into crazy amounts of
VRAM, which destroys all sorts of other logic down the line. Instead,
fail device init.
Signed-off-by: Ilia Mirkin
Cc: sta...@kernel.org
---
drm/nouveau/nv
https://bugs.freedesktop.org/show_bug.cgi?id=70972
--- Comment #19 from adlo ---
Could anyone assist with analysing my mmiotrace?
--
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=70972
adlo changed:
What|Removed |Added
Attachment #115254|mmiotrace_GeForce_7150M_nFo |mmiotrace_GeForce_7150M_nFo
filename|rc
On 05/20/2015 07:13 PM, Ilia Mirkin wrote:
This is obviously a bug, but one that has been there for some time.
Please figure out what this is guarding, and confirm that the feature
continues to work.
Sure, but do you have any ideas how to test this part of the DDX ?
It's the first time I play
This is obviously a bug, but one that has been there for some time.
Please figure out what this is guarding, and confirm that the feature
continues to work.
On Wed, May 20, 2015 at 1:11 PM, Tobias Klausmann
wrote:
> looks good to me! :)
>
> Feel free to add my R-b.
>
> On 20.05.2015 17:08, Samuel
looks good to me! :)
Feel free to add my R-b.
On 20.05.2015 17:08, Samuel Pitoiset wrote:
This is probably a typo error which has been introduced in 2009...
This fixes the following warning detected by Clang :
drmmode_display.c:907:30: warning: use of logical '&&' with constant operand
[-Wcon
This is probably a typo error which has been introduced in 2009...
This fixes the following warning detected by Clang :
drmmode_display.c:907:30: warning: use of logical '&&' with constant operand
[-Wconstant-logical-operand]
if (props && (props->flags && DRM_MODE_PROP_ENUM)) {
Signed-off-by
Ok thanks, I'll keep to it for now. Would you like me to (try to) fill a
bug report report for that?
By the way, if you come to work on that bug, I'll be glad to experiment
your solution on my machine :)
Caocoa
> On 18.05.2015 01:46, Ilia Mirkin wrote:
>> Your errors are most likely due to:
>>
>>
32 matches
Mail list logo
