search for: memtype_valid

After observing random crashes on Tegra devices when patch "fb/gf100: defer DMA mapping of scratch page to oneinit() hook" was applied, I noticed that moving the 100c10 page allocation to the oneinit() hook resulted in that page being now allocated for Tegra as well, and accesses be made to members of gf100_fb which were not accessible because gk20a_fb_new() called nvkm_fb_new_()

...U_GEM_EXPLICIT_SYNC) + nvbo->bo_flags |= NOUVEAU_GEM_EXPLICIT_SYNC; + else + nvbo->bo_flags &= ~NOUVEAU_GEM_EXPLICIT_SYNC; + return 0; } @@ -231,14 +245,15 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data, struct nouveau_bo *nvbo = NULL; int ret = 0; - if (!pfb->memtype_valid(pfb, req->info.tile_flags)) { - NV_PRINTK(error, cli, "bad page flags: 0x%08x\n", req->info.tile_flags); + if (!pfb->memtype_valid(pfb, req->info.bo_flags)) { + NV_PRINTK(error, cli, "bad page flags: 0x%08x\n", + req->info.bo_flags); return -EINVAL; }...

...pfb = nvxx_fb(&drm->device); > + struct drm_nouveau_gem_set_tiling *req = data; > + struct drm_gem_object *gem; > + struct nouveau_bo *nvbo; > + struct nvkm_vma *vma; > + int ret = 0; > + > + if (!nouveau_staging_tiling) > + return -EINVAL; > + > + if (!pfb->memtype_valid(pfb, req->tile_flags)) { > + NV_PRINTK(error, cli, "bad page flags: 0x%08x\n", req->tile_flags); > + return -EINVAL; > + } > + > + gem = drm_gem_object_lookup(dev, file_priv, req->handle); > + if (!gem) > + return -ENOENT; > + > + nvbo = nouveau_gem_...

...nvkm/subdev/fb/gm107.c index 2a91df8..9cc7e61 100644 --- a/drm/nouveau/nvkm/subdev/fb/gm107.c +++ b/drm/nouveau/nvkm/subdev/fb/gm107.c @@ -29,7 +29,7 @@ gm107_fb = { .dtor = gf100_fb_dtor, .init = gf100_fb_init, .intr = gf100_fb_intr, - .ram_new = gm107_ram_new, + .ram_new = gk104_ram_new, .memtype_valid = gf100_fb_memtype_valid, }; -- 2.7.2

...0A's FB is similar to GF100's, but without the ability to allocate VRAM */ static const struct nvkm_fb_func gk20a_fb = { + .dtor = gf100_fb_dtor, .oneinit = gf100_fb_oneinit, - .init = gk20a_fb_init, + .init = gf100_fb_init, .init_page = gf100_fb_init_page, + .intr = gf100_fb_intr, .memtype_valid = gf100_fb_memtype_valid, }; -- 2.10.0

...ON WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ +#include "gf100.h" + +static const struct nvkm_fb_func +gp10b_fb = { + .dtor = gf100_fb_dtor, + .oneinit = gf100_fb_oneinit, + .init = gm200_fb_init, + .init_page = gm200_fb_init_page, + .intr = gf100_fb_intr, + .memtype_valid = gf100_fb_memtype_valid, +}; + +int +gp10b_fb_new(struct nvkm_device *device, int index, struct nvkm_fb **pfb) +{ + return gf100_fb_new_(&gp10b_fb, device, index, pfb); +} -- 2.12.0

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

A quick look over the memory reclocking part inside the maxwell mmiotraces kind of reminded me of the kepler memory reclocking, it looks for most parts the same. I didn't do a deep inspection so treat this with great care, but it seems to work at least on those maxwell gpus this was tested on. It depends on the PMU fixes for the fuc5 though, otherwise the PMU might not work as expected and

...e "gf100.h" + +/* GM20B's FB is similar to GM200, but without the ability to allocate VRAM */ +static const struct nvkm_fb_func +gm20b_fb = { + .dtor = gf100_fb_dtor, + .oneinit = gf100_fb_oneinit, + .init = gm200_fb_init, + .init_page = gm200_fb_init_page, + .intr = gf100_fb_intr, + .memtype_valid = gf100_fb_memtype_valid, +}; + +int +gm20b_fb_new(struct nvkm_device *device, int index, struct nvkm_fb **pfb) +{ + return gf100_fb_new_(&gm20b_fb, device, index, pfb); +} -- 2.10.0

...&pfb->ram); + if (pfb->ram) { + nvkm_mm_fini(&pfb->vram); + nvkm_object_ref(NULL, (struct nvkm_object **)&pfb->ram); + } + nvkm_subdev_destroy(&pfb->base); } @@ -127,6 +134,9 @@ nvkm_fb_create_(struct nvkm_object *parent, struct nvkm_object *engine, pfb->memtype_valid = impl->memtype; + if (!impl->ram) + return 0; + ret = nvkm_object_ctor(nv_object(pfb), NULL, impl->ram, NULL, 0, &ram); if (ret) { nv_fatal(pfb, "error detecting memory configuration!!\n"); diff --git a/drm/nouveau/nvkm/subdev/ltc/gf100.c b/drm/nouveau/nvkm/subdev/...

...&pfb->ram); + if (pfb->ram) { + nvkm_mm_fini(&pfb->vram); + nvkm_object_ref(NULL, (struct nvkm_object **)&pfb->ram); + } + nvkm_subdev_destroy(&pfb->base); } @@ -127,6 +134,9 @@ nvkm_fb_create_(struct nvkm_object *parent, struct nvkm_object *engine, pfb->memtype_valid = impl->memtype; + if (!impl->ram) + return 0; + ret = nvkm_object_ctor(nv_object(pfb), NULL, impl->ram, NULL, 0, &ram); if (ret) { nv_fatal(pfb, "error detecting memory configuration!!\n"); diff --git a/drm/nouveau/nvkm/subdev/ltc/gf100.c b/drm/nouveau/nvkm/subdev/...

...&pfb->ram); + if (pfb->ram) { + nvkm_mm_fini(&pfb->vram); + nvkm_object_ref(NULL, (struct nvkm_object **)&pfb->ram); + } + nvkm_subdev_destroy(&pfb->base); } @@ -127,6 +134,9 @@ nvkm_fb_create_(struct nvkm_object *parent, struct nvkm_object *engine, pfb->memtype_valid = impl->memtype; + if (!impl->ram) + return 0; + ret = nvkm_object_ctor(nv_object(pfb), NULL, impl->ram, NULL, 0, &ram); if (ret) { nv_fatal(pfb, "error detecting memory configuration!!\n"); diff --git a/drm/nouveau/nvkm/subdev/ltc/gf100.c b/drm/nouveau/nvkm/subdev/...

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

...m); > + nvkm_object_ref(NULL, (struct nvkm_object **)&pfb->ram); > + } > + > nvkm_subdev_destroy(&pfb->base); > } > > @@ -127,6 +134,9 @@ nvkm_fb_create_(struct nvkm_object *parent, struct nvkm_object *engine, > > pfb->memtype_valid = impl->memtype; > > + if (!impl->ram) > + return 0; > + > ret = nvkm_object_ctor(nv_object(pfb), NULL, impl->ram, NULL, 0, &ram); > if (ret) { > nv_fatal(pfb, "error detecting memory configuration!!\n")...

...pfb = nvxx_fb(&drm->device); > + struct drm_nouveau_gem_set_tiling *req = data; > + struct drm_gem_object *gem; > + struct nouveau_bo *nvbo; > + struct nvkm_vma *vma; > + int ret = 0; > + > + if (!nouveau_staging_tiling) > + return -EINVAL; > + > + if (!pfb->memtype_valid(pfb, req->tile_flags)) { > + NV_PRINTK(error, cli, "bad page flags: 0x%08x\n", req->tile_flags); > + return -EINVAL; > + } > + > + gem = drm_gem_object_lookup(dev, file_priv, req->handle); > + if (!gem) > + return -ENOENT; > + > + nvbo = nouveau_gem_...

Hello all, this series includes a wide range of fixes - from a few month's old one-liners from Andreas Heider regarding vga_switcheroo, via a null pointer dereference and double memory allocation, to a buffer overflow. Please review and comment --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_device.c | 26 +++++++++++++++-----------

...0, 0, 0, 0, 0, 0, 3, - 3, 3, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 3, 3, 3, - 3, 3, 0, 0, 0, 0, 0, 0, 3, 0, 0, 3, 0, 3, 0, 3, - 3, 0, 3, 3, 3, 3, 3, 0, 0, 3, 0, 3, 0, 3, 3, 0, - 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 0, 1, 1, 0 -}; +extern const u8 nvc0_pte_storage_type_map[256]; + static bool nvc0_fb_memtype_valid(struct nouveau_fb *pfb, u32 tile_flags) { u8 memtype = (tile_flags & 0x0000ff00) >> 8; - return likely((types[memtype] == 1)); + return likely((nvc0_pte_storage_type_map[memtype] != 0xff)); } static int @@ -130,6 +111,7 @@ nvc0_fb_vram_new(struct nouveau_fb *pfb, u64 size, u32 alig...

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

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes

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