On Tuesday 02 March 2010 06:13:52 Benoit PAPILLAULT wrote: > Bruno Randolf a écrit : > > hi! > > > > i think we don't need to worry too much about one or two register reads > > more or less. (in my tests on a pretty slow board, one TSF register read > > needed about 1,3us in average thru 1000 reads). > > > > also i can reproduce the wrap problems here on a 5414 chip. > > > > the HAL has a 3x read approach, so we definetly have to do something... > > > > we could avoid the problem of being interruped locally by disabling > > interrups (local_irq_disable())... > > > > but what we cannot avoid are the HW merges, which could happen any time. > > so i guess something like the loop approach derek mentioned could be the > > safest way > > > > - but only checking the upper part is not enough. what happens if the HW > > > > merge only updated the lower 32 bits (which should happen more commonly > > by small automatic TSF adjustments)? > > > > bruno > > Hi Bruno, > > I don't think that disabling interrupts will solve the HW merges (it > might reduced the delay between register reads however). The code > proposed by Derek is safe in fact : the condition when H1 = H2 means > that no rollover has happens. In fact, the problem is not "getting TSF > after any HW update", the real problem is getting a consistent value for > upper & lower part, ie a timestamp that really happens to be (in the > past of course...). > > So, let's say a HW merge happens and only update the lower part of TSF, > there are two cases : either it happens between the first 2 reads or > between the read 2 & read 3. In both cases, the resulting value will be > consistent (in the first case, it will be after the HW merge, on the > second case it will be before the HW merge). > > I'll try to redo the patch I sent earlier.
hi benoit! i agree with what you said. let's not forget the bigger picture: while it's good to make TSF reads as reliable as possible, we can never be 100% sure about the TSF anyways (and the extended RX timestamps therefore, which use the current TSF and 15bit from the descriptor) as long as HW merges can update the TSF any time. so with ath5k hardware there will always be some uncertainity (can we say that ath5k hardware is crap for IBSS?). but right now the TSF is used for IBSS merging, beacon timer configuration and radiotap headers only. forget about the headers, so the only thing we need to be concerned is beacon timers and IBSS merging. if mac80211 is smart enough, a few extra merges to the same BSSID shouldn't hurt too much. also there is already some code in place to check for TSF jumps and fix beacon timer configuration, not sure if that's enough, but it already helps to keep track of jumping TSF values. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
