[PATCH 0/4] DMA engine driver for Freescale MPC8xxx processor.

[PATCH 0/4] DMA engine driver for Freescale MPC8xxx processor.

[Zhang Wei]

Hi, All,

These patches are DMA engine driver for Freescale MPC8xxx processor.

They implement the DMA engine API for MEM-2-MEM data DMA transfer
and extend the DMA engine API for IO_ADDR-2-MEM and IO_ADDR-2-IO_ADDR data
transfer.

Patches:
[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
[PATCH 2/4] Add dma sector to mpc8641hpcn board dts
[PATCH 3/4] Extend the DMA-engine API.
[PATCH 4/4] Add DMA engine driver for Freescale MPC8xxx processors.

Best Regards,
Zhang Wei

[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Zhang Wei]

This patch adds DMA sector to Documentation/powerpc/booting-without-of.txt file.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
---
 Documentation/powerpc/booting-without-of.txt |   60 ++++++++++++++++++++++++++
 1 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index c169299..08c619f 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1790,6 +1790,66 @@ platforms are moved over to use the flattened-device-tree model.
  		partition-names = "fs\0firmware";
  	};
 
+   k) DMA
+
+   This sector define DMA for dma-engine driver of Freescale
+   MPC8xxx silicon. For each DMA setor, you should define
+   channels included.
+   Please see below 'l) DMA channel' for DMA channel's definition.
+
+   Required properties:
+
+    - compatible : Should be "fsl,mpc8xxx-dma"
+    - reg : Offset and length of the register set for the device
+    - ranges : Should be defined as specified in 1) to describe the
+               DMA controller's register.
+
+  Example:
+	dma@21000{
+		compatible = "fsl,mpc8xxx-dma";
+		reg = <21000 100>;
+		ranges = <0 21000 1000>;
+		ch0@100{
+			reg = <100 80>;
+			extended;
+			reserved;
+			interrupt-parent = <&mpic>;
+			interrupts = <14 2>;
+		};
+		ch1@180{
+			reg = <180 80>;
+			extended;
+			reserved;
+			interrupt-parent = <&mpic>;
+			interrupts = <15 2>;
+		};
+		ch2@200{
+			reg = <200 80>;
+			extended;
+			interrupt-parent = <&mpic>;
+			interrupts = <16 2>;
+		};
+		ch3@280{
+			reg = <280 80>;
+			extended;
+			interrupt-parent = <&mpic>;
+			interrupts = <17 2>;
+		};
+	};
+
+   l) DMA channel
+
+   Required properties:
+
+    - reg : Offset and length of the register set for the device
+
+   Recommended properties :
+
+    - extended : Set the DMA channel to work at extended chain mode.
+                 If not set, the DMA channel will work at basic
+                 chain mode.
+    - reserved : Reserve the DMA channel to device.
+
    More devices will be defined as this spec matures.
 
 VII - Specifying interrupt information for devices
-- 
1.5.1

[PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Zhang Wei]

This patch add DMA sector to MPC8641HPCN board dts.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
---
 arch/powerpc/boot/dts/mpc8641_hpcn.dts |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 393cfdf..8a70736 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -405,5 +405,35 @@
 			device_type = "open-pic";
 			big-endian;
 		};
+
+		dma@21000{
+			compatible = "fsl,mpc8xxx-dma";
+			reg = <21000 100>;
+			ranges = <0 21000 1000>;
+			ch0@100{
+				reg = <100 80>;
+				extended;
+				interrupt-parent = <&mpic>;
+				interrupts = <14 2>;
+			};
+			ch1@180{
+				reg = <180 80>;
+				extended;
+				interrupt-parent = <&mpic>;
+				interrupts = <15 2>;
+			};
+			ch2@200{
+				reg = <200 80>;
+				extended;
+				interrupt-parent = <&mpic>;
+				interrupts = <16 2>;
+			};
+			ch3@280{
+				reg = <280 80>;
+				extended;
+				interrupt-parent = <&mpic>;
+				interrupts = <17 2>;
+			};
+		};
 	};
 };
-- 
1.5.1

Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Segher Boessenkool]

