Re: [linux-usb-devel] Issues with start_frame
At 12:47 PM 5/21/2007, Alan Stern wrote: Dave: The situation with regard to start_frame is a mess. Although the name and the documentation refer to frame numbers, for high speed devices the value stored there is a microframe number instead. Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Also, it seems to me that drivers ought to be able to take the current (micro)frame value, add a small amount to it, and specify the result as the start frame for an URB. But such behavior is not documented as always workable, and we don't have any firm standard for how big the small amount can be. My feeling is that all HCDs should guarantee that anything up to 1 second will be acceptable. What do you think? Alan Stern Hi Alan, About EHCI frame numbers. From the EHCI manual section 2.3.4: quote The SOF frame number value for the bus SOF token is derived or alternatively managed from this register. Please refer to Section 4.5 for a detailed explanation of the SOF value management requirements on the host controller. The value of FRINDEX must be 125 ìsec (1 micro-frame) ahead of the SOF token value. The SOF value may be implemented as an 11-bit shadow register. For this discussion, this shadow register is 11 bits and is named SOFV. SOFV updates every 8 micro-frames. (1 millisecond). An example implementation to achieve this behavior is to increment SOFV each time the FRINDEX[2:0] increments from a zero to a one. Software must use the value of FRINDEX to derive the current micro-frame number, both for high-speed isochronous scheduling purposes and to provide the get micro-frame number function required for client drivers. Therefore, the value of FRINDEX and the value of SOFV must be kept consistent if chip is reset or software writes to FRINDEX. Writes to FRINDEX must also write-through FRINDEX[13:3] to SOFV[10:0]. In order to keep the update as simple as possible, software should never write a FRINDEX value where the three least significant bits are 111b or 000b. Please refer to Section 4.5 /quote So FRINDEX does count microframes, but the bus only sees bits d13 to d3. In fact what Linux can respond in 125 microseconds? Realistically, very few systems can respond in 1ms to use the frame number. So worrying about giving an exact microframe number some unknown amount of time in the past is not very useful. Guaranteeing taking a scheduling value 1 second is the worst possible case, but really a system should somehow know what its worst latency is, and use that as the minimum. At the least, the size of the periodic table is the (useful) worst case -(which is 256, 512 or 1024 ms). Regards, Steve _ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_2G_0507 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Issues with start_frame
On Mon, 21 May 2007, Steve Calfee wrote: Hi Alan, About EHCI frame numbers. From the EHCI manual section 2.3.4: quote ... /quote That's alright; I have a copy of the spec. You don't need to include a lengthy extract, just put a reference to a section number. So FRINDEX does count microframes, but the bus only sees bits d13 to d3. In fact what Linux can respond in 125 microseconds? On a 2-GHz system that's enough time for 250,000 cycles, which is more than a few instructions. I should think a good deal could be done. Realistically, very few systems can respond in 1ms to use the frame number. So worrying about giving an exact microframe number some unknown amount of time in the past is not very useful. But this affects more than the software running on the host; it affects the functioning of the device as well. You will agree that devices can easily implement latencies much smaller than those of Linux? So it's conceivable that a driver really might need to arrange for a particular packet to be sent during a particular microframe. Guaranteeing taking a scheduling value 1 second is the worst possible case, but really a system should somehow know what its worst latency is, and use that as the minimum. I don't see what this has to do with latency -- a driver might want to schedule a transfer for 2 hours in the future! Obviously we don't need to support anything as large as that, but the principle is the same no matter what the delay value is. If we allow drivers to schedule transfers for a particular time, then we must guarantee that submissions will accepted anywhere up to X milliseconds into the future, where X is some reasonable but fixed number. At the least, the size of the periodic table is the (useful) worst case -(which is 256, 512 or 1024 ms). As I said to Dave, 256 ms is a perfectly reasonable minimum. Assuming we agree to support this at all. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Issues with start_frame
On Monday 21 May 2007, Alan Stern wrote: Dave: The situation with regard to start_frame is a mess. Although the name and the documentation refer to frame numbers, for high speed devices the value stored there is a microframe number instead. Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Simplest notion: define new primitives that always work in terms of microframes, convert to using them exclusively. Full speed ISO would ignore the LSBs. Phase out the old primitives; it's not as if anyone can rely on them much right now ... Alternatively, do that but make the old primitives work right and don't phase them out. At least, not for a year or two; this would help if anyone actually uses those primitives right now. Long term -- as yo Also, it seems to me that drivers ought to be able to take the current (micro)frame value, add a small amount to it, and specify the result as the start frame for an URB. But such behavior is not documented as always workable, In fact it's documented as barely supported. Only UHCI attempts to do that, AFAIK. and we don't have any firm standard for how big the small amount can be. My feeling is that all HCDs should guarantee that anything up to 1 second will be acceptable. What do you think? First, do we even want to support that please use this start frame mechanism? I'm not sure we do. We can't have many users that care about it right now, so removing it should be cheap... Second, if we were to want to support it, I think that kind of absolute limit is inadvisable. EHCI uses 1/4 second scheduling horizons whenever it can, because of performance issues (cache trashing on some PPCs) with the larger 1 second horizon. Some controllers would need to emulate that in software by having a second we didn't yet tell the hardware about it schedule. Better to have the HCD export what it can handle. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Issues with start_frame
Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Simplest notion: define new primitives that always work in terms of microframes, convert to using them exclusively. Full speed ISO would ignore the LSBs. Phase out the old primitives; it's not as if anyone can rely on them much right now ... Alternatively, do that but make the old primitives work right and don't phase them out. At least, not for a year or two; this would help if anyone actually uses those primitives right now. Long term -- as yo GRR, flakey keyboard. Long term -- as you probably guessed, I'd rather just see a single programming interface for such stuff. Easier to test, document, and maintain. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Issues with start_frame
On Mon, 21 May 2007, David Brownell wrote: On Monday 21 May 2007, Alan Stern wrote: Dave: The situation with regard to start_frame is a mess. Although the name and the documentation refer to frame numbers, for high speed devices the value stored there is a microframe number instead. Clearly anyone who's interested in the value will want to know the full microframe number. But on the other hand, the value returned from ehci_get_frame() actually _is_ a frame number, so there's no way for drivers to learn the current microframe. Thus we have several related problems: How to tell whether you're dealing with frames or microframes and when to use each. Any suggestions on how to solve them? Simplest notion: define new primitives that always work in terms of microframes, convert to using them exclusively. Full speed ISO would ignore the LSBs. Phase out the old primitives; it's not as if anyone can rely on them much right now ... Alternatively, do that but make the old primitives work right and don't phase them out. At least, not for a year or two; this would help if anyone actually uses those primitives right now. The start_frame values actually do get used by a few drivers: drivers/media/video/usbvideo/konicawc.c drivers/usb/misc/stimulus/stimulus.c sound/usb/usx2y/usbusx2yaudio.c sound/usb/usx2y/usx2yhwdeppcm.c They test start_frame in various hacky ways, and some even try to set urb-start_frame before submission. So it would seem to be best to keep the get_frame() value as a frame number. When people need higher precision we can add it. (By the way, there may be another minor problem with ehci_get_frame. I don't completely understand the EHCI spec, but it says that the frame boundaries reported by the controller register differ by 125 us from the frame boundaries transmitted on the bus. See sections 2.3.4 and 4.5. Should this be corrected for?) Long term -- as you probably guessed, I'd rather just see a single programming interface for such stuff. Easier to test, document, and maintain. Me too. But what happens when USB 3.0 comes out and we have to deal with super-high-speed (or ultra-speed or hyper-speed or whatever they decide to call it) buses? -- I know, it's not possible to give a reasonable answer at this time. Also, it seems to me that drivers ought to be able to take the current (micro)frame value, add a small amount to it, and specify the result as the start frame for an URB. But such behavior is not documented as always workable, In fact it's documented as barely supported. Only UHCI attempts to do that, AFAIK. and we don't have any firm standard for how big the small amount can be. My feeling is that all HCDs should guarantee that anything up to 1 second will be acceptable. What do you think? First, do we even want to support that please use this start frame mechanism? I'm not sure we do. We can't have many users that care about it right now, so removing it should be cheap... I wouldn't mind removing it. Presumably when a driver starts up an iso stream, the exact starting time doesn't matter. But what if the new stream needs to be in a prescribed phase relationship with an already-existing iso stream? Or should we just not worry about this? (And if we do remove it, there won't be any reason to keep USB_ISO_ASAP, will there? HCDs would behave the same whether or not the flag was turned on.) Second, if we were to want to support it, I think that kind of absolute limit is inadvisable. EHCI uses 1/4 second scheduling horizons whenever it can, because of performance issues (cache trashing on some PPCs) with the larger 1 second horizon. Some controllers would need to emulate that in software by having a second we didn't yet tell the hardware about it schedule. Better to have the HCD export what it can handle. If we do support it, I think there should be some minimum figure for drivers to rely on. Otherwise you're just shifting the burden from the HCDs to the drivers. I'm okay with 1/4 second. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
