summaryrefslogtreecommitdiff
path: root/drivers/misc/habanalabs
Commit message (Collapse)AuthorAgeFilesLines
* habanalabs: Fix test build failuresGuenter Roeck2022-04-041-8/+8
| | | | | | | | | | | | | | | | | allmodconfig builds on 32-bit architectures fail with the following error. drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory': drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size Fix the typecast. While at it, drop other unnecessary typecasts associated with the same commit. Fixes: e8458e20e0a3c ("habanalabs: make sure device mem alloc is page aligned") Cc: Ohad Sharabi <osharabi@habana.ai> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220404134859.3278599-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'char-misc-5.18-rc1' of ↵Linus Torvalds2022-03-2824-844/+1393
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc and other driver updates from Greg KH: "Here is the big set of char/misc and other small driver subsystem updates for 5.18-rc1. Included in here are merges from driver subsystems which contain: - iio driver updates and new drivers - fsi driver updates - fpga driver updates - habanalabs driver updates and support for new hardware - soundwire driver updates and new drivers - phy driver updates and new drivers - coresight driver updates - icc driver updates Individual changes include: - mei driver updates - interconnect driver updates - new PECI driver subsystem added - vmci driver updates - lots of tiny misc/char driver updates All of these have been in linux-next for a while with no reported problems" * tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (556 commits) firmware: google: Properly state IOMEM dependency kgdbts: fix return value of __setup handler firmware: sysfb: fix platform-device leak in error path firmware: stratix10-svc: add missing callback parameter on RSU arm64: dts: qcom: add non-secure domain property to fastrpc nodes misc: fastrpc: Add dma handle implementation misc: fastrpc: Add fdlist implementation misc: fastrpc: Add helper function to get list and page misc: fastrpc: Add support to secure memory map dt-bindings: misc: add fastrpc domain vmid property misc: fastrpc: check before loading process to the DSP misc: fastrpc: add secure domain support dt-bindings: misc: add property to support non-secure DSP misc: fastrpc: Add support to get DSP capabilities misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP misc: fastrpc: separate fastrpc device from channel context dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells dt-bindings: nvmem: make "reg" property optional nvmem: brcm_nvram: parse NVRAM content into NVMEM cells nvmem: dt-bindings: Fix the error of dt-bindings check ...
| * habanalabs: remove deprecated firmware statesOfir Bitton2022-02-281-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | During driver and F/W handshake, driver waits for F/W to reach certain states in order to progress with the boot flow. Some of the states were deprecated a long time ago and were never present on official firmwares. Therefore, let's remove them from the handshake process. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: add an option to delay a device resetTomer Tayar2022-02-283-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several H/W events can be sent adjacently, even due to a single error. If a hard-reset is triggered as part of handling one of these events, the following events won't be handled. The debug info from these missed events is important, sometimes even more important than the one that was handled. To allow handling these close events, add an option to delay a device reset and use it when resetting due to H/W events. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: Add check for pci_enable_deviceJiasheng Jiang2022-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | As the potential failure of the pci_enable_device(), it should be better to check the return value and return error if fails. Fixes: 70b2f993ea4a ("habanalabs: create common folder") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: Fix reset upon device release bugfarah kassabri2022-02-283-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case user application was interrupted while some cs still in-flight or in the middle of completion handling in driver, the last refcount of the kernel private data for the user process will not be put in the fd close flow, but in the cs completion workqueue context. This means that the device reset-upon-device-release will be called from that context. During the reset flow, the driver flushes all the cs workqueue to ensure that any scheduled work has run to completion, and since we are running from the completion context we will have deadlock. Therefore, we need to skip flushing the workqueue in those cases. It is safe to do it because the user won't be able to release the device unless the workqueues are already empty. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: make sure device mem alloc is page alignedOhad Sharabi2022-02-281-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Working with MMU that supports multiple page sizes requires that mapping of a page of a certain size will be aligned to the same size (e.g. the physical address of 32MB page shall be aligned to 32MB). To achieve this the gen_poll allocation is now using the "align" variant to comply with the alignment requirements. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs/gaudi: add missing handling of NIC related eventsOded Gabbay2022-02-282-0/+15
| | | | | | | | | | | | | | | | | | There are a few events that can arrive from the f/w and without proper handling can cause errors to appear in the kernel log without reason. Add the relevant handling that was missing. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs/gaudi: handle axi errors from NIC enginesOded Gabbay2022-02-281-0/+48
| | | | | | | | | | | | | | | | Various AXI errors can occur in the NIC engines and are reported to the driver by the f/w. Add code to print the errors and ack them to the f/w. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: allow user to set allocation page sizeOhad Sharabi2022-02-284-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In future ASICs the MMU will be able to work with multiple page sizes, thus a new flag is added to allow the user to set the requested page size. This flag is added since the whole DRAM is allocated for the user and the user also should be familiar with the memory usage use case. As such, the user may choose to "over allocate" memory in favor of performance (for instance- large page allocations covers more memory in less TLB entries). For example: say available page sizes are of 1MB and 32MB. If user wants to allocate 40MB the user can either set page size to 1MB and allocate the exact amount of memory (but will result in 40 TLB entries) or the user can use 32MB pages, "waste" 8MB of physical memory but occupy only 2 TLB entries. Note that this feature will be available only to ASIC that supports multiple DRAM page sizes. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: avoid using an uninitialized variableTomer Tayar2022-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | Fix the following compilation warning in hl_cb_ioctl() @ command_buffer.c: warning: ‘device_va’ may be used uninitialized in this function Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: set max power on device init per ASICTomer Tayar2022-02-284-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For current devices there is a need to send the max power value to F/W during device init, for example because there might be several card types. In future devices, this info will be programmed in the device's EEPROM and will be read by F/W, and hence the driver should not send it. Modify the sending of the relevant message to be done only for ASIC types that need it. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: use proper max_power variable for device utilizationTomer Tayar2022-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | The max_power variable which is used for calculating the device utilization is the ASIC specific property which is set during init. However, the max value can be modified via sysfs, and thus the updated value in the device structure should be used instead. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: enable stop-on-error debugfs setting per ASICTomer Tayar2022-02-284-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | On Goya and Gaudi, the stop-on-error configuration can be set via debugfs. However, in future devices, this configuration will always be enabled. Modify the debugfs node to be allowed only for ASICs that support this dynamic configuration. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: change function to staticOded Gabbay2022-02-281-1/+1
| | | | | | | | | | | | | | handle_registration_node() is called directly from the irq handler in irq.c, so it can be static. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: add missing include of vmalloc.hOded Gabbay2022-02-281-0/+1
| | | | | | | | | | | | | | Use of vfree(), vmalloc_user(), vmalloc() and remap_vmalloc_range() requires this include in some architectures. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix use-after-free bugOded Gabbay2022-02-281-2/+2
| | | | | | | | | | | | | | | | | | | | When the code iterates over the free list of physical pages nodes, it deletes the physical page node which is used as the iterator. Therefore, we need to use the safe version of the iteration to prevent use-after-free. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: rephrase error messages in PCI initializationOded Gabbay2022-02-281-2/+2
| | | | | | | | | | | | | | | | The iATU is an internal h/w machine inside Habana's PCI controller. Mentioning it by name doesn't say anything to the user. It is better to say the PCI controller initialization was not done successfully. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix spelling mistakeOded Gabbay2022-02-281-1/+1
| | | | | | | | | | | | The name of the property is hints_range_reservation Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: Timestamps buffers registrationfarah kassabri2022-02-286-56/+655
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Timestamp registration API allows the user to register a timestamp record event which will make the driver set timestamp when CQ counter reaches the target value and write it to a specific location specified by the user. This is a non blocking API, unlike the wait_for_interrupt which is a blocking one. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix race when waiting on encaps signalDani Liberman2022-02-281-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scenario: 1. CS which is part of encaps signal has been completed and now executing kref_put to its encaps signal handle. The refcount of the handle decremented to 0, and called the encaps signal handle release function - hl_encaps_handle_do_release. 2. At this point the user starts waiting on the signal, and finds the encaps signal handle in the handlers list and increment the habdle refcount to 1. 3. Immediately after, hl_encaps_handle_do_release removed the handle from the list and free its memory. 4. Wait function using the handle although it has been freed. This scenario caused the slab area which was previously allocated for the handle to be poison overwritten which triggered kernel bug the next time the OS needed to allocate this slab. Fixed by getting the refcount of the handle only in case it is not zero. Signed-off-by: Dani Liberman <dliberman@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: silence an uninitialized variable warningDan Carpenter2022-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Smatch warns that: drivers/misc/habanalabs/common/command_buffer.c:471 hl_cb_ioctl() error: uninitialized symbol 'device_va'. Which is true, but harmless. Anyway, it's easy to silence this by adding a error check. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: remove duplicate printOded Gabbay2022-02-281-6/+1
| | | | | | | | | | | | | | We print detailed messages inside the internal ioctl functions. No need to print a generic message at the end, it doesn't add any information. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: prevent false heartbeat failure during soft-resetTomer Tayar2022-02-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The heartbeat thread is active during soft-reset, and it tries to send messages to CPU-CP core. Within the soft-reset, in the time window in which the device is marked as disabled, any CPU-CP command is "silently" skipped and a success value it returned. However, in addition to the return value, the heartbeat function also checks the F/W result, but because no command is sent in this time window, the result variable won't hold the expected value and we will have a false heartbeat failure. To avoid it, modify the "silent" skip to be done only in hard-reset. The CPU-CP should be able to handle messages during soft-reset. In addition to the heartbeat problem, this should also solve other issues in other flows that send messages during soft-reset and use the F/W result as it w/o being aware to the reset. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix race between wait and irqOded Gabbay2022-02-281-1/+5
| | | | | | | | | | | | | | | | | | | | | | There is a race in the user interrupts code, where between checking the target value and adding the new pend to the list, there is a chance the interrupt happened. In that case, no one will complete the node, and we will get a timeout on it. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix user interrupt wait when timeout is 0Oded Gabbay2022-02-281-4/+6
| | | | | | | | | | | | | | | | | | When timeout is 0, we need to return the busy status in case the target value wasn't reached upon entry to the ioctl. Also return the correct timestamp. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: reject host map with mmu disabledOded Gabbay2022-02-281-19/+11
| | | | | | | | | | | | | | This is not something we can do a workaround. It is clearly an error and we should notify the user that it is an error. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: expose number of user interruptsOded Gabbay2022-02-281-2/+2
| | | | | | | | | | | | | | | | Currently we only expose to the user the ID of the first available user interrupt. To make user interrupts allocation truly dynamic, we need to also expose the number of user interrupts. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: update to latest f/w specsOded Gabbay2022-02-281-0/+5
| | | | | | | | | | | | Copy the latest versions of the f/w specs files. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: add missing error check in sysfs max_power_showTomer Tayar2022-02-283-3/+5
| | | | | | | | | | | | | | | | Add a missing error check in the sysfs show function for max_power. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix soft reset flow in case of failureDani Liberman2022-02-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | In case of soft reset failure, hard reset should be initiated, but reset flags were not set to enable it, which caused another soft reset followed by another failure. Updated reset flags to enable hard reset flow in case of soft reset failure. Signed-off-by: Dani Liberman <dliberman@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: add missing error check in sysfs clk_freq_mhz_showTomer Tayar2022-02-281-0/+4
| | | | | | | | | | | | | | | | | | Add a missing error check in the sysfs show functions for clk_max_freq_mhz and clk_cur_freq_mhz_show. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: avoid copying pll data if pll_info_get failsTomer Tayar2022-02-281-2/+4
| | | | | | | | | | | | | | | | | | If reading PLL info from F/W fails, the PLL info is not set in the "result" variable, and hence shouldn't be copied to the caller's array. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: don't free phys_pg_pack inside lockOded Gabbay2022-02-282-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Freeing phys_pg_pack includes calling to scrubbing functions of the device's memory, taking locks and possibly even calling reset. This is not something that should be done while holding a device-wide spinlock. Therefore, save the relevant objects on a local linked-list and after releasing the spinlock, traverse that list and free the phys_pg_pack objects. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: duplicate HOP table props to MMU propsOhad Sharabi2022-02-282-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support several device MMU blocks with different architectures (e.g. different HOP table size) we need to move to per-MMU properties rather than keeping those properties as ASIC properties. Refactoring the code to use "per-MMU proprties" is a major effort. To start making the transition towards this goal but still support taking the properties from ASIC properties (for code that currently uses them) this patch copies some of the properties to the "per-MMU" properties and later, when implementing the per-MMU properties, we would be able to delete the MMU props from the ASIC props. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: there is no kernel TDR in future ASICsOded Gabbay2022-02-281-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In future ASICs, there is no kernel TDR for new workloads that are submitted directly from user-space to the device. Therefore, the driver can NEVER know that a workload has timed-out. So, when the user asks us to wait for interrupt on the workload's completion, and the wait has timed-out, it doesn't mean the workload has timed-out. It only means the wait has timed-out, which is NOT an error from driver's perspective. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: sysfs support for fw os versionRajaravi Krishna Katta2022-02-282-0/+12
| | | | | | | | | | | | | | | | | | Adds new sysfs entry to display firmware os version /sys/class/habanalabs/hl<n>/fw_os_ver Signed-off-by: Rajaravi Krishna Katta <rkatta@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: use common wrapper for MMU cache invalidationOded Gabbay2022-02-282-6/+5
| | | | | | | | | | | | | | | | | | We have a common function that wraps the call to the MMU cache invalidation function, which is ASIC-specific. The wrapper checks the return value and prints error if necessary. For consistency, try to use the wrapper when possible. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: remove power9 workaround for dma supportOded Gabbay2022-02-284-25/+3
| | | | | | | | | | | | We don't need this workaround anymore. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: add vrm version to sysfsOded Gabbay2022-02-286-26/+77
| | | | | | | | | | | | | | infineon version is only applicable to GOYA and GAUDI. For later ASICs, we display the Voltage Regulator Monitor f/w version. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: rename dev_attr_grp to dev_clk_attr_grpOded Gabbay2022-02-284-12/+9
| | | | | | | | | | | | | | | | In this attribute group we are only adding clocks. This is in preparation for adding a device specific attribute group which is not related to clocks. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: remove asic callback set_pll_profile()Oded Gabbay2022-02-285-9/+7
| | | | | | | | | | | | | | | | Setting PLL profile is the same for all ASICs, except for GOYA. However, because this function is never called from common code, there is no need to have an asic-specific callback function. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: move more f/w functions to firmware_if.cOded Gabbay2022-02-285-158/+141
| | | | | | | | | | | | | | For better maintainability, try to concentrate all the common functions that communicate with the f/w in firmware_if.c Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: remove hwmgr.cOded Gabbay2022-02-286-54/+46
| | | | | | | | | | | | | | The two remaining functions in this file belong to firmware_if.c, as they communicate with the firmware. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: get clk is common functionOded Gabbay2022-02-285-18/+15
| | | | | | | | | | | | | | | | | | | | | | Retrieving the clock from the f/w is done exactly the same in ALL our ASICs. Therefore, no real justification for doing it as an ASIC-specific function. The only thing is we need to check if we are running on simulator, which doesn't require ASIC-specific callback. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: sysfs functions should be in sysfs.cOded Gabbay2022-02-284-76/+71
| | | | | | | | | | | | | | | | | | Move common sysfs store/show functions to sysfs.c file for consistency. This is part of a patch-set to remove hwmgr.c Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: make some MMU functions commonOhad Sharabi2022-02-283-37/+72
| | | | | | | | | | | | | | | | | | Some MMU functions can be used by different versions of our MMUs, so move them to be common. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: remove ASIC functions of clock gatingOded Gabbay2022-02-285-142/+5
| | | | | | | | | | | | | | | | Now that clock gating is permanently disabled in GAUDI, no need for the ASIC functions of setting and disabling clock gating, as this was a unique scenario in GAUDI. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs/gaudi: disable CGM permanentlyOded Gabbay2022-02-285-203/+65
| | | | | | | | | | | | | | | | Due to the need of SynapseAI to configure all TPC engines from a single QMAN, the driver must disable CGM and never allow the user to enable it. Otherwise, the configuration of the TPC engines will fail. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
| * habanalabs: fix possible memory leak in MMU DR finiOhad Sharabi2022-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | This patch fixes what seems to be copy paste error. We will have a memory leak if the host-resident shadow is NULL (which will likely happen as the DR and HR are not dependent). Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
View Lorry Controller Status