Hi Felipe,
In DWC3 driver, for three stage Control OUT transfer there is a check:
else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {.
}
I understand that we check for alignment of sizes and if not we
prepare trb with maxpacket and enable interrupt on short packet. In
databook I could not find anything related to this, it talks only
about addresses should be aligned. In Control transfer programming
model there is no difference between Control OUT or IN transfer, if
three stage transfer - prepare trb with length wLength. Initially I
followed this and not able to receive data on EP0 OUT.:( .After adding
the above check it is working. Please help me to understand why we do
this?
Thank in advance,
Sundeep.B.S.
> From: [email protected] [mailto:[email protected]] On Behalf Of sundeep subbaraya
> Sent: Friday, December 12, 2014 9:13 PM
>
> Hi Felipe,
>
> In DWC3 driver, for three stage Control OUT transfer there is a check:
>
> else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
>
> && (dep->number == 0)) {.
> }
>
> I understand that we check for alignment of sizes and if not we
> prepare trb with maxpacket and enable interrupt on short packet. In
> databook I could not find anything related to this, it talks only
> about addresses should be aligned. In Control transfer programming
> model there is no difference between Control OUT or IN transfer, if
> three stage transfer - prepare trb with length wLength. Initially I
> followed this and not able to receive data on EP0 OUT.:( .After adding
> the above check it is working. Please help me to understand why we do
> this?
Hi Sundeep,
Please see section 8.2.3.3 "Buffer Size Rules and Zero-Length Packets"
in the databook:
For OUT endpoints, the following rules apply:
- The total size of a Buffer Descriptor must be a multiple of
MaxPacketSize
The wording may be a little confusing, it actually means that the size
of the data buffer for OUT endpoints must be a multiple of MaxPacketSize.
Section 8.2.5 states it more clearly:
- An OUT transfer’s transfer size (Total TRB buffer allocation)
must be a multiple of MaxPacketSize even if software is expecting
a fixed non-multiple of MaxPacketSize transfer from the Host.
This rule applies to all OUT endpoint types, including Control endpoints.
--
Paul
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?
Hi Paul,
As per my understanding, for BULK OUT we do queue a request with 512
bytes length since we do not
know the length of the transfer Host is going to send. For Control OUT
we know the length in wLength of
Setup packet, hence I assumed there is no difference in programming
model of Control IN and OUT.
Now it is clear for me. Thanks for the clarification :)
Sundeep
On Sun, Dec 14, 2014 at 5:21 AM, Paul Zimmerman
<[email protected]> wrote:
>> From: [email protected] [mailto:[email protected]] On Behalf Of sundeep subbaraya
>> Sent: Friday, December 12, 2014 9:13 PM
>>
>> Hi Felipe,
>>
>> In DWC3 driver, for three stage Control OUT transfer there is a check:
>>
>> else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
>>
>> && (dep->number == 0)) {.
>> }
>>
>> I understand that we check for alignment of sizes and if not we
>> prepare trb with maxpacket and enable interrupt on short packet. In
>> databook I could not find anything related to this, it talks only
>> about addresses should be aligned. In Control transfer programming
>> model there is no difference between Control OUT or IN transfer, if
>> three stage transfer - prepare trb with length wLength. Initially I
>> followed this and not able to receive data on EP0 OUT.:( .After adding
>> the above check it is working. Please help me to understand why we do
>> this?
>
> Hi Sundeep,
>
> Please see section 8.2.3.3 "Buffer Size Rules and Zero-Length Packets"
> in the databook:
>
> For OUT endpoints, the following rules apply:
>
> - The total size of a Buffer Descriptor must be a multiple of
> MaxPacketSize
>
> The wording may be a little confusing, it actually means that the size
> of the data buffer for OUT endpoints must be a multiple of MaxPacketSize.
> Section 8.2.5 states it more clearly:
>
> - An OUT transfer’s transfer size (Total TRB buffer allocation)
> must be a multiple of MaxPacketSize even if software is expecting
> a fixed non-multiple of MaxPacketSize transfer from the Host.
>
> This rule applies to all OUT endpoint types, including Control endpoints.
>
> --
> Paul
>
Hi,
(please don't top-post)
On Sun, Dec 14, 2014 at 08:39:18AM +0530, sundeep subbaraya wrote:
> Hi Paul,
>
> As per my understanding, for BULK OUT we do queue a request with 512
> bytes length since we do not
sometimes we _do_ know the size. In case of Mass Storage, we _know_ that
the first bulk out transfer will be 31-bytes (CBW), if we were to start
a 31-byte transfer, we would't receive anything.
> know the length of the transfer Host is going to send. For Control OUT
> we know the length in wLength of
> Setup packet, hence I assumed there is no difference in programming
> model of Control IN and OUT.
there is _no_ difference. It's just that it was agreed that for anything
other than control ep, the function drivers would take care of it. See
the uses of quirk_ep_out_aligned_size.
--
balbi
Hi again,
On Mon, Dec 22, 2014 at 10:11:23AM -0600, Felipe Balbi wrote:
> (please don't top-post)
>
> On Sun, Dec 14, 2014 at 08:39:18AM +0530, sundeep subbaraya wrote:
> > Hi Paul,
> >
> > As per my understanding, for BULK OUT we do queue a request with 512
> > bytes length since we do not
>
> sometimes we _do_ know the size. In case of Mass Storage, we _know_ that
> the first bulk out transfer will be 31-bytes (CBW), if we were to start
> a 31-byte transfer, we would't receive anything.
>
> > know the length of the transfer Host is going to send. For Control OUT
> > we know the length in wLength of
> > Setup packet, hence I assumed there is no difference in programming
> > model of Control IN and OUT.
>
> there is _no_ difference. It's just that it was agreed that for anything
> other than control ep, the function drivers would take care of it. See
> the uses of quirk_ep_out_aligned_size.
btw, why are you reimplementing the driver when there's a perfectly good
driver to use in mainline kernel ?
--
balbi