diff options
author | Omer Shpigelman <oshpigelman@habana.ai> | 2020-05-07 14:31:49 +0300 |
---|---|---|
committer | Oded Gabbay <oded.gabbay@gmail.com> | 2020-05-19 14:48:41 +0300 |
commit | b75f22505ac97ea680bcc3e23dcd56f421252b43 (patch) | |
tree | e7bdf28528fded6b535633e989839af06e450718 /drivers/misc/habanalabs/habanalabs.h | |
parent | b0b5d92579c0970ad1f96cd6d6297c8d8ed8ed92 (diff) | |
download | linux-stable-b75f22505ac97ea680bcc3e23dcd56f421252b43.tar.gz linux-stable-b75f22505ac97ea680bcc3e23dcd56f421252b43.tar.bz2 linux-stable-b75f22505ac97ea680bcc3e23dcd56f421252b43.zip |
habanalabs: add signal/wait to CS IOCTL operations
Add the following two operations to the CS IOCTL:
Signal:
The signal operation is basically a command submission, that is created by
the driver upon user request. It will be implemented using a dedicated PQE
that will increment a specific SOB. There will be a new flag:
HL_CS_FLAGS_SIGNAL. When the user set this flag in the CS IOCTL structure,
the driver will execute a dedicated code path that will prepare this
special PQE and submit it. The user only needs to provide a queue index on
which to put the signal.
Wait:
The wait operation is also a command submission that is created by the
driver upon user request. It will be implemented using a dedicated PQE that
will contain packets of "ARM a monitor" + FENCE packet. There will be a new
flag: HL_CS_FLAGS_WAIT. When the user set this flag in the CS structure,
the driver will execute a dedicated code path that will prepare this
special PQE and submit it.
The user needs to provide the following parameters:
1. queue ID
2. an array of signal_seq numbers and the number of signals to wait on
(the length of signal_seq_arr).
The IOCTL will return the CS sequence number of the wait it put on the
queue ID.
Currently, the code supports signal_seq_nr==1. But this API definition will
allow us to put a single PQE that waits on multiple signals.
To correctly configure the monitor and fence, the driver will need to
retrieve the specified signal CS object that contains the relevant SOB and
its expected value. In case the signal CS has already been completed, there
is no point of adding a wait operation. In this case, the driver will
return to the user *without* putting anything on the PQ. The return code
should reflect to the user that the signal was completed, as we won't
return a CS sequence number for this wait.
Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai>
Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Diffstat (limited to 'drivers/misc/habanalabs/habanalabs.h')
-rw-r--r-- | drivers/misc/habanalabs/habanalabs.h | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/drivers/misc/habanalabs/habanalabs.h b/drivers/misc/habanalabs/habanalabs.h index 630ed43eb410..a68df32094f1 100644 --- a/drivers/misc/habanalabs/habanalabs.h +++ b/drivers/misc/habanalabs/habanalabs.h @@ -843,6 +843,7 @@ struct hl_userptr { * @fence: pointer to the fence object of this CS. * @signal_fence: pointer to the fence object of the signal CS (used by wait * CS only). + * @finish_work: workqueue object to run when CS is completed by H/W. * @work_tdr: delayed work node for TDR. * @mirror_node : node in device mirror list of command submissions. * @debugfs_list: node in debugfs list of command submissions. @@ -863,6 +864,7 @@ struct hl_cs { struct kref refcount; struct dma_fence *fence; struct dma_fence *signal_fence; + struct work_struct finish_work; struct delayed_work work_tdr; struct list_head mirror_node; struct list_head debugfs_list; |