linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Lamparter <chunkeey@googlemail.com>
To: Ignacy Gawedzki <i@lri.fr>
Cc: linux-wireless@vger.kernel.org
Subject: Re: A few questions about modifications in carl9170
Date: Mon, 27 Sep 2010 19:36:21 +0200	[thread overview]
Message-ID: <201009271936.22261.chunkeey@googlemail.com> (raw)
In-Reply-To: <20100927160557.GA5121@qubit.lri.fr>

[-- Attachment #1: Type: Text/Plain, Size: 1475 bytes --]

On Monday 27 September 2010 18:05:57 Ignacy Gawedzki wrote:
> On Mon, Sep 27, 2010 at 05:37:16PM +0200, thus spake Christian Lamparter:
> > [...]
> > without any problems. The device was able to connect and send a few gigs.
> > Maybe you should be a bit more "precise" about your changes ;).
> 
> Sure, see the attached diff.  The idea is to simply use the local TSF counter
> to measure the service time.  I know that the TSF gets updated in IBSS pretty
> regularly, but still, the measurements seem accurate enough.
Sure, but why when you have a monotonic 40 MHz timer?

(It isn't so much what you do in the firmware, as long as you don't put
printk into the drivers hot-paths)

> > (Haven't seen the WARN before, kernel/workqueue.c code has changed a lot
> > and flush_cpu_workqueue is no more...)
> 
> OK, I'll stick with the latest wireless-testing then.  BTW, I noticed that the
> FW API is 1.8.8.2, while driver API in wireless-testing is still 1.8.8.1.
Actually, the firmware is already at 1.8.8.3-pre. But it shouldn't matter if
what API "version" you are using, as long as the firmware descriptors and
command interface structs are the same.

> Having some stability issues with this combination, I reverted the last few
> commits in the FW's git back to API 1.8.8.1.  Are these different numbers
> nevertheless compatible with each other?
"Stability issues"? Again, a "vague" and stretchy term. Do you have "Oops" -
reports or something like that? 

Regards,
	Chr

[-- Attachment #2: carl9170-tx-measure.diff --]
[-- Type: text/x-patch, Size: 3201 bytes --]

diff --git a/carlfw/src/wlan.c b/carlfw/src/wlan.c
index b6c0e34..d76d635 100644
--- a/carlfw/src/wlan.c
+++ b/carlfw/src/wlan.c
@@ -156,6 +156,8 @@ static struct carl9170_tx_status *wlan_get_tx_status_buffer(void)
 	return tmp;
 }
 
+static unsigned int comp_tsf;
+
 /* generate _aggregated_ tx_status for the host */
 static void wlan_tx_complete(struct carl9170_tx_superframe *super,
 			     bool txs)
@@ -178,6 +180,9 @@ static void wlan_tx_complete(struct carl9170_tx_superframe *super,
 	status->rix = super->s.rix;
 	status->tries = super->s.cnt;
 	status->success = (txs) ? 1 : 0;
+
+	/* jup, no fancy rollover stuff */
+	status->duration = comp_tsf - super->s.tsfl;
 }
 
 static bool wlan_tx_consume_retry(struct carl9170_tx_superframe *super)
@@ -253,6 +258,8 @@ static void __wlan_tx(struct dma_desc *desc)
 	BUG_ON(fw.phy.psm.state != CARL9170_PSM_WAKE);
 # endif /* CONFIG_CARL9170FW_DEBUG && CONFIG_CARL9170FW_PSM */
 
+	super->s.tsfl = get_clock_counter();
+
 	/* insert desc into the right queue */
 	dma_put(&fw.wlan.tx_queue[queue], desc);
 	wlan_trigger(BIT(queue));
