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

Message ID 1d1fd019-cb3e-17e5-f7d5-dfe1debf95d5@candelatech.com
State New
Headers show

Commit Message

Ben Greear Nov. 14, 2017, 3:10 a.m. UTC
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:


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.

Thanks,
Ben

Comments

Ben Greear Nov. 14, 2017, 10:17 p.m. UTC | #1
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).

Thanks,
Ben
Sebastian Gottschall Nov. 14, 2017, 10:19 p.m. UTC | #2
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.
>
> Thanks,
> Ben
>
>
Ben Greear Nov. 16, 2017, 6:55 p.m. UTC | #3
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
Sebastian Gottschall Nov. 20, 2017, 2:09 p.m. UTC | #4
Am 16.11.2017 um 19:55 schrieb Ben Greear:
> 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.
you may send me a patch for testing. so i can do some practical tests. i 
have concert venue and more than 1000 people in the audience with mobile 
phones are a good test bed
>
> Thanks,
> Ben
>

Patch
diff mbox

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