| Message ID | cover.1415755881.git.horms+renesas@verge.net.au |
|---|---|
| State | New |
| Headers | show |
On Thursday 13 November 2014 10:19:59 Simon Horman wrote: > "mem_src6", "src6_mem", > "mem_src7", "src7_mem", > "mem_src8", "src8_mem", > - "mem_src9", "src9_mem"; > + "mem_src9", "src9_mem", > + > + "src0_ssiu0", "src1_ssiu0", "src2_ssiu0", "src3_ssiu0", "src4_ssiu0", > + "src0_ssiu1", "src1_ssiu1", "src2_ssiu1", "src3_ssiu1", "src4_ssiu1", > + "src0_ssiu2", "src1_ssiu2", "src2_ssiu2", "src3_ssiu2", "src4_ssiu2", > I have to note that this looks rather weird and that none of the names are documented in the binding. Can you explain why this device uses over 100 DMA channels and put the exact naming rules into the binding? Do you expect all channels to be in use simultaneously? Arnd
Hi Arnd > > "mem_src6", "src6_mem", > > "mem_src7", "src7_mem", > > "mem_src8", "src8_mem", > > - "mem_src9", "src9_mem"; > > + "mem_src9", "src9_mem", > > + > > + "src0_ssiu0", "src1_ssiu0", "src2_ssiu0", "src3_ssiu0", "src4_ssiu0", > > + "src0_ssiu1", "src1_ssiu1", "src2_ssiu1", "src3_ssiu1", "src4_ssiu1", > > + "src0_ssiu2", "src1_ssiu2", "src2_ssiu2", "src3_ssiu2", "src4_ssiu2", > > > > I have to note that this looks rather weird and that none of the names > are documented in the binding. > > Can you explain why this device uses over 100 DMA channels and put the > exact naming rules into the binding? > Do you expect all channels to be in use simultaneously? This device has 10 sound channels, and using 3 kind of IPs. Then, data input/output needs DMA channel which needs specific ID to using. Above name has ID pair for it, so there is much combination. These specific ID is based on SoC, not board. Sound driver / DMAEngine can get specific ID from above. Indeed binding itself was not documented yet. I will add it ASAP.
On Tue, Nov 18, 2014 at 12:03:50AM +0000, Kuninori Morimoto wrote: > > Hi Arnd > > > > "mem_src6", "src6_mem", > > > "mem_src7", "src7_mem", > > > "mem_src8", "src8_mem", > > > - "mem_src9", "src9_mem"; > > > + "mem_src9", "src9_mem", > > > + > > > + "src0_ssiu0", "src1_ssiu0", "src2_ssiu0", "src3_ssiu0", "src4_ssiu0", > > > + "src0_ssiu1", "src1_ssiu1", "src2_ssiu1", "src3_ssiu1", "src4_ssiu1", > > > + "src0_ssiu2", "src1_ssiu2", "src2_ssiu2", "src3_ssiu2", "src4_ssiu2", > > > > > > > I have to note that this looks rather weird and that none of the names > > are documented in the binding. > > > > Can you explain why this device uses over 100 DMA channels and put the > > exact naming rules into the binding? > > Do you expect all channels to be in use simultaneously? > > This device has 10 sound channels, and using 3 kind of IPs. > Then, data input/output needs DMA channel which needs specific ID to using. > Above name has ID pair for it, so there is much combination. > These specific ID is based on SoC, not board. > Sound driver / DMAEngine can get specific ID from above. > > Indeed binding itself was not documented yet. > I will add it ASAP. Hi Arnd, please let me know if a revised pull-request is in order. v3.18-rc6 is getting awfully close.
On Tuesday 18 November 2014 00:03:50 Kuninori Morimoto wrote: > Hi Arnd > > > > "mem_src6", "src6_mem", > > > "mem_src7", "src7_mem", > > > "mem_src8", "src8_mem", > > > - "mem_src9", "src9_mem"; > > > + "mem_src9", "src9_mem", > > > + > > > + "src0_ssiu0", "src1_ssiu0", "src2_ssiu0", "src3_ssiu0", "src4_ssiu0", > > > + "src0_ssiu1", "src1_ssiu1", "src2_ssiu1", "src3_ssiu1", "src4_ssiu1", > > > + "src0_ssiu2", "src1_ssiu2", "src2_ssiu2", "src3_ssiu2", "src4_ssiu2", > > > > > > > I have to note that this looks rather weird and that none of the names > > are documented in the binding. > > > > Can you explain why this device uses over 100 DMA channels and put the > > exact naming rules into the binding? > > Do you expect all channels to be in use simultaneously? > > This device has 10 sound channels, and using 3 kind of IPs. > Then, data input/output needs DMA channel which needs specific ID to using. > Above name has ID pair for it, so there is much combination. > These specific ID is based on SoC, not board. > Sound driver / DMAEngine can get specific ID from above. > > Indeed binding itself was not documented yet. > I will add it ASAP. It sounds like you have some device-to-device DMAs here, which isn't supported by the generic dmaengine binding at all, and I don't think the driver currently attempts to use them. Is that correct? Could you try to remove those from the binding and just leave the device-to-memory and memory-to-device channels there? If we ever want to support those, we probably have to extend the dmaengine binding first, and then the driver binding would also look different. Arnd
On Tuesday 18 November 2014 09:50:40 Simon Horman wrote: > > Hi Arnd, > > please let me know if a revised pull-request is in order. > v3.18-rc6 is getting awfully close. Yes, I would prefer if you could leave out patches 6 to 9 for now. I assume we can work it out in time, and then you can send a follow-up with the new version. Arnd
On Tue, Nov 18, 2014 at 01:56:18PM +0100, Arnd Bergmann wrote: > On Tuesday 18 November 2014 09:50:40 Simon Horman wrote: > > > > Hi Arnd, > > > > please let me know if a revised pull-request is in order. > > v3.18-rc6 is getting awfully close. > > Yes, I would prefer if you could leave out patches 6 to 9 > for now. I assume we can work it out in time, and then you can > send a follow-up with the new version. Sure, will do.
Hi Arnd > > This device has 10 sound channels, and using 3 kind of IPs. > > Then, data input/output needs DMA channel which needs specific ID to using. > > Above name has ID pair for it, so there is much combination. > > These specific ID is based on SoC, not board. > > Sound driver / DMAEngine can get specific ID from above. > > > > Indeed binding itself was not documented yet. > > I will add it ASAP. > > It sounds like you have some device-to-device DMAs here, which isn't > supported by the generic dmaengine binding at all, and I don't think > the driver currently attempts to use them. > > Is that correct? Could you try to remove those from the binding and > just leave the device-to-memory and memory-to-device channels there? > If we ever want to support those, we probably have to extend the > dmaengine binding first, and then the driver binding would also look > different. It depends sound data path. basically, sound data goes memory-to-device or device-to-memory. but, it needs special IP if you want to use special effect. In such case, sound data path will be memory-to-device-to-device, or device-to-device-to-memory. This path based on board, and, our reference board is using above path.
Hi Arnd, again > > > This device has 10 sound channels, and using 3 kind of IPs. > > > Then, data input/output needs DMA channel which needs specific ID to using. > > > Above name has ID pair for it, so there is much combination. > > > These specific ID is based on SoC, not board. > > > Sound driver / DMAEngine can get specific ID from above. > > > > > > Indeed binding itself was not documented yet. > > > I will add it ASAP. > > > > It sounds like you have some device-to-device DMAs here, which isn't > > supported by the generic dmaengine binding at all, and I don't think > > the driver currently attempts to use them. > > > > Is that correct? Could you try to remove those from the binding and > > just leave the device-to-memory and memory-to-device channels there? > > If we ever want to support those, we probably have to extend the > > dmaengine binding first, and then the driver binding would also look > > different. > > It depends sound data path. basically, sound data goes memory-to-device > or device-to-memory. but, it needs special IP if you want to use special effect. > In such case, sound data path will be memory-to-device-to-device, or device-to-device-to-memory. > This path based on board, and, our reference board is using above path. memory-to-device-to-device case, it is indeed using memory-to-device and device-to-device. But, DMAEngine point of view, above device-to-device interface/style is same as memory-to-device. memory-to-device case needs ID + "memory address" + "register address". device-to-device case needs ID + "register address" + "register address". It is implemented in ${LINUX}/drivers/dma/sh/rcar-audmapp.c, and used from ${LINUX}/sound/soc/sh/rcar/core.c with generic dmaengine interface/binding. Best regards --- Kuninori Morimoto
On Thursday 13 November 2014, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC DT updates for > v3.19. > > This pull request is based on the previous round of > such requests, tagged as renesas-dt-for-v3.19, > which I have already sent a pull-request for. As discussed, I'm deferring this one and hope we can figure out a better binding for the asoc DMA channels. I think I've addressed all your pull requests, please check that I haven't missed any and they show up in for-next. Arnd
On Wed, Nov 19, 2014 at 11:09:48PM +0100, Arnd Bergmann wrote: > On Thursday 13 November 2014, Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > > > Please consider these second round of Renesas ARM based SoC DT updates for > > v3.19. > > > > This pull request is based on the previous round of > > such requests, tagged as renesas-dt-for-v3.19, > > which I have already sent a pull-request for. > > As discussed, I'm deferring this one and hope we can figure out a better > binding for the asoc DMA channels. Thanks, I plan to repost this pull-request with the patches that are under discussion omitted. > I think I've addressed all your pull requests, please check that I haven't > missed any and they show up in for-next. Thanks! Will do.
Hi Arnd > > > > "mem_src6", "src6_mem", > > > > "mem_src7", "src7_mem", > > > > "mem_src8", "src8_mem", > > > > - "mem_src9", "src9_mem"; > > > > + "mem_src9", "src9_mem", > > > > + > > > > + "src0_ssiu0", "src1_ssiu0", "src2_ssiu0", "src3_ssiu0", "src4_ssiu0", > > > > + "src0_ssiu1", "src1_ssiu1", "src2_ssiu1", "src3_ssiu1", "src4_ssiu1", > > > > + "src0_ssiu2", "src1_ssiu2", "src2_ssiu2", "src3_ssiu2", "src4_ssiu2", (snip) > It sounds like you have some device-to-device DMAs here, which isn't > supported by the generic dmaengine binding at all, and I don't think > the driver currently attempts to use them. > > Is that correct? Could you try to remove those from the binding and > just leave the device-to-memory and memory-to-device channels there? > If we ever want to support those, we probably have to extend the > dmaengine binding first, and then the driver binding would also look > different. Indeed it is needed for device-to-device DMA transfer, but, it is using generic dmaengine style. (see linux/sound/soc/sh/rcar/core.c, linux/drivers/dma/sh/rcar-audmapp.c) If I exchange dmaengine binding style for device-to-device, I need to change both dmaengine driver and sound driver. But, I want to know why I should do it ? Indeed it needs many DMA binding entries now, but, it is using normal dmaengine bindings.
Hi Olof, Hi Kevin, Hi Arnd, Please consider these second round of Renesas ARM based SoC DT updates for v3.19. This pull request is based on the previous round of such requests, tagged as renesas-dt-for-v3.19, which I have already sent a pull-request for. The following changes since commit 25af9c83151822eb6d413b4d15d5f89804606ac7: ARM: shmobile: r8a7779 dtsi: Add SoC-specific SATA compatible property (2014-10-30 10:01:37 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt2-for-v3.19 for you to fetch changes up to 2887bd4265cfbec6ccdd099c1728f82b4bebb69b: ARM: shmobile: kzm9g-reference dts: Add labels for the LEDs (2014-11-10 10:12:04 +0900) ---------------------------------------------------------------- Second Round of Renesas ARM Based SoC DT Updates for v3.19 * Add labels for LEDs on kzm9g-reference and koelsch * Use SoC-specific IIC compatible properties on sh73a0 and r8a73a4 * Add Sound DMA support to r8a7790/lager and r8a7791/koelsch ---------------------------------------------------------------- Geert Uytterhoeven (4): ARM: shmobile: r8a73a4 dtsi: Add SoC-specific IIC compatible properties ARM: shmobile: sh73a0 dtsi: Add SoC-specific IIC compatible properties ARM: shmobile: koelsch dts: Add labels for the LEDs ARM: shmobile: kzm9g-reference dts: Add labels for the LEDs Koji Matsuoka (1): ARM: shmobile: r8a7794: Add VIN clock to device tree Kuninori Morimoto (20): ARM: shmobile: r8a7790: Add Audio DMAC devices to DT ARM: shmobile: r8a7791: Add Audio DMAC devices to DT ARM: shmobile: r8a7790: Add Audio DMAC peri peri devices to DT ARM: shmobile: r8a7791: Add Audio DMAC peri peri devices to DT ARM: shmobile: r8a7790: sound enables Audio DMAC entry on DTSI ARM: shmobile: r8a7791: sound enables Audio DMAC entry on DTSI ARM: shmobile: r8a7790: sound enables Audio DMAC peri peri entry on DTSI ARM: shmobile: r8a7791: sound enables Audio DMAC peri peri entry on DTSI ARM: shmobile: lager: fixup IIC2 clock frequency ARM: shmobile: lager: Sound PIO support on DTS ARM: shmobile: lager: Sound DMA support on DTS ARM: shmobile: lager: Sound DMA support via BUSIF on DTS ARM: shmobile: lager: Sound DMA support via SRC on DTS ARM: shmobile: lager: Sound DMA support via DVC on DTS ARM: shmobile: koelsch: fixup I2C2 clock frequency ARM: shmobile: koelsch: Sound PIO support on DTS ARM: shmobile: koelsch: Sound DMA support on DTS ARM: shmobile: koelsch: Sound DMA support via BUSIF on DTS ARM: shmobile: koelsch: Sound DMA support via SRC on DTS ARM: shmobile: koelsch: Sound DMA support via DVC on DTS arch/arm/boot/dts/r8a73a4.dtsi | 18 +-- arch/arm/boot/dts/r8a7790-lager.dts | 74 ++++++++++ arch/arm/boot/dts/r8a7790.dtsi | 203 ++++++++++++++++++++++++++- arch/arm/boot/dts/r8a7791-koelsch.dts | 77 +++++++++- arch/arm/boot/dts/r8a7791.dtsi | 202 +++++++++++++++++++++++++- arch/arm/boot/dts/r8a7794.dtsi | 6 +- arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 4 + arch/arm/boot/dts/sh73a0.dtsi | 10 +- include/dt-bindings/clock/r8a7790-clock.h | 2 + include/dt-bindings/clock/r8a7791-clock.h | 2 + include/dt-bindings/clock/r8a7794-clock.h | 2 + 11 files changed, 576 insertions(+), 24 deletions(-)