At least this is true for the chips tested. Verified by bringing up two mesh
nodes and checking their reported TSF offset is symmetrical within 5us. Before
this patch there was a difference of 1.3ms or so.
Thomas Pedersen (2):
ath9k: RX timestamp is reported at end of frame
ath9k_htc: RX timestamp is reported at end of frame
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.7.10.4
On Mon, Nov 12, 2012 at 11:18 AM, Adrian Chadd <[email protected]> wrote:
> Hi,
>
> Is that true for aggregate RX too? I didn't think the FIFO was big
> enough to receive the whole aggregate, so I wonder what timestamp
> aggregates sub-frames are receiving.
>From our captures it looks like the entire aggragate gets the same
timestamp (first frame?).
Thomas
Hi,
Is that true for aggregate RX too? I didn't think the FIFO was big
enough to receive the whole aggregate, so I wonder what timestamp
aggregates sub-frames are receiving.
adrian
On 12 November 2012 10:47, Thomas Pedersen <[email protected]> wrote:
> Tested with AR9280.
>
> Signed-off-by: Thomas Pedersen <[email protected]>
> ---
> drivers/net/wireless/ath/ath9k/recv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index a04028b..d4df98a 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -976,7 +976,7 @@ static int ath9k_rx_skb_preprocess(struct ath_common *common,
> rx_status->freq = hw->conf.channel->center_freq;
> rx_status->signal = ah->noise + rx_stats->rs_rssi;
> rx_status->antenna = rx_stats->rs_antenna;
> - rx_status->flag |= RX_FLAG_MACTIME_MPDU;
> + rx_status->flag |= RX_FLAG_MACTIME_END;
> if (rx_stats->rs_moreaggr)
> rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 12, 2012 at 11:00 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Mon, Nov 12, 2012 at 7:47 PM, Thomas Pedersen <[email protected]> wrote:
>> Tested with AR9280.
>>
>> Signed-off-by: Thomas Pedersen <[email protected]>
>> ---
>> drivers/net/wireless/ath/ath9k/recv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
>> index a04028b..d4df98a 100644
>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>> @@ -976,7 +976,7 @@ static int ath9k_rx_skb_preprocess(struct ath_common *common,
>> rx_status->freq = hw->conf.channel->center_freq;
>> rx_status->signal = ah->noise + rx_stats->rs_rssi;
>> rx_status->antenna = rx_stats->rs_antenna;
>> - rx_status->flag |= RX_FLAG_MACTIME_MPDU;
>> + rx_status->flag |= RX_FLAG_MACTIME_END;
>> if (rx_stats->rs_moreaggr)
>> rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
>
> Thanks but can you clarify the implications of this change within the
> commit log ? Was something not working, if not, why exactly is this
> change important?
Sure.
Thomas
On Mon, Nov 12, 2012 at 7:47 PM, Thomas Pedersen <[email protected]> wrote:
> Tested with AR9280.
>
> Signed-off-by: Thomas Pedersen <[email protected]>
> ---
> drivers/net/wireless/ath/ath9k/recv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index a04028b..d4df98a 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -976,7 +976,7 @@ static int ath9k_rx_skb_preprocess(struct ath_common *common,
> rx_status->freq = hw->conf.channel->center_freq;
> rx_status->signal = ah->noise + rx_stats->rs_rssi;
> rx_status->antenna = rx_stats->rs_antenna;
> - rx_status->flag |= RX_FLAG_MACTIME_MPDU;
> + rx_status->flag |= RX_FLAG_MACTIME_END;
> if (rx_stats->rs_moreaggr)
> rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
Thanks but can you clarify the implications of this change within the
commit log ? Was something not working, if not, why exactly is this
change important?
Luis
Tested with AR9271.
Signed-off-by: Thomas Pedersen <[email protected]>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 06cdcb7..1708b01 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -1082,7 +1082,7 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv *priv,
rx_status->freq = hw->conf.channel->center_freq;
rx_status->signal = rxbuf->rxstatus.rs_rssi + ATH_DEFAULT_NOISE_FLOOR;
rx_status->antenna = rxbuf->rxstatus.rs_antenna;
- rx_status->flag |= RX_FLAG_MACTIME_MPDU;
+ rx_status->flag |= RX_FLAG_MACTIME_END;
return true;
--
1.7.10.4
On 12 November 2012 11:26, Thomas Pedersen <[email protected]> wrote:
> From our captures it looks like the entire aggragate gets the same
> timestamp (first frame?).
Right, so MACTIME_END is not appropriate there?
adrian
Tested with AR9280.
Signed-off-by: Thomas Pedersen <[email protected]>
---
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index a04028b..d4df98a 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -976,7 +976,7 @@ static int ath9k_rx_skb_preprocess(struct ath_common *common,
rx_status->freq = hw->conf.channel->center_freq;
rx_status->signal = ah->noise + rx_stats->rs_rssi;
rx_status->antenna = rx_stats->rs_antenna;
- rx_status->flag |= RX_FLAG_MACTIME_MPDU;
+ rx_status->flag |= RX_FLAG_MACTIME_END;
if (rx_stats->rs_moreaggr)
rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
--
1.7.10.4
On Mon, Nov 12, 2012 at 11:32 AM, Adrian Chadd <[email protected]> wrote:
> On 12 November 2012 11:26, Thomas Pedersen <[email protected]> wrote:
>
>> From our captures it looks like the entire aggragate gets the same
>> timestamp (first frame?).
>
> Right, so MACTIME_END is not appropriate there?
I don't think it really matters since before they would also all get
the same timestamp anyway?
Thomas