2010/10/1 Felipe Balbi <balbi@xxxxxx>:
> On Thu, Sep 30, 2010 at 12:27:05AM -0500, Ming Lei wrote:
>>
>> If you write hw_ep->max_packet_sz_tx to MUSB_TXMAXP,
>> musb chip sends packet with this size always in usb bus. At full
>
> this is only true if you have packet combining/splitting. Otherwise,
> it'll send 64-bytes in full speed.
No, this problem is nothing to do with packet combining/splitting, which
is very different with usage of MUSB_TXMAXP. We should keep in mind
that hardware endpoint fifo size is different with actual endpoint max
packet size, which means maximum amount of data that can be transferred
on usb bus in each (u)frame.
Packet combining/splitting feature means musb chip can read or write
multiple packets into endpoint FIFO if the space is enough, but musb chip
should receive or transmit packet(s) from or to usb bus in each frame or
uframe depending on actual max packet size from MUSB_RXMAXP/MUSB_TXMAXP.
The MUSB_TXMAXP register defines the maximum amount of
data that can be transferred through the selected transmit endpoint in a
single (u)frame.
The MUSB_RXMAXP register defines the maximum amount of
data that can be transferred through the selected transmit endpoint in a
single (u)frame.
Also each usb device can use different max packet size, such as 32/16/...,
only if which meets usb spec, so we have to tell it to musb chip by
MUSB_RXMAXP/MUSB_TXMAXP register.
>
>> speed mode, max packet size is much less than that of high
>> speed mode, so overflow problem can happen. We should always
>> set this register with the value from endpoint descriptor.
>
> by the time we setup the endpoints (to allocate fifo) we don't have
> descriptors available. Look at ep_config_from_table() for instance.
No, we only configure the max hw fifo size for each hw endpoint during
setup endpoint, but the actual max packet size for one endpoint in
usb device is very possible less than max hw fifo size of each hw
endpoint, such as in fullspeed case.
The actual max packet size is from endpoint descriptor and should
always be set to MUSB_RXMAXP/MUSB_TXMAXP register in
musb_gadget_enable function.
>
>> You can reproduce the problem easily by connecting musb gadget
>> with one uhci or ohci only usb host controller.
>
> check your sniffs. If you have >64byte packet in full speed. It's the
> packet combining/splitting kicking. Check whether the below helps:
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 472b2a7..459b6b5 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1427,14 +1427,6 @@ static int __init musb_core_init(u16 musb_type,
> struct musb *musb)
> strcat(aInfo, ", dyn FIFOs");
> musb->dyn_fifo = true;
> }
> - if (reg & MUSB_CONFIGDATA_MPRXE) {
> - strcat(aInfo, ", bulk combine");
> - musb->bulk_combine = true;
> - }
> - if (reg & MUSB_CONFIGDATA_MPTXE) {
> - strcat(aInfo, ", bulk split");
> - musb->bulk_split = true;
> - }
> if (reg & MUSB_CONFIGDATA_HBRXE) {
> strcat(aInfo, ", HB-ISO Rx");
> musb->hb_iso_rx = true;
>
The change is also wrong, which may degrade performance a lot
if musb_ep->packet_sz is less than hw_ep->max_packet_sz_tx or
hw_ep->max_packet_sz_rx.
thanks,
--
Lei Ming
--
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
