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.