summaryrefslogtreecommitdiffstats
path: root/hdata/iohub.c
diff options
context:
space:
mode:
authorBalbir Singh <bsingharora@gmail.com>2018-04-23 11:43:12 +1000
committerStewart Smith <stewart@linux.ibm.com>2018-04-23 00:06:59 -0500
commit2947eaa14e771e572d4e84bf003318c590c1c7d4 (patch)
tree01d8f092fa2c30f50438f655808b233e2c338c2b /hdata/iohub.c
parent4ca5fac2c3b3571bc8ac9b1c28d0cf4ee3efaaeb (diff)
downloadblackbird-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
OpenPOWER on IntegriCloud