Hi, > The Philips app note shows the sample code repeatedly reading the PTD until > the active bit is cleared. So I wanted to see, if we are simply reading the > PTD too soon. So I added some code to detect the active bit and stop > processing PTDs after that. I then dumped the buffer using the attached > user land program. But it does not appear that the active bit ever gets > cleared. But this program may interfer with the driver, but it still may be > a useful debugging tool.
The code in the appnote is BS. First, the chip ends processing of the ATL buffer, if SOF arrives. But as I saw with the analyzer, it won't start processing the buffer again, even if there are active ptd-s in it. This observation fits with what you described above. Second, though the code would be faster if done as in the appnote, in Philips' driver for 2.4 kernel it is done differently. Briefly, there seems to be no other way than reading the ATL fifo ram into a buffer, detecting ACTIVE ptd-s and resubmitting them back into FIFO ram (after properly modifying some of the fields). > I take it from another post, you are looking into handling the active bit? > If so, I won't focus on that, but instead look into why some of my full > speed devices are not working yet. Have you tried any full speed devices > yet? Both full- and low-speed devices suffer from the same ACTIVE bit problem. See again my yesterday's post in this thread. I think in a few days I am able to post a working patch. Olav ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
