diff options
author | Balbir Singh <bsingharora@gmail.com> | 2018-04-23 11:43:12 +1000 |
---|---|---|
committer | Stewart Smith <stewart@linux.ibm.com> | 2018-04-23 00:06:59 -0500 |
commit | 2947eaa14e771e572d4e84bf003318c590c1c7d4 (patch) | |
tree | 01d8f092fa2c30f50438f655808b233e2c338c2b /hdata/iohub.c | |
parent | 4ca5fac2c3b3571bc8ac9b1c28d0cf4ee3efaaeb (diff) | |
download | blackbird-skiboot-2947eaa14e771e572d4e84bf003318c590c1c7d4.tar.gz blackbird-skiboot-2947eaa14e771e572d4e84bf003318c590c1c7d4.zip |
npu2/hw-procedures: fence bricks on GPU reset
The NPU workbook defines a way of fencing a brick and
getting the brick out of fence state. We do have an implementation
of bringing the brick out of fenced/quiesced state. We do
the latter in our procedures, but to support run time reset
we need to do the former.
The fencing ensures that access to memory behind the links
will not lead to HMI's, but instead SUE's will be populated
in cache (in the case of speculation). The expectation is then
that prior to and after reset, the operating system components
will flush the cache for the region of memory behind the GPU.
This patch does the following:
1. Implements a npu2_dev_fence_brick() function to set/clear
fence state
2. Clear FIR bits prior to clearing the fence status
3. Clear's the fence status
4. We take the powerbus out of CQ fence much later now,
in credits_check() which is the last hardware procedure
called after link training.
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Diffstat (limited to 'hdata/iohub.c')
0 files changed, 0 insertions, 0 deletions