[PATCH] mvme147: use correct order of ram pages

Discussion:

Amos Kong

2014-05-28 04:07:53 UTC

16K is 2^2 * PAGE_SIZE, so the page order should be 2, not 3.

This patch uses get_order() to get correct order, and fixes
one typo in comment.

Signed-off-by: Amos Kong <***@redhat.com>
---
This patch wasn't built. Geert, can you help to test it?
I don't know if it needs a head file by using get_order().
---
drivers/net/ethernet/amd/mvme147.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/amd/mvme147.c b/drivers/net/ethernet/amd/mvme147.c
index 0e8399d..4e98bf8 100644
--- a/drivers/net/ethernet/amd/mvme147.c
+++ b/drivers/net/ethernet/amd/mvme147.c
@@ -26,10 +26,11 @@
#include <asm/pgtable.h>
#include <asm/mvme147hw.h>

-/* We have 16834 bytes of RAM for the init block and buffers. This places
+/* We have 16384 bytes of RAM for the init block and buffers. This places
* an upper limit on the number of buffers we can use. NetBSD uses 8 Rx
* buffers and 2 Tx buffers.
*/
+#define M147LANCE_RAM_SIZE 16384 /* 16K */
#define LANCE_LOG_TX_BUFFERS 1
#define LANCE_LOG_RX_BUFFERS 3

@@ -111,7 +112,7 @@ struct net_device * __init mvme147lance_probe(int unit)
dev->dev_addr);

lp = netdev_priv(dev);
- lp->ram = __get_dma_pages(GFP_ATOMIC, 3); /* 16K */
+ lp->ram = __get_dma_pages(GFP_ATOMIC, get_order(M147LANCE_RAM_SIZE));
if (!lp->ram) {
printk("%s: No memory for LANCE buffers\n", dev->name);
free_netdev(dev);
@@ -134,7 +135,7 @@ struct net_device * __init mvme147lance_probe(int unit)

err = register_netdev(dev);
if (err) {
- free_pages(lp->ram, 3);
+ free_pages(lp->ram, get_order(M147LANCE_RAM_SIZE));
free_netdev(dev);
return ERR_PTR(err);
}
@@ -193,7 +194,7 @@ void __exit cleanup_module(void)
{
struct m147lance_private *lp = netdev_priv(dev_mvme147_lance);
unregister_netdev(dev_mvme147_lance);
- free_pages(lp->ram, 3);
+ free_pages(lp->ram, get_order(M147LANCE_RAM_SIZE));
free_netdev(dev_mvme147_lance);
}

--
1.9.0

Geert Uytterhoeven

2014-05-28 07:51:39 UTC

Permalink

Hi Amos,

Post by Amos Kong
16K is 2^2 * PAGE_SIZE, so the page order should be 2, not 3.
This patch uses get_order() to get correct order, and fixes
one typo in comment.

Thanks for your patch!

Post by Amos Kong
---
This patch wasn't built. Geert, can you help to test it?
I don't know if it needs a head file by using get_order().

It builds fine. The get_order() is nicely expanded to "2" in the assembler
output.

Now, I'd like to get some feedback from the MVME hackers first.
Perhaps the comment was wrong?

Post by Amos Kong
-/* We have 16834 bytes of RAM for the init block and buffers. This places
+/* We have 16384 bytes of RAM for the init block and buffers. This places
* an upper limit on the number of buffers we can use. NetBSD uses 8 Rx
* buffers and 2 Tx buffers.
*/
+#define M147LANCE_RAM_SIZE 16384 /* 16K */
#define LANCE_LOG_TX_BUFFERS 1
#define LANCE_LOG_RX_BUFFERS 3

BTW,I also find it fishy why the driver uses only 1+3 buffers, since more
RAM is available.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Andreas Schwab

2014-05-28 09:39:20 UTC

Permalink

Post by Geert Uytterhoeven

BTW,I also find it fishy why the driver uses only 1+3 buffers, since more
RAM is available.

It's 2^1+2^3.

Andreas.

--
Andreas Schwab, ***@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Amos Kong

2014-05-28 13:58:20 UTC

Permalink

Post by Andreas Schwab

Post by Geert Uytterhoeven

#define TX_RING_SIZE (1 << LANCE_LOG_TX_BUFFERS)
#define RX_RING_SIZE (1 << LANCE_LOG_RX_BUFFERS)

Post by Andreas Schwab

Post by Geert Uytterhoeven
BTW,I also find it fishy why the driver uses only 1+3 buffers, since more
RAM is available.

It's 2^1+2^3.

tx & rx bufs aren't 2^1 + 2^3 = 10 pages.

Rx buffers and Tx buffers are included in 'struct lance_init_block'

volatile char tx_buf[TX_RING_SIZE][TX_BUFF_SIZE];
volatile char rx_buf[RX_RING_SIZE][RX_BUFF_SIZE];

volatile char tx_buf[2][1544];
volatile char rx_buf[8][1544];

RX_BUFF_SIZE = TX_BUFF_SIZE = 1554
So tx_buf takes 1544 * 2 bytes, rx_buf takes 1544 * 8 bytes

In drivers/net/ethernet/amd/mvme147.c:
=====================================
lp->lance.init_block = (struct lance_init_block *)(lp->ram); /* CPU addr */
lp->lance.lance_init_block = (struct lance_init_block*)(lp->ram); /* LANCE addr of same RAM */

init_block and lance_init_block are set same address

In drivers/net/ethernet/amd/a2065.c:
===================================
priv->init_block = (struct lance_init_block *)dev->mem_start;
priv->lance_init_block = (struct lance_init_block *)A2065_RAM;

The ram size (A2065_RAM_SIZE) is 0x8000 -> 8 pages -> order is 3

It seems original 3 is a right order, we need to fix the comments.
it's 2^3 * 4k = 32K = 32768 bytes.

But in drivers/net/ethernet/amd/hplance.c:
=========================================
#define HPLANCE_MEMOFF 0x8000 /* struct lance_init_block */
lp->lance.init_block = (struct lance_init_block *)(va + HPLANCE_MEMOFF); /* CPU addr */
^^^^ it skips 0x8000, that is for HPLANCE
lp->lance.lance_init_block = NULL; /* LANCE addr of same RAM */

We need 2 * 32k for lp->ram?

Post by Andreas Schwab
Andreas.
--
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Amos.