[PATCH rtems-lwip] rtemslwip/xil_shims: Perform flush with invalidate

[Chris Johns]

On 31/3/2023 8:13 am, Kinsey Moore wrote:
> Xilinx wrote their A53 HAL with the assumption that the CPU did not
> support cache invalidation without a flush, so the flush and
> invalidation functions were combined and all range invalidations are
> promoted to flush/invalidate. The implementation written for lwIP was
> written to the original intent of the function and thus was not flushing
> in some cases when it needed to. This resolves that issue which prevents
> DMA transmit errors in some cases.
> ---
>  rtemslwip/zynqmp/xil_shims.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/rtemslwip/zynqmp/xil_shims.c b/rtemslwip/zynqmp/xil_shims.c
> index 2eda0c5..1b1b3cf 100644
> --- a/rtemslwip/zynqmp/xil_shims.c
> +++ b/rtemslwip/zynqmp/xil_shims.c
> @@ -102,7 +102,12 @@ void XScuGic_DisableIntr ( u32 DistBaseAddress, u32 Int_Id )
>    rtems_interrupt_vector_disable( Int_Id );
>  }
>  
> +/*
> + * The Xilinx code was written such that it assumed there was no invalidate-only
> + * functionality on A53 cores. This function must flush and invalidate because
> + * of how they mapped things.
> + */
>  void Xil_DCacheInvalidateRange( INTPTR adr, INTPTR len )
>  {
> -  rtems_cache_invalidate_multiple_data_lines( (const void *) adr, len );
> +  rtems_cache_flush_multiple_data_lines( (const void *) adr, len );
>  }

Does the Xilinx code use Xil_DCacheInvalidateRange in any DMA receive paths? If
it does is this change correct as the invalidate has been removed?

Chris