On Thu, Aug 04, 2011 at 07:55:32PM +0200, Felix Fietkau wrote:
> On 2011-08-04 7:45 PM, Rajkumar Manoharan wrote:
> >On Tue, Aug 02, 2011 at 07:33:00PM +0200, Felix Fietkau wrote:
> >> On 2011-08-02 11:46 AM, Rajkumar Manoharan wrote:
> >> >On Fri, Jul 29, 2011 at 02:41:41PM +0200, Felix Fietkau wrote:
> >> >> On 2011-07-29 2:08 PM, Rajkumar Manoharan wrote:
> >> >> >Signed-off-by: Rajkumar Manoharan<rmanohar@xxxxxxxxxxxxxxxx>
> >> >> >---
> >> >> > .../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 2 +-
> >> >> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >> >
> >> >> >diff --git a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
> >> >> >index 2339728..28b44b0 100644
> >> >> >--- a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
> >> >> >+++ b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
> >> >> >@@ -636,7 +636,7 @@ static const u32 ar9300_2p2_baseband_postamble[][5] = {
> >> >> > {0x00009e44, 0x02321e27, 0x02321e27, 0x02291e27, 0x02291e27},
> >> >> > {0x00009e48, 0x5030201a, 0x5030201a, 0x50302012, 0x50302012},
> >> >> > {0x00009fc8, 0x0003f000, 0x0003f000, 0x0001a000, 0x0001a000},
> >> >> >- {0x0000a204, 0x000037c0, 0x000037c4, 0x000037c4, 0x000037c0},
> >> >> >+ {0x0000a204, 0x000036c0, 0x000036c4, 0x000036c4, 0x000036c0},
> >> >> > {0x0000a208, 0x00000104, 0x00000104, 0x00000004, 0x00000004},
> >> >> > {0x0000a22c, 0x01026a2f, 0x01026a2f, 0x01026a2f, 0x01026a2f},
> >> >> > {0x0000a230, 0x0000000a, 0x00000014, 0x00000016, 0x0000000b},
> >> >> That patch makes no sense, it disables Walsh spatial spreading in
> >> >> the initvals, but the driver still enables it in
> >> >> ar9003_hw_set_channel_regs.
> >> >> By the way, why should we disable Walsh spatial spreading?
> >> >>
> >> >The initval table is filled with default values recommended in register spec.
> >> >This patch does that. And these default value can be altered during chip bringup
> >> >based on chip family.
> >> OK, then the patch description should probably mention that this
> >> change has no effect and does not actually disable this feature in
> >> general, since the driver unconditionally enables it elsewhere.
> >>
> >Felix,
> >
> >The Walsh bit is disabled for regulatory consideration.
> >
> >In 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)
> >
> >And also Walsh has to be disabled in ar9003_hw_set_channel_regs.
> >Thanks for finding out. Will send followup patch.
> Wouldn't that only be relevant if the regdomain/country setting is a
> FCC one *and* the configured tx power is close to the limit?
> It seems to me that if either of those is not the case, it should be
> valid to keep walsh spatial spreading enabled.
>
Sorry for the delayed response.
FCC limit for walsh enable is lower than that for walsh disable.
So disabling walsh bit will NOT limit tx power/affect tx power
even in cases where we are not FCC limited (most client cards).
If the Tx power is not FCC limited, then enabling/disabling walsh
bit will not affect Avg. EVM/overall performance in any visible manner.
When this is the case, I do not see a strong reason to have any channel
based logic to enable/disable walsh bit. The simplest solution would be
to change 1 bit in INI.
John,
Do you want me to rebase and send it again?
--
Rajkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
