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.
Best regards
Alexander Wilhelm
