On Thu, 2008-02-21 at 17:57 +0100, Michael Buesch wrote: > Can you please test if this fixes beaconing?
Hmm, unfortunately not. This results in continuous beacon update interrupts because when both templates are valid we keep them valid all the time. Hence, it's not usable. I really wonder wtf. is going on. Why do we even have two beacon templates if we can't mark them both as valid at the same time? My earlier debugging change marked only the first one ever valid and that seems to work because the machine is fast enough... Basically, I think the machine has to always be fast enough to upload a beacon template within a beacon interval. That's pretty much guaranteed though so no big deal. I guess the only reason why there are two beacon templates is the processing latency. When the "beacon template ready (for modification by host)" interrupt comes in, we might only get to process it even later than that, and the ucode might need another beacon rather quickly. It needs to be guaranteed that the ucode has another beacon before it needs to send one, so the latency must not be higher than the beacon interval, but that should be fine. If we have to then change/upload the beacon though, maybe the thinking is that the latency combined with the template RAM write might be long enough to not allow uploading the complete beacon again before the next one is needed. Hence, the ability to upload both and with a just one MMIO read and write switch to the second one before uploading the first. I think what we should do is this: * we upload both beacon templates whenever we control them and it's necessary * however, we only mark one of them as hardware valid Then, when the "beacon template ready (for modification by host)" interrupt comes in, we check for which one the interrupt came in and mark the other template as valid immediately. This allows us to mark it *really* quickly, ie. with just a single MMIO read/write and could be done even in the interrupt handler itself. Then, we can lazily see later if we need to change the beacon template data and upload that without having too much timing pressure. Then, on the next interrupt, we switch to this one etc. johannes
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
