From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 29 Jan 2013 14:55:49 +0000 Subject: [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding In-Reply-To: <20130129142434.GW23505@n2100.arm.linux.org.uk> References: <1359395857-1235-1-git-send-email-arnd@arndb.de> <201301291344.11066.arnd@arndb.de> <20130129142434.GW23505@n2100.arm.linux.org.uk> Message-ID: <201301291455.49347.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 29 January 2013, Russell King - ARM Linux wrote: > No, that's not what I mean. I mean the situation we find on Versatile > platforms: > > 8 3 >3 > PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals} > | 5 > `--/------> {On-CPU peripherals} > > This is something that I've been raising _every time_ I've been involved > with DMA engine discussions when it comes to the matching stuff, so this > is nothing new, and it's not unknown about. Ok, I see. I have not actually been involved with the DMA engine API much, so for me it's the first time /I/ see this being explained. >>From the DT binding perspective, doing this should be no problem. I guess you would model the MUX as a trivial dma engine device that forwards to another one, just like we do for nested interrupt controllers: pl080: dma-engine at 10000000 { compatible ="arm,pl080", "arm,primecell"; reg = <0x10000000 0x1000>; dma-requests = <8>; dma-channels = <4>; #dma-cells = <2>; }; fpga { mux: dma-mux at f0008000 { reg = <0xf0008000 100>; compatible = "arm,versatile-fpga-dmamux"; dma-requests = <7>; dma-channels = <3>; #dma-cells = <1>; dmas = <&pl080 5 0>, <&pl080 6 0> <&pl080 7 0>; dma-names = "mux5", "mux6", "mux7"; }; ... some-device at f000a000 { compatible = "foo,using-muxed-dma"; dmas = <&mux 3>, <&mux 4>; dma-names = "rx", "tx"; }; }; The driver for foo,using-muxed-dma just requests a slave channel for its lines, which ends up calling the xlate function of the driver for the mux. That driver still needs to get written, of course, but it should be able to recursively call dma_request_slave_channel on the pl080 device. The arm,versatile-fpga-dmamux driver would not be registered to the dmaengine layer, but it would register as an of_dma_controller. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding Date: Tue, 29 Jan 2013 14:55:49 +0000 Message-ID: <201301291455.49347.arnd@arndb.de> References: <1359395857-1235-1-git-send-email-arnd@arndb.de> <201301291344.11066.arnd@arndb.de> <20130129142434.GW23505@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130129142434.GW23505-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Russell King - ARM Linux Cc: Vinod Koul , Viresh Kumar , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, spear-devel , Andy Shevchenko , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Tuesday 29 January 2013, Russell King - ARM Linux wrote: > No, that's not what I mean. I mean the situation we find on Versatile > platforms: > > 8 3 >3 > PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals} > | 5 > `--/------> {On-CPU peripherals} > > This is something that I've been raising _every time_ I've been involved > with DMA engine discussions when it comes to the matching stuff, so this > is nothing new, and it's not unknown about. Ok, I see. I have not actually been involved with the DMA engine API much, so for me it's the first time /I/ see this being explained. >>From the DT binding perspective, doing this should be no problem. I guess you would model the MUX as a trivial dma engine device that forwards to another one, just like we do for nested interrupt controllers: pl080: dma-engine@10000000 { compatible ="arm,pl080", "arm,primecell"; reg = <0x10000000 0x1000>; dma-requests = <8>; dma-channels = <4>; #dma-cells = <2>; }; fpga { mux: dma-mux@f0008000 { reg = <0xf0008000 100>; compatible = "arm,versatile-fpga-dmamux"; dma-requests = <7>; dma-channels = <3>; #dma-cells = <1>; dmas = <&pl080 5 0>, <&pl080 6 0> <&pl080 7 0>; dma-names = "mux5", "mux6", "mux7"; }; ... some-device@f000a000 { compatible = "foo,using-muxed-dma"; dmas = <&mux 3>, <&mux 4>; dma-names = "rx", "tx"; }; }; The driver for foo,using-muxed-dma just requests a slave channel for its lines, which ends up calling the xlate function of the driver for the mux. That driver still needs to get written, of course, but it should be able to recursively call dma_request_slave_channel on the pl080 device. The arm,versatile-fpga-dmamux driver would not be registered to the dmaengine layer, but it would register as an of_dma_controller. Arnd