Stefan Richter wrote:
...
Another question is whether the stack-internal APIs are really fit for
non-OHCI chips. There is an unfinished low-level driver for GP2Lynx
which worked to some degree at some point, but other than that I don't
remember positive or negative reports in this department. Maybe proper
documentation of the stack-internal APIs would already help embedded
developers a lot. Furthermore, there may be question marks WRT
interaction of the FireWire stack with architecture specific kernel code.
I think some of the problems with the current stack come from the fact that it
was originally written (by Andreas Bombe) for the PCILynx chipset, in other
words, *not* for the OHCI chipset. The PCILynx chipset is a much lower level
chipset, it offloads much more to software. For example, each self ID is
received as an individual packet, where the OHCI chipset receives these into a
special buffer and notifies software when it has received a consistent set of
packets. The current stack has a callback for the host controller driver to
call once the bus reset phase starts, a callback for each received self ID and
a callback to indicate the end of the bus reset phase.
In the new stack, the controller/core interface is more suited for the OHCI
controller. The stack doens't go into a bus reset state, and all self IDs are
reported as an atomic event. This makes the upper layers much simpler, suits
the OHCI controller better, and should only require a few lines extra code in
a PCILynx driver to buffer up the self IDs. And it's arguably better to have
the PCILynx driver do this than have the OHCI controller split up and
otherwise atomic event.
But back to the subject matter: Clearly, Kristian concentrates on
PCI/OHCI-1394 hardware at the moment. If embedded developers have
specific requirements on the FireWire stack's design, they should IMO
contribute with a list of requirements or maybe even with patches.
It's true that I'm developing for PCI+OHCI, but I've kept the controller/core
stack split that the old stack has, nothing outside the OHCI driver depends on
PCI (I'm using the generic DMA API). I've shifted the abstraction level up a
bit for the controller interface, which makes sense in general, but also since
this is what every desktop or laptop out there has. That said, I don't think
anything in the stack design will break for embedded/non-OHCI chipsets.
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