> +		dma@21000{
> +			compatible = "fsl,mpc8xxx-dma";

Please use a real name, not this "xxx" stuff.

> +			reg = <21000 100>;
> +			ranges = <0 21000 1000>;

These overlap, that can't be right; it is just begging for
trouble.

> +			ch0@100{
> +				reg = <100 80>;
> +				extended;

I think you want a little more detailed property name
than "extended" here?


Segher

RE: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Zhang Wei-r63237]

Hi, Segher,=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
>=20
> > +		dma@21000{
> > +			compatible =3D "fsl,mpc8xxx-dma";
>=20
> Please use a real name, not this "xxx" stuff.

Does the "xxx" seems to be an evil name? :-)

>=20
> > +			reg =3D <21000 100>;
> > +			ranges =3D <0 21000 1000>;
>=20
> These overlap, that can't be right; it is just begging for
> trouble.

There is no overlap. The 'reg' is used for the register of DMA
controller. And the ranges is used for belows channel registers.

Such as ch0@100, reg=3D<100 80>, in fact, the ch0 register address is
0x21100.

>=20
> > +			ch0@100{
> > +				reg =3D <100 80>;
> > +				extended;
>=20
> I think you want a little more detailed property name
> than "extended" here?

I've explained it in [PATCH 1/4] Add DMA sector to
Documentation/powerpc/booting-without-of.txt file.
As below:
+    - extended : Set the DMA channel to work at extended chain mode.
+                 If not set, the DMA channel will work at basic
+                 chain mode.

Thanks!
Wei.

Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Segher Boessenkool]

>>> +		dma@21000{
>>> +			compatible = "fsl,mpc8xxx-dma";
>>
>> Please use a real name, not this "xxx" stuff.
>
> Does the "xxx" seems to be an evil name? :-)

You are stating this particular device is compatible to
the "mpc8xxx-dma" device, which doesn't exist.  If it is
supposed to mean it is compatible to the DMA controller
on any 8000-series device, that is incorrect; in the future,
there might be many such devices with an incompatible DMA
controller.

Just put in some real device model name.

>>> +			reg = <21000 100>;
>>> +			ranges = <0 21000 1000>;
>>
>> These overlap, that can't be right; it is just begging for
>> trouble.
>
> There is no overlap. The 'reg' is used for the register of DMA
> controller. And the ranges is used for belows channel registers.

And 21000..210ff is a subset of 21000..21fff.  So there _is_
overlap.

> Such as ch0@100, reg=<100 80>, in fact, the ch0 register address is
> 0x21100.

Sure, none of the "reg"s in any of the children overlap the
parent "reg", but the parent "reg" overlaps the "ranges".

>>> +			ch0@100{
>>> +				reg = <100 80>;
>>> +				extended;
>>
>> I think you want a little more detailed property name
>> than "extended" here?
>
> I've explained it in [PATCH 1/4] Add DMA sector to
> Documentation/powerpc/booting-without-of.txt file.
> As below:
> +    - extended : Set the DMA channel to work at extended chain mode.
> +                 If not set, the DMA channel will work at basic
> +                 chain mode.

Sure it's documented, but it would be good if the property
name itself would say a bit more than just "extended".  Property
names can be 31 characters, there's no need to make short names
(terse is good, content-free isn't).


Segher

RE: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Zhang Wei-r63237]

=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
>=20
> >>> +		dma@21000{
> >>> +			compatible =3D "fsl,mpc8xxx-dma";
> >>
> >> Please use a real name, not this "xxx" stuff.
> >
> > Does the "xxx" seems to be an evil name? :-)
>=20
> You are stating this particular device is compatible to
> the "mpc8xxx-dma" device, which doesn't exist.  If it is
> supposed to mean it is compatible to the DMA controller
> on any 8000-series device, that is incorrect; in the future,
> there might be many such devices with an incompatible DMA
> controller.
>=20
> Just put in some real device model name.

Ok, I'll use the first (or almost) real device model name.=20

>=20
> >>> +			reg =3D <21000 100>;
> >>> +			ranges =3D <0 21000 1000>;
> >>
> >> These overlap, that can't be right; it is just begging for
> >> trouble.
> >
> > There is no overlap. The 'reg' is used for the register of DMA
> > controller. And the ranges is used for belows channel registers.
>=20
> And 21000..210ff is a subset of 21000..21fff.  So there _is_
> overlap.
>=20

All right. Avoid this.

> > Such as ch0@100, reg=3D<100 80>, in fact, the ch0 register address =
is
> > 0x21100.
>=20
> Sure, none of the "reg"s in any of the children overlap the
> parent "reg", but the parent "reg" overlaps the "ranges".
>=20
> >>> +			ch0@100{
> >>> +				reg =3D <100 80>;
> >>> +				extended;
> >>
> >> I think you want a little more detailed property name
> >> than "extended" here?
> >
> > I've explained it in [PATCH 1/4] Add DMA sector to
> > Documentation/powerpc/booting-without-of.txt file.
> > As below:
> > +    - extended : Set the DMA channel to work at extended=20
> chain mode.
> > +                 If not set, the DMA channel will work at basic
> > +                 chain mode.
>=20
> Sure it's documented, but it would be good if the property
> name itself would say a bit more than just "extended".  Property
> names can be 31 characters, there's no need to make short names
> (terse is good, content-free isn't).
>=20

Ok.

Thanks!
Wei.

Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Segher Boessenkool]

> +		dma@21000{

"dma-controller" btw.  And a space before the "{" (here and
elsewhere) :-)


Segher

RE: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

[Zhang Wei-r63237]

> > +		dma@21000{
>=20
> "dma-controller" btw.  And a space before the "{" (here and
> elsewhere) :-)

All right! :-)

Wei.

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

> +   k) DMA
> +
> +   This sector define DMA for dma-engine driver of Freescale

It's called a "device node" or "node", not a "sector".

> +    - compatible : Should be "fsl,mpc8xxx-dma"

Should _include_, not should _be_.  And none of this xxx
business, of course.

> +    - 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?

> +    - reserved : Reserve the DMA channel to device.

What does this do?  Reserve it for what device, and where?
The OS driver?


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

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?

> > +    - 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?

Or don't call it anything.  The ability to do extended chain mode is
implicit in being compatible with fsl,mpc8548-dma.

> > +    - 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.

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.

-Scott

RE: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Zhang Wei-r63237]

