[Cbe-oss-dev] [RFC 1/9] AXON - common driver core

[Arnd Bergmann]

On Thursday 28 December 2006 18:09, Jean-Christophe Dubois wrote:


> > 1. only in one directory: easy, all headers go to that dir
> > 2. arch specific, kernel only, but multiple locations: should
> >    go to include/asm.
> > 3. kernel only, but multiple architectures, few headers: include/linux
> > 4. kernel only, multiple architectures, many headers: include/linux/foo/
> >    or include/foo/.
> > 5. shared with user space, linux specific: include/linux/{,foo/}, but
> >    needs to be announced/discussed on linux-kernel at vger.kernel.org.
> > 6. shared with user space and other OSs: include/foo, definitely needs
> >    discussion.
>
> I guess 4 will do for the files in axon/include at this time. So what would
> be preffered? include/linux/axon/ or include/axon/ ?

That depends on the other files:

> Then I have a few files for user space in axon/usr/include ...

Are those category 5 or 6? If they are all linux specific (5),
they should all go to include/linux/axon, otherwise to include/axon.
Only the files that are meant for user space, which I assume are the
ones you list for axon/user/include, should be marked for installation
in the include/linux/axon/Kbuild file.

> > That's an interesting idea, using DTC should vastly simplify the
> > round-trip time even for other devices where the firmware is not final.
> > If you need kernel patches to integrate the flat device tree in this,
> > please share them so we can use the same mechanism.
>
> I'll try to get time to work on this. Is there a platform (not necessarily
> Cell) where the DTC is used/integrated yet?

so far only for 32 bit. Look in arch/powerpc/boot/dts for platforms
that do this.

> > > > > +       volatile u8    *p_dma_channel;
> > > >
> > > > volatile seems wrong here.
> > >
> > > it is a pointer to an IO space where live the DMA control registers. It
> > > can be on the PLB or on DCR depending on the DMA (Aux_DMA, DMAX).
> >
> > s/volatile u8/u8 __iomem/ again. Since this is on PLB directly, not on
> > PCI, you should use in_be32/out_be32 and friends to access them.
>
> DMAX registers are accessed by the host too as they live on PLB. The host
> controls one channel for itself in our driver.

Ok, in that case, the host needs to use ioread32 or readl for accessing
them instead of in_be32. The explanation stays the same for those.

	Arnd <><