Hi, > -----Original Message----- > From: Wood Scott-B07421 > > On Tue, Jul 10, 2007 at 04:01:19PM +0200, Segher Boessenkool wrote: > > > + - compatible : Should be "fsl,mpc8xxx-dma" > > > > Should _include_, not should _be_. And none of this xxx > > business, of course. > > Especially since the 85xx/86xx version is not 100% compatible with the > 83xx version. How about fsl,mpc8349-dma and fsl,mpc8548-dma > for the two > variants?
I want to use this one driver to fit for mpc8349 and mpc8548. But it seems some register difference between them. Ok, using "fsl,mpc8548-dma". > > > > + - extended : Set the DMA channel to work at extended > chain mode. > > > + If not set, the DMA channel will work at basic > > > + chain mode. > > > > Call it "extended-chain-mode", perhaps? > It's clear, but maybe too long? > Or don't call it anything. The ability to do extended chain mode is > implicit in being compatible with fsl,mpc8548-dma. The basic mode could be used for mpc83xx silicons. > > > > + - reserved : Reserve the DMA channel to device. > > > > What does this do? Reserve it for what device, and where? > > The OS driver? > > Some hardware has DMA channels hardwired to certain > peripherals, such as > an audio codec. This keeps them from being used as general > purpose DMA > channels. DMA channels could be used as ethernet phy. You can point to DMA channel's 'phandle' in the device node for reserve use. > > I'd rather just treat the different DMA channels as > independent devices, > rather than children of a dma "bus", and change the compatible name if > they're not general purpose. There's only one register that's shared > among the channels, and it's a superfluous status summary register. > Your and my ideas are both sides of a coin. :-) Thanks! Wei. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev