Displaying 20 results from an estimated 800 matches similar to: "[PATCH 1/3] nouveau: Drop some annoying _DX_ (direct x?) object name prefixes."
2009 Nov 05
6
Some cosmetic NV10TCL method changes.
The attached patch does the cosmetic renouveau.xml changes I
proposed. I'm about to reply myself with some other patches to update
libdrm and then fix the API break up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename_some_nv10tcl_methods.patch
Type: text/x-diff
Size: 2507 bytes
Desc: not available
Url :
2016 Oct 16
10
[PATCH 1/5] hwdefs: update nvc0_3d, add gm107_texture for new TIC format
These are copied directly from the mesa repository.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
src/hwdefs/gm107_texture.xml.h | 365 +++++++++++++++++
src/hwdefs/nvc0_3d.xml.h | 867 +++++++++++++++++++++++++----------------
2 files changed, 892 insertions(+), 340 deletions(-)
create mode 100644 src/hwdefs/gm107_texture.xml.h
diff --git
2014 Dec 31
2
[PATCH 1/2] nv50: regenerate rnndb headers
The headers hadn't been regenerated in a long time, and there were a few
minor divergences. Among other things, rnndb has changed naming to
G80/etc, for now I've not tackled switching that over and manually
replaced the nvidia codenames back to the chip ids. However no other
modifications of the headergen'd headers was done.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
2016 Oct 27
11
[PATCH v2 0/7] Add Maxwell support
I believe I've addressed all the feedback from the first time around, and
also made fixes necessary for GM20x based on testing results. I believe
now it should actually work for all GM10x and GM20x. Further, GP10x should
be very easy to add, but without someone to actually test I didn't want to
claim support for it.
Ilia Mirkin (7):
exa: add GM10x acceleration support
hwdefs: update
2016 Feb 15
24
[PATCH 01/23] nv50: import updated g80_defs.xml.h from rnndb
From: Ben Skeggs <bskeggs at redhat.com>
Signed-off-by: Ben Skeggs <bskeggs at redhat.com>
---
src/gallium/drivers/nouveau/nv50/g80_defs.xml.h | 279 ++++++++++++++++++++++++
1 file changed, 279 insertions(+)
create mode 100644 src/gallium/drivers/nouveau/nv50/g80_defs.xml.h
diff --git a/src/gallium/drivers/nouveau/nv50/g80_defs.xml.h
2007 Jun 22
0
[PATCH] Commented out all macros that are not used - it still compiles.
But does it work?
---
shared-core/nouveau_reg.h | 248 ++++++++++++++++++++++----------------------
1 files changed, 124 insertions(+), 124 deletions(-)
diff --git a/shared-core/nouveau_reg.h b/shared-core/nouveau_reg.h
index ea4a2f6..e2b3012 100644
--- a/shared-core/nouveau_reg.h
+++ b/shared-core/nouveau_reg.h
@@ -25,14 +25,14 @@
# define NV_RAMHT_CONTEXT_VALID
2013 Jun 28
1
pxelinux 5.x, 6.x memtest problem
On 06/28/2013 04:25 AM, Ady wrote:
>
> @Wim and @All,
> FWIW, in 2013-February there still were other additional issues with
> some kernels, including memory testers, so having a problem to boot
> memtest(86|86+|other) might or might not be related to the
> "PXE-stack-smasher" bug.
>
> For example, in v.4.06, the cfg entry could be:
> LINUX memtest
>
2019 Jul 25
3
[PATCH 0/2] drm/nouveau: i2c over DP AUX fixes
This is another attempt at fixing an issue with
yes | sensors-detect
Causing some machines with nouveau loaded to hang if certain kinds of
displays are attached. I've also included one minor fix that I found
along the way of troubleshooting this issue.
Lyude Paul (2):
drm/nouveau: Fix missing elses in g94_i2c_aux_xfer
drm/nouveau: Don't retry infinitely when receiving no data on i2c
2014 Mar 24
4
[PATCH 1/4] pm/fan: drop the fan lock in fan_update() before rescheduling
From: Martin Peres <martin.peres at labri.fr>
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update(), leading to a deadlock.
We should Cc: <stable at vger.kernel.org> # 3.9+
Reported-by:
2014 Dec 31
0
[PATCH 2/2] nvc0: regenerate rnndb headers
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
- move macros out into a separate file
Also the upstream rnndb changed the overall chip naming convention; this
was fixed up manually in the
2003 Aug 14
2
umass0 problems, with Sony USB Memory Stick
Hi,
I'm installing a laptop for a friend of mine, and while most things work, the
Sony memory stick does not.
With respect to the HEADS UP of August 7th, I've also re-enabled the 2 Sony
memory sticks quirks, in sys/cam/scsi/da_scsi.c.
The symptoms also apply to 4.8-RELEASE:
umass0: Sony USB Memory Stick Slot, rev 1.10/1.80, addr 2
...
umass0: CBI reset failed, TIMEOUT
umass0: CBI
2013 Nov 09
2
[PATCH] drm/nouveau/clk: Initial implementation for reclocking NVAA/NVAC
Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to
2008 Feb 23
5
[LLVMdev] new LTO C interface
Hello. I work at Apple on our linker. We are working to improve
support for llvm
in our tools. A while back Devang created <llvm/LinkTimeOptimizer.h>
a C++
interface which allows the linker to process llvm bitcode files along
with native
mach-o object files.
For the next step we'd like our other tools like nm, ar, and lipo to
be able to
transparently process bitcode files
2009 Feb 16
17
[Bug 20130] New: GT200: nv50 chipset 0xa0 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=20130
Summary: GT200: nv50 chipset 0xa0 lockup
Product: xorg
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
AssignedTo: nouveau at lists.freedesktop.org
2017 Nov 14
3
[PATCH] nouveau/codegen: dump tgsi floats as hex values
Printing without this could lead to the following output, while the values are
not exactly zero:
IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000}
IMM[6] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000}
IMM[7] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000}
when printing the values as hex, we can now see the differences:
IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,
2017 Nov 15
2
[PATCH] nouveau/codegen: dump tgsi floats as hex values
Hi,
yeah in the long run showing both in an ordered manner would be a nice
thing to have! That would include patching the output and the tgsi
parser (who wants to delete half the output to parse it again e.g. with
nouveau_compiler).
I can image an output similar to the one below:
IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} ^ IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,
2015 Nov 03
3
[PATCH 1/2] disp: activate dual link TMDS links only when possible
From: Hauke Mehrtens <hauke at hauke-m.de>
Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actual possible.
Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
Signed-off-by: Ilia
2010 Jan 04
1
NV_PFIFO_INTR_DMA_PUSHER
Hello,
Could someone briefly describe (or point me to the documentation) what
can be a reason for getting NV_PFIFO_INTR_DMA_PUSHER status
(nouveau_fifo_irq_handler).
This started happening immediately after I set the nouveau_vram_pushbuf
flag to TRUE ,it's 100% repetitive and causes fences not to be signaled.
Below is the debug log from moment of creation of fifo 1 to some point
in time
2015 Nov 04
1
[PATCH 1/2] disp: activate dual link TMDS links only when possible
On Tue, Nov 3, 2015 at 7:02 PM, Ben Skeggs <skeggsb at gmail.com> wrote:
> On 11/04/2015 08:41 AM, Ilia Mirkin wrote:
>> From: Hauke Mehrtens <hauke at hauke-m.de>
>>
>> Without this patch a pixel clock rate above 165 MHz on a TMDS link is
>> assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
>> supports no dual link, but it supports
2006 May 03
1
demo() output looks garbled in default pager (less and most)
Dear Rexperts,
I have recently build R-2.3.0 from source on a Linux system and have
encountered the following problem (perhaps not exactly a problem, but a
minor display flaw):
> demo()
+------------here is how the output looks in less------------+
Demos in package <E2><80><98>base<E2><80><99>:
is.things Explore some properties of R