similar to: [bug report] drm/nouveau/object: merge with handle

From: Thierry Reding <treding at nvidia.com> The purpose of BAR1 is primarily to make memory accesses coherent. However, some GPUs do not have BAR1 functionality. For example, the GV11B found on the Xavier SoC is DMA coherent and therefore doesn't need BAR1. Implement a variant of FIFO channels that work without a mapping of instance memory through BAR1. XXX ensure memory barriers are

Thanks Ilia for the v2 review! Here is the v3 of this IOMMU support for GK20A series. Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove

Changes since v3: - Use a single dma_attr for all DMA-API allocations in instmem instead of one per allocation - Use device.info.ram_size instead of pfb->ram to check whether VRAM is present outside of nvkm Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into

Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to, and can trick

A series I have waited too long to submit, and the recent refactoring made me pay the price of my perfectionism, so here are the features that are at least completed Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to,

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

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

GK20A does not have dedicated RAM, thus having a RAM device for it does not make sense. Move the contiguous physical memory allocation to instmem. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/instmem.h | 1 + drm/nouveau/nvkm/engine/device/gk104.c | 2 +- drm/nouveau/nvkm/subdev/fb/ramgk20a.c | 86 +-----------

Spotted by coccinelle: drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nvkm/subdev/fuse/gm107.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/fuse/gm107.c b/drm/nouveau/nvkm/subdev/fuse/gm107.c index ba19158..0b256aa 100644

Let GK20A's instmem take advantage of the IOMMU if it is present. Having an IOMMU means that instmem is no longer allocated using the DMA API, but instead obtained through page_alloc and made contiguous to the GPU by IOMMU mappings. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 272 ++++++++++++++++++++++++++++---- 1 file

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

Two questions -- (a) What's the perf impact of doing this? Less work for the GPU MMU but more work for the IOMMU... (b) Would it be a good idea to do this for desktop GPUs that are on CPUs with IOMMUs in them (VT-d and whatever the AMD one is)? Is there some sort of shared API for this stuff that you should be (or are?) using? -ilia On Thu, Apr 16, 2015 at 7:06 AM, Vince Hsu <vinceh

On 8 June 2015 at 06:40, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > This commit introduces the NVIF_IOCTL_NEW_V0_PERFMON class which will be > used in order to query domains, signals and sources. This separates the > querying and the counting interface. Hey Samuel, I've merged patches 1-4 already, I've got some comments on this one, but after they're solved

Hello, This series exposes global performance counters (PCOUNTER) to the userspace through the nvif interface by reworking most of the code related to the PM engine. This interface will allow the userspace to control and monitor complex hardware events like the proprietary driver already does, for example with CUPTI and PerfKit. For now, this series only exposes performance counters on NV50,

nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau Cc: stable

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 <martin.peres at free.fr> --- configure.ac | 1 + drm/Kbuild | 4 ++ drm/core/include/subdev/fuse.h | 1 + drm/core/subdev/fuse/base.c | 1 + drm/core/subdev/fuse/g80.c | 1 +

Signed-off-by: John Rowley <john.rowley08 at gmail.com> --- nvkm/engine/device/nve0.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/nvkm/engine/device/nve0.c b/nvkm/engine/device/nve0.c index 964c183..6e72f9c 100644 --- a/nvkm/engine/device/nve0.c +++ b/nvkm/engine/device/nve0.c @@ -208,6 +208,41 @@ nve0_identify(struct nouveau_device *device)

MSI interrupts appear to not work for nv46 based cards. Change the mc subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is identical to the nv44 mc code except that it does not use msi (it does not define a msi_rearm callback). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435 Signed-off-by: Hans de Goede <hdegoede at redhat.com> ---

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Set the correct subdev/engine classes when GK20A (0xea) is probed. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git

On 01/01/14 00:55, Ilia Mirkin wrote: > On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce <sboyce at blueyonder.co.uk> wrote: >> On 31/12/13 10:36, Ilia Mirkin wrote: >>> On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce <sboyce at blueyonder.co.uk> >>> wrote: >>>> System x86_64 with openSUSE 13.1. >>>> X.Org version: 1.14.99.905 >>>>