Messages in this thread | | | Date | Wed, 06 Dec 2006 16:21:15 -0500 | From | Kristian Høgsberg <> | Subject | Re: [PATCH 0/3] New firewire stack |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |