drm/nouveau: check kind validity against mmu object
This is already handled in the top-level gem_new() ioctl in another manner, but this will be removed in a future commit. Ideally we'd not need to check up-front at all, and let the VMM code handle error checking, but there are paths in the current BO management code where this isn't possible due to map() not always being called during BO creation, and map() calls not being allowed to fail during buffer migration. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This commit is contained in:
parent
01670a79d5
commit
a220dd7321
|
@ -189,6 +189,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
|
|||
{
|
||||
struct nouveau_drm *drm = cli->drm;
|
||||
struct nouveau_bo *nvbo;
|
||||
struct nvif_mmu *mmu = &cli->mmu;
|
||||
size_t acc_size;
|
||||
int ret;
|
||||
int type = ttm_bo_type_device;
|
||||
|
@ -215,11 +216,20 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
|
|||
|
||||
if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
|
||||
nvbo->kind = (tile_flags & 0x0000ff00) >> 8;
|
||||
nvbo->comp = gf100_pte_storage_type_map[nvbo->kind] != nvbo->kind;
|
||||
if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
|
||||
kfree(nvbo);
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
|
||||
} else
|
||||
if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
|
||||
nvbo->kind = (tile_flags & 0x00007f00) >> 8;
|
||||
nvbo->comp = (tile_flags & 0x00030000) >> 16;
|
||||
if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
|
||||
kfree(nvbo);
|
||||
return -EINVAL;
|
||||
}
|
||||
} else {
|
||||
nvbo->zeta = (tile_flags & 0x00000007);
|
||||
}
|
||||
|
@ -232,7 +242,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
|
|||
nvbo->page = drm->client.vm->mmu->lpg_shift;
|
||||
else {
|
||||
if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI)
|
||||
nvbo->kind = gf100_pte_storage_type_map[nvbo->kind];
|
||||
nvbo->kind = mmu->kind[nvbo->kind];
|
||||
nvbo->comp = 0;
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue