kernel/git/stable/linux.git/drivers/misc/habanalabs/context.c, branch master

habanalabs: create common folder

2020-07-24T17:31:37+00:00

For internal needs of our CI we need to move all the common code into a common folder instead of putting them in the root folder of the driver. Same applies to the common header files under include/ Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

habanalabs: rephrase error messages

2020-07-24T17:31:35+00:00

rephrase some error/warning/notice messages to make them more accessible to ordinary users. There is no need to print context ASID as the driver currently doesn't support multiple contexts. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: Use pending CS amount per ASIC

2020-07-24T17:31:34+00:00

Training schemes requires much more concurrent command submissions than inference does. In addition, training command submissions can be completed in a non serialized manner. Hence, we add support in which each ASIC will be able to configure the amount of concurrent pending command submissions, rather than use a predefined amount. This change will enhance performance by allowing the user to add more concurrent work without waiting for the previous work to be completed. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay

habanalabs: add signal/wait to CS IOCTL operations

2020-05-19T11:48:41+00:00

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 Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay

habanalabs: rate limit error msg on waiting for CS

2019-12-14T13:12:21+00:00

In case a user submits a CS, and the submission fails, and the user doesn't check the return value and instead use the error return value as a valid sequence number of a CS and ask to wait on it, the driver will print an error and return an error code for that wait. The real problem happens if now the user ignores the error of the wait, and try to wait again and again. This can lead to a flood of error messages from the driver and even soft lockup event. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: stop using the acronym KMD

2019-09-05T11:55:27+00:00

We want to stop using the acronym KMD. Therefore, replace all locations (except for register names we can't modify) where KMD is written to other terms such as "Linux kernel driver" or "Host kernel driver", etc. Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

habanalabs: rename user_ctx as compute_ctx

2019-09-05T11:55:26+00:00

This patch renames the "user_ctx" field in the device structure to "compute_ctx". This better reflects the meaning of this context. In addition, we also check in the ctx_fini() that the debug mode should be disabled only if the context being destroyed is the compute context. This has no effect right now as we only have a single process and a single context, but this makes the code more ready for multiple process support. Signed-off-by: Oded Gabbay Reviewed-by: Greg Kroah-Hartman

habanalabs: add handle field to context structure

2019-09-05T11:55:26+00:00

This patch adds a field to the context's structure that will hold a unique handle for the context. This will be needed when the user will create the context. Signed-off-by: Oded Gabbay Reviewed-by: Greg Kroah-Hartman

habanalabs: initialize MMU context for driver

2019-05-29T12:27:48+00:00

This patch initializes the MMU structures for the kernel context. This is needed before we can configure mappings for the kernel context. Signed-off-by: Oded Gabbay

habanalabs: force user to set device debug mode

2019-05-04T14:36:06+00:00

This patch adds the implementation of the HL_DEBUG_OP_SET_MODE opcode in the DEBUG IOCTL. It forces the user who wants to debug the device to set the device into debug mode before he can configure the debug engines. The patch also makes sure to disable debug mode upon user releasing FD, in case the user forgot to disable debug mode. Signed-off-by: Oded Gabbay