- 26 Jan, 2023 40 commits
-
-
Ohad Sharabi authored
This function shall be used whenever components enable/binning masks should be updated. Usage is in one of the below cases: - update user (or default) component masks - update when getting the masks from FW (either CPUCP or COMMS) Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Koby Elbaz authored
When HL_INFO_USER_MAPPINGS IOCTL is called, we copy_to_user from a dynamically allocated memory - 'user_mappings'. Since freeing/allocating it happens in runtime (upon a page fault), it not unlikely to access it even before being initially allocated (i.e., accessing a NULL pointer). The solution is to simply mark the spot when the err info has been collected, and that way to know whether err info (either page fault or RAZWI) is available to be read. Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tom Rix authored
From reviewing the code, the line memset(kdata, 0, usize); is not needed because kdata is either zeroed by kdata = kzalloc(asize, GFP_KERNEL); when allocated at runtime or by char stack_kdata[128] = {0}; at compile time. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Koby Elbaz authored
This refactor makes the code clearer and the new variables' names better describe their roles. Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Koby Elbaz authored
It appears that, within the sync manager security configuration, we reconfigure PB registers over and over without any need to do that. Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ofir Bitton authored
During device acquire, the driver is using a QMAN for clearing some registers. In order to avoid internal races, the driver verifies the device is idle before submitting the register clear job. This check introduces an issue, as debug mode will cause the device to be non-idle which will lead to device acquire failure. In order to overcome this issue we can entirely remove the idle check as the driver is using the QMAN only when there is no active context. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Oded Gabbay authored
When entering an IOCTL, the driver prints a message in case device is not operational. This message should be printed in debug level as it can spam the kernel log and it is not an error. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Oded Gabbay authored
Update common firmware files with the latest version. There is no functional change. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Oded Gabbay authored
Update gaudi2 firmware files with the latest version. There is no functional change. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Oded Gabbay authored
Update some register files with the latest h/w auto-generated files. There is no functional change. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
Remove the distinction between user CB and kernel CB, and verify for both that they are not destroyed more than once. As kernel CB might be taken from the pre-allocated CB pool, so we need to clear the handle destroyed indication when returning a CB to the pool. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
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>
-
Oded Gabbay authored
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>
-
Oded Gabbay authored
Move the habanalabs.h uapi file from include/uapi/misc to include/uapi/drm, and rename it to habanalabs_accel.h. This is required before moving the actual driver to the accel subsystem. Update MAINTAINERS file accordingly. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
The dma-buf private object is freed if a call to dma_buf_fd() fails, and because a file was already associated with the dma-buf in dma_buf_export(), the release op will be called and will use this object. Mark the 'priv' field as NULL in this case, and avoid accessing it from the release op. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ofir Bitton authored
In order to have the no-cause error print be more informative, we add the event description in addition to the event id. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
farah kassabri authored
Add a uAPI, as part of the INFO IOCTL, to allow users to send requests directly to f/w, according to a pre-defined set of opcodes that the f/w exposes. The f/w will put the result in a kernel-allocated buffer, which the driver will then copy to the user-supplied buffer. This will allow f/w tools to communicate directly with the f/w without the need to add a new uAPI to the driver for each new type of request. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tal Cohen authored
An Ascii message that is sent from preboot towards the driver will indicate the specific error that occurred on the f/w. This commit supports that message and parse the ascii string in order to print it into the kernel log The commit also changes the way the descriptor struct is declared. While its size increased (it now above 1024 bytes), it will be allocated by using kmalloc instead of stack declaration. Signed-off-by: Tal Cohen <talcohen@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
- Add missing documentation of set DRAM props - fix typo Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
farah kassabri authored
vzalloc expects void* and not void __iomem*. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
Instead of waiting for BTM indication we should wait for preboot ready. Consider the below scenario: 1. FW update is being triggered - setting the dirty bit 2. hard reset will be triggered due to the dirty bit 3. FW initiates the reset: - dirty bit cleared - BTM indication cleared - preboot ready indication cleared 4. during hard reset: - BTM indication will be set - BIST test performed and another reset triggered 5. only after this reset the preboot will set the preboot ready When polling on BTM indication alone we can lose sync with FW while trying to communicate with FW that is during reset. To overcome this we will always wait to preboot ready indication. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
Need to put fences even if an unexpected status value is received while waiting for a fence. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
The -ERESTARTSYS return value is not handled correctly when a signal is received while waiting for CS completion. This can lead to bad output values to user when waiting for a single CS completion, and more severe, it can cause a non-stopping loop when waiting to multi-CS completion and until a CS timeout. Fix the handling and exit the waiting if this return value is received. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
This patch fixes a bug that was found in the dmabuf flow. Bug description as found on Gaudi2 device: 1. User allocates 4MB of device memory - Note that although the allocation size was 4MB the HMMU allocated a full page of 768MB to back the request. - The user gets a memory handle that points to a single page (768MB) - Mapping the handle, the user gets virtual address to the start of the page. 2. User exports the buffer 3. User registers the exported buffer in the importer. This flow has a callback to the exporter which in turn converts the phys_page_pack to an SG list for the importer. This SG list is of single entry of size 768MB. However, the size that was passed to the importer was only 4MB. The solution for this is to make sure the importer gets exposure only to the exported size. This will be done by fixing the SG created by the exporter to be of the total size of the actual exported memory requested by the user. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
A previous commit deprecated the option to export from handle, leaving the code with no support for devices with virtual memory. This commit modifies the export API in a way that unifies the uAPI to user address for both cases (i.e. with and without MMU support) and add the actual support for devices with virtual memory. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
Validate export parameters in a dedicated function instead of in the main export flow. This will be useful later when support to export dmabuf for devices with virtual memory will be added. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
The API to the user which allows exporting DMA buffer from handle is deprecated here. It was never used as it is relevant only for Gaudi2, and the user stack has yet to add support for dmabuf in Gaudi2. Looking forward, a modified API to export DMA buffer for ASICs that supports virtual memory will be added. Until the new API will be ready- exporting DMA buffer will not be supported for ASICs with virtual memory. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
farah kassabri authored
This warning doesn't have real consequences, and therefore can be printed in debug level. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
Call COMMS tracepoints from within the dynamic CPU FW load. This can help debug failures or delays in the dynamic FW load flow. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
As the COMMS protocol is being used more widely in our driver, an available debug tool for the handshake will be handy. This commit defines tracepoints to various key points of the COMMS protocol. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ofir Bitton authored
In certain scenarios, firmware might encounter a fatal event for which a device reset is required. Hence, a proper notification is needed for driver to be aware and initiate a reset sequence. In secured environments the reset will be performed by firmware without an explicit request from the driver. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
When user context is released and hpriv_release() is called, there is a device idle status check, to understand if user has left the device not idle and then a reset is required. However, if the user process is killed because of device hard reset, the device at this point would always be not idle, because the device engines were already forcefully halted. Modify hpriv_release() to skip the idle check if reset is in progress. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tamir Gilad-Raz authored
timestamp events that expire on the same interrupt will get the same timestamp value Signed-off-by: Tamir Gilad-Raz <tgiladraz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ofir Bitton authored
In order to reduce error log, we try to minimize the dumped rows while keeping all relevant error info. In addition we completely remove clock throttling debug logs. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ofir Bitton authored
During event handling we extract interrupt cause and count it. In case we could not find any cause we should add proper error. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
If the f/w reports the binning masks at the preboot stage, the driver must align its DRAM properties according to the new information. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Marco Pagani authored
Removing double assignment of the hop2_pte_addr variable in dram_default_mapping_fini(). Dead store reported by clang-analyzer. Signed-off-by: Marco Pagani <marpagan@redhat.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Ohad Sharabi authored
As ASICs are evolving, we will need to update the DRAM properties at various points because we may get different information from the f/w at different points of the initialization. This ASIC function is a foundation for this capability. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
As hl_mmap_mem_buf_get() is called also from IOCTLs which can have a bad handle from user, modify the print for "no match to handle" to use dev_dbg(). Calls to this function which are not dependent on user, already have an error print when the function fails. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-
Tomer Tayar authored
The refcount of a CB buffer is initialized when user allocates a CB, and is decreased when he destroys the CB handle. If this refcount is increased also from kernel and user sends more than one destroy requests for the handle, the buffer will be released/freed and later be accessed when the refcount is put from kernel side. To avoid it, prevent user from destroying the handle more than once. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
-