Anyone get txbf to work on ath10k when using the linux driver?

Ben Greear greearb at candelatech.com
Thu Nov 16 10:55:35 PST 2017


On 11/14/2017 02:19 PM, Sebastian Gottschall wrote:
> Am 14.11.2017 um 23:17 schrieb Ben Greear:
>> On 11/13/2017 07:10 PM, Ben Greear wrote:
>>>
>>>
>>> On 11/13/2017 06:05 PM, Sebastian Gottschall wrote:
>>>> Am 13.11.2017 um 23:50 schrieb Ben Greear:
>>>>> From what I can tell, the 10.4 firmware will not even enable txbf unless the driver
>>>>> tells it too, and I don't think the driver is doing the correct call to enable this
>>>>> (it is a testing interface hack, it appears).
>>>>>
>>>>> But, maybe I am missing something?
>>>> so the firmware does not take care about the vht flags?
>>>
>>> There is a flag to enable implicit beamforming, but it is mis-defined
>>> in the driver as far as I can tell:
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
>>> index ff15c37..9522f22 100644
>>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>>> @@ -5195,7 +5195,8 @@ enum wmi_10_4_vdev_param {
>>>  #define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)
>>>
>>>  #define WMI_TXBF_STS_CAP_OFFSET_LSB    4
>>> -#define WMI_TXBF_STS_CAP_OFFSET_MASK   0xf0
>>> +#define WMI_TXBF_STS_CAP_OFFSET_MASK   0x70
>>> +#define WMI_TXBF_CONF_IMPLICIT_BF       BIT(7)
>>>  #define WMI_BF_SOUND_DIM_OFFSET_LSB    8
>>>  #define WMI_BF_SOUND_DIM_OFFSET_MASK   0xf00
>>>
>>>
>>> Possibly that bit is somehow set anyway, dunno.
>>>
>>> And the other explicit-beamforming appears to need a special hack to enable
>>> the feature in the firmware.
>>>
>>> But, someone using my firmware gets txbf to work, so I must be missing something.
>>>
>>> I will dig into it more tomorrow.
>>
>> At least much of my confusion is that there is a bunch of logic in the rate-ctrl
>> code about txbf probing, and I was thinking that was what caused the sounding to happen.
>>
>> I now realize that is a separate feature (that cannot be enabled w/out special
>> driver hacks not currently supported).
> there are several unused wmi parameters which are undocumented in major parts. but they seem to be used for mu-mimo / txbf etc.

In the end, I had a regression bug in my firmware that broke txbf in at least some cases.

I think I have it all working properly now, but it all needs more testing since I
did some fairly large churn while adding some additional txbf features and trying
to fix some key leak issues in certain IBSS test cases.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com




More information about the ath10k mailing list