[PATCH 0/2] mac80211: Add transmit power control (TPC) support

This patch series adds necessary stuctures, annotations, flags and 
documentation to support per TPC for data and ACK packets. Different 
hardware capabilities of the TPC tunebility can be specified. TPC per
data packet, per data-packets multi-retry-stage (mrr stage) and a
global ack power level are introduced. These are pre-requisits to any
TPC algorithm at mac80211 to control power levels and individual
drivers to tranform this into necessary actions of gain amplification.

Greetings Thomas

This patch adds support to annotate and change the power-level of ACK
packets. To map hardware specific ack power capabilities to mac80211
one new hw flag is defined:

@IEEE80211_HW_SUPPORTS_TPC_ACK_GLOBAL:
	Power level of ack packets is adjustable and processed in a
	global manner, per hw rather than per ack packet or link.

The struct hw_config is extended by ack_power a global power level in
dBm to be used for all acknowledgement_packets. A new config change
event IEEE80211_CONF_CHANGE_ACK_POWER is defined to reacte with driver
specific function calls to ack_power changes from the mac80211.

Signed-off-by: Thomas Huehn <redacted>
Signed-off-by: Alina Friedrichsen <redacted>
Signed-off-by: Felix Fietkau <redacted>
---
 include/net/mac80211.h | 11 +++++++++++
 net/mac80211/rate.c    |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 27ef037..bb0ac22a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h

