All,
I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability.
Here are my questions then:
1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus?
2. If dmaengine is correct, what can I do to free up a channel for my own use?
Thank you.
Chuck
From: Ira W. Snyder <hidden> Date: 2011-04-06 20:10:33
On Wed, Apr 06, 2011 at 12:40:58PM -0700, Chuck Ketcham wrote:
All,
I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability.
Here are my questions then:
1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus?
2. If dmaengine is correct, what can I do to free up a channel for my own use?
I use the Freescale DMA engine to transfer lots of data out to PCI, on
an 8349EA chip. The P2020 DMA engine uses the same driver.
I hunch you have enabled CONFIG_NET_DMA, which will claim the channels.
You should disable it to use the devices for other uses.
If you want an example of using the DMA engine to transfer from DDR
memory to the PowerPC local bus, search the mailing list archives for
"CARMA Board Drivers" (RFCv7 was the latest posting). Transferring from
DDR to PCI works exactly the same way.
Hope it helps,
Ira
Ira,=0A=0AThanks for the reference to the CARMA drivers. I will have to ta=
ke a look at that.=0A=0AIn my case, CONFIG_NET_DMA is not enabled. However=
, I did notice the following entry in my p2020rdb.dts file that may have so=
mething to do with dma channels being allocated -- can anyone interpret thi=
s?:=0A=0A dma@21300 {=0A #address-cel=
ls =3D <1>;=0A #size-cells =3D <1>;=0A =
compatible =3D "fsl,eloplus-dma";=0A reg =
=3D <0x21300 0x4>;=0A ranges =3D <0x0 0x21100 0x200>=
;=0A cell-index =3D <0>;=0A d=
ma-channel@0 {=0A compatible =3D "fsl,eloplu=
s-dma-channel";=0A reg =3D <0x0 0x80>;=0A =
cell-index =3D <0>;=0A =
interrupt-parent =3D <&mpic>;=0A int=
errupts =3D <20 2>;=0A };=0A =
dma-channel@80 {=0A compatible =3D "fsl,elop=
lus-dma-channel";=0A reg =3D <0x80 0x80>;=0A=
cell-index =3D <1>;=0A =
interrupt-parent =3D <&mpic>;=0A =
interrupts =3D <21 2>;=0A };=0A =
dma-channel@100 {=0A compatible =3D "fsl,=
eloplus-dma-channel";=0A reg =3D <0x100 0x80=
;=0A cell-index =3D <2>;=0A =
interrupt-parent =3D <&mpic>;=0A =
interrupts =3D <22 2>;=0A };=0A =
dma-channel@180 {=0A compatible =3D =
"fsl,eloplus-dma-channel";=0A reg =3D <0x180=
0x80>;=0A cell-index =3D <3>;=0A =
interrupt-parent =3D <&mpic>;=0A =
interrupts =3D <23 2>;=0A };=0A =
};=0A=0A=0A=0A--- On Wed, 4/6/11, Ira W. Snyder [off-list ref]=
wrote:=0A=0A> From: Ira W. Snyder [off-list ref]=0A> Subject: Re: =
Using dmaengine on Freescale P2020 RDB=0A> To: "Chuck Ketcham" <chuckk2333@=
yahoo.com>=0A> Cc: linuxppc-dev@lists.ozlabs.org=0A> Date: Wednesday, April=
6, 2011, 1:10 PM=0A> On Wed, Apr 06, 2011 at 12:40:58PM=0A> -0700, Chuck K=
etcham wrote:=0A> > All,=0A> > =0A> > I have a Freescale P2020 Reference De=
sign Board.=A0=0A> I am investigating the possibility of using the dmaengin=
e=0A> capability in the 2.6.32.13 kernel to transfer data from=0A> memory o=
ut onto the PCIe bus.=A0 As a first step, I=0A> thought I would try the DMA=
test client (dmatest.ko) to make=0A> sure the dmaengine was functioning.=
=A0 I know this=0A> doesn't transfer anything over PCIe but only transfers =
from=0A> one memory buffer to another, but I figured I need to get=0A> this=
working first.=A0 Anyway I built dmatest.ko and ran=0A> it (with insmod), =
and discovered it didn't do=0A> anything.=A0 I added some printk's to the k=
ernel to=0A> investigate what was going on and I found that all attempts=0A=
to find a channel within dma_request_channel were=0A> unsuccessful.=A0 Th=
ree of the channels were not used=0A> because they were already publicly al=
located.=A0 One=0A> channel was not used because it didn't have DMA_MEMCPY=
=0A> capability.=0A> > =0A> > Here are my questions then:=0A> > 1. Is the d=
maengine the appropriate method to use for=0A> transferring data from memor=
y out onto the PCIe bus?=0A> > 2. If dmaengine is correct, what can I do to=
free up a=0A> channel for my own use?=0A> > =0A> =0A> I use the Freescale =
DMA engine to transfer lots of data out=0A> to PCI, on=0A> an 8349EA chip. =
The P2020 DMA engine uses the same driver.=0A> =0A> I hunch you have enable=
d CONFIG_NET_DMA, which will claim=0A> the channels.=0A> You should disable=
it to use the devices for other uses.=0A> =0A> If you want an example of u=
sing the DMA engine to transfer=0A> from DDR=0A> memory to the PowerPC loca=
l bus, search the mailing list=0A> archives for=0A> "CARMA Board Drivers" (=
RFCv7 was the latest posting).=0A> Transferring from=0A> DDR to PCI works e=
xactly the same way.=0A> =0A> Hope it helps,=0A> Ira=0A> __________________=
_____________________________=0A> Linuxppc-dev mailing list=0A> Linuxppc-de=
v@lists.ozlabs.org=0A> https://lists.ozlabs.org/listinfo/linuxppc-dev=0A>
From: Ira W. Snyder <hidden> Date: 2011-04-06 21:28:03
On Wed, Apr 06, 2011 at 01:29:05PM -0700, Chuck Ketcham wrote:
Ira,
Thanks for the reference to the CARMA drivers. I will have to take a look at that.
In my case, CONFIG_NET_DMA is not enabled. However, I did notice the following entry in my p2020rdb.dts file that may have something to do with dma channels being allocated -- can anyone interpret this?:
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,eloplus-dma";
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0>;
interrupt-parent = <&mpic>;
interrupts = <20 2>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
interrupt-parent = <&mpic>;
interrupts = <21 2>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&mpic>;
interrupts = <22 2>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <3>;
interrupt-parent = <&mpic>;
interrupts = <23 2>;
};
};
Your DTS file looks fine. It is what I would expect to see. The channels
are not allocated by anything here.
Turning on CONFIG_DMADEVICES_DEBUG may give you some insight into how
the dmaengine core is allocating the channels. I don't have any better
advice. I'm afraid you'll have to figure out who is requesting all of
the channels on your own.
Ira
quoted hunk
--- On Wed, 4/6/11, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
quoted
From: Ira W. Snyder <redacted>
Subject: Re: Using dmaengine on Freescale P2020 RDB
To: "Chuck Ketcham" <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
Date: Wednesday, April 6, 2011, 1:10 PM
On Wed, Apr 06, 2011 at 12:40:58PM
-0700, Chuck Ketcham wrote:
quoted
All,
I have a Freescale P2020 Reference Design Board.
I am investigating the possibility of using the dmaengine
capability in the 2.6.32.13 kernel to transfer data from
memory out onto the PCIe bus. As a first step, I
thought I would try the DMA test client (dmatest.ko) to make
sure the dmaengine was functioning. I know this
doesn't transfer anything over PCIe but only transfers from
one memory buffer to another, but I figured I need to get
this working first. Anyway I built dmatest.ko and ran
it (with insmod), and discovered it didn't do
anything. I added some printk's to the kernel to
investigate what was going on and I found that all attempts
to find a channel within dma_request_channel were
unsuccessful. Three of the channels were not used
because they were already publicly allocated. One
channel was not used because it didn't have DMA_MEMCPY
capability.
quoted
Here are my questions then:
1. Is the dmaengine the appropriate method to use for
transferring data from memory out onto the PCIe bus?
quoted
2. If dmaengine is correct, what can I do to free up a
channel for my own use?
quoted
I use the Freescale DMA engine to transfer lots of data out
to PCI, on
an 8349EA chip. The P2020 DMA engine uses the same driver.
I hunch you have enabled CONFIG_NET_DMA, which will claim
the channels.
You should disable it to use the devices for other uses.
If you want an example of using the DMA engine to transfer
from DDR
memory to the PowerPC local bus, search the mailing list
archives for
"CARMA Board Drivers" (RFCv7 was the latest posting).
Transferring from
DDR to PCI works exactly the same way.
Hope it helps,
Ira
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev