[Nouveau] [PATCH] drm/nouveau: Fix a complier warning in the card init error path
Fix an unitialized variable complier warning in nouveau_card_init.
Signed-off-by: Jimmy Rentz jb17bs...@gmail.com
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 3404950..66e8037 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -679,7 +679,7 @@ out_fifo:
engine-fifo.takedown(dev);
out_engine:
if (!nouveau_noaccel) {
- for (e = e - 1; e = 0; e--) {
+ for (e = NVOBJ_ENGINE_NR - 1; e = 0; e--) {
if (!dev_priv-eng[e])
continue;
dev_priv-eng[e]-fini(dev, e);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau: Free nv04 instmem ramin heap at card takedown
Add a missing nv04 instmem ramin heap shutdown call. Signed-off-by: Jimmy Rentz jb17bs...@gmail.com diff --git a/drivers/gpu/drm/nouveau/nv04_instmem.c b/drivers/gpu/drm/nouveau/nv04_instmem.c index b8e3edb..b8611b9 100644 --- a/drivers/gpu/drm/nouveau/nv04_instmem.c +++ b/drivers/gpu/drm/nouveau/nv04_instmem.c @@ -95,6 +95,9 @@ nv04_instmem_takedown(struct drm_device *dev) nouveau_ramht_ref(NULL, dev_priv-ramht, NULL); nouveau_gpuobj_ref(NULL, dev_priv-ramro); nouveau_gpuobj_ref(NULL, dev_priv-ramfc); + + if (drm_mm_initialized(dev_priv-ramin_heap)) + drm_mm_takedown(dev_priv-ramin_heap); } int ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau: Fix a crash at card takedown for NV40 and older cards trying to free a vga bo
NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown. The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: Jimmy Rentz jb17bs...@gmail.com
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c
b/drivers/gpu/drm/nouveau/nouveau_mem.c index 9c7bc3f..ce3cb5e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -154,8 +154,6 @@ nouveau_mem_vram_fini(struct drm_device *dev)
{
struct drm_nouveau_private *dev_priv = dev-dev_private;
- nouveau_bo_ref(NULL, dev_priv-vga_ram);
-
ttm_bo_device_release(dev_priv-ttm.bdev);
nouveau_ttm_global_release(dev_priv);
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c index 66e8037..98ab6b2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -738,6 +738,11 @@ static void nouveau_card_takedown(struct
drm_device *dev) engine-mc.takedown(dev);
engine-display.late_takedown(dev);
+ if (dev_priv-vga_ram) {
+ nouveau_bo_unpin(dev_priv-vga_ram);
+ nouveau_bo_ref(NULL, dev_priv-vga_ram);
+ }
+
mutex_lock(dev-struct_mutex);
ttm_bo_clean_mm(dev_priv-ttm.bdev, TTM_PL_VRAM);
ttm_bo_clean_mm(dev_priv-ttm.bdev, TTM_PL_TT);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Fix a complier warning in the card init error path
On Sun, 17 Apr 2011 23:18:36 +0200
Marcin Slusarz marcin.slus...@gmail.com wrote:
On Sun, Apr 17, 2011 at 04:14:53PM -0400, Jimmy Rentz wrote:
Fix an unitialized variable complier warning in nouveau_card_init.
Signed-off-by: Jimmy Rentz jb17bs...@gmail.com
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c index 3404950..66e8037
100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -679,7 +679,7 @@ out_fifo:
engine-fifo.takedown(dev);
out_engine:
if (!nouveau_noaccel) {
- for (e = e - 1; e = 0; e--) {
+ for (e = NVOBJ_ENGINE_NR - 1; e = 0; e--) {
if (!dev_priv-eng[e])
continue;
dev_priv-eng[e]-fini(dev, e);
This code is supposed to handle the situation when one of engine
initialization routines failed and this change will break it...
Marcin
Really? It wasn't intentional. I didn't see the e referenced above.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Decode videos
On Tue, 7 Dec 2010 13:58:22 + James Courtier-Dutton james.dut...@gmail.com wrote: On 7 December 2010 01:07, Jimmy Rentz jb17bs...@gmail.com wrote: On Mon, 6 Dec 2010 23:05:10 +0100 Xavier Chantry chantry.xav...@gmail.com wrote: On Mon, Dec 6, 2010 at 7:35 PM, Mikhail Ramendik m...@ramendik.ru wrote: Hello, http://nouveau.freedesktop.org/wiki/FeatureMatrix lists Decode videos as WIP for NV30 and NV40 seies. As I have an NV44, I would really like to know - what is this feature going to be? VDPAU support for these cards, or XvMC, or something else? According to http://lists.freedesktop.org/archives/nouveau/2010-August/006142.html and the following mails/patches : XvMC. Not sure what is possible on nv40 but that subject was discussed quickly here: http://lists.freedesktop.org/archives/nouveau/2010-May/005726.html Initially I would say XVMC. VDPAU expects full hw bitstream decode. XVMC only does decode starting at idct/mb. I am guessing it is possible to support VDPAU by doing the earlier stages in software then handling the reset to hw. Well, unless someone figures out some way to handle the full pipeline in hw via shaders which is something I have no time or knowledge. I think it would be better if one could do vdpau in software and then initially offload the idct/mb to the hardware. The reason being vdpau supports mpeg2 and mpeg4, XVMC only supports mpeg2. Yes, XVMC is very old and some software (mythtv for one) are removing support for it. There are some initial VDPAU stubs in the mesa.pipe-video patch but they don't do anything but support querying caps,etc and not decode/presentation. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Decode videos
On Mon, 6 Dec 2010 23:05:10 +0100 Xavier Chantry chantry.xav...@gmail.com wrote: On Mon, Dec 6, 2010 at 7:35 PM, Mikhail Ramendik m...@ramendik.ru wrote: Hello, http://nouveau.freedesktop.org/wiki/FeatureMatrix lists Decode videos as WIP for NV30 and NV40 seies. As I have an NV44, I would really like to know - what is this feature going to be? VDPAU support for these cards, or XvMC, or something else? According to http://lists.freedesktop.org/archives/nouveau/2010-August/006142.html and the following mails/patches : XvMC. Not sure what is possible on nv40 but that subject was discussed quickly here: http://lists.freedesktop.org/archives/nouveau/2010-May/005726.html Initially I would say XVMC. VDPAU expects full hw bitstream decode. XVMC only does decode starting at idct/mb. I am guessing it is possible to support VDPAU by doing the earlier stages in software then handling the reset to hw. Well, unless someone figures out some way to handle the full pipeline in hw via shaders which is something I have no time or knowledge. The latest version of the video decode/vpe/nv40 patches are here: http://people.freedesktop.org/~jb17bsome/vpe/ddx/ddx_nouveau_vpe_v1.patch http://people.freedesktop.org/~jb17bsome/vpe/drm/drm_nouveau_vpe_v5.patch http://people.freedesktop.org/~jb17bsome/vpe/kernel/kernel_nouveau_vpe_v6.patch http://people.freedesktop.org/~jb17bsome/vpe/mesa/mesa_pipe_video_nouveau_vpe_v3.patch For mesa you need to pull the pipe-video branch. All the others apply fine against the latest branches for the ddx, drm, nouveau kernel. The current patches integrate vpe better with gem/ttm. This means that relocs/fences are emitted and it doesn't just pin all memory like before. Though, it does runs much slower compared to my last non-gem version located under the old directories in (ddx/drm/kernel/mesa). I am fairly certain from oprofile dumps that it is because of too many relocs emitted or something, but I haven't followed up. Anyway hopes this helps. Jimmy ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nv vpe video decoder
Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for your review. Any comments are welcome. An important note is that the performance isn't that great in my opinion. There is something preventing the nv vpe engine from rendering cmds at the same rate as the blob. Either caching or whatever. Jimmy Rentz ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/4] drm: nv vpe
This patch includes all the relevant nv vpe drm support.
This patch applies against the latest drm.
The drm portion has a couple of classes that interface with the kernel
vpe layer:
* nouveau_vpe_channel class - Manages the drm vpe channel.
This includes open the vpe channel in the kernel, setting up the
pushbuf and each output surface. Right now I force the pushbuffer to be
allocated/managed from user-mode. This is performance reaons. However,
the kernel can always decline this.
* nouveau_vpe_pushbuf class - Manages the pushbuf.
This includes starting/ending cmd sequences, writing the cmds to the
pushbuf and firing.
Signed-off-by: Jimmy Rentz jb17bs...@gmail.com
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index a6a9f4a..c597c0a 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -79,6 +79,7 @@ struct drm_nouveau_gpuobj_free {
#define NOUVEAU_GETPARAM_CHIPSET_ID 11
#define NOUVEAU_GETPARAM_VM_VRAM_BASE12
#define NOUVEAU_GETPARAM_GRAPH_UNITS 13
+#define NOUVEAU_GETPARAM_PTIMER_TIME 14
struct drm_nouveau_getparam {
uint64_t param;
uint64_t value;
@@ -183,6 +184,52 @@ enum nouveau_bus_type {
struct drm_nouveau_sarea {
};
+/* VPE Supports mpeg2 only.*/
+struct drm_nouveau_vd_vpe_channel_alloc {
+ uint32_t width;
+ uint32_t height;
+ /* Used for user pushbuf access.
+* mmio access is not allowed so you still need to fire as normal.*/
+ uint32_t pushbuf_handle;
+};
+
+struct drm_nouveau_vd_vpe_channel_free {
+};
+
+#define NOUVEAU_VD_VPE_PUSHBUF_FIRE_FLAG_END_SEQUENCE 0x0001
+#define NOUVEAU_VD_VPE_PUSHBUF_FIRE_FLAG_UPDATE_DMA_POS 0x0002
+/* structure for surface.*/
+struct drm_nouveau_vd_vpe_surface {
+ uint32_t luma_handle;
+ uint32_t chroma_handle;
+ uint32_t surface_index;
+};
+
+/* This flag lets you turn off firing for a specific batch.
+ * This is needed in some cases to avoid locking up the decoder.*/
+#define NOUVEAU_VD_VPE_PUSHBUF_FIRE_BATCH_DO_NOT_FIRE 0x1000
+struct drm_nouveau_vd_vpe_pushbuf_fire {
+ /* [in] */
+ uint32_t nr_dwords;
+ uint64_t dwords;
+ uint32_t nr_batches;
+ uint64_t batches;
+ /* Surface[0] is always the target.*/
+ uint32_t nr_surfaces;
+ uint64_t surfaces;
+ uint32_t flags;
+ /* Needed when writing to the hw pushbuf from user space.
+* This also will perform a fire.*/
+ uint32_t dma_cur;
+ /* [out] */
+ uint32_t dma_free;
+};
+
+struct drm_nouveau_vd_vpe_surface_query {
+ uint32_t surface_index;
+ uint32_t is_busy;
+};
+
#define DRM_NOUVEAU_GETPARAM 0x00
#define DRM_NOUVEAU_SETPARAM 0x01
#define DRM_NOUVEAU_CHANNEL_ALLOC 0x02
@@ -195,5 +242,9 @@ struct drm_nouveau_sarea {
#define DRM_NOUVEAU_GEM_CPU_PREP 0x42
#define DRM_NOUVEAU_GEM_CPU_FINI 0x43
#define DRM_NOUVEAU_GEM_INFO 0x44
+#define DRM_NOUVEAU_VD_VPE_CHANNEL_ALLOC 0x49
+#define DRM_NOUVEAU_VD_VPE_CHANNEL_FREE 0x50
+#define DRM_NOUVEAU_VD_VPE_PUSHBUF_FIRE 0x51
+#define DRM_NOUVEAU_VD_VPE_SURFACE_QUERY 0x52
#endif /* __NOUVEAU_DRM_H__ */
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index de3f4df..5c148f1 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -19,7 +19,9 @@ libdrm_nouveau_la_SOURCES = \
nouveau_bo.c \
nouveau_resource.c \
nouveau_private.h \
- nouveau_reloc.c
+ nouveau_reloc.c \
+ nouveau_vpe_channel.c \
+ nouveau_vpe_pushbuf.c
libdrm_nouveaucommonincludedir = ${includedir}/nouveau
libdrm_nouveaucommoninclude_HEADERS = \
@@ -30,7 +32,10 @@ libdrm_nouveaucommoninclude_HEADERS = \
nouveau_pushbuf.h \
nouveau_bo.h \
nouveau_resource.h \
- nouveau_reloc.h
+ nouveau_reloc.h \
+ nouveau_vpe_channel.h \
+ nouveau_vpe_pushbuf.h \
+ nouveau_vpe_hw.h
libdrm_nouveauincludedir = ${includedir}/libdrm
diff --git a/nouveau/nouveau_vpe_channel.c b/nouveau/nouveau_vpe_channel.c
new file mode 100644
index 000..22092ae
--- /dev/null
+++ b/nouveau/nouveau_vpe_channel.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright (C) 2010 Jimmy Rentz
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so
[Nouveau] [PATCH 3/4] ddx: nv vpe
This patch includes all the relevant nv vpe ddx support.
This patch applies against the latest xf86-video-nouveau.
This is hooks up the XV blit adapter to be used for XvMC IDCT on
NV30/NV40 cards. This makes it possible to fallback to g3dvl XvMC
if nv vpe is in use.
Signed-off-by: Jimmy Rentz jb17bs...@gmail.com
diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c
index d1f87c3..aa07193 100644
--- a/src/nouveau_xv.c
+++ b/src/nouveau_xv.c
@@ -2062,6 +2062,7 @@ NVInitVideo(ScreenPtr pScreen)
XF86VideoAdaptorPtr blitAdaptor = NULL;
XF86VideoAdaptorPtr textureAdaptor[2] = {NULL, NULL};
int num_adaptors;
+ bool create_vpe_xvmc = false;
/*
* Driving the blitter requires the DMA FIFO. Using the FIFO
@@ -2140,14 +2141,28 @@ NVInitVideo(ScreenPtr pScreen)
* associate with any/all adapters since VL doesn't depend on
Xv for color conversion. */
if (textureAdaptor[0]) {
- XF86MCAdaptorPtr *adaptorsXvMC =
xalloc(sizeof(XF86MCAdaptorPtr));
+ if (blitAdaptor ( (pNv-Architecture == NV_ARCH_30)
||
+ (pNv-Architecture == NV_ARCH_40) ) ) {
+ create_vpe_xvmc = true;
+ num_adaptors = 2;
+ }
+ else
+ num_adaptors = 1;
+
+ XF86MCAdaptorPtr *adaptorsXvMC = xalloc(num_adaptors *
sizeof(XF86MCAdaptorPtr));
if (adaptorsXvMC) {
adaptorsXvMC[0] = vlCreateAdaptorXvMC(pScreen,
textureAdaptor[0]-name);
+ if (create_vpe_xvmc)
+ adaptorsXvMC[1] =
vlCreateAdaptorXvMCVPE(pScreen, blitAdaptor-name);
+
if (adaptorsXvMC[0]) {
- vlInitXvMC(pScreen, 1, adaptorsXvMC);
+ vlInitXvMC(pScreen, num_adaptors,
adaptorsXvMC); vlDestroyAdaptorXvMC(adaptorsXvMC[0]);
+
+ if (num_adaptors 1)
+
vlDestroyAdaptorXvMC(adaptorsXvMC[1]); }
xfree(adaptorsXvMC);
diff --git a/src/vl_hwmc.c b/src/vl_hwmc.c
index d8d8860..800fc88 100644
--- a/src/vl_hwmc.c
+++ b/src/vl_hwmc.c
@@ -58,11 +58,30 @@ static XF86MCSurfaceInfoRec yv12_mpeg2_surface =
subpicture_list
};
+static XF86MCSurfaceInfoRec yv12_mpeg2_vpe_surface =
+{
+ FOURCC_YV12,
+ XVMC_CHROMA_FORMAT_420,
+ 0,
+ 2032,
+ 2032,
+ 2048,
+ 2048,
+ XVMC_IDCT | XVMC_MPEG_2,
+ XVMC_SUBPICTURE_INDEPENDENT_SCALING | XVMC_BACKEND_SUBPICTURE,
+ subpicture_list
+};
+
static XF86MCSurfaceInfoPtr surfaces[] =
{
(XF86MCSurfaceInfoPtr)yv12_mpeg2_surface
};
+static XF86MCSurfaceInfoPtr vpe_surfaces[] =
+{
+ (XF86MCSurfaceInfoPtr)yv12_mpeg2_vpe_surface
+};
+
static XF86ImageRec rgb_subpicture = XVIMAGE_RGB;
static XF86ImagePtr subpictures[] =
@@ -85,6 +104,21 @@ static XF86MCAdaptorRec adaptor_template =
(xf86XvMCDestroySubpictureProcPtr)NULL
};
+static XF86MCAdaptorRec vpe_adaptor_template =
+{
+ ,
+ 1,
+ vpe_surfaces,
+ 1,
+ subpictures,
+ (xf86XvMCCreateContextProcPtr)NULL,
+ (xf86XvMCDestroyContextProcPtr)NULL,
+ (xf86XvMCCreateSurfaceProcPtr)NULL,
+ (xf86XvMCDestroySurfaceProcPtr)NULL,
+ (xf86XvMCCreateSubpictureProcPtr)NULL,
+ (xf86XvMCDestroySubpictureProcPtr)NULL
+};
+
XF86MCAdaptorPtr vlCreateAdaptorXvMC(ScreenPtr pScreen, char
*xv_adaptor_name) {
XF86MCAdaptorPtradaptor;
@@ -110,6 +144,31 @@ XF86MCAdaptorPtr vlCreateAdaptorXvMC(ScreenPtr
pScreen, char *xv_adaptor_name) return adaptor;
}
+XF86MCAdaptorPtr vlCreateAdaptorXvMCVPE(ScreenPtr pScreen, char
*xv_adaptor_name) +{
+ XF86MCAdaptorPtradaptor;
+ ScrnInfoPtr pScrn;
+
+ assert(pScreen);
+ assert(xv_adaptor_name);
+
+ pScrn = xf86Screens[pScreen-myNum];
+ adaptor = xf86XvMCCreateAdaptorRec();
+
+ if (!adaptor)
+ {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR, [XvMC.VPE]
Memory allocation failed.\n);
+ return NULL;
+ }
+
+ *adaptor = vpe_adaptor_template;
+ adaptor-name = xv_adaptor_name;
+
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO, [XvMC.VPE] Associated
with %s.\n, xv_adaptor_name);
+
+ return adaptor;
+}
+
void vlDestroyAdaptorXvMC(XF86MCAdaptorPtr adaptor)
{
assert(adaptor);
diff --git a/src/vl_hwmc.h b/src/vl_hwmc.h
index 715120d..efb2d56 100644
--- a/src/vl_hwmc.h
+++ b/src/vl_hwmc.h
@@ -4,6 +4,7 @@
#include xf86xvmc.h
XF86MCAdaptorPtr vlCreateAdaptorXvMC(ScreenPtr pScreen, char
*xv_adaptor_name); +XF86MCAdaptorPtr vlCreateAdaptorXvMCVPE(ScreenPtr
pScreen, char *xv_adaptor_name); void
vlDestroyAdaptorXvMC(XF86MCAdaptorPtr adaptor); void
[Nouveau] nv40 mpeg2 video decode
Hello, I have been working on a kernel and a user layer for the nv40 mpeg2 video decoding hardware: * The decode hw accepts commands written to a fifo along with a set of registers for firing (put) and queries (get). * The fifo can be mapped in vram or agp (though, agp isn't working right now). * The fifo does not support dma jumps and such like the 3d fifo. Well, I have some questions about how to implement this in nouveau: * Mapping decode fifo in user-space versus kernel-space - My current version has the fifo being mapped from the kernel (I copied the 3d fifo simple version pretty much). I could do this in the kernel or userspace but it would probably be faster in the kernel. * Fencing - Each decode cmd sequence can emit a fence in a similar fashion to the 3d fifo. So, you set the fence sequence number after a set of cmds. You then check a register to see when the hw is done with a set of cmds. I just don't see an easy of implementing this since the current fence mechanism only works for the 3d fifo. Jimmy Rentz ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [TEST REQUEST] nv40 firmware replacement
On Tue, 15 Dec 2009 17:14:10 +1000 Ben Skeggs skeg...@gmail.com wrote: So, I've spent the last few days messing around with replacing our use of NVIDIA's context programs on GeForce 6/7 hardware and have something that works on the 4 (2xNV44, NV46, NV4B) cards I have. The context programs are *much* less complex than NVIDIA's and don't handle nearly everything NVIDIA's do, however they do work for our needs, and it's as good a starting point as any. I've attached the currently generated firmware in the same binary format we packages NVIDIA's in. If people with the relevant hardware could install them, and report success/failure and the chipset they tested on (the whole Detected an NVxx generation card line from nouveau's dmesg output would be perfect), that'd be great! I'm now working on moving the code that generated the firmware in the below tarball to the DRM, and after some testing before I do! Ben. I tested this on an nv4e and nv49 and kms+X works fine. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm/nouveau: Pre-G80 tiling support.
On Fri, 11 Dec 2009 19:33:22 +0100
Francisco Jerez curroje...@riseup.net wrote:
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 23 +
drivers/gpu/drm/nouveau/nouveau_reg.h | 16 ++--
drivers/gpu/drm/nouveau/nouveau_state.c |8 ++
drivers/gpu/drm/nouveau/nv10_fb.c | 32 ++--
drivers/gpu/drm/nouveau/nv10_graph.c| 47 ---
drivers/gpu/drm/nouveau/nv20_graph.c| 80 +++
drivers/gpu/drm/nouveau/nv40_fb.c | 53 -
drivers/gpu/drm/nouveau/nv40_graph.c| 135
+++ 8 files changed, 247 insertions(+),
147 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h index 88b4c7b..2730497 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -276,8 +276,13 @@ struct nouveau_timer_engine {
};
struct nouveau_fb_engine {
+ int num_tiles;
+
int (*init)(struct drm_device *dev);
void (*takedown)(struct drm_device *dev);
+
+ void (*set_region_tiling)(struct drm_device *dev, int i,
uint32_t addr,
+ uint32_t size, uint32_t pitch);
};
struct nouveau_fifo_engine {
@@ -328,6 +333,9 @@ struct nouveau_pgraph_engine {
void (*destroy_context)(struct nouveau_channel *);
int (*load_context)(struct nouveau_channel *);
int (*unload_context)(struct drm_device *);
+
+ void (*set_region_tiling)(struct drm_device *dev, int i,
uint32_t addr,
+ uint32_t size, uint32_t pitch);
};
struct nouveau_engine {
@@ -876,10 +884,16 @@ extern void nv04_fb_takedown(struct drm_device
*); /* nv10_fb.c */
extern int nv10_fb_init(struct drm_device *);
extern void nv10_fb_takedown(struct drm_device *);
+extern void nv10_fb_set_region_tiling(struct drm_device *dev, int i,
+ uint32_t addr, uint32_t size,
+ uint32_t pitch);
/* nv40_fb.c */
extern int nv40_fb_init(struct drm_device *);
extern void nv40_fb_takedown(struct drm_device *);
+extern void nv40_fb_set_region_tiling(struct drm_device *dev, int i,
+ uint32_t addr, uint32_t size,
+ uint32_t pitch);
/* nv04_fifo.c */
extern int nv04_fifo_init(struct drm_device *);
@@ -938,6 +952,9 @@ extern void nv10_graph_destroy_context(struct
nouveau_channel *); extern int nv10_graph_load_context(struct
nouveau_channel *); extern int nv10_graph_unload_context(struct
drm_device *); extern void nv10_graph_context_switch(struct
drm_device *); +extern void nv10_graph_set_region_tiling(struct
drm_device *dev, int i,
+ uint32_t addr, uint32_t
size,
+ uint32_t pitch);
/* nv20_graph.c */
extern struct nouveau_pgraph_object_class nv20_graph_grclass[];
@@ -949,6 +966,9 @@ extern int nv20_graph_unload_context(struct
drm_device *); extern int nv20_graph_init(struct drm_device *);
extern void nv20_graph_takedown(struct drm_device *);
extern int nv30_graph_init(struct drm_device *);
+extern void nv20_graph_set_region_tiling(struct drm_device *dev, int
i,
+ uint32_t addr, uint32_t
size,
+ uint32_t pitch);
/* nv40_graph.c */
extern struct nouveau_pgraph_object_class nv40_graph_grclass[];
@@ -962,6 +982,9 @@ extern int nv40_graph_unload_context(struct
drm_device *); extern int nv40_grctx_init(struct drm_device *);
extern void nv40_grctx_fini(struct drm_device *);
extern void nv40_grctx_vals_load(struct drm_device *, struct
nouveau_gpuobj *); +extern void nv40_graph_set_region_tiling(struct
drm_device *dev, int i,
+ uint32_t addr, uint32_t
size,
+ uint32_t pitch);
/* nv50_graph.c */
extern struct nouveau_pgraph_object_class nv50_graph_grclass[];
diff --git a/drivers/gpu/drm/nouveau/nouveau_reg.h
b/drivers/gpu/drm/nouveau/nouveau_reg.h index fa1b0e7..251f1b3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_reg.h
+++ b/drivers/gpu/drm/nouveau/nouveau_reg.h
@@ -349,19 +349,19 @@
#define NV04_PGRAPH_BLEND 0x00400824
#define NV04_PGRAPH_STORED_FMT 0x00400830
#define NV04_PGRAPH_PATT_COLORRAM 0x00400900
-#define NV40_PGRAPH_TILE0(i)
(0x00400900 + (i*16)) -#define
NV40_PGRAPH_TLIMIT0(i) (0x00400904 +
(i*16)) -#define NV40_PGRAPH_TSIZE0(i)
(0x00400908 + (i*16)) -#define
NV40_PGRAPH_TSTATUS0(i)(0x0040090C +
(i*16)) +#define NV20_PGRAPH_TILE(i)
(0x00400900 + (i*16)) +#define
NV20_PGRAPH_TLIMIT(i) (0x00400904 +
(i*16))