Hi,=20

> -----Original Message-----
> From: Wood Scott-B07421=20
>=20
> On Tue, Jul 10, 2007 at 04:01:19PM +0200, Segher Boessenkool wrote:
> > > +    - compatible : Should be "fsl,mpc8xxx-dma"
> >=20
> > Should _include_, not should _be_.  And none of this xxx
> > business, of course.
>=20
> Especially since the 85xx/86xx version is not 100% compatible with the
> 83xx version.  How about fsl,mpc8349-dma and fsl,mpc8548-dma=20
> 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".

>=20
> > > +    - extended : Set the DMA channel to work at extended=20
> chain mode.
> > > +                 If not set, the DMA channel will work at basic
> > > +                 chain mode.
> >=20
> > Call it "extended-chain-mode", perhaps?
>=20
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.

>=20
> > > +    - reserved : Reserve the DMA channel to device.
> >=20
> > What does this do?  Reserve it for what device, and where?
> > The OS driver?
>=20
> Some hardware has DMA channels hardwired to certain=20
> peripherals, such as
> an audio codec.  This keeps them from being used as general=20
> 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.

>=20
> I'd rather just treat the different DMA channels as=20
> 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.
>=20

Your and my ideas are both sides of a coin. :-)

Thanks!
Wei.

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

Zhang Wei-r63237 wrote:
>>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.

Yes, and the 83xx device trees will list the compatible as 
fsl,mpc8349-dma, not fsl,mpc8548-dma.  This will tell the driver whether 
extended chain mode can be used (though I don't really see the benefit 
to using it even if it is there).

>>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. :-)

I think there's a substantive difference between them.  Making each 
channel an independent device makes it easier for other drivers to use them.

-Scott

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> 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. :-)
>
> I think there's a substantive difference between them.  Making each  
> channel an independent device makes it easier for other drivers to  
> use them.

True.  If the DMA channels are independent enough, putting them
in nodes of their own isn't too cumbersome, either.


Segher

RE: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Zhang Wei-r63237]

=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
> Sent: Thursday, July 12, 2007 1:54 AM
> To: Wood Scott-B07421
> Cc: Zhang Wei-r63237; linuxppc-dev@ozlabs.org; paulus@samba.org
> Subject: Re: [PATCH 1/4] Add DMA sector to=20
> Documentation/powerpc/booting-without-of.txt file.
>=20
> >>> I'd rather just treat the different DMA channels as independent =20
> >>> devices,
> >>> rather than children of a dma "bus", and change the compatible =20
> >>> name if
> >>> they're not general purpose.  There's only one register that's =20
> >>> shared
> >>> among the channels, and it's a superfluous status summary=20
> register.
> >>>
> >> Your and my ideas are both sides of a coin. :-)
> >
> > I think there's a substantive difference between them. =20
> Making each =20
> > channel an independent device makes it easier for other drivers to =20
> > use them.
>=20
> True.  If the DMA channels are independent enough, putting them
> in nodes of their own isn't too cumbersome, either.
>=20
>=20

If you want to use DMA engine driver for the reserved channel, you
should add it to dma-controller node and assign 'reserved'.
If you don't want to use DMA engine driver, just remove it from
dma-controller node and put the channel to special device node.

Thanks!
Wei.

RE: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Phil Terry]

Excuse me butting in if I've got this whole dtc, of, device driver
model, etc., stuff wrong but I thought it was supposed to work like
this:

The DMA engine is a generic kernel service. Its a "device". You can
infer its presence without a dts/of by the fact that you have the fsl
soc but ok if you want to put it in dts/of that works too.

All its going to do is load a "driver" which makes available the
services of the "device" under a generic DMA internal api. 

Say I'm writing a sound card, video card, widget card, etc., driver.

My driver gets loaded by virtue of detecting the card/device (via of,
pci, usb, platform, whatever bus mechanisms).

My driver would benefit from using a generic DMA device so it uses the
internal api to look for one and uses the API of that device to request
a channel for its use. I don't care what channel I get, I don't need a
fixed, reserved channel of the DMA device as specified in the dts I just
need an unused channel. If no channels are available or I'm in a system
with no generic DMA service available I can either fall back to
processor copying or refuse to load.

Given the device might be a hot-insert USB device etc, there's nothing a
dts can do to help me here in this scenario, right?

I thought the idea of the dts/of was for the hardware specific boot
loader to tell the kernel about hardware that the kernel couldn't
otherwise know about, because its not detectable by a bus probe method,
etc. Its not there to tell you how to use the device or arbitrate which
other devices get to use a device when there are resource conflicts,
etc.

If the dts/of/boot loader tells the kernel its a fsl soc then it knows
how to work out which one and what level, and therefore knows what
devices, such as the DMA device are present.

I'm truly interested in understanding the correct interpretation because
we are developing a DMA based, rapidio distributed system on fsl 8641
and from lurking on here and reading the archives etc, all I see is a
constant butting of heads on what the dts/of is and how its supposed to
work.

