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:
Ben Skeggs 2017-11-01 03:56:19 +10:00
parent 01670a79d5
commit a220dd7321
1 changed files with 12 additions and 2 deletions

View File

@ -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;
}
}