The only non-porting changes (from 2.6.6 - I can't upgrade because of
customer requirements ...) are the following. As isp116x_write_data16() is
already correctly swapping bytes for big/little endian, but the PTD payload
is a byte stream, I needed to flip the data again except for some last-byte
cases in write_ptddata_to_fifo() and read_ptddata_from_fifo():
@@ -147,14 +145,14 @@ static void write_ptddata_to_fifo(struct
for (; len > 1; len -= 2) {
w = *dp++;
w |= *dp++ << 8;
- isp116x_write_data16(isp116x, w);
+ isp116x_write_data16(isp116x, cpu_to_le16(w));
}
if (len)
isp116x_write_data16(isp116x, (u16) * dp);
} else {
// 16-bit aligned
for (; len > 1; len -= 2)
- isp116x_write_data16(isp116x, *dp2++);
+ isp116x_write_data16(isp116x, cpu_to_le16(*dp2++));
if (len)
isp116x_write_data16(isp116x, 0xff & *((u8 *) dp2));
}
@@ -177,7 +175,7 @@ static void read_ptddata_from_fifo(struc
if ((unsigned long)dp2 & 1) {
// not 16-bit aligned
for (; len > 1; len -= 2) {
- w = isp116x_read_data16(isp116x);
+ w = cpu_to_le16(isp116x_read_data16(isp116x));
*dp++ = w & 0xff;
*dp++ = (w >> 8) & 0xff;
}
@@ -186,7 +184,7 @@ static void read_ptddata_from_fifo(struc
} else {
// 16-bit aligned
for (; len > 1; len -= 2)
- *dp2++ = isp116x_read_data16(isp116x);
+ *dp2++ = cpu_to_le16(isp116x_read_data16(isp116x));
if (len)
*((u8 *) dp2) = 0xff & isp116x_read_data16(isp116x);
}
I have also tested control, in and out types using the test.sh script (I
modified the number of packets and sizes a bit to make the run-time more
practical for me). I did run this for a longer time earlier and something
happened to trigger the chip to reset the bus and re-enumerate.
Unfortunately, I didn't capture the details, but it had the same error
message you are looking into already. I will continue to let this run and
see if it happens again.
Here are the results:
bash-2.05# ./test.sh
microcontroller type: fx
single stage: load on-chip memory
open RAM hexfile image testfw.hex
stop CPU
write on-chip, addr 0x0000 len 3 (0x0003)
write on-chip, addr 0x0043 len 3 (0x0003)
write on-chip, addr 0x0128 len 3 (0x0003)
write on-chip, addr 0x012c len 3 (0x0003)
write on-chip, addr 0x0200 len 206 (0x00ce)
... WROTE: 218 bytes, 5 segments, avg 43
reset CPU
TESTING: control out in
Sat Jan 1 06:01:57 UTC 2000
** Control test cases:
test 9: ch9 postconfig
/proc/bus/usb/001/002 test 9, 27.070873 secs
test 10: control queueing
/proc/bus/usb/001/002 test 10, 102.057489 secs
test 14: control writes
assuming sink-src configuration
** Host Write (OUT) test cases:
test 1: 10000 transfers, same size
/proc/bus/usb/001/002 test 1, 20.062133 secs
test 3: 10000 transfers, variable/short size
/proc/bus/usb/001/002 test 3, 12.026838 secs
test 5: 2000 scatterlists, same size entries
/proc/bus/usb/001/002 test 5, 128.068718 secs
test 7a: 2000 scatterlists, variable size/short entries
/proc/bus/usb/001/002 test 7, 80.074403 secs
test 7b: 1000 scatterlists, variable size/bigger entries
/proc/bus/usb/001/002 test 7, 61.075177 secs
test 7c: 1000 scatterlists, variable size/micro entries
/proc/bus/usb/001/002 test 7, 32.077140 secs
** Host Read (IN) test cases:
test 2: 1000 transfers, same size
/proc/bus/usb/001/002 test 2, 20.060137 secs
test 4: 10000 transfers, variable size
/proc/bus/usb/001/002 test 4, 10.071005 secs
test 6: 2000 scatterlists, same size entries
/proc/bus/usb/001/002 test 6, 128.060720 secs
test 8a: 2000 scatterlists, variable size/short entries
/proc/bus/usb/001/002 test 8, 66.075492 secs
test 8b: 1000 scatterlists, variable size/bigger entries
/proc/bus/usb/001/002 test 8, 153.061486 secs
test 8c: 1000 scatterlists, variable size/micro entries
/proc/bus/usb/001/002 test 8, 32.077164 secs
dmesg:
Running test #9
TEST 9: ch9 (subset) control tests, 1000 times
Running test #10
TEST 10: queue 32 control calls, 1000 times
Running test #14
Running test #1
TEST 1: write 1024 bytes 10000 times
Running test #3
TEST 3: write/421 0..1024 bytes 10000 times
Running test #5
TEST 5: write 2000 sglists 32 entries of 1024 bytes
Running test #7
TEST 7: write/579 2000 sglists 32 entries 0..1024 bytes
Running test #7
TEST 7: write/41 1000 sglists 32 entries 0..4096 bytes
Running test #7
TEST 7: write/63 1000 sglists 32 entries 0..64 bytes
Running test #2
TEST 2: read 1024 bytes 10000 times
Running test #4
TEST 4: read/512 0..1024 bytes 10000 times
Running test #6
TEST 6: read 2000 sglists 32 entries of 1024 bytes
Running test #8
TEST 8: read/512 2000 sglists 32 entries 0..1024 bytes
Running test #8
TEST 8: read/512 1000 sglists 32 entries 0..4096 bytes
Running test #8
TEST 8: read/512 1000 sglists 32 entries 0..64 bytes
So things are looking pretty good for me, but I did run into some trouble
when using multiple devices on my hub. It may have to do with what you are
looking into right now. I'll dig into it a bit more ...
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Olav
Kongas
Sent: Thursday, January 20, 2005 12:07 PM
To: Philipp Schmid
Cc: linux-usb-devel@lists.sourceforge.net
Subject: RE: [linux-usb-devel] isp116x-hcd update
On Thu, 20 Jan 2005, Philipp Schmid wrote:
>
> Yes ... that did it. I've got my USB hard drive back and can do kernel
> compiles on it. However, I don't quite see how that change would affect
> anything except for preventing the break call under the USB_PID_IN/OUT
case
> ...
What happened for OUT transfers longer than
MAX_TRANSFER_SIZE_FULLSPEED was that the first PTD was sent
and then, without "break-ing" there, the urb was finished
with return code 0. With this bug, the usbtests worked (at
least in my case), because the g_zero driver at the other
end didn't care whether it got f.ex. 4096 or just first
832 bytes. Also, reading from sticks worked fine and
obviously I tested only reading from real devices after this
change (which, I thought, was just a cleanup, while it
introduced such an obvious bug).
In your case a large urb was submitted for ep3out. The
driver pushed first 832 bytes successfully to ep3out and
then finished the urb reporting about having successfully
sent all the data. The storage driver then requested 13
bytes from ep2in, but your device didn't give it, because it
was still waiting for the rest of the data on ep3out.
> that done, I will try to minimize the code changes I had to introduce and
I am very much interested in your changes. However, it would
be preferable, if you could send your functional changes or
bug fixes one by one whenever possible. This would make it
easier for me to understand and integrate them (e.g. BE
stuff separately etc.).
> pass them along to you. I would appreciate if you could accomodate them,
so
> that your driver can just be dropped into my code. Most of it are
functions
> that don't exist in 2.6.6 and a few minor USB changes, as well as, the
The aim is to get this stuff ready for inclusion into the
mainline. The 2.6.11-rc1 contains changes that made hcd-s
incompatible with 2.6.10. Therefore, the planning is to
debug the driver now on the 2.6.9-10 level, which allows
people to test and use it. But then I have to break the
compatibility to move on. As the backward compatibility,
perhaps even to 2.6.10, is not needed when already in
kernel then upstream kernel people would probably complain
about such an extra baggage in the driver. I would, if I
would be one of them :)
IOW, I propose that you maintain the changes to bring
the driver from 2.6.9-10 to 2.6.6 yourself. By the way, why
can't you upgrade from 2.6.6?
> Running test #11
> TEST 11: unlink 1000 reads of 512
> isp116x-hcd : Unlink after no-IRQ? Different ACPI or APIC settings may
> help.
I have seen this particular error a lot. Mostly with timed
plug-upplug cycles. I have tried to chase down the cause,
but failed thus far.
Great that you see so many tests running flawless, at least
for 1000 cycles.
Olav
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
