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_security_violations
107 Contact: ogabbay@kernel.org
108 Description: Dumps all security violations to dmesg. This will also ack
109 all security violations meanings those violations will not be
110 dumped next time user calls this API
112 What: /sys/kernel/debug/habanalabs/hl<n>/engines
115 Contact: ogabbay@kernel.org
116 Description: Displays the status registers values of the device engines and
117 their derived idle status
119 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_addr
122 Contact: ogabbay@kernel.org
123 Description: Sets I2C device address for I2C transaction that is generated
126 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
129 Contact: ogabbay@kernel.org
130 Description: Sets I2C bus address for I2C transaction that is generated by
133 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
136 Contact: ogabbay@kernel.org
137 Description: Triggers an I2C transaction that is generated by the device's
138 CPU. Writing to this file generates a write transaction while
139 reading from the file generates a read transaction
141 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len
144 Contact: obitton@habana.ai
145 Description: Sets I2C length in bytes for I2C transaction that is generated by
148 What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
151 Contact: ogabbay@kernel.org
152 Description: Sets I2C register id for I2C transaction that is generated by
155 What: /sys/kernel/debug/habanalabs/hl<n>/led0
158 Contact: ogabbay@kernel.org
159 Description: Sets the state of the first S/W led on the device
161 What: /sys/kernel/debug/habanalabs/hl<n>/led1
164 Contact: ogabbay@kernel.org
165 Description: Sets the state of the second S/W led on the device
167 What: /sys/kernel/debug/habanalabs/hl<n>/led2
170 Contact: ogabbay@kernel.org
171 Description: Sets the state of the third S/W led on the device
173 What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub
176 Contact: dhirschfeld@habana.ai
177 Description: Allows the root user to scrub the dram memory. The scrubbing
178 value can be set using the debugfs file memory_scrub_val.
180 What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub_val
183 Contact: dhirschfeld@habana.ai
184 Description: The value to which the dram will be set to when the user
185 scrubs the dram using 'memory_scrub' debugfs file
187 What: /sys/kernel/debug/habanalabs/hl<n>/mmu
190 Contact: ogabbay@kernel.org
191 Description: Displays the hop values and physical address for a given ASID
192 and virtual address. The user should write the ASID and VA into
193 the file and then read the file to get the result.
194 e.g. to display info about VA 0x1000 for ASID 1 you need to do:
195 echo "1 0x1000" > /sys/kernel/debug/habanalabs/hl0/mmu
197 What: /sys/kernel/debug/habanalabs/hl<n>/mmu_error
200 Contact: fkassabri@habana.ai
201 Description: Check and display page fault or access violation mmu errors for
202 all MMUs specified in mmu_cap_mask.
203 e.g. to display error info for MMU hw cap bit 9, you need to do:
204 echo "0x200" > /sys/kernel/debug/habanalabs/hl0/mmu_error
205 cat /sys/kernel/debug/habanalabs/hl0/mmu_error
207 What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump
210 Contact: osharabi@habana.ai
211 Description: Allows the root user to dump monitors status from the device's
212 protected config space.
213 This property is a binary blob that contains the result of the
214 monitors registers dump.
215 This custom interface is needed (instead of using the generic
216 Linux user-space PCI mapping) because this space is protected
217 and cannot be accessed using PCI read.
218 This interface doesn't support concurrency in the same device.
219 Only supported on GAUDI.
221 What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump_trig
224 Contact: osharabi@habana.ai
225 Description: Triggers dump of monitor data. The value to trigger the operation
226 must be 1. Triggering the monitor dump operation initiates dump of
227 current registers values of all monitors.
228 When the write is finished, the user can read the "monitor_dump"
231 What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
234 Contact: ogabbay@kernel.org
235 Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
238 What: /sys/kernel/debug/habanalabs/hl<n>/skip_reset_on_timeout
241 Contact: ynudelman@habana.ai
242 Description: Sets the skip reset on timeout option for the device. Value of
243 "0" means device will be reset in case some CS has timed out,
244 otherwise it will not be reset.
246 What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
249 Contact: ynudelman@habana.ai
250 Description: Gets the state dump occurring on a CS timeout or failure.
251 State dump is used for debug and is created each time in case of
252 a problem in a CS execution, before reset.
253 Reading from the node returns the newest state dump available.
254 Writing an integer X discards X state dumps, so that the
255 next read would return X+1-st newest state dump.
257 What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
260 Contact: ogabbay@kernel.org
261 Description: Sets the stop-on_error option for the device engines. Value of
262 "0" is for disable, otherwise enable.
263 Relevant only for GOYA and GAUDI.
265 What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked
268 Contact: obitton@habana.ai
269 Description: Sets the command submission timeout value in seconds.
271 What: /sys/kernel/debug/habanalabs/hl<n>/userptr
274 Contact: ogabbay@kernel.org
275 Description: Displays a list with information about the currently user
276 pointers (user virtual addresses) that are pinned and mapped
279 What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
282 Contact: ogabbay@kernel.org
283 Description: Allows to search for specific user pointers (user virtual
284 addresses) that are pinned and mapped to DMA addresses, and see
285 their resolution to the specific dma address.
287 What: /sys/kernel/debug/habanalabs/hl<n>/vm
290 Contact: ogabbay@kernel.org
291 Description: Displays a list with information about all the active virtual
292 address mappings per ASID and all user mappings of HW blocks