Re: [PATCH 0/3] New firewire stack
- From: Kristian Høgsberg <krh@xxxxxxxxxx>
- Date: Wed, 06 Dec 2006 16:21:15 -0500
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH 0/3] New firewire stack
- From: Kristian Høgsberg
- Re: [PATCH 0/3] New firewire stack
- From: Alexey Dobriyan
- Re: [PATCH 0/3] New firewire stack
- From: Kristian Høgsberg
- Re: [PATCH 0/3] New firewire stack
- From: Ben Collins
- Re: [PATCH 0/3] New firewire stack
- From: Stefan Richter
- Re: Re: [PATCH 0/3] New firewire stack
- From: Alexander Neundorf
- Re: [PATCH 0/3] New firewire stack
- From: Stefan Richter
- [PATCH 0/3] New firewire stack
- Prev by Date: Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
- Next by Date: Re: data corruption with nvidia chipsets and IDE/SATA drives
- Previous by thread: Re: [PATCH 0/3] New firewire stack
- Next by thread: Re: [PATCH 0/3] New firewire stack
- Index(es):
Relevant Pages
|
