1. 28 12月, 2020 2 次提交
  2. 30 11月, 2020 5 次提交
  3. 22 9月, 2020 5 次提交
  4. 25 7月, 2020 2 次提交
  5. 19 5月, 2020 2 次提交
  6. 21 11月, 2019 4 次提交
  7. 05 9月, 2019 7 次提交
  8. 01 7月, 2019 2 次提交
  9. 20 6月, 2019 1 次提交
  10. 06 6月, 2019 1 次提交
  11. 04 5月, 2019 1 次提交
    • O
      habanalabs: force user to set device debug mode · 19734970
      Oded Gabbay 提交于
      This patch adds the implementation of the HL_DEBUG_OP_SET_MODE opcode in
      the DEBUG IOCTL.
      
      It forces the user who wants to debug the device to set the device into
      debug mode before he can configure the debug engines. The patch also makes
      sure to disable debug mode upon user releasing FD, in case the user forgot
      to disable debug mode.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      19734970
  12. 06 4月, 2019 1 次提交
    • O
      habanalabs: improve IOCTLs behavior when disabled or reset · 3f5398cf
      Oded Gabbay 提交于
      This patch makes some improvement in how IOCTLs behave when the device is
      disabled or under reset.
      
      The new code checks, at the start of every IOCTL, if the device is
      disabled or in reset. If so, it prints an appropriate kernel message and
      returns -EBUSY to user-space.
      
      In addition, the code modifies the location of where the
      hard_reset_pending flag is being set or cleared:
      
      1. It is now cleared immediately after the reset *tear-down* flow is
         finished but before the re-initialization flow begins.
      
      2. It is being set in the remove function of the device, to make the
         behavior the same with the hard-reset flow
      
      There are two exceptions to the disable or in reset check:
      
      1. The HL_INFO_DEVICE_STATUS opcode in the INFO IOCTL. This opcode allows
         the user to inquire about the status of the device, whether it is
         operational, in reset or malfunction (disabled). If the driver will
         block this IOCTL, the user won't be able to retrieve the status in
         case of malfunction or in reset.
      
      2. The WAIT_FOR_CS IOCTL. This IOCTL allows the user to inquire about the
         status of a CS. We want to allow the user to continue to do so, even if
         we started a soft-reset process because it will allow the user to get
         the correct error code for each CS he submitted.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      3f5398cf
  13. 02 4月, 2019 1 次提交
    • O
      habanalabs: add new IOCTL for debug, tracing and profiling · 315bc055
      Omer Shpigelman 提交于
      Habanalabs ASICs use the ARM coresight infrastructure to support debug,
      tracing and profiling of neural networks topologies.
      
      Because the coresight is configured using register writes and reads, and
      some of the registers hold sensitive information (e.g. the address in
      the device's DRAM where the trace data is written to), the user must go
      through the kernel driver to configure this mechanism.
      
      This patch implements the common code of the IOCTL and calls the
      ASIC-specific function for the actual H/W configuration.
      
      The IOCTL supports configuration of seven coresight components:
      ETR, ETF, STM, FUNNEL, BMON, SPMU and TIMESTAMP
      
      The user specifies which component he wishes to configure and provides a
      pointer to a structure (located in its process space) that contains the
      relevant configuration.
      
      The common code copies the relevant data from the user-space to kernel
      space and then calls the ASIC-specific function to do the H/W
      configuration.
      
      After the configuration is done, which is usually composed
      of several IOCTL calls depending on what the user wanted to trace, the
      user can start executing the topology. The trace data will be written to
      the user's area in the device's DRAM.
      
      After the tracing operation is complete, and user will call the IOCTL
      again to disable the tracing operation. The user also need to read
      values from registers for some of the components (e.g. the size of the
      trace data in the device's DRAM). In that case, the user will provide a
      pointer to an "output" structure in user-space, which the IOCTL code will
      fill according the to selected component.
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      315bc055
  14. 24 3月, 2019 1 次提交
  15. 28 2月, 2019 1 次提交
  16. 07 3月, 2019 1 次提交
  17. 05 3月, 2019 1 次提交
    • O
      habanalabs: ratelimit warnings at start of IOCTLs · 680cb399
      Oded Gabbay 提交于
      At the start of some IOCTLs we check if the device is disabled or in reset.
      If it is, we return -EBUSY and print a message to kernel log.
      
      Because these IOCTLs can be called at very high frequency, use ratelimit
      to avoid spamming the kernel log. Also use the same type of message -
      dev_warn - in all the relevant IOCTLs.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      680cb399
  18. 18 2月, 2019 2 次提交