Re: [PATCH] ath10k: Allow setting coverage class

2016-08-03 Thread Michal Kazior 
On 29 July 2016 at 17:09, Ben Greear  wrote:
> On 07/29/2016 07:52 AM, Benjamin Berg wrote:
[...]
>> Yeah, I am aware of the fact that the firmware may do internal resets
>> from time to time. The interesting question (and one for which I do not
>> know the answer) is whether we get a wmi or other event under all
>> conditions where the register may be rewritten due to a reset.
>>
>> The current code will re-set the register value after any wmi event
>> including debug messages. If this is not enough, then the only solution
>> might be to periodically poll the register values instead of relying on
>> a received event.
>
> You will get a dbglog event at least most of the time, so maybe that
> will be good enough.

But you need to remember you need to enable dbglog first to get these
events. I guess when coverage class is set the driver could,
internally, override dbglog mask so that these events are guaranteed
to be reported for the purpose of properly refreshing registers on
channel programming.

At that point I guess the update hook could be just placed in dbglog
handler alone instead of all over wmi_rx variants.


Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-29 Thread Sebastian Gottschall 
if these sourcecodes would be just up to date with the binaries provided 
by qca. but qca doesnt seem to care that much about it.
this is mainly also the reason why there are soo many long term 
stability issues with no resolution



Am 29.07.2016 um 17:09 schrieb Ben Greear:

On 07/29/2016 07:52 AM, Benjamin Berg wrote:

On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:

On 07/27/2016 01:33 AM, Benjamin Berg wrote:


Unfortunately ath10k does not generally allow modifying the 
coverage class
with the stock firmware and Qualcomm has so far refused to 
implement this
feature so that it can be properly supported in ath10k. If we 
however know
the registers that need to be modified for proper operation with a 
higher

coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which 
are based
on a core that is similar to ath9k. The registers are modified in 
place and
need to be re-written every time the firmware sets them. To achieve 
this

the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the 
card
re-initializes the registers. This is for example the case during 
scanning.


A warning will be generated if the hack is not supported on the 
card or

unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).

Thanks to Sebastian Gottschall  for 
initially

working on a userspace support for this. This patch wouldn't have been
possible without this documentation.


I would be concerned about the various resets firmware does to work 
around
hardware hangs as well.  I don't think any events are generated for 
these, unless

you count the dbglog messages?


Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.


You will get a dbglog event at least most of the time, so maybe that
will be good enough.

Someone with src code and that cared could audit the code I guess, but 
then
that person could also just implement the feature properly in the 
firmware

to begin with...

Thanks,
Ben




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-29 Thread Ben Greear 

On 07/29/2016 07:52 AM, Benjamin Berg wrote:

On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:

On 07/27/2016 01:33 AM, Benjamin Berg wrote:


Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which are based
on a core that is similar to ath9k. The registers are modified in place and
need to be re-written every time the firmware sets them. To achieve this
the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

A warning will be generated if the hack is not supported on the card or
unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).


Thanks to Sebastian Gottschall  for initially

working on a userspace support for this. This patch wouldn't have been
possible without this documentation.


I would be concerned about the various resets firmware does to work around
hardware hangs as well.  I don't think any events are generated for these, 
unless
you count the dbglog messages?


Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.


You will get a dbglog event at least most of the time, so maybe that
will be good enough.

Someone with src code and that cared could audit the code I guess, but then
that person could also just implement the feature properly in the firmware
to begin with...

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-29 Thread Benjamin Berg 
On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:
> On 07/27/2016 01:33 AM, Benjamin Berg wrote:
> > 
> > Unfortunately ath10k does not generally allow modifying the coverage class
> > with the stock firmware and Qualcomm has so far refused to implement this
> > feature so that it can be properly supported in ath10k. If we however know
> > the registers that need to be modified for proper operation with a higher
> > coverage class, then we can do these modifications from the driver.
> > 
> > This patch implements this hack for first generation cards which are based
> > on a core that is similar to ath9k. The registers are modified in place and
> > need to be re-written every time the firmware sets them. To achieve this
> > the register status is verified after any event from the firmware.
> > 
> > The coverage class may not be modified temporarily right after the card
> > re-initializes the registers. This is for example the case during scanning.
> > 
> > A warning will be generated if the hack is not supported on the card or
> > unexpected values are hit. There is no error reporting for userspace
> > applications though (this is a limitation in the mac80211 driver
> > interface).
> > 
> > > > Thanks to Sebastian Gottschall  for initially
> > working on a userspace support for this. This patch wouldn't have been
> > possible without this documentation.
> 
> I would be concerned about the various resets firmware does to work around
> hardware hangs as well.  I don't think any events are generated for these, 
> unless
> you count the dbglog messages?

Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.

Benjamin

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-27 Thread Ben Greear 

On 07/27/2016 01:33 AM, Benjamin Berg wrote:

Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which are based
on a core that is similar to ath9k. The registers are modified in place and
need to be re-written every time the firmware sets them. To achieve this
the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

A warning will be generated if the hack is not supported on the card or
unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).

Thanks to Sebastian Gottschall  for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.


