From: Felix Fietkau <nbd@openwrt.org>
To: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 2/3] ath9k: Paprd calibration should be per channel
Date: Thu, 16 Sep 2010 08:47:33 +0200 [thread overview]
Message-ID: <4C91BD85.9090604@openwrt.org> (raw)
In-Reply-To: <20100916051739.GA32605@vasanth-laptop>
On 2010-09-16 7:17 AM, Vasanthakumar Thiagarajan wrote:
> On Wed, Sep 15, 2010 at 08:53:34PM +0530, Felix Fietkau wrote:
>> On 2010-09-15 4:22 PM, Vasanthakumar Thiagarajan wrote:
>> > Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
>> NACK. The point of the caldata struct is to keep calibration data for
>> the operating channel and reset it whenever that changes (but not just
>> for off-channel activity).
>> Since the PAPRD data uses quite a bit of memory and doesn't take that
>> long to generate, we don't really need to make it per-channel.
>
> Yes, it takes some memory, this looked clean and simple. It is not
> unusual case that we would be operating on different channels
> (think about roaming,dfs,p2p and etc).
Roaming is fine, since the driver is unlikely to switch back and forth
often enough for the re-calibration to matter.
As far as I know, the plan for p2p is to have a per-vif channel in the
long run. Once that is implemented, the calibration data will also be
made per-vif.
> The existing implementation
> does not do paprd calibration when the operating channel is changed.
> Having a single caldata might require us depend on SC_OP_SCANNING/
> SC_OP_OFFCHANNEL, but we are already dealing with some bugs in those
> flags. I completely agree that it takes memory, would try to fix
> existing issues in paprd rather than keeping channel specific data.
> thanks for the review.
If PAPRD is not started after the return to the operating channel, then
other calibrations will be affected as well. In that case, we definitely
need to fix the root cause and not paper over the bug by moving the
PAPRD state.
- Felix
next prev parent reply other threads:[~2010-09-16 6:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 14:22 [PATCH 1/3] ath9k: Fix regression in starting ANI after association Vasanthakumar Thiagarajan
2010-09-15 14:22 ` [PATCH 2/3] ath9k: Paprd calibration should be per channel Vasanthakumar Thiagarajan
2010-09-15 15:23 ` Felix Fietkau
2010-09-16 5:17 ` Vasanthakumar Thiagarajan
2010-09-16 6:47 ` Felix Fietkau [this message]
2010-09-15 14:22 ` [PATCH 3/3] ath9k: Fix sparse warning: symbol 'ath_ant_div_conf_fast_divbias' was not declared Vasanthakumar Thiagarajan
2010-09-15 16:21 ` [PATCH 1/3] ath9k: Fix regression in starting ANI after association Luis R. Rodriguez
2010-09-16 4:49 ` Vasanthakumar Thiagarajan
2010-09-16 14:19 ` Luis R. Rodriguez
2010-09-22 13:49 ` Vasanthakumar Thiagarajan
2010-09-27 17:21 ` Luis R. Rodriguez
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=4C91BD85.9090604@openwrt.org \
--to=nbd@openwrt.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=vasanth@atheros.com \
/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).