Hi again,
Working 36 hours in an 24-hour day at this driver i have some more things to tell and some more questions.
Torsten Koschorrek wrote:
Now , I'm not sure about this header file. I know that we need it for the ptd-struct defined in ohci-isp1362.h, but why do we need stuff like that? And does anybody has an idea, why it's hardware-specific?Hi,
Very good work! I think i have lots of this patches applied to our (Konsti and me) version of the driver, but there is more patching to do.
Based on Lothar's second patch Nov 17 (applied to 2.6.8.1) - isp1362 files
only
Changes required to make patch compile --------------------------------------
(set device option to ISP1362)
(1) asm/arch/bitfield.h not part of PPC headers. Seems generic enough, so
I've copied it from PXA.
Could we eventually incorporate it into the driver, to make it more generic?
We have it copied, too. Seems to work.
Here are some other things concerning the ptd-structure and bitfield.h.
(1) Sorry. You discussed the ptd-struct in another reply, but can't reply on that mail, because it's at work, not at home :(
(2) It's used to store the data of the "philips transfer descriptor", right? It confuses me, that the ptd, as described in the isp1161a1, contains 10-bit values but the ptd-structure contains 8-bit-width data. This means, that the 9th and 10th bit of the field "Total Bytes" for example are stored in another variable of the struct (or something like that :/ grumpf, as i said: it confuses me)
(3) I think, the ptd-struct has to be defined in another way, the variable names don't match to the philips transfer descriptor. I don't have a solution for that, but i think about it.
(4) We have a WLAN-Stick (Prism2-Chipset) and we are using the linux-wlan-ng project. We have no problem detecting the device. But when we try to load the wlan-modules (p80211, prism2_usb) and start the wlan-driver (wlanctl) we have a problem. The chip wants to read a td with lenght 3000 (bb8h) Bytes in bulk-mode. Is this value possible? I mean the buffer is 4096 (1000h) Byte, but ...
We got a timeout, because the 3000 Byte of data couldn't be read, there was no irq. The lenght of the td is stored correctly in the HCTransferCounter register. But in function isp116x_recv_queue the number of byte to be read is read from the ptd-struct (Macro PTD_GET_LEN). We got 952 (3b8h). The first 10 bits a correct, but not the higher bits (because they are not defined in the ptd). Aren't we allowed to read more data at once???
Hmmm, I removed the Macro PTD_GET_LEN and inserted and read the length from the td-struct. It works fine, we get the interrupt after reading 3000 Bytes, but the wlan-driver timed out anyway.
(5) Is this a situation the driver doesn't handle? Is there more work to do?
(12) IRQT_FALLING and set_irq_type are architecture specific. Excluded from
my compile. Should probably be in a platform specific setup file.
Good hint. Look at it tomorrow, because we are using level triggered irqs.
OK, I changed IRQT_FALLING to IRQT_LOW. I'm thinking of putting it into ohci-isp1362.h as a #define value like #define IRQ_TYPE IRQT_LOW.
Hmm, we are using a little endian architecture. I don't know any difficulties because of Big/Little Endian stuff.
Applying Big Endian Changes ---------------------------
These are hard to find and stem from the fact that OHCI is little endian.
So the emulation layer needs to be extremely careful when accessing
everything including endpoint descriptors, transfer descriptors, HCCA, and
using constants for these purposes. On little endian archs these bugs are
hidden.
This whole Big/Little Endian stuff is confusing me :/ I don't know, if it affects our hardware.
-------------------------------------------------------
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
