1 What: /sys/kernel/debug/habanalabs/hl<n>/addr
4 Contact: ogabbay@kernel.org
5 Description: Sets the device address to be used for read or write through
6 PCI bar, or the device VA of a host mapped memory to be read or
7 written directly from the host. The latter option is allowed
8 only when the IOMMU is disabled.
9 The acceptable value is a string that starts with "0x"
11 What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate
14 Contact: ogabbay@kernel.org
15 Description: This setting is now deprecated as clock gating is handled solely by the f/w
17 What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
20 Contact: ogabbay@kernel.org
21 Description: Displays a list with information about the currently allocated
24 What: /sys/kernel/debug/habanalabs/hl<n>/command_submission
27 Contact: ogabbay@kernel.org
28 Description: Displays a list with information about the currently active
31 What: /sys/kernel/debug/habanalabs/hl<n>/command_submission_jobs
34 Contact: ogabbay@kernel.org
35 Description: Displays a list with detailed information about each JOB (CB) of
36 each active command submission
38 What: /sys/kernel/debug/habanalabs/hl<n>/data32
41 Contact: ogabbay@kernel.org
42 Description: Allows the root user to read or write directly through the
43 device's PCI bar. Writing to this file generates a write
44 transaction while reading from the file generates a read
45 transaction. This custom interface is needed (instead of using
46 the generic Linux user-space PCI mapping) because the DDR bar
47 is very small compared to the DDR memory and only the driver can
48 move the bar before and after the transaction.
50 If the IOMMU is disabled, it also allows the root user to read
51 or write from the host a device VA of a host mapped memory
53 What: /sys/kernel/debug/habanalabs/hl<n>/data64
56 Contact: ogabbay@kernel.org
57 Description: Allows the root user to read or write 64 bit data directly
58 through the device's PCI bar. Writing to this file generates a
59 write transaction while reading from the file generates a read
60 transaction. This custom interface is needed (instead of using
61 the generic Linux user-space PCI mapping) because the DDR bar
62 is very small compared to the DDR memory and only the driver can
63 move the bar before and after the transaction.
65 If the IOMMU is disabled, it also allows the root user to read
66 or write from the host a device VA of a host mapped memory
68 What: /sys/kernel/debug/habanalabs/hl<n>/data_dma
71 Contact: ogabbay@kernel.org
72 Description: Allows the root user to read from the device's internal
73 memory (DRAM/SRAM) through a DMA engine.
74 This property is a binary blob that contains the result of the
76 This custom interface is needed (instead of using the generic
77 Linux user-space PCI mapping) because the amount of internal
78 memory is huge (>32GB) and reading it via the PCI bar will take
80 This interface doesn't support concurrency in the same device.
81 In GAUDI and GOYA, this action can cause undefined behavior
82 in case the it is done while the device is executing user
84 Only supported on GAUDI at this stage.
86 What: /sys/kernel/debug/habanalabs/hl<n>/device
89 Contact: ogabbay@kernel.org
90 Description: Enables the root user to set the device to specific state.
91 Valid values are "disable", "enable", "suspend", "resume".
92 User can read this property to see the valid values
94 What: /sys/kernel/debug/habanalabs/hl<n>/dma_size
97 Contact: ogabbay@kernel.org
98 Description: Specify the size of the DMA transaction when using DMA to read
99 from the device's internal memory. The value can not be larger
100 than 128MB. Writing to this value initiates the DMA transfer.
101 When the write is finished, the user can read the "data_dma"
104 What: /sys/kernel/debug/habanalabs/hl<n>/dump_razwi_events
107 Contact: fkassabri@habana.ai
108 Description: Dumps all razwi events to dmesg if exist.
109 After reading the status register of an existing event
110 the routine will clear the status register.
111 Usage: cat dump_razwi_events
113 What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations
116 Contact: ogabbay@kernel.org
117 Description: Dumps all security violations to dmesg. This will also ack
118 all security violations meanings those violations will not be
119 dumped next time user calls this API
121 What: /sys/kernel/debug/habanalabs/hl<n>/engines
124 Contact: ogabbay@kernel.org
125 Description: Displays the status registers values of the device engines and
126 their derived idle status
128 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_addr
131 Contact: ogabbay@kernel.org
132 Description: Sets I2C device address for I2C transaction that is generated
133 by the device's CPU, Not available when device is loaded with secured
136 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
139 Contact: ogabbay@kernel.org
140 Description: Sets I2C bus address for I2C transaction that is generated by
141 the device's CPU, Not available when device is loaded with secured
144 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
147 Contact: ogabbay@kernel.org
148 Description: Triggers an I2C transaction that is generated by the device's
149 CPU. Writing to this file generates a write transaction while
150 reading from the file generates a read transaction, Not available
151 when device is loaded with secured firmware
153 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len
156 Contact: obitton@habana.ai
157 Description: Sets I2C length in bytes for I2C transaction that is generated by
158 the device's CPU, Not available when device is loaded with secured
161 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
164 Contact: ogabbay@kernel.org
165 Description: Sets I2C register id for I2C transaction that is generated by
166 the device's CPU, Not available when device is loaded with secured
169 What: /sys/kernel/debug/habanalabs/hl<n>/led0
172 Contact: ogabbay@kernel.org
173 Description: Sets the state of the first S/W led on the device, Not available
174 when device is loaded with secured firmware
176 What: /sys/kernel/debug/habanalabs/hl<n>/led1
179 Contact: ogabbay@kernel.org
180 Description: Sets the state of the second S/W led on the device, Not available
181 when device is loaded with secured firmware
183 What: /sys/kernel/debug/habanalabs/hl<n>/led2
186 Contact: ogabbay@kernel.org
187 Description: Sets the state of the third S/W led on the device, Not available
188 when device is loaded with secured firmware
190 What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub
193 Contact: dhirschfeld@habana.ai
194 Description: Allows the root user to scrub the dram memory. The scrubbing
195 value can be set using the debugfs file memory_scrub_val.
197 What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub_val
200 Contact: dhirschfeld@habana.ai
201 Description: The value to which the dram will be set to when the user
202 scrubs the dram using 'memory_scrub' debugfs file and
203 the scrubbing value when using module param 'memory_scrub'
205 What: /sys/kernel/debug/habanalabs/hl<n>/mmu
208 Contact: ogabbay@kernel.org
209 Description: Displays the hop values and physical address for a given ASID
210 and virtual address. The user should write the ASID and VA into
211 the file and then read the file to get the result.
212 e.g. to display info about VA 0x1000 for ASID 1 you need to do:
213 echo "1 0x1000" > /sys/kernel/debug/habanalabs/hl0/mmu
215 What: /sys/kernel/debug/habanalabs/hl<n>/mmu_error
218 Contact: fkassabri@habana.ai
219 Description: Check and display page fault or access violation mmu errors for
220 all MMUs specified in mmu_cap_mask.
221 e.g. to display error info for MMU hw cap bit 9, you need to do:
222 echo "0x200" > /sys/kernel/debug/habanalabs/hl0/mmu_error
223 cat /sys/kernel/debug/habanalabs/hl0/mmu_error
225 What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump
228 Contact: osharabi@habana.ai
229 Description: Allows the root user to dump monitors status from the device's
230 protected config space.
231 This property is a binary blob that contains the result of the
232 monitors registers dump.
233 This custom interface is needed (instead of using the generic
234 Linux user-space PCI mapping) because this space is protected
235 and cannot be accessed using PCI read.
236 This interface doesn't support concurrency in the same device.
237 Only supported on GAUDI.
239 What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump_trig
242 Contact: osharabi@habana.ai
243 Description: Triggers dump of monitor data. The value to trigger the operation
244 must be 1. Triggering the monitor dump operation initiates dump of
245 current registers values of all monitors.
246 When the write is finished, the user can read the "monitor_dump"
249 What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
252 Contact: ogabbay@kernel.org
253 Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
256 What: /sys/kernel/debug/habanalabs/hl<n>/skip_reset_on_timeout
259 Contact: ynudelman@habana.ai
260 Description: Sets the skip reset on timeout option for the device. Value of
261 "0" means device will be reset in case some CS has timed out,
262 otherwise it will not be reset.
264 What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
267 Contact: ynudelman@habana.ai
268 Description: Gets the state dump occurring on a CS timeout or failure.
269 State dump is used for debug and is created each time in case of
270 a problem in a CS execution, before reset.
271 Reading from the node returns the newest state dump available.
272 Writing an integer X discards X state dumps, so that the
273 next read would return X+1-st newest state dump.
275 What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
278 Contact: ogabbay@kernel.org
279 Description: Sets the stop-on_error option for the device engines. Value of
280 "0" is for disable, otherwise enable.
281 Relevant only for GOYA and GAUDI.
283 What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked
286 Contact: obitton@habana.ai
287 Description: Sets the command submission timeout value in seconds.
289 What: /sys/kernel/debug/habanalabs/hl<n>/userptr
292 Contact: ogabbay@kernel.org
293 Description: Displays a list with information about the currently user
294 pointers (user virtual addresses) that are pinned and mapped
297 What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
300 Contact: ogabbay@kernel.org
301 Description: Allows to search for specific user pointers (user virtual
302 addresses) that are pinned and mapped to DMA addresses, and see
303 their resolution to the specific dma address.
305 What: /sys/kernel/debug/habanalabs/hl<n>/vm
308 Contact: ogabbay@kernel.org
309 Description: Displays a list with information about all the active virtual
310 address mappings per ASID and all user mappings of HW blocks