[PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[Holger Brunck]

From: Clive Stubbings <clive.stubbings@xentech.co.uk>

The RIPTR and TIPTR  (receive/transmit internal temporary data pointer),
used by microcode as a temporary buffer for data, must be 32-byte aligned
according to the RM for MPC8247.

Tested on mgcoge.

Signed-off-by: Clive Stubbings <clive.stubbings@xentech.co.uk>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
cc: Vitaly Bordug <vbordug@ru.mvista.com>
cc: netdev@vger.kernel.org
---
This fixes a kernel crash on mgcoge when using SPI on CPM2 and
ethernet over FCC. Now fixed because the fcc driver now allocates
the space he really needs.

 drivers/net/fs_enet/mac-fcc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 7a84e45..7583a95 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -105,7 +105,7 @@ static int do_pd_setup(struct fs_enet_private *fep)
 		goto out_ep;
 
 	fep->fcc.mem = (void __iomem *)cpm2_immr;
-	fpi->dpram_offset = cpm_dpalloc(128, 8);
+	fpi->dpram_offset = cpm_dpalloc(128, 32);
 	if (IS_ERR_VALUE(fpi->dpram_offset)) {
 		ret = fpi->dpram_offset;
 		goto out_fcccp;
-- 
1.7.1

答复: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[杨勇]

Hello,
Motioned to the memory aligned, now there is such requirement:
When the driver send an packet to hardware, the skb's address passed by
stack do a dma map into hardware, the skb's dma address must be 64-byte
aligned.
My method:
 Allocate a new skb which is 64-byte aligned, then copy the passed skb to
new one
After test, the driver can work and overcome this issue.
But I eager to get a perfect solution about that, could you offer me a nice
one? Thanks so much~~

Code：
static struct sk_buff * skb_align_copy(const struct sk_buff *skb, gfp_t
gfp_mask)
{
    if((skb->len + LEN_INFO_BYTES) > 2000 ){
        atomic_inc(&proc_stat[PROC_STAT_JUMBO_CNT]);
        return NULL;
    }    

    struct sk_buff *n;
    n = alloc_skb(2048, gfp_mask);  //0 headroom
    if(!n)
        return NULL;

    atomic_inc(&proc_stat[PROC_STAT_SKB_ALLOC]);
    skb_put(n, skb->len + LEN_INFO_BYTES);

    if((skb->data - LEN_INFO_BYTES) == NULL){
        c_err("skb->data - LEN_INFO_BYTES is NULL!\n");
        return NULL;
    }    
    memcpy(n->data, skb->data - LEN_INFO_BYTES, skb->len + LEN_INFO_BYTES);
    return n;
}
static int ne_pcie_tx_map(struct ne_pcie_ring* tx_ring, struct sk_buff* skb)
{
    struct ne_pcie_buff* buff;
    struct sk_buff* align_skb;
    int i = tx_ring->next_to_use;
    int len = skb->len;
    int count = 0;

    align_skb = skb_align_copy(skb, GFP_ATOMIC);
    if(!align_skb){
        goto dma_map_error;
    }

    buff = &tx_ring->buffer[i];
    buff->length = len+LEN_INFO_BYTES;
    buff->dma = pci_map_single(tx_ring->pci_dev, align_skb->data,
            len+LEN_INFO_BYTES, PCI_DMA_TODEVICE);
    if (pci_dma_mapping_error(tx_ring->pci_dev, buff->dma)) {
        goto dma_map_error;
    }



-----邮件原件-----
发件人: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
代表 Holger Brunck
发送时间: 2011年6月17日 16:31
收件人: linuxppc-dev@lists.ozlabs.org
抄送: Clive Stubbings; Holger Brunck; Pantelis Antoniou; Vitaly Bordug;
netdev@vger.kernel.org
主题: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

From: Clive Stubbings <clive.stubbings@xentech.co.uk>

The RIPTR and TIPTR  (receive/transmit internal temporary data pointer),
used by microcode as a temporary buffer for data, must be 32-byte aligned
according to the RM for MPC8247.

Tested on mgcoge.

Signed-off-by: Clive Stubbings <clive.stubbings@xentech.co.uk>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
cc: Vitaly Bordug <vbordug@ru.mvista.com>
cc: netdev@vger.kernel.org
---
This fixes a kernel crash on mgcoge when using SPI on CPM2 and
ethernet over FCC. Now fixed because the fcc driver now allocates
the space he really needs.

 drivers/net/fs_enet/mac-fcc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 7a84e45..7583a95 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -105,7 +105,7 @@ static int do_pd_setup(struct fs_enet_private *fep)
 		goto out_ep;
 
 	fep->fcc.mem = (void __iomem *)cpm2_immr;
-	fpi->dpram_offset = cpm_dpalloc(128, 8);
+	fpi->dpram_offset = cpm_dpalloc(128, 32);
 	if (IS_ERR_VALUE(fpi->dpram_offset)) {
 		ret = fpi->dpram_offset;
 		goto out_fcccp;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[David Laight]

 
> Hello,
> Motioned to the memory aligned, now there is such requirement:
> When the driver send an packet to hardware, the skb's address passed
by
> stack do a dma map into hardware, the skb's dma address must 
> be 64-byte aligned.

Does the hardware support buffer chaining?
In which case you only need to copy the data upto the first
64 byte boundary into another buffer.

Actually, given that you are likely to have to fixup every
fragment of the frame being transmitted, if might be worth
allocating a fixed transmnit buffer area and copying the
frames into it prior to sending.
Certainly you need to allow for transmits made up of a
significant number of small buffers linked together.

Really you should beat up the hardware designers!

Copying the data to even a 4 byte boundary is almost
always a misaligned copy. Typically this only applies
to the receive dma - when writing a 2 byte pad before
the frame data would be much better.

	David

Re: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[David Miller]

From: Holger Brunck <holger.brunck@keymile.com>
Date: Fri, 17 Jun 2011 10:30:39 +0200

> From: Clive Stubbings <clive.stubbings@xentech.co.uk>
> 
> The RIPTR and TIPTR  (receive/transmit internal temporary data pointer),
> used by microcode as a temporary buffer for data, must be 32-byte aligned
> according to the RM for MPC8247.
> 
> Tested on mgcoge.
> 
> Signed-off-by: Clive Stubbings <clive.stubbings@xentech.co.uk>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> cc: Vitaly Bordug <vbordug@ru.mvista.com>
> cc: netdev@vger.kernel.org

Applied, thanks.

??: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[??]

Hi David Laight, Thank you so much~~
1. Hardware based on FPGA, it dose not support buffer chaining.
2. How dose the dma map support buffer chaining function?
3. On the align issue, the hardware designer start to fix it, maybe it's a
better way.  

-----????-----
???: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] ??
David Laight
????: 2011?6?17? 18:16
???: yangyong@neusoft.com; Holger Brunck; linuxppc-dev@lists.ozlabs.org
??: netdev@vger.kernel.org; Clive Stubbings; Vitaly Bordug
??: RE: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

 
> Hello,
> Motioned to the memory aligned, now there is such requirement:
> When the driver send an packet to hardware, the skb's address passed
by
> stack do a dma map into hardware, the skb's dma address must 
> be 64-byte aligned.

Does the hardware support buffer chaining?
In which case you only need to copy the data upto the first
64 byte boundary into another buffer.

Actually, given that you are likely to have to fixup every
fragment of the frame being transmitted, if might be worth
allocating a fixed transmnit buffer area and copying the
frames into it prior to sending.
Certainly you need to allow for transmits made up of a
significant number of small buffers linked together.

Really you should beat up the hardware designers!

Copying the data to even a 4 byte boundary is almost
always a misaligned copy. Typically this only applies
to the receive dma - when writing a 2 byte pad before
the frame data would be much better.

	David


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------