Hi,
Thank you for applying the following patches.
[PATCH 1/8] usb: musb: clear AUTOSET while clearing DMAENAB
[PATCH 6/8] usb: musb: ux500: copy dma mask from platform device to musb
device
Please disregard the rest of the patchset. I will send the second
version (without above two patches) in a short while.
On 03/22/2011 10:05 AM, Felipe Balbi wrote:
On Tue, Mar 15, 2011 at 04:24:25PM +0100, Mian Yousaf Kaukab wrote:
For Inventra dma, dma is configured for rx transfers after receiving first
packet (MUSB_RXCSR_RXPKTRDY set in RXCSR). DMA is configured based on the
requested length or the maximum length dma can handle. However, if the
received packet is less than the maximum packet size, length of this packet
should be used to configure the dma. As it will be the only packet to transfer
for this request.
Signed-off-by: Mian Yousaf Kaukab<mian.yousaf.kaukab@xxxxxxxxxxxxxx>
AFAIK a short packet can't be transferred with mode1 DMA, so why even
bother ? Or did you manage to get mode1 to transfer this short packet ?
Without this patch, on the arrival of CBW rxstate() will pass
transfer_size = min(request->length - request->actual, channel->max_len);
to channel_program() when USE_MODE1 is set. So DMA will not know that
already a short packet has arrived. When channel_program() is called
with the
length of the short packet, DMA has the chance to reject the transfer.
Part of the problem is that when g_mass_storage sends the request for CBW
it aligns the length to maxp even though it knows that CBW length is
expected. It
is done in set_bulk_out_req_length() in f_mass_storage.c. Not sure why
it is done.
If it is not needed, should I send a patch to fix that as well?
Thanks,
--
Mian Yousaf Kaukab
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
