From: Lauri Peltonen
Notify interrupt is only used for cyclestats. We can just clear it and
avoid an "unknown stat" error that gets printed to dmesg otherwise.
Signed-off-by: Lauri Peltonen
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/gr/gf100.c | 9 +
1 file changed,
User-space use mappable BOs notably for fences, and expects that a
value update by the GPU will be immediatly visible through the
user-space mapping.
ARM has a property that may prevent this from happening though: memory
can be mapped multiple times only if the different mappings share the
same ca
Use the roundup() macro to make code easier to read and fix a warning
when the driver is compiled for 64 bit architectures.
Signed-off-by: Alexandre Courbot
---
Ben, this should probably be squashed into patch 6/6 of my "RAM device
removal & IOMMU support" series, since it is not merged yet.
dr
https://bugs.freedesktop.org/show_bug.cgi?id=80901
--- Comment #33 from Martin Peres ---
Hey guys,
I may finally have managed to reproduce your bug. To check that, I need you to
install envytools and send me the result of the following command:
nvapeek e114 10
When selecting the manual fan man
On 25-02-15 15:14, Emil Velikov wrote:
> On 24 February 2015 at 09:01, Maarten Lankhorst
> wrote:
>> While I've closed off most races in a previous patch, a small race still
>> existed
>> where importing then unreffing cound cause an invalid bo. Add a test for
>> this case.
>>
>> Racing sequen
https://bugs.freedesktop.org/show_bug.cgi?id=70972
--- Comment #13 from ade ---
I tried the nv driver and it did not list any resolutions above 1024x768, so I
could not find out if it would work at 1280x800.
--
You are receiving this mail because:
You are the assignee for the bug.
_
On Wed, Feb 25, 2015 at 11:55 AM, Maarten Lankhorst <
maarten.lankho...@canonical.com> wrote:
>
>
> On 25-02-15 18:26, Patrick Baggett wrote:
> >>
> >>
> >> In general things don't get optimized across function calls, except in
> >> case of inlinable functions.
> >>
> >> And for compiler attribute
On 25-02-15 18:26, Patrick Baggett wrote:
>>
>>
>> In general things don't get optimized across function calls, except in
>> case of inlinable functions.
>>
>> And for compiler attributes it's the opposite,__attribute__((const)) and
>> __attribute((pure)) can be used to indicate some kind of safe
>
>
> In general things don't get optimized across function calls, except in
> case of inlinable functions.
>
> And for compiler attributes it's the opposite,__attribute__((const)) and
> __attribute((pure)) can be used to indicate some kind of safety to optimize
> across functions.
>
> https://gcc.
Hey,
On 25-02-15 18:05, Ilia Mirkin wrote:
> On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett
> wrote:
>>> If code like
>>>
>>> x = *a;
>>> pthread_mutex_lock or unlock or __memory_barrier()
>>> y = *a;
>>>
>>> doesn't cause a to get loaded twice, then the compiler's in serious
>>> trouble. Basi
https://bugs.freedesktop.org/show_bug.cgi?id=72180
--- Comment #41 from Cedric Brandenbourger ---
Hi, i'm back again
I found the solution here for ubuntu and debian (it's working for BIOS and
UEFI)
https://bugs.launchpad.net/ubuntu/+source/nouveau-firmware/+bug/1309134
--
You are receiving t
On Wed, Feb 25, 2015 at 11:59 AM, Patrick Baggett
wrote:
>> If code like
>>
>> x = *a;
>> pthread_mutex_lock or unlock or __memory_barrier()
>> y = *a;
>>
>> doesn't cause a to get loaded twice, then the compiler's in serious
>> trouble. Basically functions like pthread_mutex_lock imply that all
>
On Wed, Feb 25, 2015 at 10:35 AM, Ilia Mirkin wrote:
> pthread_mutex_lock had *better* imply a compiler barrier across which
> code can't be moved... which is very different from the printf case
> where it might have done it due to register pressure or who knows
> what.
>
In the dummy function, r
pthread_mutex_lock had *better* imply a compiler barrier across which
code can't be moved... which is very different from the printf case
where it might have done it due to register pressure or who knows
what.
If code like
x = *a;
pthread_mutex_lock or unlock or __memory_barrier()
y = *a;
doesn'
https://bugs.freedesktop.org/show_bug.cgi?id=61731
--- Comment #16 from Kyle Auble ---
(In reply to Tobias Klausmann from comment #15)
> Is this still a problem with a recent kernel? (3.17/3.18)
I was actually trying to debug this driver-loading problem on & off for a
while, and while I won't be
So you're saying a compiler can optimize:
>
> - statement with memory access
> - read memory barrier
> - statement with memory access
>
> To drop the second statement? I would worry about your definition of
> memory barrier then..
>
This is tricky, but I think you're mixing up the general case wit
On 25 February 2015 at 15:43, Maarten Lankhorst
wrote:
> Op 25-02-15 om 16:28 schreef Patrick Baggett:
>> On Wed, Feb 25, 2015 at 9:07 AM, Maarten Lankhorst <
>> maarten.lankho...@ubuntu.com> wrote:
>>
>>> Op 25-02-15 om 16:04 schreef Patrick Baggett:
On Wed, Feb 25, 2015 at 8:59 AM, Maarten
Op 25-02-15 om 16:28 schreef Patrick Baggett:
> On Wed, Feb 25, 2015 at 9:07 AM, Maarten Lankhorst <
> maarten.lankho...@ubuntu.com> wrote:
>
>> Op 25-02-15 om 16:04 schreef Patrick Baggett:
>>> On Wed, Feb 25, 2015 at 8:59 AM, Maarten Lankhorst <
>>> maarten.lankho...@ubuntu.com> wrote:
>>>
O
On Wed, Feb 25, 2015 at 9:07 AM, Maarten Lankhorst <
maarten.lankho...@ubuntu.com> wrote:
> Op 25-02-15 om 16:04 schreef Patrick Baggett:
> > On Wed, Feb 25, 2015 at 8:59 AM, Maarten Lankhorst <
> > maarten.lankho...@ubuntu.com> wrote:
> >
> >> Op 25-02-15 om 15:11 schreef Emil Velikov:
> >>> On 2
On Wed, Feb 25, 2015 at 8:59 AM, Maarten Lankhorst <
maarten.lankho...@ubuntu.com> wrote:
> Op 25-02-15 om 15:11 schreef Emil Velikov:
> > On 24 February 2015 at 09:01, Maarten Lankhorst
> > wrote:
> >> Only add wrapped bo's and bo's that have been exported through flink or
> dma-buf.
> >> This a
Op 25-02-15 om 16:04 schreef Patrick Baggett:
> On Wed, Feb 25, 2015 at 8:59 AM, Maarten Lankhorst <
> maarten.lankho...@ubuntu.com> wrote:
>
>> Op 25-02-15 om 15:11 schreef Emil Velikov:
>>> On 24 February 2015 at 09:01, Maarten Lankhorst
>>> wrote:
Only add wrapped bo's and bo's that have b
Op 25-02-15 om 15:11 schreef Emil Velikov:
> On 24 February 2015 at 09:01, Maarten Lankhorst
> wrote:
>> Only add wrapped bo's and bo's that have been exported through flink or
>> dma-buf.
>> This avoids a lock in the common case, and decreases traversal needed for
>> importing
>> a dma-buf or f
On 24 February 2015 at 09:01, Maarten Lankhorst
wrote:
> While I've closed off most races in a previous patch, a small race still
> existed
> where importing then unreffing cound cause an invalid bo. Add a test for this
> case.
>
> Racing sequence fixed:
>
> - thread 1 releases bo, refcount drop
On 24 February 2015 at 09:01, Maarten Lankhorst
wrote:
> Only add wrapped bo's and bo's that have been exported through flink or
> dma-buf.
> This avoids a lock in the common case, and decreases traversal needed for
> importing
> a dma-buf or flink.
>
> Signed-off-by: Maarten Lankhorst
> ---
>
Hello Nouveau devolpers,
can you please tell me if HDMI2.0 is supported ?
I use a GTX960 which supports 3840x2160@50Hz in Windows but Nvidia Linux
driver 346.35 only allows 30Hz.
Is there a chance with nouveau ?
Thanks
Thomas
___
Nouveau mailing lis
While I've closed off most races in a previous patch, a small race still existed
where importing then unreffing cound cause an invalid bo. Add a test for this
case.
Racing sequence fixed:
- thread 1 releases bo, refcount drops to zero, blocks on acquiring nvdev->lock.
- thread 2 increases refcou
26 matches
Mail list logo
