Currently, fastpath CE RX buffers are not properly getting reset on
WCN6450 due to which driver is reading data at wrong offset leading to
packet drops. Properly resetting the nbufs after every CE RX buffer
processing is fixing the issue.
Change-Id: Ic29740fb1a72a3302752cc457bcf45f8d0094c46
CRs-Fixed: 3601680
Currently RX nbuf data pointer is reset considering
headroom reserve size of NET_SKB_PAD. So while reattaching
buffer back to H.W always data pointer is reset back to head plus
NET_SKB_PAD offset. But if skb is not allocated with head room
reserve then we should not reset data pointer taking NET_SKB_PAD
as consideration.
Fix this by pushing nbuf data pointer back to the state when
nbuf entered the host.
Change-Id: Ie96f99fdd92deaa921619a45cd5993a42f7b8f6e
CRs-Fixed: 3582873
In the case of WCN6450, WBM HW block is removed in the UMAC.
TX completions come via HTT messages. Add logic to handle
HTT TX completion messages from the firmware.
Changes are specific to WCN6450 and hence implement the logic
in the arch specific code.
Change-Id: I447020354ce26e8948e4b49648c434fb2ed302cd
CRs-Fixed: 3381814
Implement TX enqueue logic for WCN6450. There are no host facing
UMAC HW blocks in WCN6450. Driver enqueues all TX packets to
copy engine (CE) over the copy engine channel that is mapped to
HTT_DATA2_MSG_SVC service.
Changes are specific to WCN6450 and hence implement the logic
in the arch specific code.
Change-Id: Ia366a74b94a4e84c1d4c037c7a99093bb6739178
CRs-Fixed: 3381755
In the case of WCN6450, sizes of the TX descriptor pools are not known
to the driver during load time. The sizes are shared by the firmware
post VDEV creation via HTT_T2H_MSG_TYPE_FLOW_POOL_MAP HTT message.
After the VDEV gets deleted in the firmware, a corresponding flow unmap
HTT message will be sent to the driver to clean up the TX descriptors
of a particular VDEV.
Add logic to handle the flow map/unmap HTT messages for WCN6450. These
messages are specific to WCN6450 and hence the logic is implemented in
arch specific HTT code.
Change-Id: I8edcabbec77abae2c238f487acb7a48b478fd149
CRs-Fixed: 3381751
RHINE is soft UMAC based architecture which is not having
REO block, all the REO functionality will be implemented
in F.W and host level. Host will get the RX packets in
CE-RX rings in HTT format, to reap RX packets new HTT
messages will be extracted and parsed.
So implement RX handling based on new softumac architecture for RHINE.
Change-Id: If430dd017309e2b2a3eb5e27e1d8b58696abceb4
CRs-Fixed: 3382920
Add HTT changes which are specific to RHINE architecture.
Some of the changes like dedicated TX endpoint service,
fastpath implementation and few other message handling
is different in RHINE. Current change add support for
RHINE specific HTT implementation.
Change-Id: I90c2d1d66cdadc5935e6b819e3f19e635c45cb51
CRs-Fixed: 3382915
This change introduces new RHINE architecture specific DP files.
RHINE is new SOFTUMAC based architecture, unlike LI/BE targets
all the HW UMAC functionality will be replaced with software base
UMAC functionality. So current RHINE arch specific implementation
is aligned to softumac based implementation.
Change-Id: I70baf11130afc07c5c85437d2343d0976ce0ea0a
CRs-Fixed: 3382880
