Commit Message

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

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

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>>

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

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>