-
Notifications
You must be signed in to change notification settings - Fork 24
Description
In configure_unpack_AB, there is a call to modify these register bits THCON_SEC0_REG1_Unp_LF8_4b_exp_RMW and THCON_SEC1_REG1_Unp_LF8_4b_exp_RMW for a specific source format. We want the reconfig functions _llk_unpack_reconfig_data_format_src*_impl_ to also be able to set those bits depending on what the source format is reconfigured to. However, directly inserting a cfg_reg_rmw_tensix is potentially causing a race:
- multiple threads modify the byte that those register bits are contained in
- this test failed once but passed afterwards with no change in code when modifying the above register (also passed after removing the cfg_reg_rmw_tensix) which can indicate a race
If reconfiguring this bit does indeed cause a race, the solution could be to wrap it with
t6_mutex_acquire(mutex::REG_RMW);
t6_mutex_release(mutex::REG_RMW);
But we would need to make sure that the needed synchronization mechanisms are in place everywhere that this byte is modified. Note that it can be accessed not only through its own register name but through the surrounding bit registers within the same byte, and through earlier registers with added word offsets (e.g. THCON_SEC0_REG1_Row_start_section_size_ADDR32 + 3)
Similar measures may need to be taken for packer configure_pack and reconfig_packer_data_format