On Monday 04 May 2009, Martin Fuzzey wrote: > >> If no more ETDs are available can the driver return a failure status for > >> urb_enqueue() or must it queue locally? > >> In the former case which status (ENOMEM, ENXIO ??) > >> In the latter should there be a limit on the queue size? > > > > I'd queue locally in at least bulk and control cases, > > since the USB interface drivers generally won't handle > > errors. For periodic transfers they *should* have at > > least basic fault handling ... it may not be especially > > effective though. > > I can do that it's just that it didn't seem necessary to me. > As ETDs (FIFOs) correspond to active endpoints and I have 32 I have > difficultly imagining a use case where they would all be used [some of > the exmples you cite later have many less FIFOs). I have no difficulty. Stick a few hubs on, and fill the hub ports, as some users will eventually do, and it's very doable. Maybe it's not a near-term priority, sure. > That also brings up the question of how to test ETD / endpoint queuing > - as I understand it usbtest only submits URBs for one or two > endpoints. I only have one device to use with usbtest - sure I could > do other USB stuff at the same time (mass storage, webcam, ..) but > that won't reach the 32 endpoint limit. Probably the easiest way is to > artificially reduce the number of available ETDs just for the test. Yes. > That being said I don't think it should be too difficult to implement > the queuing, I just want to be sure it corresponds to a realistic > usage scenario. > The anti starvation NAK timeout thing sounds much more complicated though. It's most relevant when FIFOs are scarce. Example, with four FIFO pairs: hook up a hub, keyboard, and mouse ... the input side of three just got claimed, so there's only one left, the one dedicated for use with bulk RX. On that hub, also hook up a USB network adapter and a few USB storage devices. Now you need to have some way to share that RX channel... > > That allocation is done statically, at driver setup time. > > > > Silicon like that on DaVinci chips has just 4K SRAM for > > allocation between FIFOs; and just four FIFO pairs (plus > > ep0). OMAP3 chips, and tusb60x0, have 16K of SRAM and > > fifteen FIFO pairs (plus ep0). > > > Strange, I have twice as many "FIFOs" as the largest one > you mention but the same SRAM as the smallest.. That's fifo *pairs* ... so 30 fifos (plus ep0), or 8 fifos (plus ep0). So it's about as many fifos, but you're short on SRAM ... unless that's a fullspeed-only device? > As I have (compared to the hardware you mention) a largish number of > ETDs(FIFOs) but relatively little data memory I think dynamic > allocation is better since preallocating data memory to ETDs would > waste some. That hardware doesn't support re-allocation of the SRAM to different FIFOs after it starts operating, as I recall. If yours does, that's potentially useful. - Dave -- 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