Quite why we are using a 20 year old spec, which was never finished, and
ceased to be a formal spec 10 years ago as the "new" way forward is a
puzzle to me as well. Not flame bait, but if someone could point me to
background material it would be helpful for my education in getting up
to speed (on the rationale for using it going forwards, not all the old
sites for the spec itself).

Cheers
Phil


On Thu, 2007-07-12 at 17:48 +0800, Zhang Wei-r63237 wrote:
>  
> > -----Original Message-----
> > From: Segher Boessenkool [mailto:segher@kernel.crashing.org] 
> > Sent: Thursday, July 12, 2007 1:54 AM
> > To: Wood Scott-B07421
> > Cc: Zhang Wei-r63237; linuxppc-dev@ozlabs.org; paulus@samba.org
> > Subject: Re: [PATCH 1/4] Add DMA sector to 
> > Documentation/powerpc/booting-without-of.txt file.
> > 
> > >>> 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. :-)
> > >
> > > I think there's a substantive difference between them.  
> > Making each  
> > > channel an independent device makes it easier for other drivers to  
> > > use them.
> > 
> > True.  If the DMA channels are independent enough, putting them
> > in nodes of their own isn't too cumbersome, either.
> > 
> > 
> 
> If you want to use DMA engine driver for the reserved channel, you
> should add it to dma-controller node and assign 'reserved'.
> If you don't want to use DMA engine driver, just remove it from
> dma-controller node and put the channel to special device node.
> 
> Thanks!
> Wei.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

Phil Terry wrote:
> Say I'm writing a sound card, video card, widget card, etc., driver.
> 
> My driver gets loaded by virtue of detecting the card/device (via of,
> pci, usb, platform, whatever bus mechanisms).
> 
> My driver would benefit from using a generic DMA device so it uses the
> internal api to look for one and uses the API of that device to request
> a channel for its use. I don't care what channel I get, I don't need a
> fixed, reserved channel of the DMA device as specified in the dts I just
> need an unused channel. If no channels are available or I'm in a system
> with no generic DMA service available I can either fall back to
> processor copying or refuse to load.

The audio device example was not about using the DMA engine for generic 
memory copying; it was about an audio device that is hardwired to a 
certain DMA channel.  There is no way to do audio without using that 
specific channel.

> If the dts/of/boot loader tells the kernel its a fsl soc then it knows
> how to work out which one and what level, and therefore knows what
> devices, such as the DMA device are present.

All you'd be doing then is moving the device trees into the kernel.  The 
dtc syntax is a convenient way of expressing the information that has to 
live *somewhere*.

> Quite why we are using a 20 year old spec, which was never finished, and
> ceased to be a formal spec 10 years ago as the "new" way forward is a
> puzzle to me as well.

Probably because there was already code there to support it. :-P

It's not that bad in most respects, though unlike some, I don't think we 
need to stick dogmatically to the exact way that Open Firmware(tm) did 
everything.

-Scott

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

> It's not that bad in most respects, though unlike some, I don't  
> think we need to stick dogmatically to the exact way that Open  
> Firmware(tm) did everything.

s/did/does/

And for the record: neither do I.


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

> I thought the idea of the dts/of was for the hardware specific boot
> loader to tell the kernel about hardware that the kernel couldn't
> otherwise know about, because its not detectable by a bus probe  
> method,
> etc. Its not there to tell you how to use the device or arbitrate  
> which
> other devices get to use a device when there are resource conflicts,
> etc.
>
> If the dts/of/boot loader tells the kernel its a fsl soc then it knows
> how to work out which one and what level, and therefore knows what
> devices, such as the DMA device are present.

The device tree describes _all_ hardware in the system,
not just the things that are somewhat harder to probe
for.  Kernel drivers are free to not use all info provided
in the device tree and just hardcode some (correct or
incorrect) implicit knowledge about the device in question.
Whether this is a good idea or not is a different thing.

> I'm truly interested in understanding the correct interpretation  
> because
> we are developing a DMA based, rapidio distributed system on fsl 8641
> and from lurking on here and reading the archives etc, all I see is a
> constant butting of heads on what the dts/of is and how its  
> supposed to
> work.

Really, most of what you see is developing bindings for
specific devices, which takes a lot of discussion since
it needs to be made future-proof.

> Quite why we are using a 20 year old spec, which was never  
> finished, and
> ceased to be a formal spec 10 years ago as the "new" way forward is a
> puzzle to me as well.

You have some misconceptions about Open Firmware I'm afraid.

> Not flame bait,

Good, let's drop this then :-)

> but if someone could point me to
> background material it would be helpful for my education in getting up
> to speed (on the rationale for using it going forwards, not all the  
> old
> sites for the spec itself).

I'm afraid you'll have to get some experience using the OF
device tree to truly appreciate its power and flexibility,
and how many problems it solves.  Yeah this is a pretty weak
answer.


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Paul Mackerras]

Segher Boessenkool writes:

> The device tree describes _all_ hardware in the system,
> not just the things that are somewhat harder to probe
> for.

Actually, for embedded systems, the device tree is really only
required to describe the things that it's useful for the Linux kernel
to know.

The point of the device tree for embedded systems is to provide
configuration information, not to be able to claim compliance with
some set of legalistic requirements. :)

