Balbi,
As per CPPI DMA spec for TX we need to configure the DMA in MODE1 and
for RX we need to configure the DMA in mode 0.
This is what this patch does and only impacts CPPI DMA handling and not
the generic code. This change is done within
"#elif defined(CONFIG_USB_TI_CPPI_DMA)"
directive. This change has been validated over the last 3 years based on
2.6.10 kernel and hence is pretty stable to take it in.
On the OMAP platform I understand the definitions of mode 0/1 is
different compared to that of CPPI DMA.
I am testing these patches on the DaVinci GIT kernel at my end on the
DM644x EVM the same would apply to DM355.
Appreciate the feedback. Thanks.
Regards
Swami
-----Original Message-----
From: Felipe Balbi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2008 7:35 PM
To: Subbrathnam, Swaminathan
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[email protected]
Subject: Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code
On Wed, Dec 03, 2008 at 07:50:46PM +0530, ext Swaminathan S wrote:
> Fixes the SENTSTALL handling code to look for EP busy status before
> returning the request. If EP is not busy do not giveback the request and
> restart the request in the context of CLEAR STALL feature from the
> host.
>
> Signed-off-by: Swaminathan S <[EMAIL PROTECTED]>
> ---
> drivers/usb/musb/musb_gadget.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index d6a802c..491a3e7 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -335,10 +335,10 @@ static void txstate(struct musb *musb, struct
> musb_request *req)
> #elif defined(CONFIG_USB_TI_CPPI_DMA)
> /* program endpoint CSR first, then setup DMA */
> csr &= ~(MUSB_TXCSR_AUTOSET
> - | MUSB_TXCSR_DMAMODE
> | MUSB_TXCSR_P_UNDERRUN
> | MUSB_TXCSR_TXPKTRDY);
> - csr |= MUSB_TXCSR_MODE | MUSB_TXCSR_DMAENAB;
> + csr |= MUSB_TXCSR_MODE | MUSB_TXCSR_DMAENAB |
> + MUSB_TXCSR_DMAMODE;
does cppi_dma already have support for mode1 dma ? I can't see this
support in cppi_dma.c.
Unfortunately I don't have (yet) any davinci board for testing this so I
can't say it'll work or not for cppi_dma.
> musb_writew(epio, MUSB_TXCSR,
> (MUSB_TXCSR_P_WZC_BITS & ~MUSB_TXCSR_P_UNDERRUN)
> | csr);
> @@ -429,7 +429,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> musb->dma_controller->channel_abort(dma);
> }
>
> - if (request)
> + if (request && musb_ep->busy)
> musb_g_giveback(musb_ep, request, -EPIPE);
>
> break;
> @@ -759,7 +759,7 @@ void musb_g_rx(struct musb *musb, u8 epnum)
> csr &= ~MUSB_RXCSR_P_SENTSTALL;
> musb_writew(epio, MUSB_RXCSR, csr);
>
> - if (request)
> + if (request && musb_ep->busy)
this makes sense, but i'll ask you to hold on a bit on this patch since
I'm cleaning up dma handling on musb. You can see it on my experimental
branch at [1]. I got mode1 dma working for inventra_dma, as it's not
enough, I'm not pushing those patches yet. Wanna get tusb and cppi
working as well before pushing those patches.
Anyways, be sure enabling mode1 dma on that TX path doesn't break
anything. Leave testusb running for at least 2 days, then you resend
this patch with testusb results. If everything is fine, I can queue this
one and change my experimental patches for mode1 dma ;-)
--
balbi
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
