1. 26 Sep, 2023 5 commits
  2. 25 Sep, 2023 33 commits
  3. 22 Sep, 2023 2 commits
    • Zong-Zhe Yang's avatar
      wifi: rtw89: load TX power related tables from FW elements · 5ee7b2ea
      Zong-Zhe Yang authored
      The following FW elements are recognized, and then the valid entries
      in them are loaded into SW struct case by case.
      * TX power by rate
      * TX power limit 2 GHz
      * TX power limit 5 GHz
      * TX power limit 6 GHz
      * TX power limit RU 2 GHz
      * TX power limit RU 5 GHz
      * TX power limit RU 6 GHz
      * TX shape limit
      * TX shape limit RU
      One single firmware file can contain multiples of each of the above FW
      elements. Each of them is configured with a target RFE (RF front end)
      type. We choose one of the multiples to load based on RFE type. If there
      are multiples of the same FW elements with the same target RFE type. The
      last one will be applied.
      
      We don't want to have many loading variants for above FW elements. Even if
      between different chips or between different generations, we would like to
      maintain only one single set of loadings. So, the loadings are designed to
      consider compatibility. The main concepts are listed below.
      * The driver structures, which are used to cast binary entry from FW,
        cannot insert new members in the middle. If there are something new,
        they should always be appended at the tail.
      * Each binary entry from FW uses a dictionary way containing a key set
        and a data. The keys in the key set indicate where to put the data.
      * If size of driver struct and size of binary entry do not match when
        loading, it means the number of keys in the key set are different.
        Then, we deal with compatibility. No matter which one has more keys,
        we take/use zero on those mismatched keys.
        If driver struct is bigger (backward compatibility):
        	e.g. SW uses two keys, but FW is built with one key.
      	Then, put the data of FW(keyX) into SW[keyX][0].
        If binary entry is bigger (forward compatibility):
        	e.g. FW is built with two keys, but SW uses one key.
        	Then, only take the data of FW(keyX, keyY = 0) into SW[keyX]
      
      Besides, chip info setup flow is tweaked a bit for the following.
      * Before loading FW elements, we need to determine chip RFE via efuse.
      * Setting up RFE parameters depends on loading FW elements ahead.
      Signed-off-by: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230920074322.42898-8-pkshih@realtek.com
      5ee7b2ea
    • Zong-Zhe Yang's avatar
      wifi: rtw89: phy: extend TX power common stuffs for Wi-Fi 7 chips · f6d601c7
      Zong-Zhe Yang authored
      The following are introduced for Wi-Fi 7 chips.
      1. take BW/OFDMA into account on TX power by rate
      2. increase TX power offset types up to EHT
      3. split TX shape into tx_shape_lmt and tx_shape_lmt_ru
      
      If functions which are only for AX, they always access TX power by rate
      with BW/OFDMA = 0/0, and they don't access tx_shape's lmt_ru section.
      Signed-off-by: default avatarZong-Zhe Yang <kevin_yang@realtek.com>
      Signed-off-by: default avatarPing-Ke Shih <pkshih@realtek.com>
      Signed-off-by: default avatarKalle Valo <kvalo@kernel.org>
      Link: https://lore.kernel.org/r/20230920074322.42898-7-pkshih@realtek.com
      f6d601c7