search for: nvkm_mem

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

...lass; diff --git a/drm/nouveau/nvkm/subdev/fb/ramgk20a.c b/drm/nouveau/nvkm/subdev/fb/ramgk20a.c index 5f30db1..60d8e1c 100644 --- a/drm/nouveau/nvkm/subdev/fb/ramgk20a.c +++ b/drm/nouveau/nvkm/subdev/fb/ramgk20a.c @@ -23,99 +23,17 @@ #include <core/device.h> -struct gk20a_mem { - struct nvkm_mem base; - void *cpuaddr; - dma_addr_t handle; -}; -#define to_gk20a_mem(m) container_of(m, struct gk20a_mem, base) - static void gk20a_ram_put(struct nvkm_fb *pfb, struct nvkm_mem **pmem) { - struct device *dev = nv_device_base(nv_device(pfb)); - struct gk20a_mem *mem = to_gk20a_mem(*pmem); - - *p...

...nouveau_bo.c > +++ b/drm/nouveau/nouveau_bo.c > @@ -178,6 +178,24 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags, > *size = roundup(*size, PAGE_SIZE); > } > > +void > +nouveau_bo_update_tiling(struct nouveau_drm *drm, struct nouveau_bo *nvbo, > + struct nvkm_mem *mem) > +{ > + switch (drm->device.info.family) { > + case NV_DEVICE_INFO_V0_TESLA: > + if (drm->device.info.chipset != 0x50) > + mem->memtype = (nvbo->tile_flags & 0x7f00) >> 8; > + break; > + case NV_DEVICE_INFO_V0_FERMI: > + case NV_DEVICE_INFO_V...

...r of staging ioctls is limited to 8 (range 0x98 to 0xa0) that are to be recycled as staging ioctls become stable and are assigned a final number. Changes since v1: - Use one module option per staging ioctl - Only allow GEM_SET_TILING to be called on dma-buf imported buffers - Move the code setting nvkm_mem::memtype into its own function to avoid duplicating code Alexandre Courbot (1): drm/nouveau: placeholders for staging ioctls Ari Hirvonen (1): drm/nouveau: add GEM_SET_TILING staging ioctl drm/nouveau/nouveau_bo.c | 18 ++++++++++++ drm/nouveau/nouveau_bo.h | 2 ++ dr...

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

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

...#include <core/mm.h> > #include <core/device.h> > > +#ifdef __KERNEL__ > +#include <linux/dma-attrs.h> > +#endif > + > #include "priv.h" > > struct gk20a_instobj_priv { > @@ -34,6 +38,7 @@ struct gk20a_instobj_priv { > struct nvkm_mem _mem; > void *cpuaddr; > dma_addr_t handle; > + struct dma_attrs attrs; > struct nvkm_mm_node r; > }; > > @@ -91,8 +96,8 @@ gk20a_instobj_dtor(struct nvkm_object *object) > if (unlikely(!node->handle)) > return; &g...

...> + > +struct gk20a_mmu_iommu_mapping { > + struct nvkm_mm_node *node; > + u64 iova; > +}; > + > +extern const u8 gf100_pte_storage_type_map[256]; > + > +static void > +gk20a_vm_map(struct nvkm_vma *vma, struct nvkm_gpuobj *pgt, > + struct nvkm_mem *mem, u32 pte, u64 list) > +{ > + u32 target = (vma->access & NV_MEM_ACCESS_NOSNOOP) ? 7 : 5; > + u64 phys; > + > + pte <<= 3; > + phys = gf100_vm_addr(vma, list, mem->memtype, target); > + > + if (mem->tag) { > +...

...t;subdev/fb.h> #include <core/mm.h> #include <core/device.h> #ifdef __KERNEL__ #include <linux/dma-attrs.h> +#include <linux/iommu.h> +#include <nouveau_platform.h> #endif #include "priv.h" @@ -36,18 +56,51 @@ struct gk20a_instobj_priv { struct nvkm_mem *mem; /* Pointed by mem */ struct nvkm_mem _mem; +}; + +/* + * Used for objects allocated using the DMA API + */ +struct gk20a_instobj_dma { + struct gk20a_instobj_priv base; + void *cpuaddr; dma_addr_t handle; struct dma_attrs attrs; struct nvkm_mm_node r; }; +/* + * Used for object...

...de <subdev/bios/M0209.h> int nvkm_ram_ctor(const struct nvkm_ram_func *, struct nvkm_fb *, enum nvkm_ram_type, u64 size, u32 tags, @@ -24,6 +25,22 @@ int gf100_ram_ctor(const struct nvkm_ram_func *, struct nvkm_fb *, int gf100_ram_get(struct nvkm_ram *, u64, u32, u32, u32, struct nvkm_mem **); void gf100_ram_put(struct nvkm_ram *, struct nvkm_mem **); +/* Training */ +struct gt215_ram_train { + u16 mask; + struct nvbios_M0209S remap; + struct nvbios_M0209S type00; + struct nvbios_M0209S type01; + struct nvbios_M0209S type04; + struct nvbios_M0209S type06; + struct nvbios_M0209S t...

...rm/nouveau/nvkm/subdev/instmem/gk20a.c @@ -24,6 +24,10 @@ #include <core/mm.h> #include <core/device.h> +#ifdef __KERNEL__ +#include <linux/dma-attrs.h> +#endif + #include "priv.h" struct gk20a_instobj_priv { @@ -34,6 +38,7 @@ struct gk20a_instobj_priv { struct nvkm_mem _mem; void *cpuaddr; dma_addr_t handle; + struct dma_attrs attrs; struct nvkm_mm_node r; }; @@ -91,8 +96,8 @@ gk20a_instobj_dtor(struct nvkm_object *object) if (unlikely(!node->handle)) return; - dma_free_coherent(dev, node->mem->size << PAGE_SHIFT, node->cpuaddr,...

...rm/nouveau/nvkm/subdev/instmem/gk20a.c @@ -24,6 +24,10 @@ #include <core/mm.h> #include <core/device.h> +#ifdef __KERNEL__ +#include <linux/dma-attrs.h> +#endif + #include "priv.h" struct gk20a_instobj_priv { @@ -34,6 +38,7 @@ struct gk20a_instobj_priv { struct nvkm_mem _mem; void *cpuaddr; dma_addr_t handle; + struct dma_attrs attrs; struct nvkm_mm_node r; }; @@ -91,8 +96,8 @@ gk20a_instobj_dtor(struct nvkm_object *object) if (unlikely(!node->handle)) return; - dma_free_coherent(dev, node->mem->size << PAGE_SHIFT, node->cpuaddr,...

...nouveau_bo.c > +++ b/drm/nouveau/nouveau_bo.c > @@ -178,6 +178,24 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags, > *size = roundup(*size, PAGE_SIZE); > } > > +void > +nouveau_bo_update_tiling(struct nouveau_drm *drm, struct nouveau_bo *nvbo, > + struct nvkm_mem *mem) > +{ > + switch (drm->device.info.family) { > + case NV_DEVICE_INFO_V0_TESLA: > + if (drm->device.info.chipset != 0x50) > + mem->memtype = (nvbo->tile_flags & 0x7f00) >> 8; > + break; > + case NV_DEVICE_INFO_V0_FERMI: > + case NV_DEVICE_INFO_V...

...;ltrain; - struct nvkm_device *device = ram->base.fb->subdev.device; - struct nvkm_bios *bios = device->bios; + struct gt215_ram *gt215 = gt215_ram(ram); + struct gt215_ram_train_ddr3 *train_ddr3 = &gt215->ltrain; + struct nvkm_device *device = ram->fb->subdev.device; struct nvkm_mem *mem; - struct nvbios_M0205E M0205E; - u8 ver, hdr, cnt, len; u32 r001700; int ret, i = 0; - train->state = NVA3_TRAIN_UNSUPPORTED; + train_ddr3->state = NVA3_TRAIN_UNSUPPORTED; /* We support type "5" * XXX: training pattern table appears to be unused for this routine *...

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 specify the tiling options of a PRIME-imported buffer. The staging parameter will allow us

No, no, these will not implement Fermi reclocking. This set of patches contains some of the preparatory work that I deem stable enough to move upstream. Notable changes - Training pattern upload routines from GK104+ now shared with GT215+ - Timing calculation for Fermi - GDDR5 MR calculation from VBIOS timing table v1.0. Also useful for that pesky GT 240. - A routine to translate a VBIOS init

Two patches went missing as a result of PEBCAK. No v2 marks as nothing changed really. Just resending for easier enforcement of patch order in other people's trees. Sorry for the noise. Original message: No, no, these will not implement Fermi reclocking. This set of patches contains some of the preparatory work that I deem stable enough to move upstream. Notable changes - Training pattern

I've splitted my big series between the part which actually fixes the engine reclocking bits and the part handling voltage/clock updates on temperature change, so that the more reviewed parts can be merged in faster. This series fixes a lot of Engine reclocking issues found on Fermi, Kepler and all Maxwell generation GPUs. It does _not_ fix memory reclocking on Fermi. It mostly contains of