talos-op-linux/drivers/misc/habanalabs, branch master

habanalabs: remove variable 'val' set but not used

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

Fixes gcc '-Wunused-but-set-variable' warning: drivers/misc/habanalabs/goya/goya.c: In function goya_pldm_init_cpu: drivers/misc/habanalabs/goya/goya.c:2195:6: warning: variable val set but not used [-Wunused-but-set-variable] drivers/misc/habanalabs/goya/goya.c: In function goya_hw_init: drivers/misc/habanalabs/goya/goya.c:2505:6: warning: variable val set but not used [-Wunused-but-set-variable] Fixes: 9494a8dd8d22 ("habanalabs: add h/w queues module") Signed-off-by: Chen Wandun 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: add more protection of device during reset

2019-11-21T09:35:47+00:00

Prevent accesses to the device (register read/write) from debugfs entries during reset as that can cause the device to get stuck. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: flush EQ workers in hard reset

2019-11-21T09:35:47+00:00

During hard-reset, there can be multiple events received from the H/W. For each event, the driver opens a worker thread to handle it. For some of the events, the driver will read/write registers in the code that handles the event. In case of hard-reset, we must prevent reads/writes to the registers during the reset operation because the device might get stuck if that happens. Therefore, flush the EQ workers before resetting the device (in hard-reset only). Additional events won't arrive as we synced and disabled the interrupts. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: make the reset code more consistent

2019-11-21T09:35:47+00:00

In the hl_device_reset we ask about the hard_reset argument when we want to differentiate between soft and hard reset, except for three places where we use "from_hard_reset_thread". Replace one of those locations with the hard_reset argument as it is guaranteed that if we reached to that line in the code during hard_reset, it is from a kernel thread. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: expose reset counters via existing INFO IOCTL

2019-11-21T09:35:47+00:00

Expose both soft and hard reset counts via INFO IOCTL. This will allow system management applications to easily check if the device has undergone reset. Signed-off-by: Moti Haimovski Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay

habanalabs: make code more concise

2019-11-21T09:35:47+00:00

Instead of doing if inside if, just write them with && operator. Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

habanalabs: use defines for F/W files

2019-11-21T09:35:46+00:00

Make the code more concise and maintainable by using defines for the F/W files. Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

habanalabs: remove prints on successful device initialization

2019-11-21T09:35:46+00:00

Successful device initialization is mentioned in kernel log with the message "Successfully added device to habanalabs driver". There is no point of spamming the log with additional messages about successful queue testing, which are implied by the above mentioned message. Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

habanalabs: remove unnecessary checks

2019-11-21T09:35:46+00:00

Now that the VA block free list is not updated on context close in order to optimize this flow, no need in the sanity checks of the list contents as these will fail for sure. In addition, remove the "context closing with VA in use" print during hard reset as this situation is a side effect of the failure that caused the hard reset. Signed-off-by: Omer Shpigelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay