Hi Olav, I wanted to check that we can indeed start the HC again by rewriting PTDs back into the ATL buffer, so I just hacked a quick check into isp116x_recv_queue() to detect active PTDs. In that case I only write the first 16 bits of the PTD header back into the device and then recheck the PTD and, voila, there is the rest of the data. With that in place, I have been able to successfully register my USB mouse. In the log below, you will see the reference buf_map == 0, this is because some time later another ATL done interrupt arrives and this field isn't set correctly anymore, since I've actually serviced that PTD in the previous interrupt (not good, as it stays in the ISR too long - it's a hack nonetheless).
I am not as familiar with the actual queue handling (and all its corner cases) as you are, so you may be the better person to implement this, but I can send you what I have sofar. Also, as mentioned, it seems sufficient to only complete a single PIO transfer to kick the device again, which may improve performance. So possibly the best approach is to simply rewrite the very first PTD's 16 bits of header (unchanged), if an ACTIVE bit is set, restore all queue information, as if the ATL done interrupt had never happened and flush the PTDs in the next interrupt time (you could possibly treat all the PTDs up to the active PTD, but then you would need to know where you have left off the last time and skip these). I can send you what I have sofar, if you want. log snippet (some data bytes are missing on below due to my terminal program): isp116x_recv_queue: Got PTD (c7911000): isp116x_recv_queue: MPS=8 FA=2 DIR=2 EP=0 SPD=1 LEN=46 CNT=32 isp116x_recv_queue: 200c 080c 2e08 0200 isp116x_recv_queue<--in-- 2e 03 55 00 53 00 42 00 2d 00 50 00 53 00 2f 00 32 00 20 00 4f 00 70 00 74 00 69 00 63 00 61 00 dd ee dd ee dd ee isp116x_recv_queue: Encountered still active PTD isp116x_recv_queue: Writing new PTD Header HCREVISION [00]: 00000010 HCCONTROL [01]: 00000080 HCCMDSTAT [02]: 00000000 HCINTSTAT [03]: 00000084 HCINTENB [04]: 8000001c HCFMINTVL [0d]: 27782edf HCFMREM [0e]: 00002ed2 HCFMNUM [0f]: 0000255f HCLSTHRESH [11]: 00000628 HCRHDESCA [12]: 05000202 HCRHDESCB [13]: 00000000 HCRHSTATUS [14]: 00000000 HCRHPORT1 [15]: 00000303 HCRHPORT2 [16]: 00000100 HCHWCFG [20]: 1029 HCDMACFG [21]: 0000 HCXFERCTR [22]: 0002 HCuPINT [24]: 0017 HCuPINTENB [25]: 0033 HCCHIPID [27]: 6122 HCSCRATCH [28]: 1ad5 HCITLBUFLEN [2a]: 0000 HCATLBUFLEN [2b]: 07e0 HCBUFSTAT [2c]: 0024 HCRDITL0LEN [2d]: 0000 HCRDITL1LEN [2e]: 0000 isp116x_recv_queue: Got PTD (c7911000): isp116x_recv_queue: MPS=8 FA=2 DIR=2 EP=0 SPD=1 LEN=46 CNT=46 isp116x_recv_queue: 2e04 080c 2e08 0200 isp116x_recv_queue<--in-- 2e 03 55 00 53 00 42 00 2d 00 50 00 53 00 2f 00 32 00 20 00 4f 00 70 00 74 00 69 00 63 00 61 00 6c 00 20 00 4d 00 buf_map == 0 finish_ptds: Failed to read queue -----Original Message----- From: Olav Kongas [mailto:[EMAIL PROTECTED] Sent: Saturday, November 20, 2004 5:52 AM To: Philipp Schmid Cc: [EMAIL PROTECTED]; Dimitris Lampridis Subject: RE: [linux-usb-devel] HC gets too little data from devices 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 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
