From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Date: Fri, 22 Aug 2014 11:29:35 +0200 Subject: [U-Boot] [PATCH 8/9] net: rtl8169: Use non-cached memory if available In-Reply-To: <53F4F7F2.1020204@wwwdotorg.org> References: <1408348852-30894-1-git-send-email-thierry.reding@gmail.com> <1408348852-30894-9-git-send-email-thierry.reding@gmail.com> <53F4F7F2.1020204@wwwdotorg.org> Message-ID: <20140822092925.GE24156@ulmo> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > > >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: