Re: [PATCH v2 11/13] ath9k_hw: Disable Walsh spatial spreading for 2 chains

["John W. Linville" <linville@tuxdriver.com>]

On Mon, Aug 15, 2011 at 01:25:04PM +0530, Rajkumar Manoharan wrote:
> 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@qca.qualcomm.com>
> > >> >>  >---
> > >> >>  >    .../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

Yes, please.

Thanks,

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.