search for: gf100_fb_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_()

...m107.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

...imilar 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

...WARE 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

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

...quot; + +/* 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

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

GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for its base engines after reworking secboot a bit to accomodate its calling convention better. This patchset has been tested rendering simple off-screen buffers using Mesa and yielded the expected result. Alexandre Courbot (15): secboot: allow to boot multiple falcons secboot: pass instance to LS firmware loaders secboot: