* 答复: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment [not found] <1308299439-5975-1-git-send-email-holger.brunck@keymile.com> @ 2011-06-17 9:09 ` 杨勇 2011-06-17 10:16 ` David Laight 2011-06-17 19:21 ` David Miller 1 sibling, 1 reply; 4+ messages in thread From: 杨勇 @ 2011-06-17 9:09 UTC (permalink / raw) To: 'Holger Brunck', linuxppc-dev Cc: netdev, 'Clive Stubbings', 'Vitaly Bordug' SGVsbG8sCk1vdGlvbmVkIHRvIHRoZSBtZW1vcnkgYWxpZ25lZCwgbm93IHRoZXJlIGlzIHN1Y2gg cmVxdWlyZW1lbnQ6CldoZW4gdGhlIGRyaXZlciBzZW5kIGFuIHBhY2tldCB0byBoYXJkd2FyZSwg dGhlIHNrYidzIGFkZHJlc3MgcGFzc2VkIGJ5CnN0YWNrIGRvIGEgZG1hIG1hcCBpbnRvIGhhcmR3 YXJlLCB0aGUgc2tiJ3MgZG1hIGFkZHJlc3MgbXVzdCBiZSA2NC1ieXRlCmFsaWduZWQuCk15IG1l dGhvZDoKIEFsbG9jYXRlIGEgbmV3IHNrYiB3aGljaCBpcyA2NC1ieXRlIGFsaWduZWQsIHRoZW4g Y29weSB0aGUgcGFzc2VkIHNrYiB0bwpuZXcgb25lCkFmdGVyIHRlc3QsIHRoZSBkcml2ZXIgY2Fu IHdvcmsgYW5kIG92ZXJjb21lIHRoaXMgaXNzdWUuCkJ1dCBJIGVhZ2VyIHRvIGdldCBhIHBlcmZl Y3Qgc29sdXRpb24gYWJvdXQgdGhhdCwgY291bGQgeW91IG9mZmVyIG1lIGEgbmljZQpvbmU/IFRo YW5rcyBzbyBtdWNofn4KCkNvZGWjugpzdGF0aWMgc3RydWN0IHNrX2J1ZmYgKiBza2JfYWxpZ25f Y29weShjb25zdCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBnZnBfdApnZnBfbWFzaykKewogICAgaWYo KHNrYi0+bGVuICsgTEVOX0lORk9fQllURVMpID4gMjAwMCApewogICAgICAgIGF0b21pY19pbmMo JnByb2Nfc3RhdFtQUk9DX1NUQVRfSlVNQk9fQ05UXSk7CiAgICAgICAgcmV0dXJuIE5VTEw7CiAg ICB9ICAgIAoKICAgIHN0cnVjdCBza19idWZmICpuOwogICAgbiA9IGFsbG9jX3NrYigyMDQ4LCBn ZnBfbWFzayk7ICAvLzAgaGVhZHJvb20KICAgIGlmKCFuKQogICAgICAgIHJldHVybiBOVUxMOwoK ICAgIGF0b21pY19pbmMoJnByb2Nfc3RhdFtQUk9DX1NUQVRfU0tCX0FMTE9DXSk7CiAgICBza2Jf cHV0KG4sIHNrYi0+bGVuICsgTEVOX0lORk9fQllURVMpOwoKICAgIGlmKChza2ItPmRhdGEgLSBM RU5fSU5GT19CWVRFUykgPT0gTlVMTCl7CiAgICAgICAgY19lcnIoInNrYi0+ZGF0YSAtIExFTl9J TkZPX0JZVEVTIGlzIE5VTEwhXG4iKTsKICAgICAgICByZXR1cm4gTlVMTDsKICAgIH0gICAgCiAg ICBtZW1jcHkobi0+ZGF0YSwgc2tiLT5kYXRhIC0gTEVOX0lORk9fQllURVMsIHNrYi0+bGVuICsg TEVOX0lORk9fQllURVMpOwogICAgcmV0dXJuIG47Cn0Kc3RhdGljIGludCBuZV9wY2llX3R4X21h cChzdHJ1Y3QgbmVfcGNpZV9yaW5nKiB0eF9yaW5nLCBzdHJ1Y3Qgc2tfYnVmZiogc2tiKQp7CiAg ICBzdHJ1Y3QgbmVfcGNpZV9idWZmKiBidWZmOwogICAgc3RydWN0IHNrX2J1ZmYqIGFsaWduX3Nr YjsKICAgIGludCBpID0gdHhfcmluZy0+bmV4dF90b191c2U7CiAgICBpbnQgbGVuID0gc2tiLT5s ZW47CiAgICBpbnQgY291bnQgPSAwOwoKICAgIGFsaWduX3NrYiA9IHNrYl9hbGlnbl9jb3B5KHNr YiwgR0ZQX0FUT01JQyk7CiAgICBpZighYWxpZ25fc2tiKXsKICAgICAgICBnb3RvIGRtYV9tYXBf ZXJyb3I7CiAgICB9CgogICAgYnVmZiA9ICZ0eF9yaW5nLT5idWZmZXJbaV07CiAgICBidWZmLT5s ZW5ndGggPSBsZW4rTEVOX0lORk9fQllURVM7CiAgICBidWZmLT5kbWEgPSBwY2lfbWFwX3Npbmds ZSh0eF9yaW5nLT5wY2lfZGV2LCBhbGlnbl9za2ItPmRhdGEsCiAgICAgICAgICAgIGxlbitMRU5f SU5GT19CWVRFUywgUENJX0RNQV9UT0RFVklDRSk7CiAgICBpZiAocGNpX2RtYV9tYXBwaW5nX2Vy cm9yKHR4X3JpbmctPnBjaV9kZXYsIGJ1ZmYtPmRtYSkpIHsKICAgICAgICBnb3RvIGRtYV9tYXBf ZXJyb3I7CiAgICB9CgoKCi0tLS0t08q8/tStvP4tLS0tLQq3orz+yMs6IG5ldGRldi1vd25lckB2 Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpuZXRkZXYtb3duZXJAdmdlci5rZXJuZWwub3JnXQq0+rHt IEhvbGdlciBCcnVuY2sKt6LLzcqxvOQ6IDIwMTHE6jbUwjE3yNUgMTY6MzEKytW8/sjLOiBsaW51 eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZwqzrcvNOiBDbGl2ZSBTdHViYmluZ3M7IEhvbGdlciBC cnVuY2s7IFBhbnRlbGlzIEFudG9uaW91OyBWaXRhbHkgQm9yZHVnOwpuZXRkZXZAdmdlci5rZXJu ZWwub3JnCtb3zOI6IFtQQVRDSF0gZnNfZW5ldDogZml4IGZyZWVzY2FsZSBGQ0MgZXRoZXJuZXQg ZHAgYnVmZmVyIGFsaWdubWVudAoKRnJvbTogQ2xpdmUgU3R1YmJpbmdzIDxjbGl2ZS5zdHViYmlu Z3NAeGVudGVjaC5jby51az4KClRoZSBSSVBUUiBhbmQgVElQVFIgIChyZWNlaXZlL3RyYW5zbWl0 IGludGVybmFsIHRlbXBvcmFyeSBkYXRhIHBvaW50ZXIpLAp1c2VkIGJ5IG1pY3JvY29kZSBhcyBh IHRlbXBvcmFyeSBidWZmZXIgZm9yIGRhdGEsIG11c3QgYmUgMzItYnl0ZSBhbGlnbmVkCmFjY29y ZGluZyB0byB0aGUgUk0gZm9yIE1QQzgyNDcuCgpUZXN0ZWQgb24gbWdjb2dlLgoKU2lnbmVkLW9m Zi1ieTogQ2xpdmUgU3R1YmJpbmdzIDxjbGl2ZS5zdHViYmluZ3NAeGVudGVjaC5jby51az4KU2ln bmVkLW9mZi1ieTogSG9sZ2VyIEJydW5jayA8aG9sZ2VyLmJydW5ja0BrZXltaWxlLmNvbT4KY2M6 IFBhbnRlbGlzIEFudG9uaW91IDxwYW50ZWxpcy5hbnRvbmlvdUBnbWFpbC5jb20+CmNjOiBWaXRh bHkgQm9yZHVnIDx2Ym9yZHVnQHJ1Lm12aXN0YS5jb20+CmNjOiBuZXRkZXZAdmdlci5rZXJuZWwu b3JnCi0tLQpUaGlzIGZpeGVzIGEga2VybmVsIGNyYXNoIG9uIG1nY29nZSB3aGVuIHVzaW5nIFNQ SSBvbiBDUE0yIGFuZApldGhlcm5ldCBvdmVyIEZDQy4gTm93IGZpeGVkIGJlY2F1c2UgdGhlIGZj YyBkcml2ZXIgbm93IGFsbG9jYXRlcwp0aGUgc3BhY2UgaGUgcmVhbGx5IG5lZWRzLgoKIGRyaXZl cnMvbmV0L2ZzX2VuZXQvbWFjLWZjYy5jIHwgICAgMiArLQogMSBmaWxlcyBjaGFuZ2VkLCAxIGlu c2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvZnNf ZW5ldC9tYWMtZmNjLmMgYi9kcml2ZXJzL25ldC9mc19lbmV0L21hYy1mY2MuYwppbmRleCA3YTg0 ZTQ1Li43NTgzYTk1IDEwMDY0NAotLS0gYS9kcml2ZXJzL25ldC9mc19lbmV0L21hYy1mY2MuYwor KysgYi9kcml2ZXJzL25ldC9mc19lbmV0L21hYy1mY2MuYwpAQCAtMTA1LDcgKzEwNSw3IEBAIHN0 YXRpYyBpbnQgZG9fcGRfc2V0dXAoc3RydWN0IGZzX2VuZXRfcHJpdmF0ZSAqZmVwKQogCQlnb3Rv IG91dF9lcDsKIAogCWZlcC0+ZmNjLm1lbSA9ICh2b2lkIF9faW9tZW0gKiljcG0yX2ltbXI7Ci0J ZnBpLT5kcHJhbV9vZmZzZXQgPSBjcG1fZHBhbGxvYygxMjgsIDgpOworCWZwaS0+ZHByYW1fb2Zm c2V0ID0gY3BtX2RwYWxsb2MoMTI4LCAzMik7CiAJaWYgKElTX0VSUl9WQUxVRShmcGktPmRwcmFt X29mZnNldCkpIHsKIAkJcmV0ID0gZnBpLT5kcHJhbV9vZmZzZXQ7CiAJCWdvdG8gb3V0X2ZjY2Nw OwotLSAKMS43LjEKCi0tClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBs aW5lICJ1bnN1YnNjcmliZSBuZXRkZXYiIGluCnRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpv cmRvbW9Admdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCkNvbmZpZGVudGlhbGl0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgYW5kIGFueSBhY2NvbXBhbnlpbmcgYXR0YWNobWVu dChzKSAKaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIG9mIApOZXVzb2Z0 IENvcnBvcmF0aW9uLCBpdHMgc3Vic2lkaWFyaWVzIGFuZC9vciBpdHMgYWZmaWxpYXRlcy4gSWYg YW55IHJlYWRlciBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgCm5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB1bmF1dGhvcml6ZWQgdXNlLCBmb3J3YXJkaW5nLCBwcmludGluZywgIHN0b3Jpbmcs IGRpc2Nsb3N1cmUgb3IgY29weWluZyAKaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgYW5kIG1heSBi ZSB1bmxhd2Z1bC5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IscGxlYXNlIAppbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls LCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIGFuZCBhbGwgY29waWVzIGZyb20gCnlv dXIgc3lzdGVtLiBUaGFuayB5b3UuIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0K ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment 2011-06-17 9:09 ` 答复: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment 杨勇 @ 2011-06-17 10:16 ` David Laight 2011-06-20 4:01 ` ??: " ?? 0 siblings, 1 reply; 4+ messages in thread From: David Laight @ 2011-06-17 10:16 UTC (permalink / raw) To: yangyong, Holger Brunck, linuxppc-dev Cc: netdev, Clive Stubbings, Vitaly Bordug =20 > 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=20 > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* ??: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment 2011-06-17 10:16 ` David Laight @ 2011-06-20 4:01 ` ?? 0 siblings, 0 replies; 4+ messages in thread From: ?? @ 2011-06-20 4:01 UTC (permalink / raw) To: 'David Laight', 'Holger Brunck', linuxppc-dev Cc: netdev, 'Clive Stubbings', 'Vitaly Bordug' 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. --------------------------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment [not found] <1308299439-5975-1-git-send-email-holger.brunck@keymile.com> 2011-06-17 9:09 ` 答复: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment 杨勇 @ 2011-06-17 19:21 ` David Miller 1 sibling, 0 replies; 4+ messages in thread From: David Miller @ 2011-06-17 19:21 UTC (permalink / raw) To: holger.brunck; +Cc: clive.stubbings, netdev, linuxppc-dev, vbordug 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-06-20 4:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1308299439-5975-1-git-send-email-holger.brunck@keymile.com>
2011-06-17 9:09 ` 答复: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment 杨勇
2011-06-17 10:16 ` David Laight
2011-06-20 4:01 ` ??: " ??
2011-06-17 19:21 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).