Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
583f12a8 |
| 09-May-2023 |
Ofir Bitton <obitton@habana.ai> |
accel/habanalabs: remove support for mmu disable
As mmu disable mode is only used for bring-up stages, let's remove this option and all code related to it.
Signed-off-by: Ofir Bitton <obitton@haban
accel/habanalabs: remove support for mmu disable
As mmu disable mode is only used for bring-up stages, let's remove this option and all code related to it.
Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
adda800c |
| 03-May-2023 |
Oded Gabbay <ogabbay@kernel.org> |
accel/habanalabs: print max timeout value on CS stuck
If a workload got stuck, we print an error to the kernel log about it. Add to that print the configured max timeout value, as that value is not
accel/habanalabs: print max timeout value on CS stuck
If a workload got stuck, we print an error to the kernel log about it. Add to that print the configured max timeout value, as that value is not fixed between ASICs and in addition it can be configured using a kernel module parameter.
Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Ofir Bitton <obitton@habana.ai>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
9a4e44a4 |
| 04-Dec-2022 |
Koby Elbaz <kelbaz@habana.ai> |
accel/habanalabs: refactor abort of completions and waits
Aborting CS completions should be in command_submission.c but aborting waiting for user interrupts should be in device.c.
This separation i
accel/habanalabs: refactor abort of completions and waits
Aborting CS completions should be in command_submission.c but aborting waiting for user interrupts should be in device.c.
This separation is also for adding more abort operations in the future.
Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
ad8bfd36 |
| 17-Apr-2023 |
Koby Elbaz <kelbaz@habana.ai> |
accel/habanalabs: minimize encapsulation signal mutex lock time
Sync Stream Encapsulated Signal Handlers can be managed from different contexts, and as such they are protected via a spin_lock. Howev
accel/habanalabs: minimize encapsulation signal mutex lock time
Sync Stream Encapsulated Signal Handlers can be managed from different contexts, and as such they are protected via a spin_lock. However, spin_lock was unnecessarily protecting a larger code section than really needed, covering a sleepable code section as well. Since spin_lock disables preemption, it could lead to sleeping in atomic context.
Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
f7f0085e |
| 15-Feb-2023 |
Koby Elbaz <kelbaz@habana.ai> |
accel/habanalabs: add uapi to stall/resume engine
The user might want to stall/resume engines to perform power testing for various scenarios. Because our current HL_CS_FLAGS_ENGINE_CORE_COMMAND comm
accel/habanalabs: add uapi to stall/resume engine
The user might want to stall/resume engines to perform power testing for various scenarios. Because our current HL_CS_FLAGS_ENGINE_CORE_COMMAND command only handles the engines' cores, we need to add another opcode for handling entire engine and not just its core.
The user supplies an array, where each entry holds the engine's ID and the command to send to the engine. The size of the array is limited by the number of engines in the ASIC (only Gaudi2 is currently supported).
Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
25ebbc57 |
| 23-Feb-2023 |
farah kassabri <fkassabri@habana.ai> |
accel/habanalabs: fix few misspelled words in the code
Run spell checker on the code and fix accordingly.
Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kerne
accel/habanalabs: fix few misspelled words in the code
Run spell checker on the code and fix accordingly.
Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
60122358 |
| 25-Jan-2023 |
Tal Cohen <talcohen@habana.ai> |
accel/habanalabs: change user interrupt to threaded IRQ
We prefer not to handle the user interrupt job inside the interrupt context. Instead, use threaded IRQ to handle the user interrupts. This wil
accel/habanalabs: change user interrupt to threaded IRQ
We prefer not to handle the user interrupt job inside the interrupt context. Instead, use threaded IRQ to handle the user interrupts. This will allow to avoid disabling interrupts when the user process registers for a new event and to avoid long handling inside an interrupt.
Signed-off-by: Tal Cohen <talcohen@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
show more ...
|
#
d43bce6e |
| 18-Jan-2023 |
Tomer Tayar <ttayar@habana.ai> |
accel/habanalabs: add info when FD released while device still in use
When user closes the device file descriptor, it is checked whether the device is still in use, and a message is printed if it is
accel/habanalabs: add info when FD released while device still in use
When user closes the device file descriptor, it is checked whether the device is still in use, and a message is printed if it is. To make this message more informative, add to this print also the reason due to which the device is considered as in use. The possible reasons which are checked for now are active CS and exported dma-buf.
Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
show more ...
|
#
6168a837 |
| 18-Jan-2023 |
Ofir Bitton <obitton@habana.ai> |
accel/habanalabs: increase user interrupt grace time
Currently we support scenarios where a timestamp registration request of a certain offset is received during the interrupt handling of the same o
accel/habanalabs: increase user interrupt grace time
Currently we support scenarios where a timestamp registration request of a certain offset is received during the interrupt handling of the same offset. In this case we give a grace period of up to 100us for the interrupt handler to finish. It seems that sometimes the interrupt handling takes more than expected, and therefore this path should be optimized. Until that happens, let's increase the grace period in order not to reach timeout which will cause user call to be rejected.
Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
show more ...
|
#
75b6984e |
| 10-Jan-2023 |
Ofir Bitton <obitton@habana.ai> |
habanalabs: optimize command submission completion timestamp
Completion timestamp is taken during the actual command submission release. As the release happens in a work queue, the timestamp taken i
habanalabs: optimize command submission completion timestamp
Completion timestamp is taken during the actual command submission release. As the release happens in a work queue, the timestamp taken is not accurate. Hence, we will take the timestamp in the interrupt handler itself while propagating it to the release function.
Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
ac5af990 |
| 10-Jan-2023 |
farah kassabri <fkassabri@habana.ai> |
habanalabs: fix bug in timestamps registration code
Protect re-using the same timestamp buffer record before actually adding it to the to interrupt wait list. Mark ts buff offset as in use in the sp
habanalabs: fix bug in timestamps registration code
Protect re-using the same timestamp buffer record before actually adding it to the to interrupt wait list. Mark ts buff offset as in use in the spinlock protection area of the interrupt wait list to avoid getting in the re-use section in ts_buff_get_kernel_ts_record before adding the node to the list. this scenario might happen when multiple threads are racing on same offset and one thread could set data in the ts buff in ts_buff_get_kernel_ts_record then the other thread takes over and get to ts_buff_get_kernel_ts_record and we will try to re-use the same ts buff offset then we will try to delete a non existing node from the list.
Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
72848de0 |
| 03-Jan-2023 |
farah kassabri <fkassabri@habana.ai> |
habanalabs: check pad and reserved fields in ioctls
Make sure all reserved/pad fields in uapi input structures are set to 0.
Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Ga
habanalabs: check pad and reserved fields in ioctls
Make sure all reserved/pad fields in uapi input structures are set to 0.
Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
20faaeec |
| 18-Dec-2022 |
Ohad Sharabi <osharabi@habana.ai> |
habanalabs: add uapi to flush inbound HBM transactions
When doing p2p with a NIC device, the NIC needs to make sure all the writes to the HBM (through the PCI bar of the Gaudi device) were flushed.
habanalabs: add uapi to flush inbound HBM transactions
When doing p2p with a NIC device, the NIC needs to make sure all the writes to the HBM (through the PCI bar of the Gaudi device) were flushed.
It can be done by either the NIC or the host reading through the PCI bar.
To support the host side, we supply a simple uapi to perform this flush through the driver, because the user can't create such a transaction by itself (the PCI bar isn't exposed to normal users).
Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|
#
e65e175b |
| 26-Dec-2022 |
Oded Gabbay <ogabbay@kernel.org> |
habanalabs: move driver to accel subsystem
Now that we have a subsystem for compute accelerators, move the habanalabs driver to it.
This patch only moves the files and fixes the Makefiles. Future p
habanalabs: move driver to accel subsystem
Now that we have a subsystem for compute accelerators, move the habanalabs driver to it.
This patch only moves the files and fixes the Makefiles. Future patches will change the existing code to register to the accel subsystem and expose the accel device char files instead of the habanalabs device char files.
Update the MAINTAINERS file to reflect this change.
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
show more ...
|