Re: [PATCH 0/3] NCM gadget

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 09, 2010 at 11:38:17AM +0200, Yauheni Kaliuta wrote:

Hi!

"eGK" == ext Greg KH writes:

>  On Wed, Dec 08, 2010 at 01:12:03PM +0200, yauheni.kaliuta@xxxxxxxxx wrote:
> > From: Yauheni Kaliuta <yauheni.kaliuta@xxxxxxxxx>
> > Since the host driver is submitted by STE, resubmitting the gadget driver.
> > No improvements, mostly cosmetic changes and adoptation to the recent kernel.

> Very cool stuff, thanks for resubmitting.
> I'll queue it up in a bit.

Thanks a lot!

Some notes:

I used the recently submitted host driver for testing.

The gadget works for me with our internal setup, also works on beagleboard
with today's Linus' tree. It doesn't work "as is" with 2.6.35 kernel (for
example, MeeGo on n900), because there are some problems in musb_gadget
with MAXP calculations what breaks notifications. As a workaround it's
possible to set NCM_STATUS_BYTECOUNT to 20, then it works there as well.

About "NCM advantages". I do not see a way with the current design to make
the driver working without extra data copiing, so grouping frames on the
linux gadget side doesn't help to impove performance (there is one extra
even now, with no grouping).

I'm thinking of 2 ways how to imporove the situation: from the network
layer and on the usb gadget layer to allow to make requests from a set of
buffers (the host controllers go to the direction even in HW), especially
when we have FIFO in gadget HW.

Do you have any ideas about that?

Do you mean something like DMA chaining ? That would not work with
Inventra DMA least (which is a shame), I have also been thinking about a
way of combining the requests, but every time I think about it I
remember socket layer doesn't let us reuse the socket buffers :-(

If it did, _maybe_ we could allocate a dma pool (with dma_pool_create())
of e.g. 16Kb, and have a bunch o skbuffs allocated from that pool, then
when pool if full, we send the entire pool to DMA ?!?

That would mean we would need at least 2 pools, one for RX and one for
TX. Other than that, I can't think of anything that doesn't involve
memcpy().

--
balbi
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux