1. 08 5月, 2021 1 次提交
  2. 09 4月, 2021 4 次提交
  3. 26 3月, 2021 1 次提交
  4. 09 2月, 2021 2 次提交
  5. 28 1月, 2021 5 次提交
  6. 28 12月, 2020 2 次提交
  7. 30 11月, 2020 10 次提交
  8. 22 9月, 2020 8 次提交
  9. 16 9月, 2020 2 次提交
  10. 25 7月, 2020 2 次提交
  11. 19 5月, 2020 3 次提交
    • O
      uapi: habanalabs: add gaudi defines · 466c7822
      Oded Gabbay 提交于
      Add the new defines for GAUDI uapi interface. It includes the queue IDs,
      the engine IDs, SRAM reserved space and Sync Manager reserved resources.
      
      There is no new IOCTL or additional operations in existing IOCTLs.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      466c7822
    • O
      habanalabs: get card type, location from F/W · fca72fbb
      Omer Shpigelman 提交于
      For Gaudi the driver gets two new additional properties from the F/W:
      1. The card's type - PCI or PMC
      2. The card's location in the Gaudi's box (relevant only for PMC).
      
      The card's location is also passed to the user in the HW IP info structure
      as it needs this property for establishing communication between Gaudis.
      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>
      fca72fbb
    • 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