Dimitris Lampridis wrote:
Hi everybody,
I've started writing (yet another) driver for the isp1160, this time
using the kernel 2.6 API (hcd.h with usb_hcd_pci_[probe/remove/...]
etc.)
I'm really in the beginning and I don't have any other experience in
this field so excuse my silly questions, but there are some things that
I don't fully understand.
There's not a lot of documentation for that layer either, and
probably won't be until it gets cleaned up. (Presumably that's
for 2.7 kernels first.) So questions are probably inevitable.
The OHCI code is probably the best model to follow, since it's
simplest and least PCI-specific. Presumably you'll want your
driver to work on "real" ISP116x chips, not just the eval kit,
so the non-PCI support should be of interest. I'd suggest you
look at the new ohci-lh7a404.c support, using platform_bus,
as a model for supporting both. (Patches posted recently, and
soon to arrive in a kernel near you!)
First of all, I'm using the PCI evaluation kit (that ships with a DOS(!)
driver). As you propably know, the isp1160 defines 2 IO ports, the
command and the data port. Below is the output of lspci:
0000:00:0a.0 Bridge: PLX Technology, Inc.: Unknown device 5406 (rev 0b)
Hmm, PLX makes the PCI-to-local bus bridge. I guess the
eval kit decided not to use its own ID PROMs! I wonder if
the eval kits for other localbus chips (TDI423 etc) using
PLX bridges end up with the same PCI IDs?
...
Region 0: Memory at df101000 (32-bit, non-prefetchable)
Region 1: I/O ports at b000 [size=256]
Region 2: I/O ports at b400 [size=256]
Region 3: Memory at df000000 (32-bit, non-prefetchable) [size=1M]
...
As you can see there exist 4 IO regions. Regions 1 and 2 are detected as
IO ports.
But apart from that, I don't have a clue as to the whereabouts of the
command and data ports... Can anybody help in this? The manual of the
Board schematics would probably help. You may need to experiment.
The docs on your PLX bridge may be importatn too.
It may be that you have your choice of using I/O addressing (avoid
if possible) and memory addressing (preferable, more portable).
Anyway, in my implementation of the HCD, I have a module_init function
that calls pci_module_init() on a struct pci_driver that includes:
- a .name
- an .id_table with the vendror and product id of the board
- .probe = usb_hcd_pci_probe
- .remove etc. as for the ".probe" case
then there is a struct hc_driver with functions for reset, start etc.
Until now, i've implemented the .hcd_alloc and .hcd_free and i'm playing
with .start where i'm trying various combinations of commands to
communicate with the board (notably write and then read the HcScratch
register and HcChipID, while guessing for the IO ports)
By looking at the implementation of usb_hcd_pci_probe(), I understand
that if the HCD_MEMORY flag is not set (my case) then the driver tries
to allocate all the IO regions that are marked as IORESOURSE_IO.
Correct?
No; the usb_hcd_pci_probe() logic only maps one region. In fact
it probably only works with EHCI, OHCI, and UHCI ... seems to me
that you might need to write your own probe routine, if you need
to use more than one of those regions. Clone the code you're
looking at, and teach your clone to set up the other regions
your driver needs. (But I don't see why ISP116x would need more
than one region ... maybe I would if I knew the chip!)
PS: philips claims that the isp1160 is USB2 compliant, so I guess I
should add to the hc_driver.flags the HCD_USB2. Right?
Don't set that flag unless it's _also_ high speed; I don't
think those Philips chips handle more than usb 1.1 speeds.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
