On Tue, Sep 28, 2010 at 01:28:22AM +0200, thus spake Christian Lamparter:
> On Tuesday 28 September 2010 01:01:37 Ignacy Gawedzki wrote:
> > On Mon, Sep 27, 2010 at 07:36:21PM +0200, thus spake Christian Lamparter:
> > > Sure, but why when you have a monotonic 40 MHz timer?
> >
> > Glad to know there is such a thing, then. =)
> or was it 80Mhz? Nevermind, the docs are not very specific.
AFAICT there's a constant in timer.h :
#define AR9170_TICKS_PER_MICROSECOND 80
but there's also that clock_set() function that seems to be setting the clock
up with different frequencies, but I supppose that's a different thing.
> > Okay, I thought these API versions were there to be checked by the driver
> > somehow for conformance.
>
> They are... But only at the "highest" level ;)
> Anyway, there's a bitfield which describe what commands, operation modes
> and features are support by the firmware image.
Very well then. =)
> I posted a few patches two hours ago. you should check out
> "[PATCH] carl9170: fix hung workqueue", because it may be fixes the bug.
I'll give it a try as soon as possible, thanks.
> > I just tried the whole setup with the latest wireless-testing sources and your
> > patch on the firmware. So far, so good, the problems I had previously are not
> > showing up. I'm now just adapting your proposition to support rollover and
> > conversion of the measurement to nanoseconds.
> Rollover checks? Can you please tell me where you exactly see a potential
> rollover problem in the proposal?
Well, what I meant was to support the case when the clock ticks counter wraps
around. Supposing there are 40e6 ticks per second, 2^32 ticks run out in less
than 108 seconds, or maybe I'm missing something here. I then need to
consider the case where comp_tsf ends up not being larger than tsfl. Since
we're dealing with unsigned ints, in this case the simple difference would
end up being something rather large. :/
> > One last question about your patch. If a frame transmission fails altogether,
> > i.e. the maximum attempts have been made and no ACK has been received
> > whatsoever, will the driver get a tx_status with the overall timer spent
> > serving that frame anyway (read: that's what I actually want)?
> Currently not, but this can be achieved by moving the tsfl =
> get_clock_counter(); from __wlan_tx to _wlan_tx() and kill the one in
> wlan_tx_status.
Thanks for that hint, too. =)
Best regards,
Ignacy
--
P.S. All information contained in the above letter is false,
for reasons of military security.
--
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
