From: matthieu.castet@parrot.com (Matthieu CASTET)
To: linux-arm-kernel@lists.infradead.org
Subject: Problem with non aligned DMA in usbnet on ARM
Date: Thu, 12 Aug 2010 19:08:57 +0200 [thread overview]
Message-ID: <4C642AA9.1060404@parrot.com> (raw)
In-Reply-To: <4C632217.9000608@gmail.com>
Martin Fuzzey a ?crit :
>> We don't want to add support for this to DMA bounce. DMA bounce is already
>> a pain in the backside and causes its own set of problems - please let it
>> die a long slow but quite death.
>>
>> If you want to see the kind of pain dmabounce causes, look at this long
>> standing and as yet unsolved bug:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=7760
>>
>>
> Well I don't know the dmabounce code but why is using it likely to cause
> OOM problems (at least why more so than copying the buffer in the HCD or
> the usb core). In both cases there will be two copies of the buffer in
> memory which could I agree be a problem in memory constrained systems.
> But if we _do_ want to accept unaligned buffers from usb drivers I can't
> see a way round that.
>
memmove is our friend :
the buffer allocated in usbnet got an offset.
All you have to do it remove this offset and memmove the data. That what
I did [1], and why it is better to do it in usb driver.
Matthieu
[1] http://article.gmane.org/gmane.linux.usb.general/28700
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gadget-align.diff
Type: text/x-diff
Size: 2251 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100812/7bf8e096/attachment.bin>
WARNING: multiple messages have this Message-ID (diff)
From: Matthieu CASTET <matthieu.castet-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
To: "mfuzzey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<mfuzzey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Gary King <GKing-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
linux-usb <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Subject: Re: Problem with non aligned DMA in usbnet on ARM
Date: Thu, 12 Aug 2010 19:08:57 +0200 [thread overview]
Message-ID: <4C642AA9.1060404@parrot.com> (raw)
In-Reply-To: <4C632217.9000608-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
Martin Fuzzey a écrit :
>> We don't want to add support for this to DMA bounce. DMA bounce is already
>> a pain in the backside and causes its own set of problems - please let it
>> die a long slow but quite death.
>>
>> If you want to see the kind of pain dmabounce causes, look at this long
>> standing and as yet unsolved bug:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=7760
>>
>>
> Well I don't know the dmabounce code but why is using it likely to cause
> OOM problems (at least why more so than copying the buffer in the HCD or
> the usb core). In both cases there will be two copies of the buffer in
> memory which could I agree be a problem in memory constrained systems.
> But if we _do_ want to accept unaligned buffers from usb drivers I can't
> see a way round that.
>
memmove is our friend :
the buffer allocated in usbnet got an offset.
All you have to do it remove this offset and memmove the data. That what
I did [1], and why it is better to do it in usb driver.
Matthieu
[1] http://article.gmane.org/gmane.linux.usb.general/28700
[-- Attachment #2: gadget-align.diff --]
[-- Type: text/x-diff, Size: 2251 bytes --]
diff --git a/drivers/usb/gadget/gadget_chips.h b/drivers/usb/gadget/gadget_chips.h
index 1edbc12..ed3ee67 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -214,4 +214,14 @@ static inline bool gadget_supports_altsettings(struct usb_gadget *gadget)
return true;
}
+/**
+ * gadget_dma32 - return true if we want buffer aligned on 32 bits (for dma)
+ * @gadget: the gadget in question
+ */
+static inline bool gadget_dma32(struct usb_gadget *gadget)
+{
+ if (gadget_is_musbhdrc(gadget))
+ return true;
+ return false;
+}
#endif /* __GADGET_CHIPS_H */
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 84ca195..697af90 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -249,7 +249,12 @@ rx_submit(struct eth_dev *dev, struct usb_request *req, gfp_t gfp_flags)
* but on at least one, checksumming fails otherwise. Note:
* RNDIS headers involve variable numbers of LE32 values.
*/
- skb_reserve(skb, NET_IP_ALIGN);
+ /*
+ * RX: Do not move data by IP_ALIGN:
+ * if your DMA controller cannot handle it
+ */
+ if (!gadget_dma32(dev->gadget))
+ skb_reserve(skb, NET_IP_ALIGN);
req->buf = skb->data;
req->length = size;
@@ -282,6 +287,12 @@ static void rx_complete(struct usb_ep *ep, struct usb_request *req)
/* normal completion */
case 0:
skb_put(skb, req->actual);
+ if (gadget_dma32(dev->gadget) && NET_IP_ALIGN) {
+ u8 *data = skb->data;
+ size_t len = skb_headlen(skb);
+ skb_reserve(skb, NET_IP_ALIGN);
+ memmove(skb->data, data, len);
+ }
if (dev->unwrap) {
unsigned long flags;
@@ -573,6 +584,24 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
length = skb->len;
}
+
+ /*
+ * Align data to 32bit if the dma controller requires it
+ */
+ if (gadget_dma32(dev->gadget)) {
+ unsigned long align = (unsigned long)skb->data & 3;
+ if (WARN_ON(skb_headroom(skb) < align)) {
+ dev_kfree_skb_any(skb);
+ goto drop;
+ } else if (align) {
+ u8 *data = skb->data;
+ size_t len = skb_headlen(skb);
+ skb->data -= align;
+ memmove(skb->data, data, len);
+ skb_set_tail_pointer(skb, len);
+ }
+ }
+
req->buf = skb->data;
req->context = skb;
req->complete = tx_complete;
next prev parent reply other threads:[~2010-08-12 17:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-11 9:41 Problem with non aligned DMA in usbnet on ARM Martin Fuzzey
2010-08-11 9:41 ` Martin Fuzzey
2010-08-11 9:54 ` Russell King - ARM Linux
2010-08-11 9:54 ` Russell King - ARM Linux
2010-08-11 10:11 ` Martin Fuzzey
2010-08-11 10:11 ` Martin Fuzzey
2010-08-11 15:04 ` Greg KH
2010-08-11 15:04 ` Greg KH
2010-08-11 16:08 ` Martin Fuzzey
2010-08-11 16:08 ` Martin Fuzzey
2010-08-11 17:42 ` Greg KH
2010-08-11 17:42 ` Greg KH
2010-08-11 19:07 ` Martin Fuzzey
2010-08-11 19:07 ` Martin Fuzzey
2010-08-11 20:13 ` Greg KH
2010-08-11 20:13 ` Greg KH
2010-08-11 22:31 ` Martin Fuzzey
2010-08-11 22:31 ` Martin Fuzzey
2010-08-12 17:01 ` Matthieu CASTET
2010-08-12 17:01 ` Matthieu CASTET
2010-08-11 19:10 ` Oliver Neukum
2010-08-11 19:10 ` Oliver Neukum
2010-08-11 9:59 ` Matthieu CASTET
2010-08-11 9:59 ` Matthieu CASTET
2010-08-11 11:38 ` Martin Fuzzey
2010-08-11 11:38 ` Martin Fuzzey
2010-08-11 15:54 ` Gary King
2010-08-11 20:35 ` Russell King - ARM Linux
2010-08-11 22:20 ` Martin Fuzzey
2010-08-11 22:20 ` Martin Fuzzey
2010-08-11 22:47 ` Russell King - ARM Linux
2010-08-11 22:47 ` Russell King - ARM Linux
2010-08-12 17:08 ` Matthieu CASTET [this message]
2010-08-12 17:08 ` Matthieu CASTET
2010-08-13 10:06 ` Martin Fuzzey
2010-08-13 10:06 ` Martin Fuzzey
2010-08-13 10:58 ` Oliver Neukum
2010-08-13 10:58 ` Oliver Neukum
2010-08-13 13:42 ` David Brownell
2010-08-13 13:42 ` David Brownell
2010-08-13 13:53 ` Oliver Neukum
2010-08-13 13:53 ` Oliver Neukum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C642AA9.1060404@parrot.com \
--to=matthieu.castet@parrot.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.