I think in some cases we have gone a little over the top in trying to
put everything in the device tree, in fact.  Ultimately I think it has
to be up to the more experienced embedded developers to say how much
detail in the device tree is actually helpful and how much is dead
weight.

Paul.

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>> The device tree describes _all_ hardware in the system,
>> not just the things that are somewhat harder to probe
>> for.
>
> Actually, for embedded systems, the device tree is really only
> required to describe the things that it's useful for the Linux kernel
> to know.

Sure, for example it could provide a "SoC" node with only
an address range, and not describe all the devices on that
SoC separately.  It still describes all of the hardware,
not in quite so much detail though.  It also won't get all
the benefits of using the OF device tree, but that is a
trade off, for each group to decide on their own.

> The point of the device tree for embedded systems is to provide
> configuration information, not to be able to claim compliance with
> some set of legalistic requirements. :)

Well, if you use some certain binding, you better use it
correctly, no?  Ill-defined and ill-used interfaces aren't
the nicest thing to deal with.

> I think in some cases we have gone a little over the top in trying to
> put everything in the device tree, in fact.  Ultimately I think it has
> to be up to the more experienced embedded developers to say how much
> detail in the device tree is actually helpful and how much is dead
> weight.

Yes, more complex device bindings need a lot of time to get
right, and need a lot of input from all parties using it.
In general, it is better to leave out things from a binding
until it is very clear it is needed and is the right thing
to do.


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> +    - 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?

Fine with me.  Do put the exact model name in every .dts
file as well, e.g. for a hypothetical MPC8599:

	compatible = "fsl,mpc8599-dma", "fsl,mpc8548-dma";

so the kernel can match on the exact name if it needs a
quirk, but can use the more generic name otherwise.

>>> +    - 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?
>
> Or don't call it anything.  The ability to do extended chain mode is
> implicit in being compatible with fsl,mpc8548-dma.

Right.  I'm not sure having the channels as separate subnodes
buys anything at all, btw.

>>> +    - 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.

I think you need this knowledge in the kernel drivers anyway,
or at the very least, the device node for for example that
audio codec needs to refer to the DMA channel in the device
tree, so this "reserved" property is unnecessary.

> 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.

If you make separate nodes for the channels, they need to have
a parent.  I don't think it makes sense to have the channel
nodes and the "master" node as siblings -- maybe it all should
be just one node with a "#channels" property or such?


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

Segher Boessenkool wrote:
>> 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.
> 
> 
> I think you need this knowledge in the kernel drivers anyway,
> or at the very least, the device node for for example that
> audio codec needs to refer to the DMA channel in the device
> tree, so this "reserved" property is unnecessary.

The generic DMA driver needs to know not to touch the reserved channels.

>> 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.
> 
> If you make separate nodes for the channels, they need to have
> a parent.  I don't think it makes sense to have the channel
> nodes and the "master" node as siblings -- maybe it all should
> be just one node with a "#channels" property or such?

I don't see the need for a master node -- there are no shared registers 
(other than a redundant read-only status summary register) to 
synchronize access to.  Each channel would be an independent device 
under the SoC bus.

The benefit is that if a channel needs to be driven by (for example) a 
sound driver, it can have a different compatible that will be matched by 
the sound driver, and the generic DMA driver will never see it unless 
the sound driver explicitly chooses to make use of the generic DMA code 
-- and most of the time I think it'd be simpler for the special-purpose 
driver to manage the descriptors itself.

-Scott

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> 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.
>> I think you need this knowledge in the kernel drivers anyway,
>> or at the very least, the device node for for example that
>> audio codec needs to refer to the DMA channel in the device
>> tree, so this "reserved" property is unnecessary.
>
> The generic DMA driver needs to know not to touch the reserved  
> channels.

The generic DMA driver can look at the device tree, too.  It's
more convenient to only have to look at the dma-controller node,
true.  But with the proposed tree you have to look at all the
channel nodes already.

>>> 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.
>> If you make separate nodes for the channels, they need to have
>> a parent.  I don't think it makes sense to have the channel
>> nodes and the "master" node as siblings -- maybe it all should
>> be just one node with a "#channels" property or such?
>
> I don't see the need for a master node -- there are no shared  
> registers (other than a redundant read-only status summary  
> register) to synchronize access to.  Each channel would be an  
> independent device under the SoC bus.

The "master" node is needed to describe its register block.  It
doesn't matter whether you want to use those registers currently
or not.

> The benefit is that if a channel needs to be driven by (for  
> example) a sound driver, it can have a different compatible that  
> will be matched by the sound driver,

Nah, the sound node should just point to the channel node, or
point to the DMA controller and describe the channel # some
other way.  There is no need to make a special "sound DMA
channel" device name.

> and the generic DMA driver will never see it unless the sound  
> driver explicitly chooses to make use of the generic DMA code --  
> and most of the time I think it'd be simpler for the special- 
> purpose driver to manage the descriptors itself.

Sure.  But you yourself already say "most of the time" -- and
the device tree doesn't describe how the kernel uses the hardware,
it simply describes the hardware itself.  The sound DMA channel
is part of the DMA controller, it is only _connected_ to the
sound controller, it shouldn't be described as being more closely
connected to the sound stuff than it actually is.


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