I would be concerned about the various resets firmware does to work around
hardware hangs as well.  I don't think any events are generated for these, 
unless
you count the dbglog messages?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-27 Thread kbuild test robot 
Hi,

[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on next-20160727]
[cannot apply to v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Benjamin-Berg/ath10k-Allow-setting-coverage-class/20160727-163809
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath10k/wmi.c: In function 
'ath10k_ath9k_set_pdev_coverage_class':
>> drivers/net/wireless/ath/ath10k/wmi.c:3176:2: error: expected ';' before 
>> 'timeout'
 timeout = timeout & ATH9K_MAC_TIME_OUT_ACK;
 ^
   drivers/net/wireless/ath/ath10k/wmi.c:3181:2: error: expected ';' before 
'timeout'
 timeout = timeout >> ATH9K_MAC_TIME_OUT_CTS_S;
 ^
   drivers/net/wireless/ath/ath10k/wmi.c:3185:2: error: expected ';' before 
'timeout'
 timeout = timeout & ATH9K_MAC_TIME_OUT_CTS;
 ^

vim +3176 drivers/net/wireless/ath/ath10k/wmi.c

  3170  /* Update ack timeout (lower halfword). */
  3171  timeout = (timeout_reg & ATH9K_MAC_TIME_OUT_ACK);
  3172  timeout = timeout >> ATH9K_MAC_TIME_OUT_ACK_S;
  3173  timeout += 3 * value * counters_freq_mhz;
  3174  timeout = min_t(u32, timeout, ATH9K_MAC_TIME_OUT_MAX);
  3175  timeout = (timeout << ATH9K_MAC_TIME_OUT_ACK_S)
> 3176  timeout = timeout & ATH9K_MAC_TIME_OUT_ACK;
  3177  timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_ACK) | timeout;
  3178  
  3179  /* Update cts timeout (upper halfword). */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-27 Thread Michal Kazior 
On 27 July 2016 at 10:33, Benjamin Berg  wrote:
> Unfortunately ath10k does not generally allow modifying the coverage class
> with the stock firmware and Qualcomm has so far refused to implement this
> feature so that it can be properly supported in ath10k. If we however know
> the registers that need to be modified for proper operation with a higher
> coverage class, then we can do these modifications from the driver.
>
> This patch implements this hack for first generation cards which are based
> on a core that is similar to ath9k. The registers are modified in place and
> need to be re-written every time the firmware sets them. To achieve this
> the register status is verified after any event from the firmware.

"After any event from firmware" would also need to include HTT events
which your patch doesn't consider.


> The coverage class may not be modified temporarily right after the card
> re-initializes the registers. This is for example the case during scanning.
>
> A warning will be generated if the hack is not supported on the card or
> unexpected values are hit. There is no error reporting for userspace
> applications though (this is a limitation in the mac80211 driver
> interface).

With a recent change in ath10k the ieee80211_ops can be updated in
ar->ops so you can NULL-ify .set_coverage_class before registering to
mac80211. See how wake_tx_queue() is masked. You could use this to
mask it for WAVE2 devices that haven't been verified.


[...]
> @@ -257,6 +258,12 @@ extern const struct ath10k_hw_regs qca6174_regs;
>  extern const struct ath10k_hw_regs qca99x0_regs;
>  extern const struct ath10k_hw_regs qca4019_regs;
>
> +enum ath10k_hw_mac_core_rev {
> +   ATH10K_HW_MAC_CORE_UNKNOWN = 0,
> +   ATH10K_HW_MAC_CORE_ATH9K,

WAVE1 would be more appropriate.


> +   ATH10K_HW_MAC_CORE_WAVE2,
> +};
> +
[...]
> +#define ATH9K_MAC_TIME_OUT 0x8014
> +#define ATH9K_MAC_TIME_OUT_MAX 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_ACK 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_ACK_S   0
> +#define ATH9K_MAC_TIME_OUT_CTS 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_CTS_S   16
> +
> +#define ATH9K_MAC_IFS_SLOT 0x1070
> +#define ATH9K_MAC_IFS_SLOT_M   0x
> +#define ATH9K_MAC_IFS_SLOT_RESV0   0x

The prefix is wrong. It shouldn't be ATH9K.

Moreover FW refers to these register as PCU_ACK_CTS_TIMEOUT and
PCU_GBL_IFS_SLOT.


> +
>  #endif /* _HW_H_ */
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 55c823f..a9b587e 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5372,6 +5372,15 @@ static void ath10k_bss_info_changed(struct 
> ieee80211_hw *hw,
> mutex_unlock(>conf_mutex);
>  }
>
> +static void ath10k_set_coverage_class(struct ieee80211_hw *hw,
> + s16 value)

Wrong function prefix/name. Should be: ath10k_mac_op_set_coverage_class


