On 10/27/2014 03:18 PM, Adrien Decostre wrote:

Hello Zefir,

Thanks a lot for your answer. This helps me a lot.
If I correctly understand, the ability of ath9k to detect all pulses
may also depend of the platform performances. So on an embedded
platform with limited performances, we may observe more pulses losses
than on a more powerful platform. Is this a right statement?

No, there is no bottleneck in the platform performance. Presumed radar pulses are
reported as RX_ERROR descriptors and even lower end embedded systems are able to
handle the load. What makes the difference with the minimum pulse width is the
chip DFS engine's ability to isolate and identify very short spikes as potential
radar pulses.

This goes very deeply into material I had available under NDA while implementing
the DFS support for ath9k. If you intend to work on that topic, I encourage you to
contact the folks at QCA and join their 'NDA for Developers' program. The document
you want to read is 'Baseband DFS 2 (Radar) Micro-Architecture'.

What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it
to enable the detection of 0.5usec. pulses?

Yes, this driver specific flag (also available for 10k) you need to set to get the
DFS detector built (not related to pulse width). It essentially shifts the
responsibility of the product working in restricted bands to you / the manufacturer.

Thanks in advance for your answer.

Best regards

Adrien

Good Luck,
Zefir