qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH] Set ENET_BD_BDU in I.MX FEC controller


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH] Set ENET_BD_BDU in I.MX FEC controller
Date: Wed, 7 Aug 2019 18:05:31 +0100

On Mon, 5 Aug 2019 at 15:24, Aaron Hill <address@hidden> wrote:
>
> From: Aaron Hill <address@hidden>
>
> This commit properly sets the ENET_BD_BDU flag once the emulated FEC 
> controller
> has finished processing the last descriptor. This is done for both transmit
> and receive descriptors.
>
> This allows the QNX 7.0.0 BSP for the Sabrelite board (which can be
> found at http://blackberry.qnx.com/en/developers/bsp) to properly
> control the FEC. Without this patch, the BSP ethernet driver will never
> re-use FEC descriptors, as the unset ENET_BD_BDU flag will cause
> it to believe that the descriptors are still in use by the NIC.
>
> Note that Linux does not appear to use this field at all, and is
> unaffected by this patch.
>
> Without this patch, QNX will think that the NIC is still processing its
> transaction descriptors, and won't send any more data over the network.
>
> For reference:
>
> On page 1192 of the I.MX 6DQ reference manual revision (Rev. 5, 06/2018),
> which can be found at 
> https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-6-processors/i.mx-6quad-processors-high-performance-3d-graphics-hd-video-arm-cortex-a9-core:i.MX6Q?&tab=Documentation_Tab&linkline=Application-Note
>
> the 'BDU' field is described as follows for the 'Enhanced transmit
> buffer descriptor':
>
> 'Last buffer descriptor update done. Indicates that the last BD data has been 
> updated by
> uDMA. This field is written by the user (=0) and uDMA (=1).'
>
> The same description is used for the receive buffer descriptor.
>
> Signed-off-by: Aaron Hill <address@hidden>
> ---



Hi; thanks for this patch. The data sheet's description of the
buffer descriptors was a bit confusing to me (since it describes
what we have as a "uint32_t last_buffer" as two separate 16 bit
fields) but I think this is correct given how we define ENET_BD_BDU.

I've applied it to target-arm.next ready to go in once the
4.1 release ships and we reopen trunk for new development.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]