> +{
> +   struct ath10k *ar = hw->priv;
> +
> +   if (ath10k_wmi_pdev_set_coverage_class(ar, value) == -EOPNOTSUPP)
> +   ath10k_warn(ar, "Modification of coverage class is not 
> supported!\n");

Warning doesn't match the style used in ath10k. "failed to set
coverage class: not supported\n".


[...]
> diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
> b/drivers/net/wireless/ath/ath10k/wmi-ops.h
> index 64ebd30..3ebc57e 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
> @@ -52,6 +52,8 @@ struct wmi_ops {
> int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
>   struct wmi_wow_ev_arg *arg);
> enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
> +   void (*set_pdev_coverage_class)(struct ath10k *ar,
> +   s16 value);

WMI ops are used to generate and process events and command buffers.
These ops are not supposed to have side-effects but
"set_pdev_coverage_class" implies it does.


[...]
>  /* MAIN WMI cmd track */
>  static struct wmi_cmd_map wmi_cmd_map = {
> @@ -3096,6 +3097,121 @@ ath10k_wmi_op_pull_peer_kick_ev(struct ath10k *ar, 
> struct sk_buff *skb,
> return 0;
>  }
>
> +static void
> +ath10k_ath9k_set_pdev_coverage_class(struct ath10k *ar, s16 value)

The prefix is wrong. "ath9k" should be used here.

ath10k_wmi_ is appropriate for stuff in wmi.c


[...]
> +   /* Do some sanity checks on the slottime register. */
> +   if (unlikely(slottime_reg % counters_freq_mhz)) {
> +   ath10k_warn(ar,
> +   "Not adjusting coverage class timeouts, expected 
> an integer microsecond slot time in HW register\n");

Wrong message style.


> +
> +   goto store_regs;
> +   }
> +
> +   slottime = (slottime_reg & ATH9K_MAC_IFS_SLOT_M) / counters_freq_mhz;
> +   if

[PATCH] ath10k: Allow setting coverage class

2016-07-27 Thread Benjamin Berg 
Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which are based
on a core that is similar to ath9k. The registers are modified in place and
need to be re-written every time the firmware sets them. To achieve this
the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

A warning will be generated if the hack is not supported on the card or
unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).

Thanks to Sebastian Gottschall  for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.

Signed-off-by: Benjamin Berg 
Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath10k/core.h|  10 ++
 drivers/net/wireless/ath/ath10k/hw.c  |   9 ++
 drivers/net/wireless/ath/ath10k/hw.h  |  28 +-
 drivers/net/wireless/ath/ath10k/mac.c |  10 ++
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  17 
 drivers/net/wireless/ath/ath10k/wmi.c | 151 ++
 6 files changed, 224 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 9374bcd..781219b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -935,6 +935,16 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
 
+   /* protected by data_lock */
+   struct {
+   s16 coverage_class;
+
+   u32 reg_slottime_conf;
+   u32 reg_slottime_orig;
+   u32 reg_ack_cts_timeout_conf;
+   u32 reg_ack_cts_timeout_orig;
+   } fw_coverage;
+
/* must be last */
u8 drv_priv[0] __aligned(sizeof(void *));
 };
diff --git a/drivers/net/wireless/ath/ath10k/hw.c 
b/drivers/net/wireless/ath/ath10k/hw.c
index f903d46..82249be 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -22,6 +22,7 @@ const struct ath10k_hw_regs qca988x_regs = {
.rtc_soc_base_address   = 0x4000,
.rtc_wmac_base_address  = 0x5000,
.soc_core_base_address  = 0x9000,
+   .wlan_mac_base_address  = 0x0002,
.ce_wrapper_base_address= 0x00057000,
.ce0_base_address   = 0x00057400,
.ce1_base_address   = 0x00057800,
@@ -48,6 +49,7 @@ const struct ath10k_hw_regs qca6174_regs = {
.rtc_soc_base_address   = 0x0800,
.rtc_wmac_base_address  = 0x1000,
.soc_core_base_address  = 0x0003a000,
+   .wlan_mac_base_address  = 0x0002,
.ce_wrapper_base_address= 0x00034000,
.ce0_base_address   = 0x00034400,
.ce1_base_address   = 0x00034800,
@@ -74,6 +76,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
.rtc_soc_base_address   = 0x0008,
.rtc_wmac_base_address  = 0x,
.soc_core_base_address  = 0x00082000,
+   .wlan_mac_base_address  = 0x0003,
.ce_wrapper_base_address= 0x0004d000,
.ce0_base_address   = 0x0004a000,
.ce1_base_address   = 0x0004a400,
@@ -109,6 +112,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
 const struct ath10k_hw_regs qca4019_regs = {
.rtc_soc_base_address   = 0x0008,
.soc_core_base_address  = 0x00082000,
+   .wlan_mac_base_address  = 0x0003,
.ce_wrapper_base_address= 0x0004d000,
.ce0_base_address   = 0x0004a000,
.ce1_base_address   = 0x0004a400,
@@ -139,6 +143,7 @@ const struct ath10k_hw_regs qca4019_regs = {
 };
 
 const struct ath10k_hw_values qca988x_values = {
+   .mac_core_rev   = ATH10K_HW_MAC_CORE_ATH9K,
.rtc_state_val_on   = 3,
.ce_count   = 8,
.msi_assign_ce_max  = 7,
@@ -148,6 +153,7 @@ const struct ath10k_hw_values