Segher Boessenkool wrote:
> The generic DMA driver can look at the device tree, too.  It's more
> convenient to only have to look at the dma-controller node, true.
> But with the proposed tree you have to look at all the channel nodes
> already.

But if the only way to tell is a phandle from the sound device, it has
to look at the sound node as well, and somehow figure out where in the
sound node the phandle is stored.

>> I don't see the need for a master node -- there are no shared 
>> registers (other than a redundant read-only status summary
>> register) to synchronize access to.  Each channel would be an
>> independent device under the SoC bus.
> 
> 
> The "master" node is needed to describe its register block.  It 
> doesn't matter whether you want to use those registers currently or
> not.

It doesn't have a register block, as such.  There's one fairly useless
read-only register, that if we really wanted to we could describe as a
second reg resource in each channel, combined with a channel-ID property.

I'm not inclined to bother, though -- not because we don't currently use
it, but because I have a hard time seeing anyone needing to use it.
There is no information in that register that is not the individual
channels' registers.  I'd just lump it in with all of the other assorted
SoC registers that we don't describe in the device tree.

>> The benefit is that if a channel needs to be driven by (for
>> example) a sound driver, it can have a different compatible that
>> will be matched by the sound driver,
> 
> 
> Nah, the sound node should just point to the channel node, or point
> to the DMA controller and describe the channel # some other way.
> There is no need to make a special "sound DMA channel" device name.

It's by far the simplest way to tell the generic DMA driver "do not
touch".  "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA 
channel".  "fsl,mpc8548-audio-dma" says "this is a non-generic DMA 
channel, hooked up to an audio codec".

Would you prefer something like "fsl,mpc8548-dma-special-purpose"? 
Though there's also the possibility that there might be no other node to 
indicate the function, and that the only way to program the device is to 
start DMA.

> Sure.  But you yourself already say "most of the time" -- and the
> device tree doesn't describe how the kernel uses the hardware, it
> simply describes the hardware itself.

Precisely.  If the fsl,whatever-audio-dma driver wants to call the
generic DMA code, it can do so without the device tree's help.  I see no 
reason to give the mem-to-mem DMA driver special status compared to 
other users of the DMA channels.

> The sound DMA channel is part of the DMA controller, it is only
> _connected_ to the sound controller, it shouldn't be described as
> being more closely connected to the sound stuff than it actually is.

It's not as if I'm suggesting making it a child of the sound node -- 
just that each channel be a separate SoC-level device, and only 
mem-to-mem channels match the mem-to-mem driver.

-Scott

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>> The generic DMA driver can look at the device tree, too.  It's more
>> convenient to only have to look at the dma-controller node, true.
>> But with the proposed tree you have to look at all the channel nodes
>> already.
>
> But if the only way to tell is a phandle from the sound device, it has
> to look at the sound node as well, and somehow figure out where in the
> sound node the phandle is stored.

Yes, like I said, not very convenient.  I don't find a property
per channel to be all that convenient either, but hey that's
just me I suppose.  Either way, the "reserved" property isn't
*needed*.  It's misnamed too btw; the hardware doesn't reserve
anything (how could it?); maybe the channel is unusable for
general purpose stuff though, dunno.

>>> I don't see the need for a master node -- there are no shared  
>>> registers (other than a redundant read-only status summary
>>> register) to synchronize access to.  Each channel would be an
>>> independent device under the SoC bus.
>> The "master" node is needed to describe its register block.  It  
>> doesn't matter whether you want to use those registers currently or
>> not.
>
> It doesn't have a register block, as such.  There's one fairly useless
> read-only register,

There's your register block.  21000..210ff or what was it.

> that if we really wanted to we could describe as a
> second reg resource in each channel, combined with a channel-ID  
> property.

You cannot describe one register in two different nodes.

> I'm not inclined to bother, though -- not because we don't  
> currently use
> it, but because I have a hard time seeing anyone needing to use it.

Unless you're sure no one ever wants to use it, it should be in
the device tree.

> There is no information in that register that is not the individual
> channels' registers.

People use it to get the status of all registers at once.  I/O reads
aren't cheap...

> I'd just lump it in with all of the other assorted
> SoC registers that we don't describe in the device tree.
>
>>> The benefit is that if a channel needs to be driven by (for
>>> example) a sound driver, it can have a different compatible that
>>> will be matched by the sound driver,
>> Nah, the sound node should just point to the channel node, or point
>> to the DMA controller and describe the channel # some other way.
>> There is no need to make a special "sound DMA channel" device name.
>
> It's by far the simplest way to tell the generic DMA driver "do not
> touch".  "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA  
> channel".

I would expect it to mean "this is the 8548 DMA controller".

> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,  
> hooked up to an audio codec".

So this DMA channel cannot be used for general purpose stuff
at all?

> Would you prefer something like "fsl,mpc8548-dma-special-purpose"?

Just don't overload the "compatible" property with extra semantics.
Just add some extra property (I'm not happy about "reserved", but
_some_ new property is the way to go).