@@ -328,6 +335,8 @@ static bool wlan_tx_status(struct dma_queue *queue,
 				/* demise descriptor ownership back to the hardware */
 				dma_rearm(desc);
 
+				super->s.tsfl = get_clock_counter();
+
 				/*
 				 * And this will get the queue going again.
 				 * To understand why: you have to get the HW
@@ -399,6 +408,8 @@ static void handle_tx_completion(void)
 	struct dma_desc *desc;
 	unsigned int i;
 
+	comp_tsf = get_clock_counter();
+
 	for (i = 0; i < __AR9170_NUM_TX_QUEUES; i++) {
 		__while_desc_bits(desc, &fw.wlan.tx_queue[i], AR9170_OWN_BITS_SW) {
 			if (!wlan_tx_status(&fw.wlan.tx_queue[i], desc)) {
diff --git a/include/shared/fwcmd.h b/include/shared/fwcmd.h
index d4a4e1d..248b34d 100644
--- a/include/shared/fwcmd.h
+++ b/include/shared/fwcmd.h
@@ -215,6 +215,8 @@ struct carl9170_tx_status {
 	u8 rix:2;
 	u8 tries:3;
 	u8 success:1;
+
+	__le32 duration;
 } __packed;
 struct _carl9170_tx_status {
 	/*
@@ -223,8 +225,10 @@ struct _carl9170_tx_status {
 
 	u8 cookie;
 	u8 info;
+
+	__le32 duration;
 } __packed;
-#define CARL9170_TX_STATUS_SIZE		2
+#define CARL9170_TX_STATUS_SIZE		6
 
 #define	CARL9170_RSP_TX_STATUS_NUM	(CARL9170_MAX_CMD_PAYLOAD_LEN /	\
 					 sizeof(struct _carl9170_tx_status))
diff --git a/include/shared/wlan.h b/include/shared/wlan.h
index 48ead22..074c641 100644
--- a/include/shared/wlan.h
+++ b/include/shared/wlan.h
@@ -254,6 +254,7 @@ struct carl9170_tx_superdesc {
 	u8 fill_in_tsf:1;
 	u8 cab:1;
 	u8 padding2;
+	u32 tsfl;
 	struct ar9170_tx_rate_info ri[CARL9170_TX_MAX_RATES];
 	struct ar9170_tx_hw_phy_control rr[CARL9170_TX_MAX_RETRY_RATES];
 } __packed;
@@ -317,6 +318,7 @@ struct _carl9170_tx_superdesc {
 	u8 ampdu_settings;
 	u8 misc;
 	u8 padding;
+	__le32 tsfl;
 	u8 ri[CARL9170_TX_MAX_RATES];
 	__le32 rr[CARL9170_TX_MAX_RETRY_RATES];
 } __packed;
@@ -327,7 +329,7 @@ struct _carl9170_tx_superframe {
 	u8 frame_data[0];
 } __packed;
 
-#define	CARL9170_TX_SUPERDESC_LEN		24
+#define	CARL9170_TX_SUPERDESC_LEN		28
 #define	AR9170_TX_HWDESC_LEN			8
 #define	AR9170_TX_SUPERFRAME_LEN		(CARL9170_TX_HWDESC_LEN + \
 						 AR9170_TX_SUPERDESC_LEN)

  reply	other threads:[~2010-09-27 17:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-27 13:29 A few questions about modifications in carl9170 Ignacy Gawedzki
2010-09-27 15:37 ` Christian Lamparter
2010-09-27 16:05   ` Ignacy Gawedzki
2010-09-27 17:36     ` Christian Lamparter [this message]
2010-09-27 23:01       ` Ignacy Gawedzki
2010-09-27 23:23         ` Ignacy Gawedzki
2010-09-27 23:39           ` Christian Lamparter
2010-09-28  6:44             ` Ignacy Gawedzki
2010-09-27 23:28         ` Christian Lamparter
2010-09-28  6:27           ` Ignacy Gawedzki
2010-09-28 12:04             ` Christian Lamparter
2010-09-28 12:40               ` Ignacy Gawedzki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201009271936.22261.chunkeey@googlemail.com \
    --to=chunkeey@googlemail.com \
    --cc=i@lri.fr \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).