1. 25 5月, 2020 1 次提交
  2. 19 5月, 2020 12 次提交
    • O
      habanalabs: move event handling to common firmware file · ebd8d122
      Ofir Bitton 提交于
      Instead of writing similar event handling code for each ASIC, move the code
      to the common firmware file. This code will be used for GAUDI and all
      future ASICs.
      
      In addition, add two new fields to the auto-generated events file: valid
      and description. This will save the need to manually write the events
      description in the source code and simplify the code.
      Signed-off-by: NOfir Bitton <obitton@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      ebd8d122
    • O
      habanalabs: add gaudi asic-dependent code · ac0ae6a9
      Oded Gabbay 提交于
      Add the ASIC-dependent code for GAUDI. Supply (almost) all of the function
      callbacks that the driver's common code need to initialize, finalize and
      submit workloads to the GAUDI ASIC.
      
      It also contains the code to initialize the F/W of the GAUDI ASIC and to
      receive events from the F/W.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      ac0ae6a9
    • O
      habanalabs: support clock gating enable/disable · ca62433f
      Oded Gabbay 提交于
      In Gaudi there is a feature of clock gating certain engines.
      Therefore, add this property to the device structure.
      
      In addition, due to a limitation of this feature, the driver needs to
      dynamically enable or disable this feature during run-time. Therefore, add
      ASIC interface functions to enable/disable this function from the common
      code.
      
      Moreover, this feature must be turned off when the user wishes to debug the
      ASIC by reading/writing registers and/or memory through the driver's
      debugfs. Therefore, add an option to enable/disable clock gating via the
      debugfs interface.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      ca62433f
    • O
      habanalabs: add dedicated define for hard reset · e09498b0
      Omer Shpigelman 提交于
      Gaudi requires longer waiting during reset due to closing of network ports.
      Add this explanation to the relevant comment in the code and add a
      dedicated define for this reset timeout period, instead of multiplying
      another define.
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      e09498b0
    • O
      habanalabs: check if CoreSight is supported · 9e5e49cd
      Omer Shpigelman 提交于
      Coresight is not supported on simulator, therefore add a boolean for
      checking that (currently used by un-upstreamed code).
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      9e5e49cd
    • O
      habanalabs: add signal/wait to CS IOCTL operations · b75f2250
      Omer Shpigelman 提交于
      Add the following two operations to the CS IOCTL:
      
      Signal:
      
      The signal operation is basically a command submission, that is created by
      the driver upon user request. It will be implemented using a dedicated PQE
      that will increment a specific SOB. There will be a new flag:
      HL_CS_FLAGS_SIGNAL. When the user set this flag in the CS IOCTL structure,
      the driver will execute a dedicated code path that will prepare this
      special PQE and submit it. The user only needs to provide a queue index on
      which to put the signal.
      
      Wait:
      
      The wait operation is also a command submission that is created by the
      driver upon user request. It will be implemented using a dedicated PQE that
      will contain packets of "ARM a monitor" + FENCE packet. There will be a new
      flag: HL_CS_FLAGS_WAIT. When the user set this flag in the CS structure,
      the driver will execute a dedicated code path that will prepare this
      special PQE and submit it.
      
      The user needs to provide the following parameters:
      1. queue ID
      2. an array of signal_seq numbers and the number of signals to wait on
         (the length of signal_seq_arr).
      
      The IOCTL will return the CS sequence number of the wait it put on the
      queue ID.
      
      Currently, the code supports signal_seq_nr==1. But this API definition will
      allow us to put a single PQE that waits on multiple signals.
      
      To correctly configure the monitor and fence, the driver will need to
      retrieve the specified signal CS object that contains the relevant SOB and
      its expected value. In case the signal CS has already been completed, there
      is no point of adding a wait operation. In this case, the driver will
      return to the user *without* putting anything on the PQ. The return code
      should reflect to the user that the signal was completed, as we won't
      return a CS sequence number for this wait.
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      b75f2250
    • O
      habanalabs: handle the h/w sync object · b0b5d925
      Omer Shpigelman 提交于
      Define a structure representing the h/w sync object (SOB).
      
      a SOB can contain up to 2^15 values. Each signal CS will increment the SOB
      by 1, so after some time we will reach the maximum number the SOB can
      represent. When that happens, the driver needs to move to a different SOB
      for the signal operation.
      
      A SOB can be in 1 of 4 states:
      
      1. Working state with value < 2^15
      
      2. We reached a value of 2^15, but the signal operations weren't completed
      yet OR there are pending waits on this signal. For the next submission, the
      driver will move to another SOB.
      
      3. ALL the signal operations on the SOB have finished AND there are no more
      pending waits on the SOB AND we reached a value of 2^15 (This basically
      means the refcnt of the SOB is 0 - see explanation below). When that
      happens, the driver can clear the SOB by simply doing WREG32 0 to it and
      set the refcnt back to 1.
      
      4. The SOB is cleared and can be used next time by the driver when it needs
      to reuse an SOB.
      
      Per SOB, the driver will maintain a single refcnt, that will be initialized
      to 1. When a signal or wait operation on this SOB is submitted to the PQ,
      the refcnt will be incremented. When a signal or wait operation on this SOB
      completes, the refcnt will be decremented. After the submission of the
      signal operation that increments the SOB to a value of 2^15, the refcnt is
      also decremented.
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      b0b5d925
    • O
      habanalabs: define ASIC-dependent interface for signal/wait · ec2f8a30
      Omer Shpigelman 提交于
      This feature requires handling h/w resources which are a bit different from
      one ASIC to the other. Therefore, we need to define a set of interfaces the
      ASIC code provides to the common code to signal, wait, reset sync object
      and to reset and init a queue.
      
      As this feature is not supported in Goya, provide an empty implementation
      of those functions.
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      ec2f8a30
    • O
      uapi: habanalabs: add signal/wait operations · f9e5f295
      Omer Shpigelman 提交于
      This is a pre-requisite to upstreaming GAUDI support.
      
      Signal/wait operations are done by the user to perform sync between two
      Primary Queues (PQs). The sync is done using the sync manager and it is
      usually resolved inside the device, but sometimes it can be resolved in the
      host, i.e. the user should be able to wait in the host until a signal has
      been completed.
      
      The mechanism to define signal and wait operations is done by the driver
      because it needs atomicity and serialization, which is already done in the
      driver when submitting work to the different queues.
      
      To implement this feature, the driver "takes" a couple of h/w resources,
      and this is reflected by the defines added to the uapi file.
      
      The signal/wait operations are done via the existing CS IOCTL, and they use
      the same data structure. There is a difference in the meaning of some of
      the parameters, and for that we added unions to make the code more
      readable.
      Signed-off-by: NOmer Shpigelman <oshpigelman@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      f9e5f295
    • O
      habanalabs: load CPU device boot loader from host · 47f6b41c
      Ofir Bitton 提交于
      Load CPU device boot loader during driver boot time in order to avoid flash
      write for every boot loader update.
      
      To preserve backward-compatibility, skip the device boot load if the device
      doesn't request it.
      Signed-off-by: NOfir Bitton <obitton@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      47f6b41c
    • C
      habanalabs: support hwmon_reset_history attribute · 8e708af2
      Christine Gharzuzi 提交于
      Support hwmon_temp_reset_histroy, hwmon_in_reset_history and
      hwmon_curr_reset attribute which resets the historical highest value.
      Signed-off-by: NChristine Gharzuzi <cgharzuzi@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      8e708af2
    • T
      habanalabs: Add INFO IOCTL opcode for time sync information · 25e7aeba
      Tomer Tayar 提交于
      Add a new opcode to the INFO IOCTL that retrieves the device time
      alongside the host time, to allow a user application that want to measure
      device time together with host time (such as a profiler) to synchronize
      these times.
      Signed-off-by: NTomer Tayar <ttayar@habana.ai>
      Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      25e7aeba
  3. 17 5月, 2020 6 次提交
  4. 24 3月, 2020 7 次提交
  5. 21 11月, 2019 10 次提交
  6. 05 9月, 2019 4 次提交