> Though there's also the possibility that there might be no other  
> node to indicate the function, and that the only way to program the  
> device is to start DMA.
>
>> Sure.  But you yourself already say "most of the time" -- and the
>> device tree doesn't describe how the kernel uses the hardware, it
>> simply describes the hardware itself.
>
> Precisely.  If the fsl,whatever-audio-dma driver wants to call the
> generic DMA code, it can do so without the device tree's help.  I  
> see no reason to give the mem-to-mem DMA driver special status  
> compared to other users of the DMA channels.

Sure, we agree on this.  It is prudent to describe in the sound
node which DMA channel is associated with the sound thing though,
even if this is a SoC and all that.  It is just describing the
hardware; if your sound driver wants to hardcode the DMA stuff,
that's fine with me, but that's no reason to not describe the
relation in the device tree.

>> The sound DMA channel is part of the DMA controller, it is only
>> _connected_ to the sound controller, it shouldn't be described as
>> being more closely connected to the sound stuff than it actually is.
>
> It's not as if I'm suggesting making it a child of the sound node  
> -- just that each channel be a separate SoC-level device, and only  
> mem-to-mem channels match the mem-to-mem driver.

I see no reason to pretend the non-mem-to-mem channels are somehow
different from the mem-to-mem channels.


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

Segher Boessenkool wrote:
>> that if we really wanted to we could describe as a
>> second reg resource in each channel, combined with a channel-ID  
>> property.
> 
> 
> You cannot describe one register in two different nodes.

Why not?  It's read-only.

>> I'm not inclined to bother, though -- not because we don't  currently use
>> it, but because I have a hard time seeing anyone needing to use it.
> 
> 
> Unless you're sure no one ever wants to use it, it should be in
> the device tree.

There are lots of registers that are used that aren't in the device 
tree.  This one's pretty low on the priority list to get added, IMHO.

>> There is no information in that register that is not the individual
>> channels' registers.
> 
> People use it to get the status of all registers at once.  I/O reads
> aren't cheap...

On-chip I/O reads shouldn't be all that slow...

>> It's by far the simplest way to tell the generic DMA driver "do not
>> touch".  "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA  
>> channel".
> 
> 
> I would expect it to mean "this is the 8548 DMA controller".

What if the mem-to-mem channels were explicitly labelled 
fsl,mpc8548-dma-mem-to-mem?

>> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,  
>> hooked up to an audio codec".
> 
> So this DMA channel cannot be used for general purpose stuff
> at all?

I don't know if it *can* or not, though it'd be a pretty unusual way of 
using it.  In any case, the device tree should be able to handle the 
case where it can't.

> Sure, we agree on this.  It is prudent to describe in the sound
> node which DMA channel is associated with the sound thing though,
> even if this is a SoC and all that.  It is just describing the
> hardware; if your sound driver wants to hardcode the DMA stuff,
> that's fine with me, but that's no reason to not describe the
> relation in the device tree.

Sure, I was never saying that there shouldn't be phandle linkage from 
the sound node to the dma channel node.  I just don't want the 
mem-to-mem driver to have to go to great lengths to figure out whether 
it owns the channel.

Phandle linkage the other way could work, though; if the channel has a 
phandle set in an attached-device property, then the mem-to-mem driver 
leaves it alone.

> I see no reason to pretend the non-mem-to-mem channels are somehow
> different from the mem-to-mem channels.

But they are different, just like an SCC UART is different from an SCC 
ethernet, even though they both go through the SCC.

-Scott

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> that if we really wanted to we could describe as a
>>> second reg resource in each channel, combined with a channel-ID   
>>> property.
>> You cannot describe one register in two different nodes.
>
> Why not?  It's read-only.

Because a register belongs to one, and only one, device
node.  There is no such concept as "read-only registers"
in Open Firmware btw.  How a device (or a driver for a
device) uses the registers is its own business; OF merely
describes what devices uses what address range.

>>> I'm not inclined to bother, though -- not because we don't   
>>> currently use
>>> it, but because I have a hard time seeing anyone needing to use it.
>> Unless you're sure no one ever wants to use it, it should be in
>> the device tree.
>
> There are lots of registers that are used that aren't in the device  
> tree.  This one's pretty low on the priority list to get added, IMHO.

It is in the original proposed tree already.  I see no reason
to take it out.

>>> There is no information in that register that is not the individual
>>> channels' registers.
>> People use it to get the status of all registers at once.  I/O reads
>> aren't cheap...
>
> On-chip I/O reads shouldn't be all that slow...

There's a full sync after every I/O read.  Anyway, it doesn't
matter; the register is there, why not describe it.

>>> It's by far the simplest way to tell the generic DMA driver "do not
>>> touch".  "fsl,mpc8548-dma" says "this is a generic, mem-to-mem  
>>> DMA  channel".
>> I would expect it to mean "this is the 8548 DMA controller".
>
> What if the mem-to-mem channels were explicitly labelled  
> fsl,mpc8548-dma-mem-to-mem?

Why would you?  Why would you put _any_ compatible property in
the individual channels, even; they aren't separate devices
after all.

>>> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,   
>>> hooked up to an audio codec".
>> So this DMA channel cannot be used for general purpose stuff
>> at all?
>
> I don't know if it *can* or not, though it'd be a pretty unusual  
> way of using it.  In any case, the device tree should be able to  
> handle the case where it can't.

