* [PATCH v2 4/8] dmaengine: rcar-dmac: Add device tree bindings documentation
2014-07-18 23:50 [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Laurent Pinchart
@ 2014-07-18 23:50 ` Laurent Pinchart
2014-07-23 0:35 ` [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Simon Horman
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Laurent Pinchart @ 2014-07-18 23:50 UTC (permalink / raw)
To: linux-sh; +Cc: dmaengine, Kuninori Morimoto, devicetree
Document the device tree bindings for the R-Car Generation 2 DMA
Controller (DMAC).
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
Changes since v1:
- Remove ch15 from interrupt names
---
.../devicetree/bindings/dma/renesas,rcar-dmac.txt | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
new file mode 100644
index 0000000..df0f48b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -0,0 +1,98 @@
+* Renesas R-Car DMA Controller Device Tree bindings
+
+Renesas R-Car Generation 2 SoCs have have multiple multi-channel DMA
+controller instances named DMAC capable of serving multiple clients. Channels
+can be dedicated to specific clients or shared between a large number of
+clients.
+
+DMA clients are connected to the DMAC ports referenced by an 8-bit identifier
+called MID/RID.
+
+Each DMA client is connected to one dedicated port of the DMAC, identified by
+an 8-bit port number called the MID/RID. A DMA controller can thus serve up to
+256 clients in total. When the number of hardware channels is lower than the
+number of clients to be served, channels must be shared between multiple DMA
+clients. The association of DMA clients to DMAC channels is fully dynamic and
+not described in these device tree bindings.
+
+Required Properties:
+
+- compatible: must contain "renesas,rcar-dmac"
+
+- reg: base address and length of the registers block for the DMAC
+
+- interrupts: interrupt specifiers for the DMAC, one for each entry in
+ interrupt-names.
+- interrupt-names: one entry per channel, named "ch%u", where %u is the
+ channel number ranging from zero to the number of channels minus one.
+
+- clock-names: "fck" for the functional clock
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+ in clock-names.
+- clock-names: must contain "fck" for the functional clock.
+
+- #dma-cells: must be <1>, the cell specifies the MID/RID of the DMAC port
+ connected to the DMA client
+- dma-channels: number of DMA channels
+
+Example: R8A7790 (R-Car H2) SYS-DMACs
+
+ dmac0: dma-controller@e6700000 {
+ compatible = "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
+ 0 200 IRQ_TYPE_LEVEL_HIGH
+ 0 201 IRQ_TYPE_LEVEL_HIGH
+ 0 202 IRQ_TYPE_LEVEL_HIGH
+ 0 203 IRQ_TYPE_LEVEL_HIGH
+ 0 204 IRQ_TYPE_LEVEL_HIGH
+ 0 205 IRQ_TYPE_LEVEL_HIGH
+ 0 206 IRQ_TYPE_LEVEL_HIGH
+ 0 207 IRQ_TYPE_LEVEL_HIGH
+ 0 208 IRQ_TYPE_LEVEL_HIGH
+ 0 209 IRQ_TYPE_LEVEL_HIGH
+ 0 210 IRQ_TYPE_LEVEL_HIGH
+ 0 211 IRQ_TYPE_LEVEL_HIGH
+ 0 212 IRQ_TYPE_LEVEL_HIGH
+ 0 213 IRQ_TYPE_LEVEL_HIGH
+ 0 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC0>;
+ clock-names = "fck";
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller@e6720000 {
+ compatible = "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
+ 0 216 IRQ_TYPE_LEVEL_HIGH
+ 0 217 IRQ_TYPE_LEVEL_HIGH
+ 0 218 IRQ_TYPE_LEVEL_HIGH
+ 0 219 IRQ_TYPE_LEVEL_HIGH
+ 0 308 IRQ_TYPE_LEVEL_HIGH
+ 0 309 IRQ_TYPE_LEVEL_HIGH
+ 0 310 IRQ_TYPE_LEVEL_HIGH
+ 0 311 IRQ_TYPE_LEVEL_HIGH
+ 0 312 IRQ_TYPE_LEVEL_HIGH
+ 0 313 IRQ_TYPE_LEVEL_HIGH
+ 0 314 IRQ_TYPE_LEVEL_HIGH
+ 0 315 IRQ_TYPE_LEVEL_HIGH
+ 0 316 IRQ_TYPE_LEVEL_HIGH
+ 0 317 IRQ_TYPE_LEVEL_HIGH
+ 0 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC1>;
+ clock-names = "fck";
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
--
1.8.5.5
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH v2 0/8] R-Car Gen2 DMA Controller driver
2014-07-18 23:50 [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Laurent Pinchart
2014-07-18 23:50 ` [PATCH v2 4/8] dmaengine: rcar-dmac: Add device tree bindings documentation Laurent Pinchart
@ 2014-07-23 0:35 ` Simon Horman
2014-07-23 8:47 ` Laurent Pinchart
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Simon Horman @ 2014-07-23 0:35 UTC (permalink / raw)
To: linux-sh
On Sat, Jul 19, 2014 at 01:50:17AM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch sets adds a new driver for the DMA controller found in the R-Car
> Gen2 SoCs under the name "Direct Memory Access Controller for System
> (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
> (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)" will
> be added later.
>
> For the rationale of why a new driver is needed, and performance figures,
> please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
> driver") [1].
>
> Support for hardware descriptors lists is under development and will be posted
> in the near future. No change to the DT bindings will be needed.
>
> The first five patches should go through the DMA engine tree, while the last
> three patches should go through the Renesas tree. If the driver can make it to
> v3.17 merging the platform changes will be easier.
>
> Morimoto-san, could you please test if this version fixes the channel filter
> issue you've experienced with the R-Car audio driver ? I would also appreciate
> if you could tell me how to test cyclic DMA transfers using the audio driver.
>
> Changes since v1:
>
> - Allocate IRQ name strings dynamically
> - Only call the callback function if one is supplied
> - Don't overallocate sg list entries
> - Allocate sg list entries with GFP_KERNEL
> - Don't manage function clock manually
> - Make channel filter ignore unrelated devices
> - Document why the cyclic sg list is kcalloc'ed
> - Remove ch15 from interrupt names in DT
> - Replace CONFIG_OF with OF in Kconfig
>
> [1] http://www.spinics.net/lists/linux-sh/msg33768.html
>
> Laurent Pinchart (8):
> dmaengine: sh: Rework Kconfig and Makefile
> dmaengine: shdma: Make channel filter ignore unrelated devices
> dmaengine: shdma: Allocate cyclic sg list dynamically
> dmaengine: rcar-dmac: Add device tree bindings documentation
> dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> driver
I have queued up the above three patches in the shdma-for-v3.17 branch
of the renesas tree. I intend to send a pull-request for them once they
have sat in next.
> ARM: shmobile: r8a7790: Add DMAC clocks to DT
> ARM: shmobile: r8a7790: Add DMAC devices to DT
> ARM: shmobile: r8a7791: Add DMAC devices to DT
I am holding off on the above patches as there is still some chance
the dmaengine subsystem maintainer may reject the new binding introduced
by the 4th patch of this series.
Could you repost them once he has accepted my as-yet-unsent pull-request.
Thanks
>
> .../devicetree/bindings/dma/renesas,rcar-dmac.txt | 98 ++
> arch/arm/boot/dts/r8a7790.dtsi | 66 +-
> arch/arm/boot/dts/r8a7791.dtsi | 60 +
> drivers/dma/sh/Kconfig | 30 +-
> drivers/dma/sh/Makefile | 15 +-
> drivers/dma/sh/rcar-dmac.c | 1525 ++++++++++++++++++++
> drivers/dma/sh/shdma-base.c | 101 +-
> 7 files changed, 1845 insertions(+), 50 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> create mode 100644 drivers/dma/sh/rcar-dmac.c
>
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH v2 0/8] R-Car Gen2 DMA Controller driver
2014-07-18 23:50 [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Laurent Pinchart
2014-07-18 23:50 ` [PATCH v2 4/8] dmaengine: rcar-dmac: Add device tree bindings documentation Laurent Pinchart
2014-07-23 0:35 ` [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Simon Horman
@ 2014-07-23 8:47 ` Laurent Pinchart
2014-07-23 10:34 ` Simon Horman
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Laurent Pinchart @ 2014-07-23 8:47 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Wednesday 23 July 2014 09:35:33 Simon Horman wrote:
> On Sat, Jul 19, 2014 at 01:50:17AM +0200, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch sets adds a new driver for the DMA controller found in the
> > R-Car Gen2 SoCs under the name "Direct Memory Access Controller for System
> > (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
> > (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)"
> > will be added later.
> >
> > For the rationale of why a new driver is needed, and performance figures,
> > please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
> > driver") [1].
> >
> > Support for hardware descriptors lists is under development and will be
> > posted in the near future. No change to the DT bindings will be needed.
> >
> > The first five patches should go through the DMA engine tree, while the
> > last three patches should go through the Renesas tree. If the driver can
> > make it to v3.17 merging the platform changes will be easier.
> >
> > Morimoto-san, could you please test if this version fixes the channel
> > filter issue you've experienced with the R-Car audio driver ? I would
> > also appreciate if you could tell me how to test cyclic DMA transfers
> > using the audio driver.
> >
> > Changes since v1:
> >
> > - Allocate IRQ name strings dynamically
> > - Only call the callback function if one is supplied
> > - Don't overallocate sg list entries
> > - Allocate sg list entries with GFP_KERNEL
> > - Don't manage function clock manually
> > - Make channel filter ignore unrelated devices
> > - Document why the cyclic sg list is kcalloc'ed
> > - Remove ch15 from interrupt names in DT
> > - Replace CONFIG_OF with OF in Kconfig
> >
> > [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> >
> > Laurent Pinchart (8):
> > dmaengine: sh: Rework Kconfig and Makefile
> > dmaengine: shdma: Make channel filter ignore unrelated devices
> > dmaengine: shdma: Allocate cyclic sg list dynamically
> > dmaengine: rcar-dmac: Add device tree bindings documentation
> > dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> > driver
>
> I have queued up the above three patches in the shdma-for-v3.17 branch
> of the renesas tree.
I suppose you meant five, not three.
> I intend to send a pull-request for them once they have sat in next.
I was waiting for acks before sending the pull request, but that's fine. Who
will you send the pull request to, the dmaengine maintainer ?
> > ARM: shmobile: r8a7790: Add DMAC clocks to DT
> > ARM: shmobile: r8a7790: Add DMAC devices to DT
> > ARM: shmobile: r8a7791: Add DMAC devices to DT
>
> I am holding off on the above patches as there is still some chance
> the dmaengine subsystem maintainer may reject the new binding introduced
> by the 4th patch of this series.
>
> Could you repost them once he has accepted my as-yet-unsent pull-request.
Sure. You could already apply "ARM: shmobile: r8a7790: Add DMAC clocks to DT"
as that's independent from the DMAC DT bindings, but that's up to you.
> > .../devicetree/bindings/dma/renesas,rcar-dmac.txt | 98 ++
> > arch/arm/boot/dts/r8a7790.dtsi | 66 +-
> > arch/arm/boot/dts/r8a7791.dtsi | 60 +
> > drivers/dma/sh/Kconfig | 30 +-
> > drivers/dma/sh/Makefile | 15 +-
> > drivers/dma/sh/rcar-dmac.c | 1525 +++++++++++++++
> > drivers/dma/sh/shdma-base.c | 101 +-
> > 7 files changed, 1845 insertions(+), 50 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt create mode
> > 100644 drivers/dma/sh/rcar-dmac.c
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH v2 0/8] R-Car Gen2 DMA Controller driver
2014-07-18 23:50 [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Laurent Pinchart
` (2 preceding siblings ...)
2014-07-23 8:47 ` Laurent Pinchart
@ 2014-07-23 10:34 ` Simon Horman
2014-07-23 10:39 ` Laurent Pinchart
2014-07-23 13:12 ` Simon Horman
5 siblings, 0 replies; 7+ messages in thread
From: Simon Horman @ 2014-07-23 10:34 UTC (permalink / raw)
To: linux-sh
On Wed, Jul 23, 2014 at 10:47:11AM +0200, Laurent Pinchart wrote:
> Hi Simon,
>
> On Wednesday 23 July 2014 09:35:33 Simon Horman wrote:
> > On Sat, Jul 19, 2014 at 01:50:17AM +0200, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > This patch sets adds a new driver for the DMA controller found in the
> > > R-Car Gen2 SoCs under the name "Direct Memory Access Controller for System
> > > (SYS-DMAC)". Support for the "Realtime Direct Memory Access Controller
> > > (RT-DMAC)" and "Direct Memory Access Controller for Audio (Audio-DMAC)"
> > > will be added later.
> > >
> > > For the rationale of why a new driver is needed, and performance figures,
> > > please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2 DMA Controller
> > > driver") [1].
> > >
> > > Support for hardware descriptors lists is under development and will be
> > > posted in the near future. No change to the DT bindings will be needed.
> > >
> > > The first five patches should go through the DMA engine tree, while the
> > > last three patches should go through the Renesas tree. If the driver can
> > > make it to v3.17 merging the platform changes will be easier.
> > >
> > > Morimoto-san, could you please test if this version fixes the channel
> > > filter issue you've experienced with the R-Car audio driver ? I would
> > > also appreciate if you could tell me how to test cyclic DMA transfers
> > > using the audio driver.
> > >
> > > Changes since v1:
> > >
> > > - Allocate IRQ name strings dynamically
> > > - Only call the callback function if one is supplied
> > > - Don't overallocate sg list entries
> > > - Allocate sg list entries with GFP_KERNEL
> > > - Don't manage function clock manually
> > > - Make channel filter ignore unrelated devices
> > > - Document why the cyclic sg list is kcalloc'ed
> > > - Remove ch15 from interrupt names in DT
> > > - Replace CONFIG_OF with OF in Kconfig
> > >
> > > [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> > >
> > > Laurent Pinchart (8):
> > > dmaengine: sh: Rework Kconfig and Makefile
> > > dmaengine: shdma: Make channel filter ignore unrelated devices
> > > dmaengine: shdma: Allocate cyclic sg list dynamically
> > > dmaengine: rcar-dmac: Add device tree bindings documentation
> > > dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> > > driver
> >
> > I have queued up the above three patches in the shdma-for-v3.17 branch
> > of the renesas tree.
>
> I suppose you meant five, not three.
There were three, then I decided to take the next two too.
> > I intend to send a pull-request for them once they have sat in next.
>
> I was waiting for acks before sending the pull request, but that's fine. Who
> will you send the pull request to, the dmaengine maintainer ?
Yes, I was planning to send a pull-request to Vinod.
I have already sent two recently, one of which was even accepted.
Of course If you want to handle things then I'm happy to discuss that.
My main aim is too try to streamline things for Vinod. And if I'm not
achieving that then we need to talk :)
> > > ARM: shmobile: r8a7790: Add DMAC clocks to DT
> > > ARM: shmobile: r8a7790: Add DMAC devices to DT
> > > ARM: shmobile: r8a7791: Add DMAC devices to DT
> >
> > I am holding off on the above patches as there is still some chance
> > the dmaengine subsystem maintainer may reject the new binding introduced
> > by the 4th patch of this series.
> >
> > Could you repost them once he has accepted my as-yet-unsent pull-request.
>
> Sure. You could already apply "ARM: shmobile: r8a7790: Add DMAC clocks to DT"
> as that's independent from the DMAC DT bindings, but that's up to you.
Yes, I realise that. But its also not very exciting without the rest of the
series, so I think that I prefer to wait. If that creates a headache for
you then I'm happy to reconsider.
> > > .../devicetree/bindings/dma/renesas,rcar-dmac.txt | 98 ++
> > > arch/arm/boot/dts/r8a7790.dtsi | 66 +-
> > > arch/arm/boot/dts/r8a7791.dtsi | 60 +
> > > drivers/dma/sh/Kconfig | 30 +-
> > > drivers/dma/sh/Makefile | 15 +-
> > > drivers/dma/sh/rcar-dmac.c | 1525 +++++++++++++++
> > > drivers/dma/sh/shdma-base.c | 101 +-
> > > 7 files changed, 1845 insertions(+), 50 deletions(-)
> > > create mode 100644
> > > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt create mode
> > > 100644 drivers/dma/sh/rcar-dmac.c
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH v2 0/8] R-Car Gen2 DMA Controller driver
2014-07-18 23:50 [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Laurent Pinchart
` (3 preceding siblings ...)
2014-07-23 10:34 ` Simon Horman
@ 2014-07-23 10:39 ` Laurent Pinchart
2014-07-23 13:12 ` Simon Horman
5 siblings, 0 replies; 7+ messages in thread
From: Laurent Pinchart @ 2014-07-23 10:39 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Wednesday 23 July 2014 19:34:28 Simon Horman wrote:
> On Wed, Jul 23, 2014 at 10:47:11AM +0200, Laurent Pinchart wrote:
> > On Wednesday 23 July 2014 09:35:33 Simon Horman wrote:
> >> On Sat, Jul 19, 2014 at 01:50:17AM +0200, Laurent Pinchart wrote:
> >>> Hello,
> >>>
> >>> This patch sets adds a new driver for the DMA controller found in the
> >>> R-Car Gen2 SoCs under the name "Direct Memory Access Controller for
> >>> System (SYS-DMAC)". Support for the "Realtime Direct Memory Access
> >>> Controller (RT-DMAC)" and "Direct Memory Access Controller for Audio
> >>> (Audio-DMAC)" will be added later.
> >>>
> >>> For the rationale of why a new driver is needed, and performance
> >>> figures, please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2
> >>> DMA Controller driver") [1].
> >>>
> >>> Support for hardware descriptors lists is under development and will
> >>> be posted in the near future. No change to the DT bindings will be
> >>> needed.
> >>>
> >>> The first five patches should go through the DMA engine tree, while
> >>> the last three patches should go through the Renesas tree. If the
> >>> driver can make it to v3.17 merging the platform changes will be
> >>> easier.
> >>>
> >>> Morimoto-san, could you please test if this version fixes the channel
> >>> filter issue you've experienced with the R-Car audio driver ? I would
> >>> also appreciate if you could tell me how to test cyclic DMA transfers
> >>> using the audio driver.
> >>>
> >>> Changes since v1:
> >>>
> >>> - Allocate IRQ name strings dynamically
> >>> - Only call the callback function if one is supplied
> >>> - Don't overallocate sg list entries
> >>> - Allocate sg list entries with GFP_KERNEL
> >>> - Don't manage function clock manually
> >>> - Make channel filter ignore unrelated devices
> >>> - Document why the cyclic sg list is kcalloc'ed
> >>> - Remove ch15 from interrupt names in DT
> >>> - Replace CONFIG_OF with OF in Kconfig
> >>>
> >>> [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> >>>
> >>> Laurent Pinchart (8):
> >>> dmaengine: sh: Rework Kconfig and Makefile
> >>> dmaengine: shdma: Make channel filter ignore unrelated devices
> >>> dmaengine: shdma: Allocate cyclic sg list dynamically
> >>> dmaengine: rcar-dmac: Add device tree bindings documentation
> >>> dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> >>> driver
> >>
> >> I have queued up the above three patches in the shdma-for-v3.17 branch
> >> of the renesas tree.
> >
> > I suppose you meant five, not three.
>
> There were three, then I decided to take the next two too.
>
> > > I intend to send a pull-request for them once they have sat in next.
> >
> > I was waiting for acks before sending the pull request, but that's fine.
> > Who will you send the pull request to, the dmaengine maintainer ?
>
> Yes, I was planning to send a pull-request to Vinod.
> I have already sent two recently, one of which was even accepted.
>
> Of course If you want to handle things then I'm happy to discuss that.
> My main aim is too try to streamline things for Vinod. And if I'm not
> achieving that then we need to talk :)
Your help is appreciated. I'm totally fine with you sending a pull request.
The only issue I can think of with this unsynchronized process would be pull
requests being sent too soon when the driver isn't ready yet. In this specific
case I consider the driver as ready (even if it's obviously not perfect, more
patches will come soon), so we can proceed.
> >>> ARM: shmobile: r8a7790: Add DMAC clocks to DT
> >>> ARM: shmobile: r8a7790: Add DMAC devices to DT
> >>> ARM: shmobile: r8a7791: Add DMAC devices to DT
> >>
> >> I am holding off on the above patches as there is still some chance
> >> the dmaengine subsystem maintainer may reject the new binding introduced
> >> by the 4th patch of this series.
> >>
> >> Could you repost them once he has accepted my as-yet-unsent
> >> pull-request.
> >
> > Sure. You could already apply "ARM: shmobile: r8a7790: Add DMAC clocks to
> > DT" as that's independent from the DMAC DT bindings, but that's up to
> > you.
>
> Yes, I realise that. But its also not very exciting without the rest of the
> series, so I think that I prefer to wait. If that creates a headache for
> you then I'm happy to reconsider.
That's fine with me.
> >>> .../devicetree/bindings/dma/renesas,rcar-dmac.txt | 98 ++
> >>> arch/arm/boot/dts/r8a7790.dtsi | 66 +-
> >>> arch/arm/boot/dts/r8a7791.dtsi | 60 +
> >>> drivers/dma/sh/Kconfig | 30 +-
> >>> drivers/dma/sh/Makefile | 15 +-
> >>> drivers/dma/sh/rcar-dmac.c | 1525 +++++++++++++
> >>> drivers/dma/sh/shdma-base.c | 101 +-
> >>> 7 files changed, 1845 insertions(+), 50 deletions(-)
> >>> create mode 100644
> >>> Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> >>> create mode 100644 drivers/dma/sh/rcar-dmac.c
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH v2 0/8] R-Car Gen2 DMA Controller driver
2014-07-18 23:50 [PATCH v2 0/8] R-Car Gen2 DMA Controller driver Laurent Pinchart
` (4 preceding siblings ...)
2014-07-23 10:39 ` Laurent Pinchart
@ 2014-07-23 13:12 ` Simon Horman
5 siblings, 0 replies; 7+ messages in thread
From: Simon Horman @ 2014-07-23 13:12 UTC (permalink / raw)
To: linux-sh
On Wed, Jul 23, 2014 at 12:39:42PM +0200, Laurent Pinchart wrote:
> Hi Simon,
>
> On Wednesday 23 July 2014 19:34:28 Simon Horman wrote:
> > On Wed, Jul 23, 2014 at 10:47:11AM +0200, Laurent Pinchart wrote:
> > > On Wednesday 23 July 2014 09:35:33 Simon Horman wrote:
> > >> On Sat, Jul 19, 2014 at 01:50:17AM +0200, Laurent Pinchart wrote:
> > >>> Hello,
> > >>>
> > >>> This patch sets adds a new driver for the DMA controller found in the
> > >>> R-Car Gen2 SoCs under the name "Direct Memory Access Controller for
> > >>> System (SYS-DMAC)". Support for the "Realtime Direct Memory Access
> > >>> Controller (RT-DMAC)" and "Direct Memory Access Controller for Audio
> > >>> (Audio-DMAC)" will be added later.
> > >>>
> > >>> For the rationale of why a new driver is needed, and performance
> > >>> figures, please see the cover letter of v1 ("[PATCH 0/7] R-Car Gen2
> > >>> DMA Controller driver") [1].
> > >>>
> > >>> Support for hardware descriptors lists is under development and will
> > >>> be posted in the near future. No change to the DT bindings will be
> > >>> needed.
> > >>>
> > >>> The first five patches should go through the DMA engine tree, while
> > >>> the last three patches should go through the Renesas tree. If the
> > >>> driver can make it to v3.17 merging the platform changes will be
> > >>> easier.
> > >>>
> > >>> Morimoto-san, could you please test if this version fixes the channel
> > >>> filter issue you've experienced with the R-Car audio driver ? I would
> > >>> also appreciate if you could tell me how to test cyclic DMA transfers
> > >>> using the audio driver.
> > >>>
> > >>> Changes since v1:
> > >>>
> > >>> - Allocate IRQ name strings dynamically
> > >>> - Only call the callback function if one is supplied
> > >>> - Don't overallocate sg list entries
> > >>> - Allocate sg list entries with GFP_KERNEL
> > >>> - Don't manage function clock manually
> > >>> - Make channel filter ignore unrelated devices
> > >>> - Document why the cyclic sg list is kcalloc'ed
> > >>> - Remove ch15 from interrupt names in DT
> > >>> - Replace CONFIG_OF with OF in Kconfig
> > >>>
> > >>> [1] http://www.spinics.net/lists/linux-sh/msg33768.html
> > >>>
> > >>> Laurent Pinchart (8):
> > >>> dmaengine: sh: Rework Kconfig and Makefile
> > >>> dmaengine: shdma: Make channel filter ignore unrelated devices
> > >>> dmaengine: shdma: Allocate cyclic sg list dynamically
> > >>> dmaengine: rcar-dmac: Add device tree bindings documentation
> > >>> dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC)
> > >>> driver
> > >>
> > >> I have queued up the above three patches in the shdma-for-v3.17 branch
> > >> of the renesas tree.
> > >
> > > I suppose you meant five, not three.
> >
> > There were three, then I decided to take the next two too.
> >
> > > > I intend to send a pull-request for them once they have sat in next.
> > >
> > > I was waiting for acks before sending the pull request, but that's fine.
> > > Who will you send the pull request to, the dmaengine maintainer ?
> >
> > Yes, I was planning to send a pull-request to Vinod.
> > I have already sent two recently, one of which was even accepted.
> >
> > Of course If you want to handle things then I'm happy to discuss that.
> > My main aim is too try to streamline things for Vinod. And if I'm not
> > achieving that then we need to talk :)
>
> Your help is appreciated. I'm totally fine with you sending a pull request.
> The only issue I can think of with this unsynchronized process would be pull
> requests being sent too soon when the driver isn't ready yet. In this specific
> case I consider the driver as ready (even if it's obviously not perfect, more
> patches will come soon), so we can proceed.
Thanks, sorry for being a little hasty there.
I'll try and co-ordinate things better next time.
> > >>> ARM: shmobile: r8a7790: Add DMAC clocks to DT
> > >>> ARM: shmobile: r8a7790: Add DMAC devices to DT
> > >>> ARM: shmobile: r8a7791: Add DMAC devices to DT
> > >>
> > >> I am holding off on the above patches as there is still some chance
> > >> the dmaengine subsystem maintainer may reject the new binding introduced
> > >> by the 4th patch of this series.
> > >>
> > >> Could you repost them once he has accepted my as-yet-unsent
> > >> pull-request.
> > >
> > > Sure. You could already apply "ARM: shmobile: r8a7790: Add DMAC clocks to
> > > DT" as that's independent from the DMAC DT bindings, but that's up to
> > > you.
> >
> > Yes, I realise that. But its also not very exciting without the rest of the
> > series, so I think that I prefer to wait. If that creates a headache for
> > you then I'm happy to reconsider.
>
> That's fine with me.
>
> > >>> .../devicetree/bindings/dma/renesas,rcar-dmac.txt | 98 ++
> > >>> arch/arm/boot/dts/r8a7790.dtsi | 66 +-
> > >>> arch/arm/boot/dts/r8a7791.dtsi | 60 +
> > >>> drivers/dma/sh/Kconfig | 30 +-
> > >>> drivers/dma/sh/Makefile | 15 +-
> > >>> drivers/dma/sh/rcar-dmac.c | 1525 +++++++++++++
> > >>> drivers/dma/sh/shdma-base.c | 101 +-
> > >>> 7 files changed, 1845 insertions(+), 50 deletions(-)
> > >>> create mode 100644
> > >>> Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > >>> create mode 100644 drivers/dma/sh/rcar-dmac.c
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply [flat|nested] 7+ messages in thread