Also fixes the values for Turing, even though we don't use it yet.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Mostly so we don't lose info hidden in falcon.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NVDEC is available from GM107, and we currently only have a stub
implementation anyway, let's make it explicit.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow us to register the falcon with ACR, and further customise
its behaviour by providing the nvkm_falcon_func structure directly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow for further customisation of the subdev depending on what
firmware is available.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow us to register the falcon with ACR, and further customise
its behaviour by providing the nvkm_falcon_func structure directly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow for further customisation of the subdev depending on what
firmware is available.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

ACR LS FW loading is moving out of SECBOOT and into their specific subdevs,
and the available GP108/GV100 FWs differ from the other GP10x boards.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow us to register the falcon with ACR, and further customise
its behaviour by providing the nvkm_falcon_func structure directly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow for further customisation of the subdev depending on what
firmware is available.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

ACR LS FW loading is moving out of SECBOOT and into their specific subdevs,
and the available GP107/GP108 FWs have interface differences.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It serves the exact same purpose.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow us to register the falcon with ACR, and further customise
its behaviour by providing the nvkm_falcon_func structure directly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow for further customisation of the subdev depending on what
firmware is available.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

ACR LS FW loading is moving out of SECBOOT and into their specific subdevs,
and the available GM20B/GP10B FWs have interface differences.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow us to register the falcon with ACR, and further customise
its behaviour by providing the nvkm_falcon_func structure directly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow for further customisation of the subdev depending on what
firmware is available.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

PMU, SEC2 and GR will be modified to register their falcons with ACR before
the main commit switching everything over.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will replace the current SECBOOT subdev for handling firmware on
secure falcons.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Will be used in upcoming commits to allow subdevs to better customise
themselves based on which (if any) firmware is available.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These will be used in upcoming commits which will provide more customisation.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Shortcut to avoid each subdev having to do this itself.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We want to be able to register falcons with ACR during the constructor for
the subdev it belongs to, however, we may not have access to the falcon's
registers prior to DEVINIT.

Delay touching registers until the first time the falcon is acquired.

This may temporarily break secboot on non-production boards due to not
being able to determine whether the falcon is in debug or production mode,
the new ACR subdev will not have this issue, and it's not a use-case that's
terribly important for bisectability.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new:
drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:
drivers/gpu/drm/nouveau/nouveau_ttm.c:106:22: warning: variable mem set but not used [-Wunused-but-set-variable]

They are not used any more, so remove it.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.

Fixes: 0ec5f02f ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>