hi,
On Wed, Mar 26, 2014 at 10:13:24AM -0700, Jack Pham wrote:
> On Tue, Mar 25, 2014 at 08:45:11PM -0500, Felipe Balbi wrote:
> > > + for (num = 0; num < dwc->num_in_eps; num++) {
> > > + struct dwc3_ep *dep = dwc->eps[(num << 1) | 1];
> >
> > Just add a comment here stating that bit0 is the direction bit, just so
> > we don't forget in the future.
>
> Ok, will do.
thanks
> > One question, out of curiosity:
> >
> > do you *really* need to enable tx-fifo-resize ? I thought OMAP5 ES1.0
> > was the only brainfart with FIFO setups which wouldn't even fit a single
> > USB3 packet :-p
> >
> > Sure your patch is correct, and will be applied soonish, but if you
> > don't need to resize fifos, you might want to avoid it. Just curious.
>
> Yes, although our FIFO RAM is certainly larger than a USB3 packet :-),
> we do have one use case of a high-bandwidth debugging trace function,
> which when enabled consumes at least half of that FIFO for its own
> buffer usage. If it's combined in a composite gadget with other
> functions (such as RNDIS) we found we had to enable tx-fifo-resize in
> order to get the core to conservatively allocate the remaining memory
> for the rest of the endpoints.
>
> The only way to avoid needing tx-fifo-resize is if this HW trace
> function gets its own memory instead of sharing the FIFO with USB but
> unfortunately our current SoCs have it sorta hardwired this way.
we have such a trace capability too but we're using bulk EPs ;-)
> > ps: can you guys, please, just send your dwc3 glue layer ? :-)
>
> Ivan Ivanov (cc'ed) had sent a number of patches for our "dwc3-msm"
> layer to the list for review, but I think they were still held up in the
> feedback process. Ivan, what is the status of this?
they had some comments which never got addressed, both dwc3-msm and
phy-msm.
--
balbi
Attachment:
signature.asc
Description: Digital signature
