Balbi Felipe (Nokia-D/Helsinki) wrote:
Hi,
On Fri, Dec 18, 2009 at 03:06:30PM +0100, ext Subbrathnam, Swaminathan wrote:
What advantages does a qtd implementation provide over the
existing qh based implementation?
Mentor controller supports only a fixed number of ep's unlinke
EHCI and I feel that it is better to have the implementation
reflect it rather than attempting to make an EHCI out of Mentor.
Heikki, correct me if I'm wrong.
the idea was to have qh always allocated so that next_urb() becomes a
list_entry(). When you don't have data to transfer it means that you
have an empty list_head rather than a NULL qh pointer.
When queueing a new urb, you just list_add_tail() and stuff like that.
Yes, this was a problem we encountered, but for now there actually isn't
much more benefit from qtds.
But I think they can be most useful later. You could use them for
example, with large transfers that go though limited
transfer_buffer_length (network), for having an empty qtd at the end of
transfer to indicate, yes, the end of transfer, to hanlde
musb_dma_channel.max_len why not for large transfers, etc.
br,
--
heikki
--
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
