similar to: [PATCH 0/6] map big page by platform IOMMU

On Sat, Apr 18, 2015 at 12:37 AM, Terje Bergstrom <tbergstrom at nvidia.com> wrote: > > On 04/17/2015 02:11 AM, Alexandre Courbot wrote: >> >> Tracking the PDE and PTE of each memory chunk can probably be avoided >> if you change your unmapping strategy. Currently you are going through >> the list of nvkm_vm_bp_list, but you know your PDE and PTE are always

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

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,

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

On Thu, Apr 16, 2015 at 8:06 PM, Vince Hsu <vinceh at nvidia.com> wrote: > Some platforms have IOMMU to map non-contiguous physical memory into > contiguous GPU virtual address. We can use this feature to enable big pages > mapping on scattered small pages. To achieve that, we also need changes in > subdev/mmu as well. > > Signed-off-by: Vince Hsu <vinceh at

From: Deepak Goyal <dgoyal at nvidia.com> - Maps PMU firmware into PMU virtual memory. - Copy bootloader into PMU memory and start it. - Allow the PMU to interact with HOST via interrupts. PMU after successful configurations (to follow after this patch) will: 1.Autonomously power gate graphics engine when not in use.It will save us a lot of power. 2.Provide better way to scale frequencies

These are based on 5.8.0-rc2 and intended for Ben Skeggs' nouveau tree. I believe the changes can be queued for 5.8-rcX after being reviewed. These were part of a larger series but I'm resending them separately as suggested by Jason Gunthorpe. https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell at nvidia.com/ Note that in order to exercise/test patch 2 here, you will need a

On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > I think I found at least two cases where "12" was used where it should > have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This > is only the tip of the iceberg, so this isn't a formal patch submission, > but I would appreciate your thought as to whether the below is correct > (and thus

On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote: > > Additionally the current code is broken in that the upper layer in > > vm/base.c doesn't increment "pte" by the right amount. > > > > Now, if those two assertions can be made always true: > > > > - Those two functions (map_sg and map_sg_table) never deal with the > > "big"

On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > index 5c7433d..c314a5f 100644 > > --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > @@ -190,8 +190,8 @@

From: Jérôme Glisse <jglisse at redhat.com> (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)). git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00

Op 11-08-13 07:36, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: >> Now, to do that, I need a better understanding of the various things >> in there since I'm not familiar with nouveau at all. What I think I've >> figured out is with a few questions, it would be awesome if you could >> answer them so I can have

Some Tegra drivers might be compiled as kernel modules, and they need the fuse information for initialization. One example is the GK20A Nouveau driver. It needs the GPU speedo value to calculate frequency-voltage table. So export the tegra_sku_info. Signed-off-by: Vince Hsu <vinceh at nvidia.com> Acked-by: Alexandre Courbot <acourbot at nvidia.com> Acked-by: Thierry Reding <treding

New version of the secure boot code that works with the blobs just merged into linux-firmware. Since the required Mesa patches are also merged, this set is the last piece of the puzzle to get out-of-the-box accelerated Maxwell 2. The basic code remains the same, with a few improvements with respect to how secure falcons are started. Hopefully the patchset is better split too. I have a

Hi folks ! So I've been trying to figure out what it would take to make nouveau work properly on architectures where PAGE_SIZE isn't 4k such as most ppc64's. An initial patch from Dave fixed a bogon in nv41.c nv41_vm_map_sg() which was trying to handle the case at that low level, but this isn't enough, and after a bit of digging, I also think that's not the right approach:

- Maps PMU firmware into PMU virtual memory. - Copy bootloader into PMU memory and start it. - Allow the PMU to interact with HOST via interrupts. PMU after successful configurations (to follow after this patch) will: 1.Autonomously power gate graphics engine when not in use.It will save us a lot of power. 2.Provide better way to scale frequencies by reporting Perf counters. 3.Be critical for GPU

This is a highly changed revision of the first patch series that adds secure boot support to Nouveau. This code still depends on NVIDIA releasing official firmware files, but the files released with SHIELD TV and Pixel C can already be used on a Jetson TX1. As you know we are working hard to release the official firmware files, however in the meantime it doesn't hurt to review the code so it

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to