[PATCH RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above

[PATCH RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above

[Anand Gadiyar]

The Inventra DMA engine in version 1.8 and later of the MUSB
controller cannot handle DMA addresses that are not aligned
to a 4 byte boundary. It ends up ignoring the last two bits
programmed in the DMA_ADDR register. This is a deliberate
design change in the controller and is documented in the
programming guide.

Earlier versions of the controller could handle these
accesses just fine.

Fail dma_channel_program if we see an unaligned address when
using the newer controllers, so that the caller can carry out
the transfer using PIO mode.
(Current callers already have this backup path in place).

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
---
Patch based on linux-next as of 20101029.

I believe Blackfin is also affected by this, but I'm not sure how
they're working around this. Mike?

 drivers/usb/musb/musbhsdma.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

Index: mainline/drivers/usb/musb/musbhsdma.c
===================================================================
--- mainline.orig/drivers/usb/musb/musbhsdma.c
+++ mainline/drivers/usb/musb/musbhsdma.c
@@ -158,6 +158,8 @@ static int dma_channel_program(struct dm
 				dma_addr_t dma_addr, u32 len)
 {
 	struct musb_dma_channel *musb_channel = channel->private_data;
+	struct musb_dma_controller *controller = musb_channel->controller;
+	struct musb *musb = controller->private_data;
 
 	DBG(2, "ep%d-%s pkt_sz %d, dma_addr 0x%x length %d, mode %d\n",
 		musb_channel->epnum,
@@ -167,6 +169,18 @@ static int dma_channel_program(struct dm
 	BUG_ON(channel->status == MUSB_DMA_STATUS_UNKNOWN ||
 		channel->status == MUSB_DMA_STATUS_BUSY);
 
+	/*
+	 * The DMA engine in RTL1.8 and above cannot handle
+	 * DMA addresses that are not aligned to a 4 byte boundary.
+	 * It ends up masking the last two bits of the address
+	 * programmed in DMA_ADDR.
+	 *
+	 * Fail such DMA transfers, so that the backup PIO mode
+	 * can carry out the transfer
+	 */
+	if ((musb->hwvers >= MUSB_HWVERS_1800) && (dma_addr %4))
+		return false;
+
 	channel->actual_len = 0;
 	musb_channel->start_addr = dma_addr;
 	musb_channel->len = len;

Re: [PATCH RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above

[Ming Lei]

Cc Hema

2010/10/31 Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org>:
> The Inventra DMA engine in version 1.8 and later of the MUSB
> controller cannot handle DMA addresses that are not aligned
> to a 4 byte boundary. It ends up ignoring the last two bits
> programmed in the DMA_ADDR register. This is a deliberate
> design change in the controller and is documented in the
> programming guide.
>
> Earlier versions of the controller could handle these
> accesses just fine.
>
> Fail dma_channel_program if we see an unaligned address when
> using the newer controllers, so that the caller can carry out
> the transfer using PIO mode.
> (Current callers already have this backup path in place).
>
> Signed-off-by: Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org>
> Cc: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
> Cc: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
> Cc: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>

Tested-by: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

This patch is verified OK about g_ether function on beagle xM board,
but the revised patch "usb: musb: gadget: Unmapping the dma buffer
when switching to PIO mode" [1] should be applied first.

> ---
> Patch based on linux-next as of 20101029.
>
> I believe Blackfin is also affected by this, but I'm not sure how
> they're working around this. Mike?

MUSB on Blackfin will fallback to PIO too, so no any working around
for it, right?

>
>  drivers/usb/musb/musbhsdma.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> Index: mainline/drivers/usb/musb/musbhsdma.c
> ===================================================================
> --- mainline.orig/drivers/usb/musb/musbhsdma.c
> +++ mainline/drivers/usb/musb/musbhsdma.c
> @@ -158,6 +158,8 @@ static int dma_channel_program(struct dm
>                                dma_addr_t dma_addr, u32 len)
>  {
>        struct musb_dma_channel *musb_channel = channel->private_data;
> +       struct musb_dma_controller *controller = musb_channel->controller;
> +       struct musb *musb = controller->private_data;
>
>        DBG(2, "ep%d-%s pkt_sz %d, dma_addr 0x%x length %d, mode %d\n",
>                musb_channel->epnum,
> @@ -167,6 +169,18 @@ static int dma_channel_program(struct dm
>        BUG_ON(channel->status == MUSB_DMA_STATUS_UNKNOWN ||
>                channel->status == MUSB_DMA_STATUS_BUSY);
>
> +       /*
> +        * The DMA engine in RTL1.8 and above cannot handle
> +        * DMA addresses that are not aligned to a 4 byte boundary.
> +        * It ends up masking the last two bits of the address
> +        * programmed in DMA_ADDR.
> +        *
> +        * Fail such DMA transfers, so that the backup PIO mode
> +        * can carry out the transfer
> +        */
> +       if ((musb->hwvers >= MUSB_HWVERS_1800) && (dma_addr %4))
> +               return false;
> +
>        channel->actual_len = 0;
>        musb_channel->start_addr = dma_addr;
>        musb_channel->len = len;
>

[1], http://marc.info/?l=linux-usb&m=128532510705381&w=2

-- 
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above

[Anand Gadiyar]

On 10/31/2010 3:29 PM, Ming Lei wrote:
> 2010/10/31 Anand Gadiyar<gadiyar@ti.com>:
>> The Inventra DMA engine in version 1.8 and later of the MUSB
>> controller cannot handle DMA addresses that are not aligned
>> to a 4 byte boundary. It ends up ignoring the last two bits
>> programmed in the DMA_ADDR register. This is a deliberate
>> design change in the controller and is documented in the
>> programming guide.
>>
>> Earlier versions of the controller could handle these
>> accesses just fine.
>>
>> Fail dma_channel_program if we see an unaligned address when
>> using the newer controllers, so that the caller can carry out
>> the transfer using PIO mode.
>> (Current callers already have this backup path in place).
>>
>> Signed-off-by: Anand Gadiyar<gadiyar@ti.com>
>> Cc: Felipe Balbi<balbi@ti.com>
>> Cc: Ming Lei<tom.leiming@gmail.com>
>> Cc: Ajay Kumar Gupta<ajay.gupta@ti.com>
>> Cc: Mike Frysinger<vapier@gentoo.org>
>
> Tested-by: Ming Lei<tom.leiming@gmail.com>
>
> This patch is verified OK about g_ether function on beagle xM board,
> but the revised patch "usb: musb: gadget: Unmapping the dma buffer
> when switching to PIO mode" [1] should be applied first.
>
>> ---
>> Patch based on linux-next as of 20101029.
>>
>> I believe Blackfin is also affected by this, but I'm not sure how
>> they're working around this. Mike?
>
> MUSB on Blackfin will fallback to PIO too, so no any working around
> for it, right?
>

I meant Blackfin should also have hit this issue so far. I'm making
a change based on the MUSB revision - so this change will affect 
Blackfin for sure - they use revision 1.9 and 2.0 I think. So I'm just 
wondering if they really are affected, or they've simply never hit this 
scenario before.

- Anand

Re: [PATCH RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above

[Sergei Shtylyov]

Hello.

On 31-10-2010 8:25, Anand Gadiyar wrote:

> The Inventra DMA engine in version 1.8 and later of the MUSB
> controller cannot handle DMA addresses that are not aligned
> to a 4 byte boundary. It ends up ignoring the last two bits
> programmed in the DMA_ADDR register. This is a deliberate
> design change in the controller and is documented in the
> programming guide.

> Earlier versions of the controller could handle these
> accesses just fine.

> Fail dma_channel_program if we see an unaligned address when
> using the newer controllers, so that the caller can carry out
> the transfer using PIO mode.
> (Current callers already have this backup path in place).

> Signed-off-by: Anand Gadiyar<gadiyar-l0cyMroinI0@public.gmane.org>
> Cc: Felipe Balbi<balbi-l0cyMroinI0@public.gmane.org>
> Cc: Ming Lei<tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Ajay Kumar Gupta<ajay.gupta-l0cyMroinI0@public.gmane.org>
> Cc: Mike Frysinger<vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
[...]

> Index: mainline/drivers/usb/musb/musbhsdma.c
> ===================================================================
> --- mainline.orig/drivers/usb/musb/musbhsdma.c
> +++ mainline/drivers/usb/musb/musbhsdma.c
[...]
> @@ -167,6 +169,18 @@ static int dma_channel_program(struct dm
>   	BUG_ON(channel->status == MUSB_DMA_STATUS_UNKNOWN ||
>   		channel->status == MUSB_DMA_STATUS_BUSY);
>
> +	/*
> +	 * The DMA engine in RTL1.8 and above cannot handle
> +	 * DMA addresses that are not aligned to a 4 byte boundary.
> +	 * It ends up masking the last two bits of the address
> +	 * programmed in DMA_ADDR.
> +	 *
> +	 * Fail such DMA transfers, so that the backup PIO mode
> +	 * can carry out the transfer
> +	 */
> +	if ((musb->hwvers >= MUSB_HWVERS_1800) && (dma_addr %4))

    Also need space after %.

> +		return false;
> +

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] usb: musb: fail unaligned DMA transfers on v1.8 and above

[Felipe Balbi]

On Sun, Oct 31, 2010 at 12:25:59AM -0500, Gadiyar, Anand wrote:
>The Inventra DMA engine in version 1.8 and later of the MUSB
>controller cannot handle DMA addresses that are not aligned
>to a 4 byte boundary. It ends up ignoring the last two bits
>programmed in the DMA_ADDR register. This is a deliberate
>design change in the controller and is documented in the
>programming guide.
>
>Earlier versions of the controller could handle these
>accesses just fine.
>
>Fail dma_channel_program if we see an unaligned address when
>using the newer controllers, so that the caller can carry out
>the transfer using PIO mode.
>(Current callers already have this backup path in place).
>
>Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
>Cc: Felipe Balbi <balbi@ti.com>
>Cc: Ming Lei <tom.leiming@gmail.com>
>Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>
>Cc: Mike Frysinger <vapier@gentoo.org>

please fix comment from Sergei and resend without RFC.

-- 
balbi