On 8/19/2025 1:40 PM, Alexander Wilhelm wrote:
Am Tue, Aug 19, 2025 at 03:26:34PM +0800 schrieb Baochen Qiang:
On 8/19/2025 2:59 PM, Alexander Wilhelm wrote:
Am Tue, Aug 19, 2025 at 02:38:38PM +0800 schrieb Baochen Qiang:
On 8/15/2025 4:13 PM, Alexander Wilhelm wrote:
Hello devs,
I'm currently working on getting the 'ath12k' driver running on a big endian
PowerPC platform and have encountered the following issue.
In the function 'ath12k_dp_rx_process_reo_status', the REO status is determined
by inspecting memory that the hardware has previously written via DMA.
Specifically, during the call to 'ath12k_hal_srng_access_begin', the driver
reads the value of 'hp_addr' for the destination ring (in my case, always with
ID 21). On the big endian platform, this value is consistently 0, which prevents
the REO status from being updated.
This does not seem an endian issue to me, because either of them we should get a value
other than 0.
Really? I always assumed the value remains 0 until the firmware writes something
to memory and moves the head pointer of the SRNG ring buffer. By the way, I've
correct!
already implemented the missing endianness conversions for reading from and
writing to ring buffer pointers like this one:
hp = le32_to_cpu(*srng->u.dst_ring.hp_addr);
I was actually meaning that, when hp get updated by firmware, either with or without
le32_to_cpu conversion, we should get a value other than 0.
So in your cause I am suspecting that hardware/firmware has never sent any REO status to
host.
Yes, I see it the same way.
Interestingly, DMA read/write accesses work fine for other rings, just not for
this one. What makes the REO status ring so special? I couldn’t find anything in
the initialization routine that would explain the difference.
Could anyone give me a hint on what I should be looking for?
What hardware are you using? WCN7850 or QCN9274?
I'm using QCN9274-based dualmac modules.
sure
Best regards
Alexander Wilhelm
so did you see any obvious issue?
For example, in the function 'ath12k_dp_rx_peer_tid_delete', the function
'ath12k_dp_reo_cmd_send' is called, which in turn registers the function
'ath12k_dp_rx_tid_del_func' as a callback. On PowerPC, this callback function is
never invoked, which eventually leads to the following error:
ath12k_pci 0002:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 15 (-105)
ath12k_pci 0002:01:00.0: failed to update rx tid queue, tid 0 (-105)
ath12k_pci 0002:01:00.0: failed to update reo for rx tid 0
ath12k_pci 0002:01:00.0: failed to setup rx tid -105
ath12k_pci 0002:01:00.0: pdev idx 0 unable to perform ampdu action 0 ret -105
My investigations have shown that a cache flush is supposed to happen at some
point, e.g. after a timeout or when a threshold of 64 is reached. Since this
does not happen, I encounter errors after the 127th 'cmd_num'. This callback
function should actually be called from the 'reo_cmd_list' within the function
'ath12k_dp_rx_process_reo_status'. However, this does not happen because the
pointer is always 0.
I hope I was able to explain clearly what I was able to trace. Please correct me
if any of my assumptions are wrong.
Your understanding is mostly correct. it is also possible that there may be something
missing in REO_CMD ring (setup and cmd_send) which shows symptom like this in
REO_STATUS ring processing. If other src and dst rings are working fine,
REO_CMD/STATUS rings also are expected to work. Pls check src and dst ring
setup path once again.
Vasanth