Yes, but also the case where it _can_.

>> Sure, we agree on this.  It is prudent to describe in the sound
>> node which DMA channel is associated with the sound thing though,
>> even if this is a SoC and all that.  It is just describing the
>> hardware; if your sound driver wants to hardcode the DMA stuff,
>> that's fine with me, but that's no reason to not describe the
>> relation in the device tree.
>
> Sure, I was never saying that there shouldn't be phandle linkage  
> from the sound node to the dma channel node.  I just don't want the  
> mem-to-mem driver to have to go to great lengths to figure out  
> whether it owns the channel.
>
> Phandle linkage the other way could work, though; if the channel  
> has a phandle set in an attached-device property,

I'm not sure that would cleanly work in all cases, I'll have to
think about it.

> then the mem-to-mem driver leaves it alone.

Yeah that would work.  There are much simpler solutions though.

>> I see no reason to pretend the non-mem-to-mem channels are somehow
>> different from the mem-to-mem channels.
>
> But they are different, just like an SCC UART is different from an  
> SCC ethernet, even though they both go through the SCC.

The SCC is the same; if there was a node describing just the SCC
part, like we have nodes describing _just_ the DMA channel part
here, it would be the same situation.


Segher

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Scott Wood]

Segher Boessenkool wrote:
>> What if the mem-to-mem channels were explicitly labelled  
>> fsl,mpc8548-dma-mem-to-mem?
> 
> 
> Why would you?  Why would you put _any_ compatible property in
> the individual channels, even; they aren't separate devices
> after all.

They should be. :-)

-Scott

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> What if the mem-to-mem channels were explicitly labelled   
>>> fsl,mpc8548-dma-mem-to-mem?
>> Why would you?  Why would you put _any_ compatible property in
>> the individual channels, even; they aren't separate devices
>> after all.
>
> They should be. :-)

But they're not, no amount of wishing or trying to discount the
shared ("master") register block will change that.


Segher

RE: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Zhang Wei-r63237]

Hi,=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
>=20
> > +   k) DMA
> > +
> > +   This sector define DMA for dma-engine driver of Freescale
>=20
> It's called a "device node" or "node", not a "sector".

Ok, "node".

>=20
> > +    - compatible : Should be "fsl,mpc8xxx-dma"
>=20
> Should _include_, not should _be_.  And none of this xxx
> business, of course.
>=20

All right.

> > +    - extended : Set the DMA channel to work at extended=20
> chain mode.
> > +                 If not set, the DMA channel will work at basic
> > +                 chain mode.
>=20
> Call it "extended-chain-mode", perhaps?
>=20

Is it maybe too long?

> > +    - reserved : Reserve the DMA channel to device.
>=20
> What does this do?  Reserve it for what device, and where?
> The OS driver?
>=20

Yes, it reserve for the special device, which must use the fixed
channel. Thus, reserve channels requested by that device.

And in the device node of dts file, you can use such as
"dma-channel=3D<&dma-ch0>" to reference the below channel:

dma-ch0: ch0@100 {
...
}

Thanks!
Wei.

Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> +    - 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?
>
> Is it maybe too long?

Not really no.  It's only 19 characters, and it isn't used
all over the place, so that should be fine.

>>> +    - reserved : Reserve the DMA channel to device.
>>
>> What does this do?  Reserve it for what device, and where?
>> The OS driver?
>>
>
> Yes, it reserve for the special device, which must use the fixed
> channel. Thus, reserve channels requested by that device.
>
> And in the device node of dts file, you can use such as
> "dma-channel=<&dma-ch0>" to reference the below channel:
>
> dma-ch0: ch0@100 {
> ...
> }

Right, so you don't need a "reserved" property, that information
is in the tree already.

Alternatively, for ease of use, you could put a "reserved" bitmap
in the master DMA controller node.  I wouldn't make nodes per
channel anyway, just describe the channels using properties -- that
takes care of the "reg" vs. "ranges" thing too, etc.


Segher

RE: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Zhang Wei-r63237]

Hi,=20

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
> >> Call it "extended-chain-mode", perhaps?
> >
> > Is it maybe too long?
>=20
> Not really no.  It's only 19 characters, and it isn't used
> all over the place, so that should be fine.

Ok,

>=20
> >>> +    - reserved : Reserve the DMA channel to device.
> >>
> >> What does this do?  Reserve it for what device, and where?
> >> The OS driver?
> >>
> >
> > Yes, it reserve for the special device, which must use the fixed
> > channel. Thus, reserve channels requested by that device.
> >
> > And in the device node of dts file, you can use such as
> > "dma-channel=3D<&dma-ch0>" to reference the below channel:
> >
> > dma-ch0: ch0@100 {
> > ...
> > }
>=20
> Right, so you don't need a "reserved" property, that information
> is in the tree already.

Ok, I'll remove "reserved" description.

>=20
> Alternatively, for ease of use, you could put a "reserved" bitmap
> in the master DMA controller node.  I wouldn't make nodes per
> channel anyway, just describe the channels using properties -- that
> takes care of the "reg" vs. "ranges" thing too, etc.

Bitmap for reserved? Not very clear. :(

Thanks!
Wei.