diff options
author | Ohad Sharabi <osharabi@habana.ai> | 2021-12-07 13:30:20 +0100 |
---|---|---|
committer | Oded Gabbay <ogabbay@kernel.org> | 2021-12-26 07:59:09 +0100 |
commit | e2558f0f84d85bfe2407b91d57798f133d8ad32a (patch) | |
tree | 8780499666f4ddfd5a5af42e69ea563f8a7d5d34 /include/uapi/misc | |
parent | habanalabs: modify cpu boot status error print (diff) | |
download | linux-e2558f0f84d85bfe2407b91d57798f133d8ad32a.tar.xz linux-e2558f0f84d85bfe2407b91d57798f133d8ad32a.zip |
habanalabs: prevent wait if CS in multi-CS list completed
By the original design we assumed that if we "miss" multi CS completion
it is of no severe consequence as we'll just call wait_for_multi_cs
again.
Sequence of events for such scenario:
1. user submit CS with sequence N
2. user calls wait for multi-CS with only CS #N in the list
3. the multi CS call starts with poll of the CSs but find that none
completed (while CS #N did not completed yet)
4. now, multi CS #N complete but multi CS CTX was not yet created for
the above multi-CS. so, attempt to complete multi-CS fails (as no
multi CS CTX exist)
5. wait_for_multi_cs call now does init_wait_multi_cs_completion (and
for this create the multi-CS CTX)
6. wait_for_multi_cs wits on completion but will not get one as CS #N
already completed
To fix the issue we initialize the multi-CS CTX prior polling the
fences.
Signed-off-by: Ohad Sharabi <osharabi@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Diffstat (limited to 'include/uapi/misc')
0 files changed, 0 insertions, 0 deletions