[U-Boot] [PATCH 8/9] net: rtl8169: Use non-cached memory if available

[Thierry Reding]

On Wed, Aug 20, 2014 at 01:33:06PM -0600, Stephen Warren wrote:
> On 08/18/2014 02:00 AM, Thierry Reding wrote:
> >From: Thierry Reding <treding at nvidia.com>
> >
> >To work around potential issues with explicit cache maintenance of the
> >RX and TX descriptor rings, allocate them from a pool of uncached memory
> >if the architecture supports it.
> 
> >diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
> 
> >+#ifndef CONFIG_SYS_NONCACHED_MEMORY
> >  /* Define the TX Descriptor */
> >  DEFINE_ALIGN_BUFFER(struct TxDesc, tx_ring, NUM_TX_DESC, RTL8169_ALIGN);
> >
> >  /* Define the RX Descriptor */
> >  DEFINE_ALIGN_BUFFER(struct RxDesc, rx_ring, NUM_RX_DESC, RTL8169_ALIGN);
> >+#endif
> 
> It feels slightly inconsistent to have one case allocate this memory in BSS
> at compile-time, and in the other to allocate it dynamically.
> 
> Would it be better to remove this global, and simply call different APIs
> (regular aligned malloc, v.s. non-cached allocate) during rtl_init()?

I've reworked this a bit to use memalign() when non-cached memory isn't
available and factored out the descriptor allocation. I liked the code
slightly better before, but I guess consistently using dynamic memory
allocations is worth it. One potential downside is that memalign()
allocates from the malloc() pool, therefore devices using this driver
will now use more memory. I suppose they could even run out of memory
depending on how large the number of receive buffers becomes. Although
it's only the descriptors that are being dynamically allocated and they
are 16 bytes each. And it's not a problem that couldn't easily be solved
by increasing the malloc() size.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140822/a4fb97b7/attachment.pgp>