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

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

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

Thanks,
Ben

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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Sebastian Gottschall]

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?
>
> Thanks,
> Ben
>

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

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.

Thanks,
Ben


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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[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).

Thanks,
Ben


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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Sebastian Gottschall]

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

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

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

Thanks,
Ben

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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Sebastian Gottschall]

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
>

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k