The broadcom firmware sends a flowcontrol status in the rx packet
indicating that it is running short on tx buffers. This bit is used to
tell the driver to stop sending packets (based on their priority).
However, there seems to be a significantly large delay (~100ms) in the
fw updating the driver with the new flowcontrol bits.
Ozmo's audio traffic is marked as 0x106 priority which translates to
priority=0x40.
This change overrides the flowcontrol bits sent by the fw
and makes it so that the 0x40 priority traffic is never blocked from
flowcontrol. The DATAOK(bus) check on the bus ensures that we always
have enough tx buffers on the chip (despite the flowcontrol being set)
and that we don't end up clobbering packets on the fw.
Change-Id: I26c2d6f3b66d2e2f23c4c5327ed2577025bc089c
Signed-off-by: Aly Hirani <ahirani@nvidia.com>
Reviewed-on: http://git-master/r/433463
Reviewed-by: Chas Inman <chasi@nvidia.com>
if (delta) {
bus->fc_rcvd++;
- bus->flowcontrol = fcbits;
+ bus->flowcontrol = fcbits & ~(1 << 6);
}
/* Check and update sequence number */
if (delta) {
bus->fc_rcvd++;
- bus->flowcontrol = fcbits;
+ bus->flowcontrol = fcbits & ~(1 << 6);
}
/* Check and update sequence number */
bus->fc_xon++;
bus->fc_rcvd++;
- bus->flowcontrol = fcbits;
+ bus->flowcontrol = fcbits & ~(1 << 6);
}
#ifdef DHD_DEBUG