Hi,
A few months ago, Christian Lamparter suggested to me the use of
get_clock_counter() in the carl9170 firmware code for time measurement
purposes.
I just got back to that, after a long period of other things to do instead.
According to the results of a few tests I've been running yesterday, it looks
that this clock is 44Mhz, not 40Mhz, nor 80Mhz.
According to Christian, the clock source, as accessed through
get_clock_counter() is stable and does not depend on calls to clock_set().
This is further corroborated by the definition and use of the
AR9170_TICKS_PER_MICROSECOND *constant* in timer.h. But still, how comes that
constant is 80 then?
I'm obviously missing something here. I would be really thankful to anybody
who could explain how these clocks/timers work and how they are supposed to be
used.
Thanks,
Ignacy
--
I have not lost my mind, it's backed up on disk somewhere.
On Wed, Jan 5, 2011 at 6:13 AM, Ignacy Gawedzki <[email protected]> wrote:
> Hi,
>
> A few months ago, Christian Lamparter suggested to me the use of
> get_clock_counter() in the carl9170 firmware code for time measurement
> purposes.
>
> I just got back to that, after a long period of other things to do instead.
>
> According to the results of a few tests I've been running yesterday, it looks
> that this clock is 44Mhz, not 40Mhz, nor 80Mhz.
I have seen the same thing. In 802.11g mode, that clock counter runs
at 44MHz. There are rumors that this changes with operating mode.
Its easy to believe that it would run at 80MHz in turbo (40MHz
channel-width) mode. But, I haven't tested that, and can only say
that I've seen that clock counter run at 44MHz as well.
> According to Christian, the clock source, as accessed through
> get_clock_counter() is stable and does not depend on calls to clock_set().
> This is further corroborated by the definition and use of the
> AR9170_TICKS_PER_MICROSECOND *constant* in timer.h. ?But still, how comes that
> constant is 80 then?
Does anything in the firmware really rely on that constant being
right? I'm more familiar with ar9170usb and the open firmware for
that, where the constants were also wrong, but nothing used them
except for some delay functions, for which the accuracy wasn't
critical.
> I'm obviously missing something here. ?I would be really thankful to anybody
> who could explain how these clocks/timers work and how they are supposed to be
> used.
>
> Thanks,
>
> Ignacy
-Brian
On Wed, Jan 05, 2011 at 08:57:14AM -0500, thus spake Brian Prodoehl:
> On Wed, Jan 5, 2011 at 6:13 AM, Ignacy Gawedzki <[email protected]> wrote:
> > Hi,
> >
> > A few months ago, Christian Lamparter suggested to me the use of
> > get_clock_counter() in the carl9170 firmware code for time measurement
> > purposes.
> >
> > I just got back to that, after a long period of other things to do instead.
> >
> > According to the results of a few tests I've been running yesterday, it looks
> > that this clock is 44Mhz, not 40Mhz, nor 80Mhz.
>
> I have seen the same thing. In 802.11g mode, that clock counter runs
> at 44MHz. There are rumors that this changes with operating mode.
> Its easy to believe that it would run at 80MHz in turbo (40MHz
> channel-width) mode. But, I haven't tested that, and can only say
> that I've seen that clock counter run at 44MHz as well.
That would make sense indeed.
>
> > According to Christian, the clock source, as accessed through
> > get_clock_counter() is stable and does not depend on calls to clock_set().
> > This is further corroborated by the definition and use of the
> > AR9170_TICKS_PER_MICROSECOND *constant* in timer.h. ?But still, how comes that
> > constant is 80 then?
>
> Does anything in the firmware really rely on that constant being
> right? I'm more familiar with ar9170usb and the open firmware for
> that, where the constants were also wrong, but nothing used them
> except for some delay functions, for which the accuracy wasn't
> critical.
AFAICT, the delay functions are used during initialization and AGC
calibration. I have no idea whether the accuracy is critical or not in these
parts.
In any case, there is room for developing an accurate clock, assuming that it
always changes on request of the firmware and never by itself. I'll give it a
try and test whether it breaks everything or not. =)
--
I used to have a sig, but I've stopped smoking now.