similar to: [PATCH] drm/nve4: fix size of POLY2ESETUP buffer (s/gpc_nr/tpc_total)

This fixes write faults from GPCCLIENT 5 in geometry shader tests. For now this is just a guess from a single mmio trace, it looks like 8 large pages are being used, i.e. one per TPC. Can we just ask NV for the correct sizes ? --- drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- MMIO32 R 0x17e91c 0x0b040a0b PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb040a0b MMIO32 R 0x17e920 0x00090c03 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90c03 MMIO32 W 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C <= 0xb030a0c MMIO32 W 0x17e920 0x00090d08 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 <= 0x90d08 And then

This fixes hangs on GK208 which happen instantaneously on trying to use a geometry shader. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org # v3.14+ --- ctxnvf0 also writes to these registers (although slightly diff values), so I think this is right. So I guess trap 4 is whatever this 406 subengine is...

Add a GR device for GK20A based on NVE4, with the correct classes definitions (GK20A's 3D class is 0xa297). Most of the NVE4 code can be used on GK20A, so make relevant bits of NVE4 available to other chips as well. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/Makefile | 1 + .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c

Hi everyone, Here is the second batch of patches to add GK20A support to Nouveau. This time we are adding the actual chip support, and this series brings the driver to a point where a slightly-tweaked Mesa successfully runs shaders and renders triangles on GBM! Many thanks to Thierry Reding and the people on the #nouveau IRC channel for their help without which we would not have reached this

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a GR device for GK20A based on NVE4, with the correct classes > definitions (GK20A's 3D class is 0xa297). > > Most of the NVE4 code can be used on GK20A, so make relevant bits of > NVE4 available to other chips as well. This will need a bit of a rebase on top of the tree I mentioned

https://bugs.freedesktop.org/show_bug.cgi?id=54437 Bug #: 54437 Summary: linux-nouveau2.6 (3.6.0-rc4) : GTX580 : Xorg freezes when using accel Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical

Changes since v2: - Enabled software class - Removed unneeded changes to nouveau_accel_init() - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with the portable page_to_phys()/phys_to_page() - Fixed incorrect comment/commit log talking about bytes instead of words Hope this looks good! Once this gets merged the next set will be to use this driver on Jetson and Venice2

Latest patches for GK20A, taking comments received for v3 into account. Changes since v3: - use only pfn_to_page() and page_to_pfn() in GK20A's FB. These functions are present on every arch and the physical address to page frame number conversion is also consistently a shift of PAGE_SHIFT. This part will probably be replaced by something nicer in the future anyway. - fixed a warning on

Second version of this patchset. Not many changes since first version - I hope this means the changes are not too controversial. Changes since v1: - Removed lookup for previous FW files in "nouveau/" - Went back to using request_firmware() since we only try to load one file Original cover letter follows: GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support

Hello everyone, GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion. The first patch adds support for loading the FECS and GPCCS firmwares from firmware files

Hi everyone, Way overdue v2 of the final patches that enable basic GK20A support. Hopefully all the issues raised with v1 have been addressed. Changes since v1: - Use gk20a clock driver by Ben instead of twiddling nv04's - Name new classes after gk20a instead of nvea - Addressed comments about BAR initialization code factorization - Removed non-essential code which only purpose was to avoid

Hi, Generally the the imported buffers which has memory type TTM_PL_TT are mapped as small pages probably due to lack of big page allocation. But the platform device which also use memory type TTM_PL_TT, like GK20A, can *allocate* big page though the IOMMU hardware inside the SoC. This is a try to map the imported buffers as big pages in GMMU by the platform IOMMU. With some preparation work to

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 for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options

On 13.09.2014 23:45, Roy Spliet wrote: > Dear Poma, > > Don't get anyone wrong, your input is greatly valued. The reason why > "we" (nouveau developers) generally ask for a git bisection is because > we don't know or track specific distributions. Although your search has > narrowed the problem down (thanks for that!), we don't know how big the >

On 13.09.2014 22:58, Ilia Mirkin wrote: > On Sat, Sep 13, 2014 at 4:52 PM, poma <pomidorabelisima at gmail.com> wrote: >> On 13.09.2014 07:02, poma wrote: >>> On 13.09.2014 06:57, poma wrote: >>>> >>>> Actually I have nothing to show cause logs are all OK. >>>> Haha, it seems to me that the bugs become intelligent. >>>>

From: Thierry Reding <treding at nvidia.com> gp10b doesn't have all the registers that gp102_gr_zbc wants to access, which causes IBUS MMIO faults to occur. Avoid this by using the gp100 variants of grctx and gr_zbc. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gp100.c | 2

--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git

On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Changes since v2: > - Enabled software class > - Removed unneeded changes to nouveau_accel_init() > - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with > the portable page_to_phys()/phys_to_page() page_to_phys() looks well defined and used everywhere, phys_to_page() not

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index