Message ID | 1347662517-4210-2-git-send-email-jon-hunter@ti.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 09/14/2012 04:41 PM, Jon Hunter wrote: > This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] > to add some basic helpers to retrieve a DMA controller device_node and the > DMA request/channel information. The binding looks good to me now, so, Reviewed-by: Stephen Warren <swarren@wwwdotorg.org> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > 3. Supporting legacy devices not using DMA Engine > > These devices present a problem, as there may not be a uniform way to easily > support them with regard to device tree. Ideally, these should be migrated > to DMA engine. However, if this is not possible, then they should still be > able to use this binding, the only constaint imposed by this implementation > is that when requesting a DMA channel via of_dma_request_slave_channel(), it > will return a type of dma_chan. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 15 September 2012, Russell King - ARM Linux wrote: > > On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > > 3. Supporting legacy devices not using DMA Engine > > > > These devices present a problem, as there may not be a uniform way to easily > > support them with regard to device tree. Ideally, these should be migrated > > to DMA engine. However, if this is not possible, then they should still be > > able to use this binding, the only constaint imposed by this implementation > > is that when requesting a DMA channel via of_dma_request_slave_channel(), it > > will return a type of dma_chan. > > As far as devices not using DMA engine, the answer is we don't support > their specification in the DT model. Note that the legacy OMAP DMA > API is scheduled for removal next year, so it's not going to be around > that much longer. There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), and I agree that they are unlikely to see OF support, although if they did, it wouldn't be unreasonable to encode their DMA channels using the same binding. The other ones that are currently around with their own DMA implementation are bcmring --> platform is going away samsung --> gradually getting moved to dmaengine, already has its own binding that needs to be replaced with this one, so best do it at the same time. tegra --> old dma code gone in 3.7 pxa/mmp --> dmaengine implementation being worked on, should wait for that. msm --> dma implementation only used by two drivers (serial and mmc). Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their own dma APIs based on the ISA interfaces. I don't currently see any of them moving towards DT, but it's definitely possible. Among the above MSM seems to be the most likely candidate to use the binding before moving to DT. The msm_sdcc driver is (like much of the msm platform code) lagging far behind the internel version that qualcomm have, and the device tree binding they are using is incompatible with the common MMC binding (and of course the DMA binding here) as well. For getting MSM up to speed compared with the other platforms, they have to use proper DT bindings as well as proper DMA engine support. Between those two, I'd prefer fixing the DT binding first, in order to limit the amount of changes that have to be done to external device tree files. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 17, 2012 at 08:42:11PM +0000, Arnd Bergmann wrote: > On Saturday 15 September 2012, Russell King - ARM Linux wrote: > > > > On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > > > 3. Supporting legacy devices not using DMA Engine > > > > > > These devices present a problem, as there may not be a uniform way to easily > > > support them with regard to device tree. Ideally, these should be migrated > > > to DMA engine. However, if this is not possible, then they should still be > > > able to use this binding, the only constaint imposed by this implementation > > > is that when requesting a DMA channel via of_dma_request_slave_channel(), it > > > will return a type of dma_chan. > > > > As far as devices not using DMA engine, the answer is we don't support > > their specification in the DT model. Note that the legacy OMAP DMA > > API is scheduled for removal next year, so it's not going to be around > > that much longer. > > There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), > and I agree that they are unlikely to see OF support, although if they did, it > wouldn't be unreasonable to encode their DMA channels using the same binding. > > The other ones that are currently around with their own DMA implementation are > > bcmring --> platform is going away > samsung --> gradually getting moved to dmaengine, already has its own binding > that needs to be replaced with this one, so best do it at the same > time. > tegra --> old dma code gone in 3.7 > pxa/mmp --> dmaengine implementation being worked on, should wait for that. > msm --> dma implementation only used by two drivers (serial and mmc). > > Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their > own dma APIs based on the ISA interfaces. I don't currently see any of them > moving towards DT, but it's definitely possible. > > Among the above MSM seems to be the most likely candidate to use the binding > before moving to DT. The msm_sdcc driver is (like much of the msm platform > code) lagging far behind the internel version that qualcomm have, and the > device tree binding they are using is incompatible with the common MMC > binding (and of course the DMA binding here) as well. For getting MSM up > to speed compared with the other platforms, they have to use proper DT > bindings as well as proper DMA engine support. Between those two, I'd prefer > fixing the DT binding first, in order to limit the amount of changes that > have to be done to external device tree files. There is also a lot of similarity between the mmci hardware and the msm_sdcc hardware. Enough so, that it is probably better for us to make the mmci driver work with our hardware, rather than trying to keep msm_sdcc going. There is also an MSM nand device that appears to have not made it in. It is heavily dependent on the weird features of the DMA hardware. I don't have any current plans to support this device, since most boards using MSMs these days are using mmc/sd instead of bare NAND. Our DMA hardware is really weird, but should be a bit reasonable. It is also being gradually replaced in newer chips with a different DMA framework. As far as I'm concerned, I consider making our DMA driver(s) use the DMA engine API to be part of getting these platforms working with DT. It is planned, but there are quite a few things that need to be tackled first. David
On Monday 17 September 2012, David Brown wrote: > There is also a lot of similarity between the mmci hardware and the > msm_sdcc hardware. Enough so, that it is probably better for us to > make the mmci driver work with our hardware, rather than trying to > keep msm_sdcc going. > > There is also an MSM nand device that appears to have not made it in. > It is heavily dependent on the weird features of the DMA hardware. I > don't have any current plans to support this device, since most boards > using MSMs these days are using mmc/sd instead of bare NAND. > > Our DMA hardware is really weird, but should be a bit reasonable. It > is also being gradually replaced in newer chips with a different DMA > framework. > > As far as I'm concerned, I consider making our DMA driver(s) use the > DMA engine API to be part of getting these platforms working with DT. > > It is planned, but there are quite a few things that need to be > tackled first. Ok, thanks for the information. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/18/2012 4:42 AM, Arnd Bergmann wrote: > On Saturday 15 September 2012, Russell King - ARM Linux wrote: >> >> On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: >>> 3. Supporting legacy devices not using DMA Engine >>> >>> These devices present a problem, as there may not be a uniform way to easily >>> support them with regard to device tree. Ideally, these should be migrated >>> to DMA engine. However, if this is not possible, then they should still be >>> able to use this binding, the only constaint imposed by this implementation >>> is that when requesting a DMA channel via of_dma_request_slave_channel(), it >>> will return a type of dma_chan. >> >> As far as devices not using DMA engine, the answer is we don't support >> their specification in the DT model. Note that the legacy OMAP DMA >> API is scheduled for removal next year, so it's not going to be around >> that much longer. > > There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), > and I agree that they are unlikely to see OF support, (Warning - historical rambling follows) There is a delicious irony here with respect to Shark. Shark has real Open Firmware. It's the platform that I used for the first OFW port to ARM. We (the Shark design team) had a version of NetBSD that would run on Shark without any native drivers, calling into the Open Firmware drivers. It was very useful for bringup. I wonder when was the last time anyone turned on a Shark? I ran my mail server on one until 8 years ago, when the incoming spam load began to saturate the 10 Mbit Ethernet. Shark had decent computational power, but the I/O system, built around a low cost PC I/O chip, didn't have much bandwidth. Also in that time frame (early 2000s), some of us Shark designers managed to grab a pile of Sharks that HP was going to scrap. (HP had inherited them as part of Compaq, who had acquired them as part of Digital.) We used them as production unit testers for a consumer gadget that we were building. But, alas, even that usage fell to the wayside. I redesigned the tester around an ATSAM7 chip and put the entire test setup into a tiny box. I still have a couple of Sharks, but they haven't been turned on for at least 6 years. Is there ever a point when old architectures leave the Linux tree, or will people have to see grep hits from them until the end of time? although if they did, it > wouldn't be unreasonable to encode their DMA channels using the same binding. > > The other ones that are currently around with their own DMA implementation are > > bcmring --> platform is going away > samsung --> gradually getting moved to dmaengine, already has its own binding > that needs to be replaced with this one, so best do it at the same > time. > tegra --> old dma code gone in 3.7 > pxa/mmp --> dmaengine implementation being worked on, should wait for that. > msm --> dma implementation only used by two drivers (serial and mmc). > > Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their > own dma APIs based on the ISA interfaces. I don't currently see any of them > moving towards DT, but it's definitely possible. > > Among the above MSM seems to be the most likely candidate to use the binding > before moving to DT. The msm_sdcc driver is (like much of the msm platform > code) lagging far behind the internel version that qualcomm have, and the > device tree binding they are using is incompatible with the common MMC > binding (and of course the DMA binding here) as well. For getting MSM up > to speed compared with the other platforms, they have to use proper DT > bindings as well as proper DMA engine support. Between those two, I'd prefer > fixing the DT binding first, in order to limit the amount of changes that > have to be done to external device tree files. > > Arnd > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 19, 2012 at 06:19:06AM +0800, Mitch Bradley wrote: > Is there ever a point when old architectures leave the Linux tree, or > will people have to see grep hits from them until the end of time? That depends on use and the burden of keeping them in the tree. I'm not aware of much activity around Shark, and I'm not aware of Shark causing that many problems either... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 18 September 2012, Mitch Bradley wrote: > There is a delicious irony here with respect to Shark. Shark has real > Open Firmware. It's the platform that I used for the first OFW port to > ARM. We (the Shark design team) had a version of NetBSD that would run > on Shark without any native drivers, calling into the Open Firmware > drivers. It was very useful for bringup. Very interesting, thanks for sharing this bit of history. Are you aware of other ARM systems using open firmware that we still support in Linux (besides the XO-1.75)? > Is there ever a point when old architectures leave the Linux tree, or > will people have to see grep hits from them until the end of time? As long as someone is interested in keeping an architecture or driver alive, it stays. If something is causing problems and we have reason to assume it will never be used again with current kernels, we toss them out. Russell has recently removed support for ARMv3 CPUs, but some of the StrongARM targets (especially SA-1100) are still being actively used, so the CPU support is not going away any time soon. If you have a bunch of Shark machines for testing and would like to port it over to device tree passing from its open firmware, you are definitely welcome ;-) Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: ... Typo nits in the binding examples below... > Documentation/devicetree/bindings/dma/dma.txt | 81 +++++++++ > drivers/of/Makefile | 2 +- > drivers/of/dma.c | 219 +++++++++++++++++++++++++ > include/linux/of_dma.h | 45 +++++ > 4 files changed, 346 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/dma/dma.txt > create mode 100644 drivers/of/dma.c > create mode 100644 include/linux/of_dma.h > > diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt > new file mode 100644 > index 0000000..a4f59a5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/dma.txt > @@ -0,0 +1,81 @@ > +* Generic DMA Controller and DMA request bindings > + > +Generic binding to provide a way for a driver using DMA Engine to retrieve the > +DMA request or channel information that goes from a hardware device to a DMA > +controller. > + > + > +* DMA controller > + > +Required property: > +- #dma-cells: Must be at least 1. Used to provide DMA controller > + specific information. See DMA client binding below for > + more details. > + > +Optional properties: > +- #dma-channels: Number of DMA channels supported by the controller. > +- #dma-requests: Number of DMA requests signals supported by the > + controller. > + > +Example: > + > + dma: dma@48000000 { > + compatible = "ti,omap-sdma" ; here > + reg = <0x48000000 0x1000>; > + interrupts = <0 12 0x4 > + 0 13 0x4 > + 0 14 0x4 > + 0 15 0x4>; > + #dma-cells = <1>; > + #dma-channels = <32>; > + #dma-requests = <127>; > + }; > + > + > +* DMA client > + > +Client drivers should specify the DMA property using a phandle to the controller > +followed by DMA controller specific data. > + > +Required property: > +- dmas: List of one or more DMA specifiers, each consisting of > + - A phandle pointing to DMA controller node > + - A number of integer cells, as determined by the > + #dma-cells property in the node referenced by phandle > + containing DMA controller specific information. This > + typically contains a DMA request line number or a > + channel number, but can contain any data that is used > + required for configuring a channel. > +- dma-names: Contains one identifier string for each DMA specifier in > + the dmas property. The specific strings that can be used > + are defined in the binding of the DMA client device. > + Multiple DMA specifiers can be used to represent > + alternatives and in this case the dma-names for those > + DMA specifiers must be identical (see examples). > + > +Examples: > + > +1. A device with one DMA read channel, one DMA write channel: > + > + i2c1: i2c@1 { > + ... > + dmas = <&dma 2 /* read channel */ > + &dma 3>; /* write channel */ > + dma-names = "rx", "tx" ; here too > + ... > + }; > + > +2. A single read-write channel with three alternative DMA controllers: > + > + dmas = <&dma1 5 > + &dma2 7 > + &dma3 2>; > + dma-names = "rx-tx", "rx-tx", "rx-tx" again ; > + > +3. A device with three channels, one of which has two alternatives: > + > + dmas = <&dma1 2 /* read channel */ > + &dma1 3 /* write channel */ > + &dma2 0 /* error read */ > + &dma3 0>; /* alternative error read */ > + dma-names = "rx", "tx", "error", "error"; Patch for these posted separately. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: > diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt > new file mode 100644 > index 0000000..a4f59a5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/dma.txt > @@ -0,0 +1,81 @@ > +* Generic DMA Controller and DMA request bindings > + > +Generic binding to provide a way for a driver using DMA Engine to retrieve the > +DMA request or channel information that goes from a hardware device to a DMA > +controller. > + > + > +* DMA controller > + > +Required property: > +- #dma-cells: Must be at least 1. Used to provide DMA controller > + specific information. See DMA client binding below for > + more details. > + > +Optional properties: > +- #dma-channels: Number of DMA channels supported by the controller. > +- #dma-requests: Number of DMA requests signals supported by the > + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the "*-cells" cell sizes. A quick search indicates this is the case throughout all the current bindings. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/14/2012 05:41 PM, Jon Hunter wrote: > This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] > to add some basic helpers to retrieve a DMA controller device_node and the > DMA request/channel information. [snip] > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com> > Signed-off-by: Jon Hunter <jon-hunter@ti.com> > --- > Documentation/devicetree/bindings/dma/dma.txt | 81 +++++++++ > drivers/of/Makefile | 2 +- > drivers/of/dma.c | 219 +++++++++++++++++++++++++ We've been moving in the direction of not putting subsystem related code under drivers/of, but rather with the subsystem. Although in some cases (i2c), the maintainers didn't want the OF code there. In any case, I guess this will go thru Vinod's tree, so: Acked-by: Rob Herring <rob.herring@calxeda.com> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 19 September 2012, Matt Porter wrote: > > +Optional properties: > > +- #dma-channels: Number of DMA channels supported by the controller. > > +- #dma-requests: Number of DMA requests signals supported by the > > + controller. > > Shouldn't these two optional properties drop the prefix #? By > convention adopted from the various original OF/ePAPR/etc specs, the > only properties I would expect to see with this prefix are the > "*-cells" cell sizes. A quick search indicates this is the case > throughout all the current bindings. I always assumed that the # prefix is used to indicate that we are counting things instead of listing them. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/19/2012 09:24 AM, Arnd Bergmann wrote: > On Wednesday 19 September 2012, Matt Porter wrote: >>> +Optional properties: >>> +- #dma-channels: Number of DMA channels supported by the controller. >>> +- #dma-requests: Number of DMA requests signals supported by the >>> + controller. >> >> Shouldn't these two optional properties drop the prefix #? By >> convention adopted from the various original OF/ePAPR/etc specs, the >> only properties I would expect to see with this prefix are the >> "*-cells" cell sizes. A quick search indicates this is the case >> throughout all the current bindings. > > I always assumed that the # prefix is used to indicate that we are counting > things instead of listing them. Lots of properties count things, but don't have a #. nr_gpios or spi chipselect counts for example. I'd say drop the #. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote: > On 09/19/2012 09:24 AM, Arnd Bergmann wrote: > > On Wednesday 19 September 2012, Matt Porter wrote: > >>> +Optional properties: > >>> +- #dma-channels: Number of DMA channels supported by the controller. > >>> +- #dma-requests: Number of DMA requests signals supported by the > >>> + controller. > >> > >> Shouldn't these two optional properties drop the prefix #? By > >> convention adopted from the various original OF/ePAPR/etc specs, the > >> only properties I would expect to see with this prefix are the > >> "*-cells" cell sizes. A quick search indicates this is the case > >> throughout all the current bindings. > > > > I always assumed that the # prefix is used to indicate that we are counting > > things instead of listing them. > > Lots of properties count things, but don't have a #. nr_gpios or spi > chipselect counts for example. I'd say drop the #. Ok, I can drop another trivial patch since I hear Jon is on vacation. Yeah, I grepped all the bindings and it's only ever encountered on cell sizes. There's not even one example of it used as above. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/19/2012 7:09 PM, Arnd Bergmann wrote: > On Tuesday 18 September 2012, Mitch Bradley wrote: >> There is a delicious irony here with respect to Shark. Shark has real >> Open Firmware. It's the platform that I used for the first OFW port to >> ARM. We (the Shark design team) had a version of NetBSD that would run >> on Shark without any native drivers, calling into the Open Firmware >> drivers. It was very useful for bringup. > > Very interesting, thanks for sharing this bit of history. Are you aware > of other ARM systems using open firmware that we still support in Linux > (besides the XO-1.75)? There is the successor to the XO-1.75 that we working on now. I don't know of any others. We just did a big push to convert a bunch of drivers to DT so we will able to use the same kernel on XO-1.75 and XO-4. The conversion went pretty smoothly, but there is still a fair amount of testing, integration, and coordination to do. When things get a bit less hectic, we'll start submitting patches. > >> Is there ever a point when old architectures leave the Linux tree, or >> will people have to see grep hits from them until the end of time? > > As long as someone is interested in keeping an architecture or driver > alive, it stays. If something is causing problems and we have reason > to assume it will never be used again with current kernels, we toss > them out. Russell has recently removed support for ARMv3 CPUs, but > some of the StrongARM targets (especially SA-1100) are still being > actively used, so the CPU support is not going away any time soon. > > If you have a bunch of Shark machines for testing and would like to > port it over to device tree passing from its open firmware, you are > definitely welcome ;-) I'm too busy working on new machines :-) Old machines are an exercise in frustration, due to hardware that stops working over time and insufficient hardware resources to meet the expectations of modern software. Not to mention the financial advantages of doing work that someone cares about ... > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 19 September 2012, Matt Porter wrote: > On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote: > > On 09/19/2012 09:24 AM, Arnd Bergmann wrote: > > > On Wednesday 19 September 2012, Matt Porter wrote: > > >>> +Optional properties: > > >>> +- #dma-channels: Number of DMA channels supported by the controller. > > >>> +- #dma-requests: Number of DMA requests signals supported by the > > >>> + controller. > > >> > > >> Shouldn't these two optional properties drop the prefix #? By > > >> convention adopted from the various original OF/ePAPR/etc specs, the > > >> only properties I would expect to see with this prefix are the > > >> "*-cells" cell sizes. A quick search indicates this is the case > > >> throughout all the current bindings. > > > > > > I always assumed that the # prefix is used to indicate that we are counting > > > things instead of listing them. > > > > Lots of properties count things, but don't have a #. nr_gpios or spi > > chipselect counts for example. I'd say drop the #. > > Ok, I can drop another trivial patch since I hear Jon is on vacation. > > Yeah, I grepped all the bindings and it's only ever encountered on cell > sizes. There's not even one example of it used as above. Ok, sounds good. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/19/2012 10:24 PM, Arnd Bergmann wrote: > On Wednesday 19 September 2012, Matt Porter wrote: >>> +Optional properties: >>> +- #dma-channels: Number of DMA channels supported by the controller. >>> +- #dma-requests: Number of DMA requests signals supported by the >>> + controller. >> >> Shouldn't these two optional properties drop the prefix #? By >> convention adopted from the various original OF/ePAPR/etc specs, the >> only properties I would expect to see with this prefix are the >> "*-cells" cell sizes. A quick search indicates this is the case >> throughout all the current bindings. > > I always assumed that the # prefix is used to indicate that we are counting > things instead of listing them. Your assumption is historically correct. It seems that usage has drifted somewhat. > > Arnd > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt new file mode 100644 index 0000000..a4f59a5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -0,0 +1,81 @@ +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells: Must be at least 1. Used to provide DMA controller + specific information. See DMA client binding below for + more details. + +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. + +Example: + + dma: dma@48000000 { + compatible = "ti,omap-sdma" + reg = <0x48000000 0x1000>; + interrupts = <0 12 0x4 + 0 13 0x4 + 0 14 0x4 + 0 15 0x4>; + #dma-cells = <1>; + #dma-channels = <32>; + #dma-requests = <127>; + }; + + +* DMA client + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of + - A phandle pointing to DMA controller node + - A number of integer cells, as determined by the + #dma-cells property in the node referenced by phandle + containing DMA controller specific information. This + typically contains a DMA request line number or a + channel number, but can contain any data that is used + required for configuring a channel. +- dma-names: Contains one identifier string for each DMA specifier in + the dmas property. The specific strings that can be used + are defined in the binding of the DMA client device. + Multiple DMA specifiers can be used to represent + alternatives and in this case the dma-names for those + DMA specifiers must be identical (see examples). + +Examples: + +1. A device with one DMA read channel, one DMA write channel: + + i2c1: i2c@1 { + ... + dmas = <&dma 2 /* read channel */ + &dma 3>; /* write channel */ + dma-names = "rx", "tx" + ... + }; + +2. A single read-write channel with three alternative DMA controllers: + + dmas = <&dma1 5 + &dma2 7 + &dma3 2>; + dma-names = "rx-tx", "rx-tx", "rx-tx" + +3. A device with three channels, one of which has two alternatives: + + dmas = <&dma1 2 /* read channel */ + &dma1 3 /* write channel */ + &dma2 0 /* error read */ + &dma3 0>; /* alternative error read */ + dma-names = "rx", "tx", "error", "error"; diff --git a/drivers/of/Makefile b/drivers/of/Makefile index e027f44..eafa107 100644 --- a/drivers/of/Makefile +++ b/drivers/of/Makefile @@ -1,4 +1,4 @@ -obj-y = base.o +obj-y = base.o dma.o obj-$(CONFIG_OF_FLATTREE) += fdt.o obj-$(CONFIG_OF_PROMTREE) += pdt.o obj-$(CONFIG_OF_ADDRESS) += address.o diff --git a/drivers/of/dma.c b/drivers/of/dma.c new file mode 100644 index 0000000..19ad37c --- /dev/null +++ b/drivers/of/dma.c @@ -0,0 +1,219 @@ +/* + * Device tree helpers for DMA request / controller + * + * Based on of_gpio.c + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/device.h> +#include <linux/err.h> +#include <linux/module.h> +#include <linux/rculist.h> +#include <linux/slab.h> +#include <linux/of.h> +#include <linux/of_dma.h> + +static LIST_HEAD(of_dma_list); + +/** + * of_dma_find_controller - Find a DMA controller in DT DMA helpers list + * @np: device node of DMA controller + */ +static struct of_dma *of_dma_find_controller(struct device_node *np) +{ + struct of_dma *ofdma; + + if (list_empty(&of_dma_list)) { + pr_err("empty DMA controller list\n"); + return NULL; + } + + list_for_each_entry_rcu(ofdma, &of_dma_list, of_dma_controllers) + if (ofdma->of_node == np) + return ofdma; + + return NULL; +} + +/** + * of_dma_controller_register - Register a DMA controller to DT DMA helpers + * @np: device node of DMA controller + * @of_dma_xlate: translation function which converts a phandle + * arguments list into a dma_chan structure + * @data pointer to controller specific data to be used by + * translation function + * + * Returns 0 on success or appropriate errno value on error. + * + * Allocated memory should be freed with appropriate of_dma_controller_free() + * call. + */ +int of_dma_controller_register(struct device_node *np, + struct dma_chan *(*of_dma_xlate) + (struct of_phandle_args *, struct of_dma *), + void *data) +{ + struct of_dma *ofdma; + int nbcells; + + if (!np || !of_dma_xlate) { + pr_err("%s: not enough information provided\n", __func__); + return -EINVAL; + } + + ofdma = kzalloc(sizeof(*ofdma), GFP_KERNEL); + if (!ofdma) + return -ENOMEM; + + nbcells = be32_to_cpup(of_get_property(np, "#dma-cells", NULL)); + if (!nbcells) { + pr_err("%s: #dma-cells property is missing or invalid\n", + __func__); + return -EINVAL; + } + + ofdma->of_node = np; + ofdma->of_dma_nbcells = nbcells; + ofdma->of_dma_xlate = of_dma_xlate; + ofdma->of_dma_data = data; + + /* Now queue of_dma controller structure in list */ + list_add_tail_rcu(&ofdma->of_dma_controllers, &of_dma_list); + + return 0; +} +EXPORT_SYMBOL_GPL(of_dma_controller_register); + +/** + * of_dma_controller_free - Remove a DMA controller from DT DMA helpers list + * @np: device node of DMA controller + * + * Memory allocated by of_dma_controller_register() is freed here. + */ +void of_dma_controller_free(struct device_node *np) +{ + struct of_dma *ofdma; + + ofdma = of_dma_find_controller(np); + if (ofdma) { + list_del_rcu(&ofdma->of_dma_controllers); + kfree(ofdma); + } +} +EXPORT_SYMBOL_GPL(of_dma_controller_free); + +/** + * of_dma_find_channel - Find a DMA channel by name + * @np: device node to look for DMA channels + * @name: name of desired channel + * @dma_spec: pointer to DMA specifier as found in the device tree + * + * Find a DMA channel by the name. Returns 0 on success or appropriate + * errno value on error. + */ +static int of_dma_find_channel(struct device_node *np, char *name, + struct of_phandle_args *dma_spec) +{ + int count, i; + const char *s; + + count = of_property_count_strings(np, "dma-names"); + if (count < 0) + return count; + + for (i = 0; i < count; i++) { + if (of_property_read_string_index(np, "dma-names", i, &s)) + continue; + + if (strcmp(name, s)) + continue; + + if (!of_parse_phandle_with_args(np, "dmas", "#dma-cells", i, + dma_spec)) + return 0; + } + + return -ENODEV; +} + +/** + * of_dma_request_slave_channel - Get the DMA slave channel + * @np: device node to get DMA request from + * @name: name of desired channel + * + * Returns pointer to appropriate dma channel on success or NULL on error. + */ +struct dma_chan *of_dma_request_slave_channel(struct device_node *np, + char *name) +{ + struct of_phandle_args dma_spec; + struct of_dma *ofdma; + struct dma_chan *chan; + int r; + + if (!np || !name) { + pr_err("%s: not enough information provided\n", __func__); + return NULL; + } + + do { + r = of_dma_find_channel(np, name, &dma_spec); + if (r) { + pr_err("%s: can't find DMA channel\n", np->full_name); + return NULL; + } + + ofdma = of_dma_find_controller(dma_spec.np); + if (!ofdma) { + pr_debug("%s: can't find DMA controller %s\n", + np->full_name, dma_spec.np->full_name); + continue; + } + + if (dma_spec.args_count != ofdma->of_dma_nbcells) { + pr_debug("%s: wrong #dma-cells for %s\n", np->full_name, + dma_spec.np->full_name); + continue; + } + + chan = ofdma->of_dma_xlate(&dma_spec, ofdma); + + of_node_put(dma_spec.np); + + } while (!chan); + + return chan; +} + +/** + * of_dma_simple_xlate - Simple DMA engine translation function + * @dma_spec: pointer to DMA specifier as found in the device tree + * @of_dma: pointer to DMA controller data + * + * A simple translation function for devices that use a 32-bit value for the + * filter_param when calling the DMA engine dma_request_channel() function. + * Note that this translation function requires that #dma-cells is equal to 1 + * and the argument of the dma specifier is the 32-bit filter_param. Returns + * pointer to appropriate dma channel on success or NULL on error. + */ +struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, + struct of_dma *ofdma) +{ + int count = dma_spec->args_count; + struct of_dma_filter_info *info = ofdma->of_dma_data; + + if (!info || !info->filter_fn) + return NULL; + + if (count != 1) + return NULL; + + return dma_request_channel(info->dma_cap, info->filter_fn, + &dma_spec->args[0]); +} +EXPORT_SYMBOL_GPL(of_dma_simple_xlate); diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h new file mode 100644 index 0000000..337823d --- /dev/null +++ b/include/linux/of_dma.h @@ -0,0 +1,45 @@ +/* + * OF helpers for DMA request / controller + * + * Based on of_gpio.h + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __LINUX_OF_DMA_H +#define __LINUX_OF_DMA_H + +#include <linux/of.h> +#include <linux/dmaengine.h> + +struct device_node; + +struct of_dma { + struct list_head of_dma_controllers; + struct device_node *of_node; + int of_dma_nbcells; + struct dma_chan *(*of_dma_xlate) + (struct of_phandle_args *, struct of_dma *); + void *of_dma_data; +}; + +struct of_dma_filter_info { + dma_cap_mask_t dma_cap; + dma_filter_fn filter_fn; +}; + +extern int of_dma_controller_register(struct device_node *np, + struct dma_chan *(*of_dma_xlate) + (struct of_phandle_args *, struct of_dma *), + void *data); +extern void of_dma_controller_free(struct device_node *np); +extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np, + char *name); +extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, + struct of_dma *ofdma); + +#endif /* __LINUX_OF_DMA_H */