@@ -772,6 +772,7 @@ enum ieee80211_conf_flags {
  * @IEEE80211_CONF_CHANGE_RETRY_LIMITS: retry limits changed
  * @IEEE80211_CONF_CHANGE_IDLE: Idle flag changed
  * @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
+ * @IEEE80211_CONF_CHANGE_ACK_POWER: Global ACK power level (in dBm) changed
  */
 enum ieee80211_conf_changed {
 	IEEE80211_CONF_CHANGE_SMPS		= BIT(1),

@@ -782,6 +783,7 @@ enum ieee80211_conf_changed {
 	IEEE80211_CONF_CHANGE_CHANNEL		= BIT(6),
 	IEEE80211_CONF_CHANGE_RETRY_LIMITS	= BIT(7),
 	IEEE80211_CONF_CHANGE_IDLE		= BIT(8),
+	IEEE80211_CONF_CHANGE_ACK_POWER		= BIT(9),
 };
 
 /**

@@ -838,6 +840,8 @@ enum ieee80211_smps_mode {
  * @smps_mode: spatial multiplexing powersave mode; note that
  *	%IEEE80211_SMPS_STATIC is used when the device is not
  *	configured for an HT channel
+ * @ack_power: global power level in dBm to use for all
+ * 	mac80211 acknowledgement_packets
  */
 struct ieee80211_conf {
 	u32 flags;

@@ -852,6 +856,8 @@ struct ieee80211_conf {
 	struct ieee80211_channel *channel;
 	enum nl80211_channel_type channel_type;
 	enum ieee80211_smps_mode smps_mode;
+
+	u8 ack_power;
 };
 
 /**

@@ -1227,6 +1233,10 @@ struct ieee80211_tx_control {
  * @IEEE80211_HW_SUPPORTS_TPC_DATA_MRR: One power levels per multi-rate-retry
  *	stage can be processed. Each retry stage of a data packet is send out
  *	using its specified power level.
+ *
+ * @IEEE80211_HW_SUPPORTS_TPC_ACK_GLOBAL: Power level of ack packets is
+ *	adjustable and processed in a global setting, per hardware rather
+ *	than per ack packet and link.
  */
 enum ieee80211_hw_flags {
 	IEEE80211_HW_HAS_RATE_CONTROL			= 1<<0,

@@ -1256,6 +1266,7 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_SCAN_WHILE_IDLE			= 1<<24,
 	IEEE80211_HW_SUPPORTS_TPC_DATA_PACKET		= 1<<25,
 	IEEE80211_HW_SUPPORTS_TPC_DATA_MRR		= 1<<26,
+	IEEE80211_HW_SUPPORTS_TPC_ACK_GLOBAL            = 1<<27,
 };
 
 /**

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 98bde93..aab4333 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c

@@ -260,6 +260,7 @@ bool rate_control_send_low(struct ieee80211_sta *sta,
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(txrc->skb);
 	struct ieee80211_supported_band *sband = txrc->sband;
 	int mcast_rate;
+	int i;
 
 	if (!sta || !priv_sta || rc_no_data_or_no_ack_use_min(txrc)) {
 		if ((sband->band != IEEE80211_BAND_2GHZ) ||

@@ -283,6 +284,9 @@ bool rate_control_send_low(struct ieee80211_sta *sta,
 					      txrc->bss_conf->basic_rates,
 					      sband);
 		}
+		for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
+			info->control.rates[i].tpc = txrc->hw->conf.power_level;
+		}
 		return true;
 	}
 	return false;

-- 
1.7.11.1

This patch creates a transmit power control (TPC) API for data packets.
It enables a per multi-rate-retry stage annotaion of power-levelvalue
in dBm for each data packet via ieee80211_tx_info->control.Necessary
flags are defined to specify and map hardware specific TPC capabilities
to mac80211. Someone can specify transmit power control capabilities to
the stack via:

@IEEE80211_HW_SUPPORTS_TPC_DATA_PACKET:
	One power level per data packet can be processed. Each data
	packet with all its potential retries is send out at this
	individual power level.

@IEEE80211_HW_SUPPORTS_TPC_DATA_MRR
	One power levels per multi-rate-retry stage can be processed.
	Each retry stage of a data packet is send out at its individual
	power level.

Signed-off-by: Thomas Huehn <redacted>
Signed-off-by: Alina Friedrichsen <redacted>
Signed-off-by: Felix Fietkau <redacted>
---
 include/net/mac80211.h | 41 +++++++++++++++++++++++++++--------------
 net/mac80211/rate.c    |  1 +
 2 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 8114f59..27ef037 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h

@@ -491,32 +491,35 @@ enum mac80211_rate_control_flags {
  * @idx: rate index to attempt to send with
  * @flags: rate control flags (&enum mac80211_rate_control_flags)
  * @count: number of tries in this rate before going to the next rate
+ * @tpc: transmit power level in dBm per packet multi-rate-retry (mrr) stage
  *
  * A value of -1 for @idx indicates an invalid rate and, if used
  * in an array of retry rates, that no more rates should be tried.
  *
  * When used for transmit status reporting, the driver should
- * always report the rate along with the flags it used.
+ * always report the rate  and power along with the flags it used.
  *
  * &struct ieee80211_tx_info contains an array of these structs
- * in the control information, and it will be filled by the rate
- * control algorithm according to what should be sent. For example,
- * if this array contains, in the format { <idx>, <count> } the
+ * in the control information, and it will be filled by the joint rate-
+ * power control algorithm according to what should be sent. For example,
+ * if this array contains, in the format { <idx>, <count>, <tpc> } the
  * information
- *    { 3, 2 }, { 2, 2 }, { 1, 4 }, { -1, 0 }, { -1, 0 }
+ *    { 3, 2, 16 }, { 2, 2, 10 }, { 1, 4, 5 }, { -1, 0, 0 }
  * then this means that the frame should be transmitted
- * up to twice at rate 3, up to twice at rate 2, and up to four
- * times at rate 1 if it doesn't get acknowledged. Say it gets
- * acknowledged by the peer after the fifth attempt, the status
+ * up to twice at rate 3 with 16 dBm, up to twice at rate 2 with 10 dBm,
+ * and up to four times at rate 1 with 5 dBm if it doesn't get acknowledged.
+ * Say it gets acknowledged by the peer after the fifth attempt, the status
  * information should then contain
- *   { 3, 2 }, { 2, 2 }, { 1, 1 }, { -1, 0 } ...
- * since it was transmitted twice at rate 3, twice at rate 2
- * and once at rate 1 after which we received an acknowledgement.
+ *   { 3, 2, 16 }, { 2, 2, 10 }, { 1, 1, 5 }, { -1, 0, 0 }
+ * since it was transmitted twice at rate 3 with 16 dBm, twice at rate 2 with
+ * 10 dBm and once at rate 1 with 5 dBm after which we received an
+ * acknowledgement.
  */
 struct ieee80211_tx_rate {
 	s8 idx;
 	u8 count;
 	u8 flags;
+	u8 tpc;
 } __packed;
 
 /**

@@ -552,7 +555,7 @@ struct ieee80211_tx_info {
 	union {
 		struct {
 			union {
-				/* rate control */
+				/* rate control and transmit power control */
 				struct {
 					struct ieee80211_tx_rate rates[
 						IEEE80211_TX_MAX_RATES];

@@ -573,7 +576,7 @@ struct ieee80211_tx_info {
 			u8 ampdu_ack_len;
 			u8 ampdu_len;
 			u8 antenna;
-			/* 21 bytes free */
+			/* 17 bytes free */
 		} status;
 		struct {
 			struct ieee80211_tx_rate driver_rates[

@@ -640,7 +643,7 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
 		info->status.rates[i].count = 0;
 
 	BUILD_BUG_ON(
-	    offsetof(struct ieee80211_tx_info, status.ack_signal) != 20);
+	    offsetof(struct ieee80211_tx_info, status.ack_signal) != 24);
 	memset(&info->status.ampdu_ack_len, 0,
 	       sizeof(struct ieee80211_tx_info) -
 	       offsetof(struct ieee80211_tx_info, status.ampdu_ack_len));

@@ -1216,6 +1219,14 @@ struct ieee80211_tx_control {
  *	queue mapping in order to use different queues (not just one per AC)
  *	for different virtual interfaces. See the doc section on HW queue
  *	control for more details.
+ *
+ * @IEEE80211_HW_SUPPORTS_TPC_DATA_PACKET: One power level per data packet
+ *	can be processed. Each data packet with all its potential retries
+ *	is send out at this individual power level.
+ *
+ * @IEEE80211_HW_SUPPORTS_TPC_DATA_MRR: One power levels per multi-rate-retry
+ *	stage can be processed. Each retry stage of a data packet is send out
+ *	using its specified power level.
  */
 enum ieee80211_hw_flags {
 	IEEE80211_HW_HAS_RATE_CONTROL			= 1<<0,

@@ -1243,6 +1254,8 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_AP_LINK_PS				= 1<<22,
 	IEEE80211_HW_TX_AMPDU_SETUP_IN_HW		= 1<<23,
 	IEEE80211_HW_SCAN_WHILE_IDLE			= 1<<24,
+	IEEE80211_HW_SUPPORTS_TPC_DATA_PACKET		= 1<<25,
+	IEEE80211_HW_SUPPORTS_TPC_DATA_MRR		= 1<<26,
 };
 
 /**

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 3313c11..98bde93 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c

@@ -448,6 +448,7 @@ void rate_control_get_rate(struct ieee80211_sub_if_data *sdata,
 		info->control.rates[i].idx = -1;
 		info->control.rates[i].flags = 0;
 		info->control.rates[i].count = 0;
+		info->control.rates[i].tpc = sdata->local->hw.conf.power_level;
 	}
 
 	if (sdata->local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL)

-- 
1.7.11.1

On Friday 27 July 2012 18:00:09 Thomas Huehn wrote:

This patch adds support to annotate and change the power-level of ACK
packets. To map hardware specific ack power capabilities to mac80211
one new hw flag is defined:

@IEEE80211_HW_SUPPORTS_TPC_ACK_GLOBAL:
	Power level of ack packets is adjustable and processed in a
	global manner, per hw rather than per ack packet or link.

The struct hw_config is extended by ack_power a global power level in
dBm to be used for all acknowledgement_packets. A new config change
event IEEE80211_CONF_CHANGE_ACK_POWER is defined to reacte with driver
specific function calls to ack_power changes from the mac80211.

I know this is kind of an odd. But as carl9170 has TPC settings
for BlockACK, CF-End and QoS-Null frames, it wouldn't be possible
to extend "ACK" to "response".

NB: The HW has also TPC control registers for ERP(RTS/CTS)
but that's sort of a different issue.

Regards,
	Chr

Hi Christian,

Christian Lamparter schrieb:

On Friday 27 July 2012 18:00:09 Thomas Huehn wrote:

quoted

This patch adds support to annotate and change the power-level of ACK
packets. To map hardware specific ack power capabilities to mac80211
one new hw flag is defined:

@IEEE80211_HW_SUPPORTS_TPC_ACK_GLOBAL:
	Power level of ack packets is adjustable and processed in a
	global manner, per hw rather than per ack packet or link.

The struct hw_config is extended by ack_power a global power level in
dBm to be used for all acknowledgement_packets. A new config change
event IEEE80211_CONF_CHANGE_ACK_POWER is defined to reacte with driver
specific function calls to ack_power changes from the mac80211.

I know this is kind of an odd. But as carl9170 has TPC settings
for BlockACK, CF-End and QoS-Null frames, it wouldn't be possible
to extend "ACK" to "response".

NB: The HW has also TPC control registers for ERP(RTS/CTS)
but that's sort of a different issue.

I just double checked with the registers for Atheros ath5k and ath9k
chips and it is register at address offset: 0x80E8 and holds the
transmit powers for self- generated response frames: ACK_PWR (ACK
self-generated response frames), CTS_PWR (CTS self-generated response
frames) and CHRIP_PWR (Chirp self-generated response frames). So at
least for those chips, I can not see an separate TPC setting .. lets say
for BlockACK. Maybe the Atheros Guys can help out here ?
If my proposed FLAG is to generous we can introduce more hardware
specific ones. My TPC algorithm does consider DATA and ACK packets at
the moment as they are most relevant for interference management but
could be extended to other types.


Greetings Thomas

On Fri, 2012-07-27 at 18:00 +0200, Thomas Huehn wrote:

  * &struct ieee80211_tx_info contains an array of these structs
- * in the control information, and it will be filled by the rate
- * control algorithm according to what should be sent. For example,
- * if this array contains, in the format { <idx>, <count> } the
+ * in the control information, and it will be filled by the joint rate-
+ * power control algorithm according to what should be sent. For example,
+ * if this array contains, in the format { <idx>, <count>, <tpc> } the
  * information
- *    { 3, 2 }, { 2, 2 }, { 1, 4 }, { -1, 0 }, { -1, 0 }
+ *    { 3, 2, 16 }, { 2, 2, 10 }, { 1, 4, 5 }, { -1, 0, 0 }
  * then this means that the frame should be transmitted
- * up to twice at rate 3, up to twice at rate 2, and up to four
- * times at rate 1 if it doesn't get acknowledged. Say it gets
- * acknowledged by the peer after the fifth attempt, the status
+ * up to twice at rate 3 with 16 dBm, up to twice at rate 2 with 10 dBm,

You might want to consider using 1/2 or 1/4 dBm granularity? A lot of
hardware can do that.

 struct ieee80211_tx_rate {
 	s8 idx;
 	u8 count;
 	u8 flags;
+	u8 tpc;

I'm not sure that should be named "tpc". Think about what that means --
"transmit power control", but it's really the power value, so it should
be "txpower" or so.

johannes

On Fri, 2012-07-27 at 18:00 +0200, Thomas Huehn wrote:

No need for braces, and a blank line above it would be good. Remember
code is meant to be read by people and compilers (in that order)

Anyway I don't think I'm going to apply any of this until we have some
code that uses it.

johannes

Hi Johannes

Johannes Berg schrieb:

On Fri, 2012-07-27 at 18:00 +0200, Thomas Huehn wrote:

quoted

  * &struct ieee80211_tx_info contains an array of these structs
- * in the control information, and it will be filled by the rate
- * control algorithm according to what should be sent. For example,
- * if this array contains, in the format { <idx>, <count> } the
+ * in the control information, and it will be filled by the joint rate-
+ * power control algorithm according to what should be sent. For example,
+ * if this array contains, in the format { <idx>, <count>, <tpc> } the
  * information
- *    { 3, 2 }, { 2, 2 }, { 1, 4 }, { -1, 0 }, { -1, 0 }
+ *    { 3, 2, 16 }, { 2, 2, 10 }, { 1, 4, 5 }, { -1, 0, 0 }
  * then this means that the frame should be transmitted
- * up to twice at rate 3, up to twice at rate 2, and up to four
- * times at rate 1 if it doesn't get acknowledged. Say it gets
- * acknowledged by the peer after the fifth attempt, the status
+ * up to twice at rate 3 with 16 dBm, up to twice at rate 2 with 10 dBm,

You might want to consider using 1/2 or 1/4 dBm granularity? A lot of
hardware can do that.

The choice of 1 dBm as step width was based on our experiments with
Atheros chips that do support up to 0,5dBm step width. We concluded that
1dBm is sufficient as it provides 20 steps from 1 till 100 mWatt as
dynamic range of control. But there is no problem for my tpc algorithm
to handle a granularity of 0.5 dBm as step size, or any other upcoming
tpc controller. Should we gather some feedback about todays hardware
specs in terms of tx_power abilities? Or should I just apply 0.5 dBm
steps in v2 ?

quoted

 struct ieee80211_tx_rate {
 	s8 idx;
 	u8 count;
 	u8 flags;
+	u8 tpc;

I'm not sure that should be named "tpc". Think about what that means --
"transmit power control", but it's really the power value, so it should
be "txpower" or so.

I will change this to tx_power in v2, sounds reasonable.

Greetings Thomas

On Mon, 2012-07-30 at 13:29 +0200, Thomas Huehn wrote:

quoted

quoted

- *    { 3, 2 }, { 2, 2 }, { 1, 4 }, { -1, 0 }, { -1, 0 }
+ *    { 3, 2, 16 }, { 2, 2, 10 }, { 1, 4, 5 }, { -1, 0, 0 }
  * then this means that the frame should be transmitted
- * up to twice at rate 3, up to twice at rate 2, and up to four
- * times at rate 1 if it doesn't get acknowledged. Say it gets
- * acknowledged by the peer after the fifth attempt, the status
+ * up to twice at rate 3 with 16 dBm, up to twice at rate 2 with 10 dBm,

You might want to consider using 1/2 or 1/4 dBm granularity? A lot of
hardware can do that.

The choice of 1 dBm as step width was based on our experiments with
Atheros chips that do support up to 0,5dBm step width. We concluded that
1dBm is sufficient as it provides 20 steps from 1 till 100 mWatt as
dynamic range of control. But there is no problem for my tpc algorithm
to handle a granularity of 0.5 dBm as step size, or any other upcoming
tpc controller. Should we gather some feedback about todays hardware
specs in terms of tx_power abilities? Or should I just apply 0.5 dBm
steps in v2 ?

I have no idea, it was really just a thought. I believe Broadcom HW can
handle 1/4 dBm, but then you'd have to know what the granularity really
is otherwise it all doesn't make much sense...

It really only gets interesting if there's a limit (regulatory or
otherwise) that isn't a full dBm, because then the algorithm couldn't
use the maximum permitted power, right? Say there's a 14.5 dBm limit,
then the algorithm could only go up to 14 dBm.

johannes