All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Chadd <adrian@freebsd.org>
To: Felix Fietkau <nbd@openwrt.org>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>,
	linville@tuxdriver.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v3 11/13] ath9k_hw: Disable Walsh spatial spreading for 2 chains
Date: Fri, 5 Aug 2011 19:50:44 +0800	[thread overview]
Message-ID: <CAJ-VmomE7UCaetEGQU8xK1ysUyOzr97Wn7TVXAD3CubZfNg8VA@mail.gmail.com> (raw)
In-Reply-To: <4E3BBC7F.9040902@openwrt.org>

.. question: are the regulatory limits programmed into the cards
taking this spreading into effect?



Adrian

On 5 August 2011 17:48, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-08-05 10:36 AM, Rajkumar Manoharan wrote:
>>
>> On Fri, Aug 05, 2011 at 08:24:53AM +0530, Rajkumar Manoharan wrote:
>>>
>>>  On Thu, Aug 04, 2011 at 08:23:28PM +0200, Felix Fietkau wrote:
>>>  >  On 2011-08-04 7:54 PM, Rajkumar Manoharan wrote:
>>>  >  >The Walsh bit is disabled for regulatory consideration.
>>>  >  >
>>>  >  >As per the FCC rulings, only transmissions that are completely
>>>  >  >non-coherent, are allowed to waive the array gain contribution
>>>  >  >to EIRP for multi-transmit configurations. The use of 2-stream
>>>  >  >with 2 transmit and use of 3-steam with 3 transmit qualifies
>>>  >  >for this spatial multiplexing MIMO classification as long as
>>>  >  >the streams are directly mapped to each radio (not Walsh spread
>>>  >  >prior to splitting to multiple radios)
>>>  >  I think ath9k does not waive the array gain contribution. I haven't
>>>  >  checked AR9003, but on AR9002 and older, it explicitly includes the
>>>  >  array gain contribution in the tx power limit calculation. I'm not
>>>  >  sure that unconditionally disabling spatial spreading is the right
>>>  >  way to deal with this.
>>>  >
>>>  We might violate the FCC rule with 2x2 config(3dB higher at 2-stream)
>>>  if this bit is enabled. Based on chainmask we can disable Walsh bit.
>>
>> This change does not affect 3x3, since we don't use 2-chain for 2-stream.
>> And Walsh mode would follow INI setting for 2x2 or 3x3 config.
>
> The thing is, on many channels the the card is allowed to transmit at up to
> 27 dBm, and often the hardware does not even get close to that. Why limit tx
> power by disabling this bit in cases where it's not even close to going over
> the limit.
> How about disabling it only if the combined txpower is within x dBm of the
> regulatory limit, or simply adding the same kind of multi-chain limit
> calculation that is being used on AR9280?
>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

      reply	other threads:[~2011-08-05 11:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 17:54 [PATCH v3 11/13] ath9k_hw: Disable Walsh spatial spreading for 2 chains Rajkumar Manoharan
2011-08-04 18:23 ` Felix Fietkau
2011-08-05  2:54   ` Rajkumar Manoharan
2011-08-05  6:35     ` Adrian Chadd
2011-08-05  7:24       ` Rajkumar Manoharan
2011-08-05  8:36     ` Rajkumar Manoharan
2011-08-05  9:48       ` Felix Fietkau
2011-08-05 11:50         ` Adrian Chadd [this message]

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=CAJ-VmomE7UCaetEGQU8xK1ysUyOzr97Wn7TVXAD3CubZfNg8VA@mail.gmail.com \
    --to=adrian@freebsd.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=nbd@openwrt.org \
    --cc=rmanohar@qca.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.