STRUCT GAUDI2_DEVICE(9)
π NAME π
struct gaudi2_device β the ASIC-specific manage structure, bestie. it's the bookkeeping struct, and honestly? she's carrying the whole device on her back π
this lil page lives in the Kernel API Manual, and it's here to walk you through every single field like a group chat recap π«Ά
β¨ SYNOPSIS β¨
struct gaudi2_device {
int (*cpucp_info_get)(struct hl_device *hdev);
struct user_mapped_block mapped_blocks[NUM_USER_MAPPED_BLOCKS];
int lfsr_rand_seeds[MME_NUM_OF_LFSR_SEEDS];
spinlock_t hw_queues_lock;
void *scratchpad_kernel_address;
dma_addr_t scratchpad_bus_address;
void *virt_msix_db_cpu_addr;
dma_addr_t virt_msix_db_dma_addr;
u64 dram_bar_cur_addr;
u64 hw_cap_initialized;
u64 active_hw_arc;
u64 dec_hw_cap_initialized;
u64 tpc_hw_cap_initialized;
u64 active_tpc_arc;
u64 nic_hw_cap_initialized;
u64 active_nic_arc;
u32 hw_events[GAUDI2_EVENT_SIZE];
u32 events_stat[GAUDI2_EVENT_SIZE];
u32 events_stat_aggregate[GAUDI2_EVENT_SIZE];
u32 num_of_valid_hw_events;
struct gaudi2_queues_test_info queues_test_info[GAUDI2_NUM_TESTED_QS];
};
look at her. 21 fields. main character energy, no cap π
πΈ Members πΈ
okay so field-by-field, let's go πββοΈ
cpucp_info_getβ a function pointer that gets information on the device from CPU-CP. she's the little fetch quest for device intel β¨mapped_blocksβ an array that holds the base address and size of all blocks the user can map. like a guest list but for memory πlfsr_rand_seedsβ array of MME ACC random seeds to set. seeds!! π±hw_queues_lockβ protects the H/W queues from concurrent access. it's giving bouncer at the club door, nobody gets in at the same time π€scratchpad_kernel_addressβ general purposePAGE_SIZEcontiguous memory. and listen: this memory region should be write-only. currently used for HBW QMAN writes which is redundant. so like, write-only, okay?? don't come at her trying to read πscratchpad_bus_addressβ scratchpad bus address. the bus-address twin of the above, slay π«virt_msix_db_cpu_addrβ host memory page for the virtual MSI-X doorbell. a whole page, just for a doorbell ποΈvirt_msix_db_dma_addrβ bus address of the page for the virtual MSI-X doorbell. same doorbell, different address flavor πdram_bar_cur_addrβ current address of DRAM PCI bar. current! as in right now πhw_cap_initializedβ this field contains a bit per H/W engine. when that engine is initialized, that bit is set by the driver to signal we can use this engine in later code paths. each bit is cleared upon reset of its corresponding H/W engine. one bit per engine, on when ready, off on reset β literally a vibe check for hardware βactive_hw_arcβ this field contains a bit per ARC of an H/W engine, with the exception of TPC and NIC engines. once an engine arc is initialized, its respective bit is set. driver can uniquely identify each initialized ARC and use this information in later code paths. each respective bit is cleared upon reset of its corresponding ARC of the H/W engine. yes TPC and NIC are not invited to this one, they have their own fields πdec_hw_cap_initializedβ this field contains a bit per decoder H/W engine. when that engine is initialized, that bit is set by the driver to signal we can use this engine in later code paths. each bit is cleared upon reset of its corresponding H/W engine. decoders get their own bitmask, periodt π₯tpc_hw_cap_initializedβ this field contains a bit per TPC H/W engine. when that engine is initialized, that bit is set by the driver to signal we can use this engine in later code paths. each bit is cleared upon reset of its corresponding H/W engine. TPC's turn πactive_tpc_arcβ this field contains a bit per ARC of the TPC engines. once an engine arc is initialized, its respective bit is set. each respective bit is cleared upon reset of its corresponding ARC of the TPC engine. the ARC bitmask, TPC edition π¦nic_hw_cap_initializedβ this field contains a bit per nic H/W engine. short and sweet, she doesn't overexplain πactive_nic_arcβ this field contains a bit per ARC of the NIC engines. once an engine arc is initialized, its respective bit is set. each respective bit is cleared upon reset of its corresponding ARC of the NIC engine. and that's the NIC ARC bitmask, completing the trilogy β¨hw_eventsβ array that holds all H/W events that are defined valid. the valid ones only, we don't associate with invalid events πββοΈevents_statβ array that holds histogram of all received events. count 'em up πevents_stat_aggregateβ same asevents_statbut doesn't get cleared on reset. she remembers. iconic behavior πnum_of_valid_hw_eventsβ used to hold the number of valid H/W events. just a count, bestie π’queues_test_infoβ information used by the driver when testing the HW queues. test era, we love to see it π§
okay real talk for a sec π«Ά β don't go reading scratchpad_kernel_address expecting sensible results. the docs say it should be write-only, and that it's currently used for HBW QMAN writes which is redundant. respect the write-only lifestyle or catch these bugs π
π₯ SEE ALSO π₯
- Kernel file
./drivers/accel/habanalabs/gaudi2/gaudi2P.hstructdup_block_ctx(9) struct gaudi2_queues_test_info(9)
go read those too, they're the friend group π
and that's the page!! π source: ./drivers/accel/habanalabs/gaudi2, version vibes from October 2026 β mwah, ty for reading, ily, go init some engines πππ¦
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms