On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong wrote:
>
> The bug is here:
> return encoder;
>
> The list iterator value 'encoder' will *always* be set and non-NULL
> by drm_for_each_encoder_mask(), so it is incorrect to assume that the
> iterator value will be NULL if the list is empty or no
On Mon, 28 Mar 2022 at 03:09, Xiaomeng Tong wrote:
>
> on Sun, 27 Mar 2022 16:59:28 +0100, Emil Velikov wrote:
> > On Sun, 27 Mar 2022 at 08:39, Xiaomeng Tong wrote:
> > >
> > > The bug is here:
> > > return encoder;
> > >
> > > T
On Mon, 11 May 2020 at 21:43, Dave Airlie wrote:
>
> On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
> >
> > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir
> > wrote:
> > >
> > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > > Hi guys,
> > >
> > > > Well let's face it AGP i
On Tue, 12 May 2020 at 20:48, Alex Deucher wrote:
> > >>
> > >> There's some AGP support code in the DRM core. Can some of that declared
> > >> as legacy?
> > >>
> > >> Specifically, what about these AGP-related ioctl calls? Can they be
> > >> declared as legacy? It would appear to me that KMS-ba
ff-by: Thierry Reding
Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation
based on available FW")
Reviewed-by: Emil Velikov
-Emil
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote:
>
> It's 0.
>
I'd add a bit more information here. Feel free to reuse as much/little
of the following:
Both macros evaluate to 0. At the same time flag is already set to
zero since the struct is kzalloc'd in framebuffer_alloc().
As called by drm_
From: Emil Velikov
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 --
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
3 files changed, 1 insertion(+), 8 deletions
On 2019/05/23, Ben Skeggs wrote:
> On Thu, 23 May 2019 at 01:03, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > Cc: Ben Skeggs
> > Cc: nouveau@lists.freedesktop.org
> > Signed-off-by: Emil Velikov
> Thanks!
>
Forgot to mention, any objectio
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- legacy DRI1 ioctl, which is already neutered
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
&
On 2019/06/14, Daniel Vetter wrote:
> Split out to make the functional changes stick out more.
>
Since this patch flew-by, as standalone one (intentionally or not) I'd
add, anything vaguely like:
"Core users of DRIVER_PRIME were removed from core with prior patches."
HTH
Emil
Some weird interaction with disabling the i2c access, in the following
patch perhaps?
commit cd68344b283174a9b38e9488d5a929464e1f417c
Author: Lyude Paul
Date: Tue Apr 9 16:23:30 2019 -0400
drm/nouveau/i2c: Disable i2c bus access after ->fini()
On Sun, 16 Jun 2019 at 15:28, Ilia Mirkin wr
d files, and most
> are header files anyways.
>
All of my glorious 23 patches to nouveau are meant to be under MIT.
Acked-by: Emil Velikov
> Another change might be to add the SPDX identifier to files *with*
> the MIT boilerplate, but I didn't want to do
uveau_drm *drm = nouveau_drm(dev);
> struct nvkm_i2c_aux *aux;
> u8 dpcd[8];
> + u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {0};
IIRC clang will complain about {0}. How about we make this a {}.
Regardless of the above nitpick, the series is:
Reviewed-by: Emil Velikov
Thanks for the follow-up :-)
Emil
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Hi Ben,
On Thu, 23 May 2019 at 01:19, Ben Skeggs wrote:
>
> On Thu, 23 May 2019 at 01:03, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > Cc: Ben Skeggs
> > Cc: nouveau@lists.freedesktop.org
> > Signed-off-by: Emil Velikov
> Thanks!
>
S
n be a completely separate patch.
This patch is:
Reviewed-by: Emil Velikov
-Emil
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Hi Thomas,
On Tuesday, 25 February 2020, Thomas Zimmermann wrote:
> Non-KMS drivers store state in struct drm_driver. This bloats the
> structure for KMS drivers and prevents it from being declared with
> 'static const' qualifiers. Moving the non-KMS state into a separate
> data structure resolv
Hi Christophe,
s/fix some error handling in 'ls_ucode_img_load_gr/plug memory leak in
ls_ucode_img_load_gr() error path/
On 8 May 2017 at 08:46, Christophe JAILLET
wrote:
> The last goto looks spurious because it releases less resources than the
> previous one.
> Add a new label in order to free
PROP_
> - Updated uses of the defines to the new prefix
> - Removed include from drm_rect.c
> - Stopped using the BIT() macro
>
Reviewed-by: Emil Velikov
-Emil
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On 10 August 2017 at 20:29, Joe Kniss wrote:
> On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss wrote:
>> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes wrote:
>>>
>>> Den 09.08.2017 01.42, skrev Joe Kniss:
Because all drivers currently use gem objects for framebuffer planes,
the virtua
On 17 August 2017 at 11:37, Colin King wrote:
> From: Colin Ian King
>
> The check to see if mstm->msto is null is redundant because it is
> an array and hence can never be null. Remove the redundant check.
>
> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>
> Signed-off-by:
Signed-off-by: Emil Velikov
Cc: # 3.9+
---
drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
index f02fd9f..15df527
On 28/08/13 23:03, Sam Varshavchik wrote:
> I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and
> xorg-x11-server-Xorg-1.14.2-9.fc19.x86_64
>
> On the following chipset, the display suffers from "stuttering":
>
> 06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce
> GTX 285
Ever since the initial import of nouveau into upstream
kernel it has been a KMS only driver. Drop the old and
unused code, and update the comments while we're there.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/nouveau/nouveau_ioc32.c | 17 +++--
1 file changed, 3 inser
On 15/09/13 10:38, P NIKOLIC wrote:
> Hi .
>
Hi Pete
> For some time now i have had problems with video on this system .
>
> from dmesg iget the following
>
> 6.408406] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a5000a2
> [6.408411] nouveau [ DEVICE][:01:00.0] Chipset: GT216 (NV
On 26/09/13 23:37, Pavel Roskin wrote:
> Hello!
>
> I have spent some time on the issue. I'm not sure it's a nouveau bug.
> I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only.
>
> GRUB actually uses graphic mode on my card. That mode is supported by
> simplefb. However, the resour
On 03/10/13 19:45, Fernando Negro wrote:
> Hi everyone.
>
> I read on a 2011 article -
> http://www.phoronix.com/scan.php?page=article&item=nouveau_comp_2011&num=19 -
> that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I
> never tried using if for long, before, as soon as
On 03/10/13 15:41, Christoph Rudorff wrote:
> On resume of a hibernated notebook, I get garbled virtual consoles.
>
> fb_set_suspend(*dev, state == 0 means dev is running ...)
>
> This patch fixes that issue for me:
>
Ouch, nice catch Christoph :)
Seems like the following commit flipped the log
,
when contemplating if optimus is present on the platform.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70208
Signed-off-by: Emil Velikov
---
Ideally we would not need to iterate though the pci devices
twice. Although currently we have to do that as there is no
function that can takes
On 29/10/13 01:15, Gmail wrote:
> Hello group -
>
> Never heard a peep about thiswasn't sure it was actually posted. Anyone
> seen this before?
>
Peep, peep, it did get posted :P
> Thx
>
> RSV869
>
Top-posting as well as setting up your account name as "Gmail" is
considered a bad practic
Hello Christoph,
I was looking at bug 64323[1] over the weekend as to why this case works
under nvc0+ hardware and does not under nv50. Here are some of the
things I've noticed:
* nvc0 uses immediate(s) for VERTEX_BEGIN_GL/VERTEX_END_GL
* nvc0 is more consistent for doing pushbuffer space checks
*
On 04/10/13 01:54, Christoph Rudorff wrote:
> Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov:
>> I'm not entirely sure this is correct. One needs to save and disable
>> accleration before suspending the fb. Please try the following
>>
>> -if (st
On 17/11/13 18:30, Christoph Rudorff wrote:
> On 17.11.2013 00:22, Emil Velikov wrote:
>> On 04/10/13 01:54, Christoph Rudorff wrote:
>>> Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov:
>>>> I'm not entirely sure this is correct. One needs t
On 19/11/13 19:23, Christoph Rudorff wrote:
> On 19.11.2013 19:48, Greg KH wrote:
>> On Tue, Nov 19, 2013 at 05:59:13PM +0100, Christoph Rudorff wrote:
>>> Current code disables fbcon acceleration before fbcon is suspended,
>>> leading to corrupted console after resume from s2disk. In a similar
>>>
On 10/01/14 12:36, Fernando Negro wrote:
> Hi everyone.
>
Hi Fernando,
>
> I'm a big Free Software enthusiast and, therefore, I would very much like to
> use the nouveau free driver, instead of the proprietary one.
>
> My problem is that, looking for the cheapest option available, when I need
On 14/01/14 05:15, Ben Skeggs wrote:
> On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs wrote:
>> On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann
>> wrote:
>>> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8
>>> git. Maybe it's obvious.
>> Hey Bob,
>>
>> Thanks for reporting th
ou know why we cannot set the rt height to 64? After all you
explicitly set the format to NONE.
Either way this patch looks good afaics
Reviewed-by: Emil Velikov
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/drivers/nouveau/nv50/nv50_defs.xml.h | 1 +
> src/gallium/drivers/no
nitial assumption was that if there is a color buffer it must be at
cbuf[0].
The corrected version in your github branch looks alot better, it
handles the above case and does not overwrite the clear buffer on rt0.
That one is Reviewed-by: Emil Velikov
> if (buffers & PIPE_CL
On 23/01/14 19:39, Ilia Mirkin wrote:
>> Ilia,
>> > Do you know why we cannot set the rt height to 64? After all you
>> > explicitly set the format to NONE.
> Because then the RT would have a size, which we don't want. The real
> question is why not set the width to 0. It was that way in Christoph'
On 23/01/14 20:15, Ilia Mirkin wrote:
> On Thu, Jan 23, 2014 at 3:11 PM, Emil Velikov
> wrote:
>> On 17/01/14 02:23, Ilia Mirkin wrote:
>>> Fixes fbo-drawbuffers-none glClearBuffer piglit test.
>>>
>>> Signed-off-by: Ilia Mirkin
>>> ---
>&
being a high correlation between reported capabilities
> and ability to create a decoder.
>
Not the most elegant implementation, but it just works(tm). Tested on my
rusty nv96 (vp2).
Tested-by: Emil Velikov
> Signed-off-by: Ilia Mirkin
> Cc: 10.0 10.1
> ---
>
> I tested thi
On 11/02/14 05:42, Ilia Mirkin wrote:
> It should be possible to make this be 16 on nvc0.
>
> Signed-off-by: Ilia Mirkin
Reviewed-by: Emil Velikov
I have some other patches in the queue and I'll push this shortly
-Emil
> ---
>
> Not touching nv50 since I have a patch
system lockup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74866
Reported-by: John F. Godfrey
Signed-off-by: Emil Velikov
Cc: sta...@vger.kernel.org # 3.13+
---
drivers/gpu/drm/nouveau/core/subdev/fb/nv1a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu
On 12/02/14 05:38, Alexandre Courbot wrote:
> Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
> of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
> to handle platform devices by:
>
> - abstracting PCI-dependent functions that were typically used for
>
On 15/02/14 00:38, Ilia Mirkin wrote:
> So... I was wondering what the impact of splitting up the card compilation by
> e.g. generation would be. Depending on the split things would get fairly
> intertwined, so I thought I'd start small. This just splits NVC0 from
> everything else. I figure that f
Signed-off-by: Emil Velikov
---
Noticed while looking at an issue reported by Rafał Miłecki.
Seems like the right thing to do, but I don't know the specifics
behind the mode_set_base_atomic() so cannot comment if
nouveau_fbcon_save/restore is even needed or not.
Cheers
Emil
drivers/gp
On 06/03/14 04:01, Ilia Mirkin wrote:
> nouveau_fence_wait has the expectation that an external entity is
> holding onto the fence being waited on, not that it is merely held onto
> by the current pointer. Fixes a use-after-free in nouveau_fence_wait
> when used on the screen's current fence.
>
IM
On 11/03/14 14:46, Daniel Melo Jorge da Cunha wrote:
Sorry for the lame question, but is nouveau_device_wrap (...) implemented
outside Mesa source code? (like libdrm, I don't know...)
Indeed it is inside libdrm-nouveau [1].
Because I searched the whole Mesa-10.0.3 source and found no
implemen
On 15/04/14 22:49, Sergei Antonov wrote:
> On 15 April 2014 23:18, Sergei Antonov wrote:
>> Commit 457e77b26428ab4a24998eecfb99f27fa4195397 added two checks applied to a
>> value received from nv_rd32(bios, 0x619f04). But after this new piece of code
>> is executed, the addr local variable does no
On 21/05/14 00:39, Ilia Mirkin wrote:
> From: Christoph Bumiller
>
> Reviewed-by: Ilia Mirkin
> Cc: "10.2"
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_i
On 21/05/14 00:39, Ilia Mirkin wrote:
> From: Christoph Bumiller
>
> [imirkin: add logic to also clear the "regular" scissors]
Can you please share why are you've added the "regular" scissors ?
Does it matter if we set the screen scissors before the render target params?
Thanks
Emil
> Reviewed-
On 21/05/14 19:53, Ilia Mirkin wrote:
> On Wed, May 21, 2014 at 2:51 PM, Emil Velikov
> wrote:
>> On 21/05/14 00:39, Ilia Mirkin wrote:
>>> From: Christoph Bumiller
>>>
>>> Reviewed-by: Ilia Mirkin
>>> Cc: "10.2"
>>> ---
On 21/05/14 19:59, Ilia Mirkin wrote:
> On Wed, May 21, 2014 at 2:57 PM, Emil Velikov
> wrote:
>> On 21/05/14 00:39, Ilia Mirkin wrote:
>>> From: Christoph Bumiller
>>>
>>> [imirkin: add logic to also clear the "regular" scissors]
>>
_
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
>From d437ca90803ddf70190cdbaf617e815f6441f134 Mon Sep 17 00:00:00 2001
From: Emil Velikov
Date: Tue, 1 Jul 2014 22:31:47 +0100
Subject: [PATCH] xorg_li
On 30/07/14 11:16, Christian König wrote:
> [CCing Emil as well]
>
> Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst:
>> Using -export-symbols-regex all private symbols are hidden, resulting in the
>> following changes:
>
> Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid
t all symbols will be hidden via the VISIBILITY_CFLAGS. The
> drm_public macro can be used to mark symbols that should be exported.
>
Thank you Thierry. Finally we can cleanup some of the exports that libdrm*
erroneously provides :)
Reviewed-by: Emil Velikov
> Signed-off-by: Thierry
On 30/07/14 15:31, Rob Clark wrote:
> On Wed, Jul 30, 2014 at 9:48 AM, Thierry Reding
> wrote:
>> From: Thierry Reding
>>
>> Checks whether or not the compiler supports the -fvisibility option. If
>> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
>> directory AM_CFLAGS wh
On 31/07/14 14:44, Maarten Lankhorst wrote:
> This hides all the abi16_* functions and the nouveau_debug variable,
> they should have been private to begin with.
>
> Signed-off-by: Maarten Lankhorst
Looks good afaict
Reviewed-by:
On 24/08/14 22:15, Martin Peres wrote:
> We will use this subdev to disable temperature reading on cards that did not
> get a sensor calibration in the factory.
>
> Signed-off-by: Martin Peres
> ---
> configure.ac | 1 +
> drm/Kbuild | 4 ++
> drm/core/inc
On 30/08/14 23:02, Ilia Mirkin wrote:
> Samplers are only defined up to num_samplers, so set all samplers above
> nr to NULL so that we don't try to read them again later.
>
Would it be worth doing a similar thing with the unlocked samplers below the
nr mark ? It seems to me that we might be leaki
On 31/08/14 00:34, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 7:30 PM, Emil Velikov
> wrote:
>> On 30/08/14 23:02, Ilia Mirkin wrote:
>>> Samplers are only defined up to num_samplers, so set all samplers above
>>> nr to NULL so that we don't try to read t
On 31/08/14 00:34, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 7:30 PM, Emil Velikov
> wrote:
>> On 30/08/14 23:02, Ilia Mirkin wrote:
>>> Samplers are only defined up to num_samplers, so set all samplers above
>>> nr to NULL so that we don't try to read t
On 31/08/14 01:13, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 8:09 PM, Emil Velikov
> wrote:
>> On 31/08/14 00:34, Ilia Mirkin wrote:
>>> On Sat, Aug 30, 2014 at 7:30 PM, Emil Velikov
>>> wrote:
>>>> On 30/08/14 23:02, Ilia Mirkin wrote:
>>>
gpio: split g92 class from nv50
Reported-by: estece on #nouveau
Cc: sta...@vger.kernel.org # 3.16+
Signed-off-by: Emil Velikov
---
nvkm/engine/device/nv50.c| 22 ++---
nvkm/engine/device/nvc0.c| 14 -
nvkm/subdev/gpio/Makefile.am | 2 +-
nvkm/subdev/gpio/nv92.c | 74
Signed-off-by: Emil Velikov
---
src/nv_accel_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/nv_accel_common.c b/src/nv_accel_common.c
index eebb0ab..a2557e0 100644
--- a/src/nv_accel_common.c
+++ b/src/nv_accel_common.c
@@ -91,7 +91,7
Signed-off-by: Emil Velikov
---
src/nv_accel_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nv_accel_common.c b/src/nv_accel_common.c
index 4484c1c..eebb0ab 100644
--- a/src/nv_accel_common.c
+++ b/src/nv_accel_common.c
@@ -37,7 +37,7 @@ nouveau_allocate_surface
On 29/10/14 16:58, Stéphane Marchesin wrote:
> This isn't needed any longer (DRI1 is gone) so let's remove this as
> well.
>
Nice catch Stéphane. Welcome back :)
FWIW
Reviewed-by: Emil Velikov
> Signed-off-by: Stéphane Marchesin
_
Hi Chris,
On 06/11/14 19:05, Chris wrote:
> Greetings,
> I remember Nouveau being in the ports tree on FreeBSD some
> time ago. As I see it isn't there now. I was wondering if anyone
> else might have, or be working on a BSD branch. Or might be able
> to provide some insight on getting a branch o
Hi Valeria,
On 16/11/14 20:03, valeria aguilera wrote:
>
> Dear community members,
>
>
> Im a graphic designer and for the last couple of months I have been working
> on a new logo for the Nouveau project. After sending preliminary designs to
> both Martin Peres and Ilia Mirkin, we have decid
Hi Thierry,
Must admit that I really prefer this idea over modifying existing
applications/users [1] because:
- Most of these setups are tightly coupled (imx+vivante, tegra+nouveau)
and pushing this down to the driver prevents duplication, and hardware
specific details in the users.
- Removes th
On 23/12/14 10:40, Vince Hsu wrote:
> This patch adds some checks in the suspend/resume functions to distinguish
> the dGPU and mobile GPU and exports some variables/functions so that the
> nouveau platform device can reuse them.
>
Hi Vince,
Afaiu one needs to export a symbol as it's used by anot
On 31/12/14 03:42, Ilia Mirkin wrote:
> The headers hadn't been regenerated in a long time and had seen a number
> of manual modifications. A few changes:
> - remove nvc0_2d entirely, use the nv50 header which has the nvc0
>values too
> - remove 3ddefs, it's identical to the nv50 file
> - mo
On 23 January 2015 at 08:53, Alexandre Courbot wrote:
> Having a RAM device does not make sense for chips like GK20A which have
> no dedicated video memory. The dummy RAM device that we used so far
> works as a temporary band-aid, but in the long-term it is desirable for
> the driver to be able to
On 21 August 2014 at 12:45, Roy Spliet wrote:
> Signed-off-by: Roy Spliet
Hi Roy
Just have a quick scan through a nouveau build with -Wextra and I've
noticed an interesting warning
> ---
> drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c | 73
> +++-
> drivers/gpu/drm/nouv
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
> ---
>
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
gt;> 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
>>>>>>
On 25 February 2015 at 21:59, Maarten Lankhorst
wrote:
> On 25-02-15 15:14, Emil Velikov wrote:
>> On 24 February 2015 at 09:01, Maarten Lankhorst
>> wrote:
...
>>> +static const char default_device[] = "/dev/dri/renderD128";
>>> +
>> Reuse
On 26/02/15 10:54, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Hmm atomic differences between the different platforms are fun. Bring on
C11 atomics :-P
But seriously, feel free to add acked-by for patches 1 & 2, and
tested-by for the whole series.
Thanks
Emil
___
On 26/05/15 19:06, Martin Peres wrote:
> On 26/05/2015 16:23, Alexandre Courbot wrote:
>> On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst
>> wrote:
>>> Op 23-05-15 om 08:45 schreef Alexandre Courbot:
On Fri, May 22, 2015 at 3:23 AM, Martin Peres
wrote:
> On 21/05/2015 11:47, Ben
That would be great, as long as it does only that and does not go into
the "drivername" territory. As the said driver ;-)
"A driver name to use can be provided instead
of simple boolean value, which will be passed to the GL implementation for
it to load the appropriate backend."
-Emil
On 4 July
out there... i915g vs i915? Anyways, I just meant the version
> numbers :)
>
> On Sat, Jul 4, 2015 at 2:23 PM, Emil Velikov wrote:
>> That would be great, as long as it does only that and does not go into
>> the "drivername" territory. As the said driver ;-)
>>
>&g
Curious how many times this needs to come along, for you to change
your mind. :-)
On 8 July 2015 at 19:38, Ilia Mirkin wrote:
> Compiler is wrong.
>
> On Wed, Jul 8, 2015 at 2:27 PM, Tobias Klausmann
> wrote:
>> nouveau_compiler.c: In function ‘main’:
>> nouveau_compiler.c:216:27: warning: ‘code
On 8 July 2015 at 19:27, Tobias Klausmann
wrote:
> codegen/nv50_ir_emit_nv50.cpp: In member function
> ‘void nv50_ir::CodeEmitterNV50::emitLOAD(const nv50_ir::Instruction*)’:
> codegen/nv50_ir_emit_nv50.cpp:620:12: warning: unused variable ‘offset’
> [-Wunused-variable]
> int32_t offset = i->
On 8 July 2015 at 20:34, Tobias Klausmann
wrote:
> Mh i'm not aware of me ever changed the "nouveau_compiler". But i'm happy to
> see this made you laugh, so it has something positive at least... :/
>
Story time:
This particular compiler warning has been brought up (incl here) four
or five times.
On 14 July 2015 at 22:17, Ilia Mirkin wrote:
> ---
> src/nouveau_dri2.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
> index f22e319..4398559 100644
> --- a/src/nouveau_dri2.c
> +++ b/src/nouveau_dri2.c
> @@ -142
;screen_x;
> + off_y = pDraw->y - pPix->screen_y;
> }
>
> pGC = GetScratchGC(pDraw->depth, pScreen);
>
>
> Now I sort of assume that pDraw->x == pWin->origin.x. But... who knows.
>
> -ilia
>
>
> On Tue, Jul 14, 201
On 15 July 2015 at 14:12, Emil Velikov wrote:
> Upon closer look it seem that I was a bit off - the ati/intel ddx does
> not set off_x/y to zero when built without composite*.
>
> ... in copy_region2, they do so when working with video -
> XvAdaptorPtr::ddPutImage/XF86VideoAdapt
The variables are already set/substituted by the PKG_CHECK_MODULES
macro.
Signed-off-by: Emil Velikov
---
configure.ac | 4
1 file changed, 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 03563c1..6048c5a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,8 +82,6
... and use drmGetNodeTypeFromFd where possible.
Signed-off-by: Emil Velikov
---
src/nouveau_dri2.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index ce6f53e..d3cce4e 100644
--- a/src/nouveau_dri2.c
+++ b
select between DRI3 on and off, but changed
> here to a DRI level to make it consistent with the
> same option in the released Intel-ddx.
>
> v2: Use fixed up Bool return type of nouveau_present_init().
>
> Signed-off-by: Mario Kleiner
> Cc: Ilia Mirkin
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
nouveau/abi16.c | 13 ++---
nouveau/nouveau.c | 6 +++---
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/nouveau/abi16.c b/nouveau/abi16.c
index 4ca0bfb..59bc436 100644
--- a/nouveau/abi16.c
+++ b
Hello Hans,
Not to muddy the waters or anything, have you thought about the NIR
integration that Rob was thinking about ?
I'm pretty sure he'll be happy to have extra people helping him out.
Cheers,
Emil
___
Nouveau mailing list
Nouveau@lists.freedeskto
On 13 November 2015 at 14:38, Ilia Mirkin wrote:
> On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov
> wrote:
>> Hello Hans,
>>
>> Not to muddy the waters or anything, have you thought about the NIR
>> integration that Rob was thinking about ?
>> I'm pretty
On 14 November 2015 at 19:51, Karol Herbst wrote:
> I hit this while loop in an error state of the gpu
>
> v2: unlock mutex only if reply == true
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/nvkm/subdev/pmu/base.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> dif
Hi Ben,
On 26 November 2015 at 07:13, Ben Skeggs wrote:
> From: Ben Skeggs
>
> Signed-off-by: Ben Skeggs
> ---
> nouveau/abi16.c | 62
> ++-
> nouveau/nouveau.c | 56 +++--
> nouveau/private.h |
On 26 November 2015 at 07:14, Ben Skeggs wrote:
> From: Ben Skeggs
>
> This will expose functionality supported by newer kernel interfaces.
>
> Current userspace uses the chipset to determine which classes are likely
> exposed, which generally works pretty well, but isn't as flexible as it
> coul
On 26 November 2015 at 07:14, Ben Skeggs wrote:
> --- a/nouveau/nouveau.c
> +++ b/nouveau/nouveau.c
> +int
> +nouveau_drm_new(int fd, struct nouveau_drm **pdrm)
> +{
> + struct nouveau_drm *drm;
> + drmVersionPtr ver;
> +
> +#ifdef DEBUG
> + debug_init(getenv("NOUVEAU_LIBDRM_DE
On 26 November 2015 at 07:14, Ben Skeggs wrote:
> --- a/nouveau/nouveau.c
> +++ b/nouveau/nouveau.c
> + nvdev->base.lib_version = drm->lib_version;
On top of last patch "do we need lib_version" there has been no ddx
and mesa users that I can see. Do we want to carry keep this or we can
just
On 26 November 2015 at 07:14, Ben Skeggs wrote:
> From: Ben Skeggs
>
> The latter is deprecated, and will not be valid for newer clients.
>
Mention (or split) the removal of nouveau_object_find ? Afaics it has
never been used in mesa + ddx.
-Emil
___
N
1 - 100 of 260 matches
Mail list logo
