Search Linux Wireless

Re: [RFC 3/3] ath9k: add spectral scan feature

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adrian,

thanks a lot for your feedback!

On Fri, Nov 30, 2012 at 08:00:51PM -0800, Adrian Chadd wrote:
> Not that I'm specifically getting into this in any deep way right now, but..
> 
> On 27 November 2012 11:01, Simon Wunderlich
> <simon.wunderlich@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> [snip] - this should apply to AR9380 and later I think.
> 

Actually I have pretty much the same code in both ar9002_phy.c and ar9003_phy.c,
because they get different register definitions (addresses etc) from their respective
header files.

You think that this wouldn't apply for AR9280? Is there something wrong or different
with the register access?

I have put scan count of 8 in here, but on AR9380 I get much more samples (more like
256). I haven't played with this very much, because "a couple" of samples was all I
needed for my graphical analyzer.

> > +void ar9002_hw_spectral_scan(struct ath_hw *ah)
> > +{
> > +       struct ath_common *common = ath9k_hw_common(ah);
> > +
> > +       REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
> > +
> > +       /* NOTE: this will generate a few samples ... lacking documentation,
> > +        * I'm not really sure what these parameters mean.
> > +        */
> > +       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
> > +       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > +                   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
> > +       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > +                     AR_PHY_SPECTRAL_SCAN_COUNT, 8);
> > +       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > +                     AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
> > +       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > +                     AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
> > +
> > +       /* Activate spectral scan */
> > +       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > +                   AR_PHY_SPECTRAL_SCAN_ACTIVE);
> > +
> > +       /* Poll for spectral scan complete */
> > +       if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
> > +                          AR_PHY_SPECTRAL_SCAN_ACTIVE,
> > +                          0, AH_WAIT_TIMEOUT)) {
> > +               ath_err(common, "spectral scan wait failed\n");
> > +               return;
> > +       }
> > +
> > +       /* Disable spectral scan */
> > +       REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > +                   AR_PHY_SPECTRAL_SCAN_ENABLE);
> > +}
> > +
> 
> You shouldn't have to do this. There's two spectral scan modes (well, three) -
> 
> * when you're not decoding things, and you meet these parameters,
> please send me some events (I think the patent mentions this);
> * trigger _now_ and send me "X" events; then clear the spectral scan bit;
> * trigger _now_ and just send me infinite events - on earlier chips
> (AR9280 I think) the magic value may be 0; on the later values it may
> be 255. Someone should experiment.
> 
> I suggest you separate out "configure/enable/disable" and "trigger" as options.

OK, yeah I can do that - guess we should have different function calls for this
then, too. Don't know if all of this should be callable from mac80211 as well.

> 
> Grr, mumble mumble open source developers mumble mumble.. :-)

What are you muttering about? :D

Should we rather keep this wonderful feature to the closed source world?
I don't think so :)

> 
> I suggest experimenting around with those particular parameters. You
> should be able to coax out specific numbers of spectral scan events
> when you set the COUNT parameter to something other than 8. But
> polling that bit isn't needed. It should be asynchronous.

As I said, on AR9220 it appears I get 8 samples when doing setting 
AR_PHY_SPECTRAL_SCAN_COUNT to 8 (plus maybe some other "stuff"/non-samples).
On AR9380 I'm not so sure. Probably need to play with it a little
more. Also, I don't know what "SHORT REPEAT" is supposed to mean, etc.

About polling, you mean the SCAN_ACTIVE bit? It is probably only
needed when I want to trigger for few samples and want to be informed when
it's finished -  which is a good thing when doing spectral scan (change channel,
start and wait for samples, change again). But we probably don't need to wait
for the "background spectral scanning" mode, that's right. If someone wants
to implement detection for interfering radio users, that mode would be useful.
I don't need it, but can prepare the neccesary functions.

So I'd repost then:
 * ath9k/debugfs only patch for now, as Johannes suggested - I think we
   should concentrate on this for now (their are still a lot of open
   questions in my initial mail regarding sample interpretation etc)
 * split commands into enable/disable/configure/trigger
 * maybe add some defines for magic values (if I find any)

I'd like this patchset to make the graphical spectral scan possible (as
a Ubiquiti Airview), and give others the opportunity to add own features
(pattern matching etc) on top of it. However I (currently) don't plan to
do the latter myself.

> 
> Good luck,
> 
> 
> 
> Adrian

Thanks!
	Simon

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux