* Using dmaengine on Freescale P2020 RDB @ 2011-04-06 19:40 Chuck Ketcham 2011-04-06 20:10 ` Ira W. Snyder 2011-04-08 15:29 ` Timur Tabi 0 siblings, 2 replies; 5+ messages in thread From: Chuck Ketcham @ 2011-04-06 19:40 UTC (permalink / raw) To: linuxppc-dev 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using dmaengine on Freescale P2020 RDB 2011-04-06 19:40 Using dmaengine on Freescale P2020 RDB Chuck Ketcham @ 2011-04-06 20:10 ` Ira W. Snyder 2011-04-06 20:29 ` Chuck Ketcham 2011-04-08 15:29 ` Timur Tabi 1 sibling, 1 reply; 5+ messages in thread From: Ira W. Snyder @ 2011-04-06 20:10 UTC (permalink / raw) To: Chuck Ketcham; +Cc: linuxppc-dev 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using dmaengine on Freescale P2020 RDB 2011-04-06 20:10 ` Ira W. Snyder @ 2011-04-06 20:29 ` Chuck Ketcham 2011-04-06 21:28 ` Ira W. Snyder 0 siblings, 1 reply; 5+ messages in thread From: Chuck Ketcham @ 2011-04-06 20:29 UTC (permalink / raw) To: Ira W. Snyder; +Cc: linuxppc-dev 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 <iws@ovro.caltech.edu>= wrote:=0A=0A> From: Ira W. Snyder <iws@ovro.caltech.edu>=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> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using dmaengine on Freescale P2020 RDB 2011-04-06 20:29 ` Chuck Ketcham @ 2011-04-06 21:28 ` Ira W. Snyder 0 siblings, 0 replies; 5+ messages in thread From: Ira W. Snyder @ 2011-04-06 21:28 UTC (permalink / raw) To: Chuck Ketcham; +Cc: linuxppc-dev 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 > --- On Wed, 4/6/11, Ira W. Snyder <iws@ovro.caltech.edu> wrote: > > > From: Ira W. Snyder <iws@ovro.caltech.edu> > > Subject: Re: Using dmaengine on Freescale P2020 RDB > > To: "Chuck Ketcham" <chuckk2333@yahoo.com> > > 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: > > > 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 > > _______________________________________________ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using dmaengine on Freescale P2020 RDB 2011-04-06 19:40 Using dmaengine on Freescale P2020 RDB Chuck Ketcham 2011-04-06 20:10 ` Ira W. Snyder @ 2011-04-08 15:29 ` Timur Tabi 1 sibling, 0 replies; 5+ messages in thread From: Timur Tabi @ 2011-04-08 15:29 UTC (permalink / raw) To: Chuck Ketcham; +Cc: linuxppc-dev On Wed, Apr 6, 2011 at 2:40 PM, Chuck Ketcham <chuckk2333@yahoo.com> wrote: > Three of the channels were not used because they were already publicly al= located. =A0One channel was > not used because it didn't have DMA_MEMCPY capability. That's strange, because all four DMA channels are identical. > 2. If dmaengine is correct, what can I do to free up a channel for my own= use? There must be something else in your system using up the channels. --=20 Timur Tabi Linux kernel developer at Freescale ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-04-08 15:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-06 19:40 Using dmaengine on Freescale P2020 RDB Chuck Ketcham 2011-04-06 20:10 ` Ira W. Snyder 2011-04-06 20:29 ` Chuck Ketcham 2011-04-06 21:28 ` Ira W. Snyder 2011-04-08 15:29 ` Timur Tabi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).