Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

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

 



On Mon, Apr 19, 2010 at 08:57:18PM +0200, ext Michał Nazarewicz wrote:
on top of FunctionFS before optimising the code) and in particular u_char
seem to be a good piece to steal code from. ;)  Still, as said, I haven't
analysed possible optimisations just yet.

On Mon, 19 Apr 2010 22:04:57 +0200, Felipe Balbi <felipe.balbi@xxxxxxxxx> wrote:
go for it :-)

I only started wondering whether buffering won't break some drivers.
Queuing the requests and buffering the data may be good from speed
point of view, but it may lead to user space driver loosing control
over the transmission.

My understanding of USB protocol is not perfect so I may use wrong
terms here, but please bare with me.

fsync() solves the issue of not knowing when the data is sent but
there is no similar mechanism for reading.

In particular how can we stall on read? Say protocol is designed in
such a way, that host sends a request on EP0 and some data on EP1.
Now, after handling the control request from EP0 we would like to
stall no EP1 but by the time we try to do that the data from host
has already been received and buffered in FunctionFS.

--
Best regards,                                           _     _
 .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
 ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
 ooo +---[mina86@xxxxxxxxxx]---[mina86@jabber.org]---ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux