Message ID | 8761ekokpf.wl%kuninori.morimoto.gx@renesas.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Hi Vinod These are Audio DMAC peri peri v4 patches. 1) removes old drivers, and 2) replaces it. These are based on vinod/topic/rcar Kuninori Morimoto (2): dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v1 dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 drivers/dma/sh/Kconfig | 13 +- drivers/dma/sh/Makefile | 2 +- drivers/dma/sh/rcar-audmapp.c | 420 +++++++++++------------- include/linux/platform_data/dma-rcar-audmapp.h | 34 -- 4 files changed, 206 insertions(+), 263 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vinod ping ? > These are Audio DMAC peri peri v4 patches. > 1) removes old drivers, and 2) replaces it. > These are based on vinod/topic/rcar > > Kuninori Morimoto (2): > dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v1 > dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 > > drivers/dma/sh/Kconfig | 13 +- > drivers/dma/sh/Makefile | 2 +- > drivers/dma/sh/rcar-audmapp.c | 420 +++++++++++------------- > include/linux/platform_data/dma-rcar-audmapp.h | 34 -- > 4 files changed, 206 insertions(+), 263 deletions(-) > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vinod, Arnd, Simon # I added Arnd > These are Audio DMAC peri peri v4 patches. > 1) removes old drivers, and 2) replaces it. > These are based on vinod/topic/rcar > > Kuninori Morimoto (2): > dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v1 > dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 There is no response from Vinod about these patches. So, I re-send these again. This time I added SoC/platform side setting patches too (= 3) - 6)). SoC/platform side setting needs many entries for this rcar-audmapp, because it has many combinations. But, I believe this is very normal DMAEngine style, not special. Kuninori Morimoto (6): 1) dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v1 2) dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 3) ARM: shmobile: r8a7790: sound enables Audio DMAC entry on DTSI 4) ARM: shmobile: r8a7791: sound enables Audio DMAC entry on DTSI 5) ARM: shmobile: r8a7790: sound enables Audio DMAC peri peri entry on DTSI 6) ARM: shmobile: r8a7791: sound enables Audio DMAC peri peri entry on DTSI arch/arm/boot/dts/r8a7790.dtsi | 154 +++++++++ arch/arm/boot/dts/r8a7791.dtsi | 154 +++++++++ drivers/dma/sh/Kconfig | 13 +- drivers/dma/sh/Makefile | 2 +- drivers/dma/sh/rcar-audmapp.c | 420 +++++++++++------------- include/linux/platform_data/dma-rcar-audmapp.h | 34 -- 6 files changed, 514 insertions(+), 263 deletions(-) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Morimoto-san, Thank you for the patches. On Tuesday 20 January 2015 01:43:29 Kuninori Morimoto wrote: > Hi Vinod, Arnd, Simon > > # I added Arnd > > > These are Audio DMAC peri peri v4 patches. > > 1) removes old drivers, and 2) replaces it. > > These are based on vinod/topic/rcar > > > > Kuninori Morimoto (2): > > dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v1 > > dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 > > There is no response from Vinod about these patches. > So, I re-send these again. > > This time I added SoC/platform side setting patches too (= 3) - 6)). > SoC/platform side setting needs many entries for this rcar-audmapp, > because it has many combinations. > But, I believe this is very normal DMAEngine style, not special. Vinod commented on 22/12/2014 (Message-ID: <20141222151447.GL16827@intel.com>) "I think this makes sense. Going thru the driver, it was clear that we were not really gaining anything for using dmaengine API here. So agree that lets use dmanegine for 1st dmac thru dmaengine library and then configure this in your sound driver.." My understanding is that a solution specific to the sound driver was preferred, instead of a generic DMA engine driver. Have I missed something ? > Kuninori Morimoto (6): > 1) dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v1 > 2) dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 > 3) ARM: shmobile: r8a7790: sound enables Audio DMAC entry on DTSI > 4) ARM: shmobile: r8a7791: sound enables Audio DMAC entry on DTSI > 5) ARM: shmobile: r8a7790: sound enables Audio DMAC peri peri entry on > DTSI 6) ARM: shmobile: r8a7791: sound enables Audio DMAC peri peri entry on > DTSI > > arch/arm/boot/dts/r8a7790.dtsi | 154 +++++++++ > arch/arm/boot/dts/r8a7791.dtsi | 154 +++++++++ > drivers/dma/sh/Kconfig | 13 +- > drivers/dma/sh/Makefile | 2 +- > drivers/dma/sh/rcar-audmapp.c | 420 ++++++++++---------- > include/linux/platform_data/dma-rcar-audmapp.h | 34 -- > 6 files changed, 514 insertions(+), 263 deletions(-)
Hi Laurent, Vinod Thank you for your feedback > > This time I added SoC/platform side setting patches too (= 3) - 6)). > > SoC/platform side setting needs many entries for this rcar-audmapp, > > because it has many combinations. > > But, I believe this is very normal DMAEngine style, not special. > > Vinod commented on 22/12/2014 (Message-ID: <20141222151447.GL16827@intel.com>) > > "I think this makes sense. Going thru the driver, it was clear that we were > not really gaining anything for using dmaengine API here. So agree that lets > use dmanegine for 1st dmac thru dmaengine library and then configure this in > your sound driver.." > > My understanding is that a solution specific to the sound driver was > preferred, instead of a generic DMA engine driver. Have I missed something ? Grr... my understanding was that "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx functions) 2nd DMAC will use normal dmaengine API" But, I need to fixup sound driver ? - 1st DMAC = normal DMAEngine API - 2nd DMAC = part of sound driver Sorry, for discuss it again here, but I want flexible switching for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). So, using same DMAEngine interface from sound driver is easy to implement/understanding. - 1st DMAC = normal DMAEngine API - 2nd DMAC = normal DMAEngine API Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vinod, Arnd, Simon There is no response from Vinod, and, I might have misunderstanding about this sound DMAC. But, I send latest patch-set. We don't need to replace rcar-audmapp if we can have Arnd's short term bugfix patch. Arnd Bergmann (1): dmaengine: shdma-base: enable to be non multiplexed DMAEngine driver Kuninori Morimoto (4): 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 arch/arm/boot/dts/r8a7790.dtsi | 154 ++++++++++++++++++++++++++++++++++++++++ arch/arm/boot/dts/r8a7791.dtsi | 154 ++++++++++++++++++++++++++++++++++++++++ drivers/dma/sh/rcar-hpbdma.c | 1 + drivers/dma/sh/shdma-base.c | 11 +++ drivers/dma/sh/shdmac.c | 1 + include/linux/shdma-base.h | 1 + 6 files changed, 322 insertions(+) Best regards --- Kuninori Morimoto -- 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 -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all > There is no response from Vinod, > and, I might have misunderstanding about this sound DMAC. > But, I send latest patch-set. > We don't need to replace rcar-audmapp if we can have Arnd's > short term bugfix patch. > > Arnd Bergmann (1): > dmaengine: shdma-base: enable to be non multiplexed DMAEngine driver > > Kuninori Morimoto (4): > 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 I'm sorry, but I noticed it still have bug. Hmm... -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Morimoto-san, On Wednesday 21 January 2015 00:51:20 Kuninori Morimoto wrote: > Hi Laurent, Vinod > > Thank you for your feedback > > >> This time I added SoC/platform side setting patches too (= 3) - 6)). > >> SoC/platform side setting needs many entries for this rcar-audmapp, > >> because it has many combinations. > >> But, I believe this is very normal DMAEngine style, not special. > > > > Vinod commented on 22/12/2014 (Message-ID: > > <20141222151447.GL16827@intel.com>) > > > > "I think this makes sense. Going thru the driver, it was clear that we > > were not really gaining anything for using dmaengine API here. So agree > > that lets use dmanegine for 1st dmac thru dmaengine library and then > > configure this in your sound driver.." > > > > My understanding is that a solution specific to the sound driver was > > preferred, instead of a generic DMA engine driver. Have I missed something > > ? > > Grr... my understanding was that > "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx > functions) 2nd DMAC will use normal dmaengine API" > > But, I need to fixup sound driver ? > - 1st DMAC = normal DMAEngine API > - 2nd DMAC = part of sound driver > > Sorry, for discuss it again here, but I want flexible switching > for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > So, using same DMAEngine interface from sound driver is easy to > implement/understanding. > - 1st DMAC = normal DMAEngine API > - 2nd DMAC = normal DMAEngine API The first DMA engine (the one handling transfer from/to memory) is a general- purpose DMA engine. It should be handled by a driver that implement the DMA engine API, no doubt about that. The second "DMA engine" is dedicated to the sound IP cores and is far from being general-purpose, given that it only supports peripheral-to-peripheral transfers, without even interrupts to report transfer completion. I'm not even sure we can call it a DMA engine as there's no Direct Memory Access involved here :-) The hardware looks more like a crossbar switch with programmable routing of audio channels. That's why Vinod and I were wondering whether it really makes sense to implement it using the DMA engine API, given the resulting complexity of the DT bindings (the sound DT nodes look a bit scary), or if it could be simpler to implement it as part of the Renesas sound drivers.
Hi Laurent, Vinod, and Arnd # I added Linux ALSA ML and Mark > > >> This time I added SoC/platform side setting patches too (= 3) - 6)). > > >> SoC/platform side setting needs many entries for this rcar-audmapp, > > >> because it has many combinations. > > >> But, I believe this is very normal DMAEngine style, not special. > > > > > > Vinod commented on 22/12/2014 (Message-ID: > > > <20141222151447.GL16827@intel.com>) > > > > > > "I think this makes sense. Going thru the driver, it was clear that we > > > were not really gaining anything for using dmaengine API here. So agree > > > that lets use dmanegine for 1st dmac thru dmaengine library and then > > > configure this in your sound driver.." > > > > > > My understanding is that a solution specific to the sound driver was > > > preferred, instead of a generic DMA engine driver. Have I missed something > > > ? > > > > Grr... my understanding was that > > "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx > > functions) 2nd DMAC will use normal dmaengine API" > > > > But, I need to fixup sound driver ? > > - 1st DMAC = normal DMAEngine API > > - 2nd DMAC = part of sound driver > > > > Sorry, for discuss it again here, but I want flexible switching > > for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > > So, using same DMAEngine interface from sound driver is easy to > > implement/understanding. > > - 1st DMAC = normal DMAEngine API > > - 2nd DMAC = normal DMAEngine API > > The first DMA engine (the one handling transfer from/to memory) is a general- > purpose DMA engine. It should be handled by a driver that implement the DMA > engine API, no doubt about that. > > The second "DMA engine" is dedicated to the sound IP cores and is far from > being general-purpose, given that it only supports peripheral-to-peripheral > transfers, without even interrupts to report transfer completion. I'm not even > sure we can call it a DMA engine as there's no Direct Memory Access involved > here :-) The hardware looks more like a crossbar switch with programmable > routing of audio channels. That's why Vinod and I were wondering whether it > really makes sense to implement it using the DMA engine API, given the > resulting complexity of the DT bindings (the sound DT nodes look a bit scary), > or if it could be simpler to implement it as part of the Renesas sound > drivers. If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using it though...) it is for peripheral-to-peripheral ? And API point of view, 2nd DMAC doesn't need new DMAEngine API. From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create "similar but different" implementation for naming issue. From DT bindings complexity point of view, which is complex ? DMAC driver side ? DT node side ? Indeed sound driver needs many node, but is is regular arrangement, not complex, and, it needs many node for 1st DMAC too. I don't understand why 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of view, 1st DMAC has same complexity (= it accepts many node from many drivers) ? If I need to move 2nd DMAC from DMAEngine to sound driver side, please explain it to Mark Brown (= ALSA SoC maintainer) Best regards --- Kuninori Morimoto Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mark I need your comment about this > > > Grr... my understanding was that > > > "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx > > > functions) 2nd DMAC will use normal dmaengine API" > > > > > > But, I need to fixup sound driver ? > > > - 1st DMAC = normal DMAEngine API > > > - 2nd DMAC = part of sound driver > > > > > > Sorry, for discuss it again here, but I want flexible switching > > > for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > > > So, using same DMAEngine interface from sound driver is easy to > > > implement/understanding. > > > - 1st DMAC = normal DMAEngine API > > > - 2nd DMAC = normal DMAEngine API > > > > The first DMA engine (the one handling transfer from/to memory) is a general- > > purpose DMA engine. It should be handled by a driver that implement the DMA > > engine API, no doubt about that. > > > > The second "DMA engine" is dedicated to the sound IP cores and is far from > > being general-purpose, given that it only supports peripheral-to-peripheral > > transfers, without even interrupts to report transfer completion. I'm not even > > sure we can call it a DMA engine as there's no Direct Memory Access involved > > here :-) The hardware looks more like a crossbar switch with programmable > > routing of audio channels. That's why Vinod and I were wondering whether it > > really makes sense to implement it using the DMA engine API, given the > > resulting complexity of the DT bindings (the sound DT nodes look a bit scary), > > or if it could be simpler to implement it as part of the Renesas sound > > drivers. > > If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". > I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using it though...) > it is for peripheral-to-peripheral ? > And API point of view, 2nd DMAC doesn't need new DMAEngine API. > From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create > "similar but different" implementation for naming issue. > > From DT bindings complexity point of view, which is complex ? > DMAC driver side ? DT node side ? > Indeed sound driver needs many node, but is is regular arrangement, not complex, > and, it needs many node for 1st DMAC too. I don't understand why 1st is OK, 2nd is not OK ? > From DMAC driver side complexity point of view, > 1st DMAC has same complexity (= it accepts many node from many drivers) ? > > If I need to move 2nd DMAC from DMAEngine to sound driver side, > please explain it to Mark Brown (= ALSA SoC maintainer) http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=42054 http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=42998 Sorry for sudden request, but can you please check above mail thread ? This topic is for Renesas sound DMAC driver. Renesas sound driver is using 2 DMAEngine now (= 1st/2nd). And, this mail thread was started for replacement of 2nd DMAC. (This replacement is because 2nd DMAC driver's bug fix). In this mail thread, (I was misunderstanding about agreement though... but) Vinod/Laurent are thinking that 2nd DMAC should be implemented in sound driver side. (I'm thinking that both 1st/2nd DMAC on DMAEngine is useful) But if we need to move 2nd DMAC from DMAEngine to sound driver, I need to get agreement from you. What is you opinion ? If you agree about it, I will send the patch to ALSA/DMAEngine ML. Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Morimoto-san, On Friday 23 January 2015 00:35:32 Kuninori Morimoto wrote: > Hi Laurent, Vinod, and Arnd > > # I added Linux ALSA ML and Mark > > >>>> This time I added SoC/platform side setting patches too (= 3) - 6)). > >>>> SoC/platform side setting needs many entries for this rcar-audmapp, > >>>> because it has many combinations. > >>>> But, I believe this is very normal DMAEngine style, not special. > >>> > >>> Vinod commented on 22/12/2014 (Message-ID: > >>> <20141222151447.GL16827@intel.com>) > >>> > >>> "I think this makes sense. Going thru the driver, it was clear that we > >>> were not really gaining anything for using dmaengine API here. So > >>> agree that lets use dmanegine for 1st dmac thru dmaengine library and > >>> then configure this in your sound driver.." > >>> > >>> My understanding is that a solution specific to the sound driver was > >>> preferred, instead of a generic DMA engine driver. Have I missed > >>> something ? > >> > >> Grr... my understanding was that > >> "1st DMAC will use dmaengine library (= sound framework has > >> sound-dma-xxx > >> functions) 2nd DMAC will use normal dmaengine API" > >> > >> But, I need to fixup sound driver ? > >> > >> - 1st DMAC = normal DMAEngine API > >> - 2nd DMAC = part of sound driver > >> > >> Sorry, for discuss it again here, but I want flexible switching > >> for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > >> So, using same DMAEngine interface from sound driver is easy to > >> implement/understanding. > >> > >> - 1st DMAC = normal DMAEngine API > >> - 2nd DMAC = normal DMAEngine API > > > > The first DMA engine (the one handling transfer from/to memory) is a > > general- purpose DMA engine. It should be handled by a driver that > > implement the DMA engine API, no doubt about that. > > > > The second "DMA engine" is dedicated to the sound IP cores and is far from > > being general-purpose, given that it only supports > > peripheral-to-peripheral transfers, without even interrupts to report > > transfer completion. I'm not even sure we can call it a DMA engine as > > there's no Direct Memory Access involved here :-) The hardware looks more > > like a crossbar switch with programmable routing of audio channels. That's > > why Vinod and I were wondering whether it really makes sense to implement > > it using the DMA engine API, given the resulting complexity of the DT > > bindings (the sound DT nodes look a bit scary), or if it could be simpler > > to implement it as part of the Renesas sound drivers. > > If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". > I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using > it though...) it is for peripheral-to-peripheral ? > And API point of view, 2nd DMAC doesn't need new DMAEngine API. > From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create > "similar but different" implementation for naming issue. > > From DT bindings complexity point of view, which is complex ? > DMAC driver side ? DT node side ? > Indeed sound driver needs many node, but is is regular arrangement, not > complex, and, it needs many node for 1st DMAC too. I don't understand why > 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of view, > 1st DMAC has same complexity (= it accepts many node from many drivers) ? > > If I need to move 2nd DMAC from DMAEngine to sound driver side, > please explain it to Mark Brown (= ALSA SoC maintainer) I'm not saying you need to, I just wanted to raise the issue. From what I understood Vinod was also having doubts on using the DMA engine API for this device, given that it doesn't really match what the DMA engine API has been designed for. If everybody else is fine with your patches, and if the sound DT nodes are not considered overly complex with the DMA engine bindings, then I have no objection.
Hi Laurent > > If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". > > I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using > > it though...) it is for peripheral-to-peripheral ? > > And API point of view, 2nd DMAC doesn't need new DMAEngine API. > > From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create > > "similar but different" implementation for naming issue. > > > > From DT bindings complexity point of view, which is complex ? > > DMAC driver side ? DT node side ? > > Indeed sound driver needs many node, but is is regular arrangement, not > > complex, and, it needs many node for 1st DMAC too. I don't understand why > > 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of view, > > 1st DMAC has same complexity (= it accepts many node from many drivers) ? > > > > If I need to move 2nd DMAC from DMAEngine to sound driver side, > > please explain it to Mark Brown (= ALSA SoC maintainer) > > I'm not saying you need to, I just wanted to raise the issue. From what I > understood Vinod was also having doubts on using the DMA engine API for this > device, given that it doesn't really match what the DMA engine API has been > designed for. If everybody else is fine with your patches, and if the sound DT > nodes are not considered overly complex with the DMA engine bindings, then I > have no objection. Thank you for your feedback, and I'm so sorry for my previous rude mail. I think 2nd DMAC doesn't be complex issue, because it is very simple device. But, this is my side (sound driver point) opinion. Of course I can agree about DMAEngine side opinion/concern. I don't know what it the best solution. Now, I asked about it to Mark (= ALSA SoC maintainer). I can follow ALSA SoC maintainer + DMAEngine maintainer. Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Morimoto-san, On Monday 26 January 2015 02:57:32 Kuninori Morimoto wrote: > Hi Laurent > > >> If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". > >> I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not > >> using it though...) it is for peripheral-to-peripheral ? > >> And API point of view, 2nd DMAC doesn't need new DMAEngine API. > >> From DRY (= Don't Repeat Yourself) point of view, I don't want to > >> re-create "similar but different" implementation for naming issue. > >> > >> From DT bindings complexity point of view, which is complex ? > >> DMAC driver side ? DT node side ? > >> Indeed sound driver needs many node, but is is regular arrangement, not > >> complex, and, it needs many node for 1st DMAC too. I don't understand > >> why 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of > >> view, 1st DMAC has same complexity (= it accepts many node from many > >> drivers) ? > >> > >> If I need to move 2nd DMAC from DMAEngine to sound driver side, > >> please explain it to Mark Brown (= ALSA SoC maintainer) > > > > I'm not saying you need to, I just wanted to raise the issue. From what I > > understood Vinod was also having doubts on using the DMA engine API for > > this device, given that it doesn't really match what the DMA engine API > > has been designed for. If everybody else is fine with your patches, and > > if the sound DT nodes are not considered overly complex with the DMA > > engine bindings, then I have no objection. > > Thank you for your feedback, > and I'm so sorry for my previous rude mail. No worries, I haven't found it rude. I know it could seem that I've trying to block this patch series without any reason, so a straight to the point reply was expected :-) > I think 2nd DMAC doesn't be complex issue, because it is very simple device. > But, this is my side (sound driver point) opinion. > Of course I can agree about DMAEngine side opinion/concern. > I don't know what it the best solution. > > Now, I asked about it to Mark (= ALSA SoC maintainer). > I can follow ALSA SoC maintainer + DMAEngine maintainer. I'd like to hear Marc's opinion, yes. And if Vinod is fine with your proposal, that's totally fine with me as well.
Hi Arnd I need your comment about this, too. Because, you are ARM platform maintainer, and my DTS patch for it was rejected before. So, It needs total agreement from - DMAEngine maintainer - ALSA SoC maintainer - ARM platform maintainer > > > > Grr... my understanding was that > > > > "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx > > > > functions) 2nd DMAC will use normal dmaengine API" > > > > > > > > But, I need to fixup sound driver ? > > > > - 1st DMAC = normal DMAEngine API > > > > - 2nd DMAC = part of sound driver > > > > > > > > Sorry, for discuss it again here, but I want flexible switching > > > > for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > > > > So, using same DMAEngine interface from sound driver is easy to > > > > implement/understanding. > > > > - 1st DMAC = normal DMAEngine API > > > > - 2nd DMAC = normal DMAEngine API > > > > > > The first DMA engine (the one handling transfer from/to memory) is a general- > > > purpose DMA engine. It should be handled by a driver that implement the DMA > > > engine API, no doubt about that. > > > > > > The second "DMA engine" is dedicated to the sound IP cores and is far from > > > being general-purpose, given that it only supports peripheral-to-peripheral > > > transfers, without even interrupts to report transfer completion. I'm not even > > > sure we can call it a DMA engine as there's no Direct Memory Access involved > > > here :-) The hardware looks more like a crossbar switch with programmable > > > routing of audio channels. That's why Vinod and I were wondering whether it > > > really makes sense to implement it using the DMA engine API, given the > > > resulting complexity of the DT bindings (the sound DT nodes look a bit scary), > > > or if it could be simpler to implement it as part of the Renesas sound > > > drivers. > > > > If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". > > I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using it though...) > > it is for peripheral-to-peripheral ? > > And API point of view, 2nd DMAC doesn't need new DMAEngine API. > > From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create > > "similar but different" implementation for naming issue. > > > > From DT bindings complexity point of view, which is complex ? > > DMAC driver side ? DT node side ? > > Indeed sound driver needs many node, but is is regular arrangement, not complex, > > and, it needs many node for 1st DMAC too. I don't understand why 1st is OK, 2nd is not OK ? > > From DMAC driver side complexity point of view, > > 1st DMAC has same complexity (= it accepts many node from many drivers) ? > > > > If I need to move 2nd DMAC from DMAEngine to sound driver side, > > please explain it to Mark Brown (= ALSA SoC maintainer) > > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=42054 > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=42998 > > Sorry for sudden request, but can you please check above mail thread ? > This topic is for Renesas sound DMAC driver. > Renesas sound driver is using 2 DMAEngine now (= 1st/2nd). > And, this mail thread was started for replacement of 2nd DMAC. > (This replacement is because 2nd DMAC driver's bug fix). > > In this mail thread, (I was misunderstanding about agreement though... but) > Vinod/Laurent are thinking that 2nd DMAC should be implemented in sound driver side. > (I'm thinking that both 1st/2nd DMAC on DMAEngine is useful) > But if we need to move 2nd DMAC from DMAEngine to sound driver, > I need to get agreement from you. > What is you opinion ? If you agree about it, I will send the patch to > ALSA/DMAEngine ML. > > Best regards > --- > Kuninori Morimoto > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 26, 2015 at 04:39:42AM +0200, Laurent Pinchart wrote: > Hi Morimoto-san, > > On Friday 23 January 2015 00:35:32 Kuninori Morimoto wrote: > > Hi Laurent, Vinod, and Arnd > > > > # I added Linux ALSA ML and Mark > > > > >>>> This time I added SoC/platform side setting patches too (= 3) - 6)). > > >>>> SoC/platform side setting needs many entries for this rcar-audmapp, > > >>>> because it has many combinations. > > >>>> But, I believe this is very normal DMAEngine style, not special. > > >>> > > >>> Vinod commented on 22/12/2014 (Message-ID: > > >>> <20141222151447.GL16827@intel.com>) > > >>> > > >>> "I think this makes sense. Going thru the driver, it was clear that we > > >>> were not really gaining anything for using dmaengine API here. So > > >>> agree that lets use dmanegine for 1st dmac thru dmaengine library and > > >>> then configure this in your sound driver.." > > >>> > > >>> My understanding is that a solution specific to the sound driver was > > >>> preferred, instead of a generic DMA engine driver. Have I missed > > >>> something ? > > >> > > >> Grr... my understanding was that > > >> "1st DMAC will use dmaengine library (= sound framework has > > >> sound-dma-xxx > > >> functions) 2nd DMAC will use normal dmaengine API" > > >> > > >> But, I need to fixup sound driver ? > > >> > > >> - 1st DMAC = normal DMAEngine API > > >> - 2nd DMAC = part of sound driver > > >> > > >> Sorry, for discuss it again here, but I want flexible switching > > >> for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > > >> So, using same DMAEngine interface from sound driver is easy to > > >> implement/understanding. > > >> > > >> - 1st DMAC = normal DMAEngine API > > >> - 2nd DMAC = normal DMAEngine API > > > > > > The first DMA engine (the one handling transfer from/to memory) is a > > > general- purpose DMA engine. It should be handled by a driver that > > > implement the DMA engine API, no doubt about that. > > > > > > The second "DMA engine" is dedicated to the sound IP cores and is far from > > > being general-purpose, given that it only supports > > > peripheral-to-peripheral transfers, without even interrupts to report > > > transfer completion. I'm not even sure we can call it a DMA engine as > > > there's no Direct Memory Access involved here :-) The hardware looks more > > > like a crossbar switch with programmable routing of audio channels. That's > > > why Vinod and I were wondering whether it really makes sense to implement > > > it using the DMA engine API, given the resulting complexity of the DT > > > bindings (the sound DT nodes look a bit scary), or if it could be simpler > > > to implement it as part of the Renesas sound drivers. > > > > If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". > > I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using > > it though...) it is for peripheral-to-peripheral ? > > And API point of view, 2nd DMAC doesn't need new DMAEngine API. > > From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create > > "similar but different" implementation for naming issue. > > > > From DT bindings complexity point of view, which is complex ? > > DMAC driver side ? DT node side ? > > Indeed sound driver needs many node, but is is regular arrangement, not > > complex, and, it needs many node for 1st DMAC too. I don't understand why > > 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of view, > > 1st DMAC has same complexity (= it accepts many node from many drivers) ? > > > > If I need to move 2nd DMAC from DMAEngine to sound driver side, > > please explain it to Mark Brown (= ALSA SoC maintainer) > > I'm not saying you need to, I just wanted to raise the issue. From what I > understood Vinod was also having doubts on using the DMA engine API for this > device, given that it doesn't really match what the DMA engine API has been > designed for. If everybody else is fine with your patches, and if the sound DT > nodes are not considered overly complex with the DMA engine bindings, then I > have no objection. Laurent is right in his observations, When I last reviewed the series (though have looked at this one yet), the advise was to use dmaengine APIs with sound dmanengine library for 1st DMAC. The second DMAC is specfic to this device so should be handled internally or as part of the sound driver (or whatever client) HTH
Hi Vinod > > I'm not saying you need to, I just wanted to raise the issue. From what I > > understood Vinod was also having doubts on using the DMA engine API for this > > device, given that it doesn't really match what the DMA engine API has been > > designed for. If everybody else is fine with your patches, and if the sound DT > > nodes are not considered overly complex with the DMA engine bindings, then I > > have no objection. > Laurent is right in his observations, When I last reviewed the series > (though have looked at this one yet), the advise was to use dmaengine APIs > with sound dmanengine library for 1st DMAC. The second DMAC is specfic to > this device so should be handled internally or as part of the sound driver > (or whatever client) So, is this mean we can't use DMAEngine style if it was non-generic DMAC ? For Example, we have USB-DMAC (it is used from USB only) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vinod, again > > > I'm not saying you need to, I just wanted to raise the issue. From what I > > > understood Vinod was also having doubts on using the DMA engine API for this > > > device, given that it doesn't really match what the DMA engine API has been > > > designed for. If everybody else is fine with your patches, and if the sound DT > > > nodes are not considered overly complex with the DMA engine bindings, then I > > > have no objection. > > Laurent is right in his observations, When I last reviewed the series > > (though have looked at this one yet), the advise was to use dmaengine APIs > > with sound dmanengine library for 1st DMAC. The second DMAC is specfic to > > this device so should be handled internally or as part of the sound driver > > (or whatever client) > > So, is this mean we can't use DMAEngine style if it was non-generic DMAC ? > For Example, we have USB-DMAC (it is used from USB only) This is out-of-topic from sound DMAC, but in USB-DMAC case, our SoC have USB IP and its DMAC. Old USB used generic DMAC before, but, New USB have USB specific DMAC today. And we already have usb driver. what should we do in this case ? Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Laurent, everyone, On Mon, Jan 26, 2015 at 12:01 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Morimoto-san, > > On Monday 26 January 2015 02:57:32 Kuninori Morimoto wrote: >> Hi Laurent >> >> >> If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". >> >> I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not >> >> using it though...) it is for peripheral-to-peripheral ? >> >> And API point of view, 2nd DMAC doesn't need new DMAEngine API. >> >> From DRY (= Don't Repeat Yourself) point of view, I don't want to >> >> re-create "similar but different" implementation for naming issue. >> >> >> >> From DT bindings complexity point of view, which is complex ? >> >> DMAC driver side ? DT node side ? >> >> Indeed sound driver needs many node, but is is regular arrangement, not >> >> complex, and, it needs many node for 1st DMAC too. I don't understand >> >> why 1st is OK, 2nd is not OK ? From DMAC driver side complexity point of >> >> view, 1st DMAC has same complexity (= it accepts many node from many >> >> drivers) ? >> >> >> >> If I need to move 2nd DMAC from DMAEngine to sound driver side, >> >> please explain it to Mark Brown (= ALSA SoC maintainer) >> > >> > I'm not saying you need to, I just wanted to raise the issue. From what I >> > understood Vinod was also having doubts on using the DMA engine API for >> > this device, given that it doesn't really match what the DMA engine API >> > has been designed for. If everybody else is fine with your patches, and >> > if the sound DT nodes are not considered overly complex with the DMA >> > engine bindings, then I have no objection. >> >> Thank you for your feedback, >> and I'm so sorry for my previous rude mail. > > No worries, I haven't found it rude. I know it could seem that I've trying to > block this patch series without any reason, so a straight to the point reply > was expected :-) > >> I think 2nd DMAC doesn't be complex issue, because it is very simple device. >> But, this is my side (sound driver point) opinion. >> Of course I can agree about DMAEngine side opinion/concern. >> I don't know what it the best solution. >> >> Now, I asked about it to Mark (= ALSA SoC maintainer). >> I can follow ALSA SoC maintainer + DMAEngine maintainer. > > I'd like to hear Marc's opinion, yes. And if Vinod is fine with your proposal, > that's totally fine with me as well. From my side anything is fine really, and I agree that the DT integration patch looked rather "special". =) At the same time I do think it makes sense to model the DT after the hardware. So if there is a separate DMA controller device then I can't see what is wrong with representing that in DT as a separate device. That aside, the current implementation may not have been entirely clean so perhaps we can begin by fixing that and see where that leads us. So I wonder as an incremental approach, how about simply reworking the DT interface (old code has 200+ channels mapped out individually) to something more manageable (maybe 20+ groups instead)? If that still seems completely wrong DT-wise then we can look into how to rework the architecture. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vinod, Laurent, Magnus Thank you for your feedback > From my side anything is fine really, and I agree that the DT > integration patch looked rather "special". =) > > At the same time I do think it makes sense to model the DT after the > hardware. So if there is a separate DMA controller device then I can't > see what is wrong with representing that in DT as a separate device. > That aside, the current implementation may not have been entirely > clean so perhaps we can begin by fixing that and see where that leads > us. > > So I wonder as an incremental approach, how about simply reworking the > DT interface (old code has 200+ channels mapped out individually) to > something more manageable (maybe 20+ groups instead)? If that still > seems completely wrong DT-wise then we can look into how to rework the > architecture. Yes indeed, it needs too many DT nodes in current implementation (total 220 node). and I can agree that it is one of concern about Vinod/Laurent. It could be reduced to 22 node if I fixuped current implementation to calculate ID by DMAEngine driver side. It is not full-patchset, but I send this fixup patch as [RFC] Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Morimoto-san, On Thu, Jan 29, 2015 at 10:23 AM, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote: > > Hi Vinod, Laurent, Magnus > > Thank you for your feedback > >> From my side anything is fine really, and I agree that the DT >> integration patch looked rather "special". =) >> >> At the same time I do think it makes sense to model the DT after the >> hardware. So if there is a separate DMA controller device then I can't >> see what is wrong with representing that in DT as a separate device. >> That aside, the current implementation may not have been entirely >> clean so perhaps we can begin by fixing that and see where that leads >> us. >> >> So I wonder as an incremental approach, how about simply reworking the >> DT interface (old code has 200+ channels mapped out individually) to >> something more manageable (maybe 20+ groups instead)? If that still >> seems completely wrong DT-wise then we can look into how to rework the >> architecture. > > Yes indeed, it needs too many DT nodes in current implementation > (total 220 node). and I can agree that it is one of concern about Vinod/Laurent. > It could be reduced to 22 node if I fixuped current implementation to calculate ID > by DMAEngine driver side. > It is not full-patchset, but I send this fixup patch as [RFC] Sounds good. Can you please let me know exactly which patch series should I look at? Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus > >> From my side anything is fine really, and I agree that the DT > >> integration patch looked rather "special". =) > >> > >> At the same time I do think it makes sense to model the DT after the > >> hardware. So if there is a separate DMA controller device then I can't > >> see what is wrong with representing that in DT as a separate device. > >> That aside, the current implementation may not have been entirely > >> clean so perhaps we can begin by fixing that and see where that leads > >> us. > >> > >> So I wonder as an incremental approach, how about simply reworking the > >> DT interface (old code has 200+ channels mapped out individually) to > >> something more manageable (maybe 20+ groups instead)? If that still > >> seems completely wrong DT-wise then we can look into how to rework the > >> architecture. > > > > Yes indeed, it needs too many DT nodes in current implementation > > (total 220 node). and I can agree that it is one of concern about Vinod/Laurent. > > It could be reduced to 22 node if I fixuped current implementation to calculate ID > > by DMAEngine driver side. > > It is not full-patchset, but I send this fixup patch as [RFC] > > Sounds good. Can you please let me know exactly which patch series > should I look at? Thank you for your help I have sent 2 patches as [RFC] [RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr [RFC] ARM: shmobile: r8a7790: sound enables Audio DMAC peri peri entry on DTSI Actually, sound driver side needs fixup patch related to these change. But above are focusing to Audio DMAC peri peri at this point. Main change is 2/2 patch, it is using 22 node on this patch. (it needed 220 node without theses patches) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all These are v2 of rcar-audmapp driver as [RFC]. We can reduce Audio DMAC peri peri DT entry 220 -> 22 node by these patches. Actually, sound driver side needs update for this rcar-audmapp update, but it doesn't include these patches at this point. These are focuing about rcar-audmapp only at this point. Kuninori Morimoto (3): dmaengine: rcar-audmapp: calculate chcr via src/dst addr ARM: shmobile: r8a7790: add SSIU/DTCP/MLM/SCU reg for Audio DMAC peri peri ARM: shmobile: r8a7790: enables Audio DMAC peri peri entry on DTSI arch/arm/boot/dts/r8a7790.dtsi | 26 ++++++- drivers/dma/sh/rcar-audmapp.c | 164 +++++++++++++++++++++++++++++++++++++--- 2 files changed, 175 insertions(+), 15 deletions(-) Best regards --- Kuninori Morimoto
Hi all These are v3 of rcar-audmapp driver as [RFC]. We can reduce Audio DMAC peri peri DT entry 220 -> 22 node by these patches. Actually, sound driver side needs update for this rcar-audmapp update, but it doesn't include these patches at this point. These are focuing about rcar-audmapp only at this point. Main change on this version is that audmapp driver assumes DTS has reg-names Kuninori Morimoto (3): dmaengine: rcar-audmapp: calculate chcr via src/dst addr ARM: shmobile: r8a7790: add SSIU/DTCP/MLM/SCU reg for Audio DMAC peri peri ARM: shmobile: r8a7790: enables Audio DMAC peri peri entry on DTSI arch/arm/boot/dts/r8a7790.dtsi | 26 ++++++- drivers/dma/sh/rcar-audmapp.c | 164 +++++++++++++++++++++++++++++++++++++--- 2 files changed, 175 insertions(+), 15 deletions(-) Best regards --- Kuninori Morimoto
Hi Vinod, Arnd Can I have feedback from you about below mail, and this patch ? http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=43372 > Hi all > > These are v3 of rcar-audmapp driver as [RFC]. > We can reduce Audio DMAC peri peri DT entry 220 -> 22 node by these patches. > > Actually, sound driver side needs update for this rcar-audmapp update, > but it doesn't include these patches at this point. > These are focuing about rcar-audmapp only at this point. > > Main change on this version is that audmapp driver assumes DTS has reg-names > > Kuninori Morimoto (3): > dmaengine: rcar-audmapp: calculate chcr via src/dst addr > ARM: shmobile: r8a7790: add SSIU/DTCP/MLM/SCU reg for Audio DMAC peri peri > ARM: shmobile: r8a7790: enables Audio DMAC peri peri entry on DTSI > > arch/arm/boot/dts/r8a7790.dtsi | 26 ++++++- > drivers/dma/sh/rcar-audmapp.c | 164 +++++++++++++++++++++++++++++++++++++--- > 2 files changed, 175 insertions(+), 15 deletions(-) > > Best regards > --- > Kuninori Morimoto > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- > 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 > -- > 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 Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 09 February 2015 01:37:41 Kuninori Morimoto wrote: > > Hi Vinod, Arnd > > Can I have feedback from you about below mail, and this patch ? > > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=43372 I had the chance to discuss this in more depth with Laurent last week. What it basically comes down to is that you try to do something that the existing DT binding and slave API does not support: we only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV. To properly support this with the dmaengine API, we would likely first need to extend the generic DT binding, and then implement the driver to use that extended binding. The easiest way out however seems to be to move the audmapp implementation into the rcar audio driver itself. As Laurent pointed out, it is not really a general-purpose dmaengine anyway and it only ever gets used by one driver, so we could not find any downsides. Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd Cc Mark Brown > > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=43372 > > I had the chance to discuss this in more depth with Laurent last > week. What it basically comes down to is that you try to do something > that the existing DT binding and slave API does not support: we > only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV. > > To properly support this with the dmaengine API, we would likely first > need to extend the generic DT binding, and then implement the driver > to use that extended binding. > > The easiest way out however seems to be to move the audmapp > implementation into the rcar audio driver itself. As Laurent pointed > out, it is not really a general-purpose dmaengine anyway and it > only ever gets used by one driver, so we could not find any downsides. Hmm... OK I understand. Mark I try to move audmapp from current drivers/dma/sh/rcar-audmapp.c to sound/soc/sh/rcar/ Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 17 February 2015 00:10:10 Kuninori Morimoto wrote: > Hi Arnd > Cc Mark Brown > > > > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=43372 > > > > I had the chance to discuss this in more depth with Laurent last > > week. What it basically comes down to is that you try to do something > > that the existing DT binding and slave API does not support: we > > only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV. > > > > To properly support this with the dmaengine API, we would likely first > > need to extend the generic DT binding, and then implement the driver > > to use that extended binding. > > > > The easiest way out however seems to be to move the audmapp > > implementation into the rcar audio driver itself. As Laurent pointed > > out, it is not really a general-purpose dmaengine anyway and it > > only ever gets used by one driver, so we could not find any downsides. > > Hmm... OK I understand. > > Mark > > I try to move audmapp from current drivers/dma/sh/rcar-audmapp.c > to sound/soc/sh/rcar/ > Sounds good. I've thought some more about what it would really mean to support DMA_DEV_TO_DEV with the existing framework and binding. I believe we can actually do this with the existing DT binding if we really wanted to, but the dmaengine code would have to change. At the moment, we have struct dma_chan *dma_request_slave_channel_reason(struct device *dev, const char *name); as the main interface. What I think we would need is a respective interface that takes two separate names for source and sink, like struct dma_chan *dma_request_dev_to_dev_channel(struct device *dev, const char *source, const char *sink); Then you'd list all available sources and all sinks separately in the device node for the audio device and combine the ones you need. Making this particular device specific to the audio driver is still much easier, I just wanted to ensure we document it here in case we need the same functionality later for something else. There seems to be some weird workaround for a related problem in sound/soc/fsl/fsl_asrc_dma.c, which tries to get two channels individually, and then puts them into a private datas structre and filter function to get a third channel that is actually being used. Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 17, 2015 at 03:09:41PM +0100, Arnd Bergmann wrote: > I've thought some more about what it would really mean to support > DMA_DEV_TO_DEV with the existing framework and binding. I believe > we can actually do this with the existing DT binding if we really > wanted to, but the dmaengine code would have to change. At the > moment, we have > > struct dma_chan *dma_request_slave_channel_reason(struct device *dev, > const char *name); > > as the main interface. What I think we would need is a respective > interface that takes two separate names for source and sink, like > > struct dma_chan *dma_request_dev_to_dev_channel(struct device *dev, > const char *source, > const char *sink); > > Then you'd list all available sources and all sinks separately > in the device node for the audio device and combine the ones you > need. > > Making this particular device specific to the audio driver is > still much easier, I just wanted to ensure we document it here > in case we need the same functionality later for something else. > > There seems to be some weird workaround for a related problem > in sound/soc/fsl/fsl_asrc_dma.c, which tries to get two channels > individually, and then puts them into a private datas structre > and filter function to get a third channel that is actually being > used. The fsl_asrc_dma was implemented upon ASoC DPCM -- it's using ASRC (it has 3 pairs) as the Front-end and one of possible Back-ends (several I2S controllers or a SPDIF controller). So its DMA channel of the Front-end is based on which ASRC pair the ASRC driver assigns while the Back-end is totally according to which Back-end controller the DAI link is using. It means the driver has to dynamically fetch them at runtime and overwrite the configurations in order to request corresponding DMA channels on the fly. Generic DMA engine looks more perfect to deal with static channel assignments: even the dma_request_dev_to_dev_channel() above is also seemly a bit tough to apply to ASRC's case unless we list all the possible Back-ends in the DT and select one of names of Back-ends based on the controller being used at runtime, although listing all the Back-ends doesn't sound too much unreasonable. Best regards, Nicolin -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd Thank you for your feedback > I've thought some more about what it would really mean to support > DMA_DEV_TO_DEV with the existing framework and binding. I believe > we can actually do this with the existing DT binding if we really > wanted to, but the dmaengine code would have to change. At the > moment, we have > > struct dma_chan *dma_request_slave_channel_reason(struct device *dev, > const char *name); > > as the main interface. What I think we would need is a respective > interface that takes two separate names for source and sink, like > > struct dma_chan *dma_request_dev_to_dev_channel(struct device *dev, > const char *source, > const char *sink); > > Then you'd list all available sources and all sinks separately > in the device node for the audio device and combine the ones you > need. > > Making this particular device specific to the audio driver is > still much easier, I just wanted to ensure we document it here > in case we need the same functionality later for something else. Ahh... Actually I didn't 100% understand about your concern of DT bindings. but, now I could. Thank you for your explain Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 16, 2015 at 08:47:00PM +0100, Arnd Bergmann wrote: > On Monday 09 February 2015 01:37:41 Kuninori Morimoto wrote: > > > > Hi Vinod, Arnd > > > > Can I have feedback from you about below mail, and this patch ? > > > > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=43372 > > I had the chance to discuss this in more depth with Laurent last > week. What it basically comes down to is that you try to do something > that the existing DT binding and slave API does not support: we > only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV. For the record, device_prep_slave_sg() can do DMA_DEV_TO_DEV. That is the sole reason why dma_slave_config has both the directions for every field. HTH
diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig index 8190ad2..41e5c97 100644 --- a/drivers/dma/sh/Kconfig +++ b/drivers/dma/sh/Kconfig @@ -53,7 +53,8 @@ config RCAR_HPB_DMAE config RCAR_AUDMAC_PP tristate "Renesas R-Car Audio DMAC Peripheral Peripheral support" - depends on SH_DMAE_BASE + depends on ARCH_SHMOBILE || COMPILE_TEST + select RENESAS_DMA help Enable support for the Renesas R-Car Audio DMAC Peripheral Peripheral controllers. diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c index d95bbdd..b39e388 100644 --- a/drivers/dma/sh/rcar-audmapp.c +++ b/drivers/dma/sh/rcar-audmapp.c @@ -18,14 +18,10 @@ * */ #include <linux/delay.h> -#include <linux/init.h> #include <linux/module.h> -#include <linux/slab.h> -#include <linux/dmaengine.h> #include <linux/of_dma.h> -#include <linux/platform_data/dma-rcar-audmapp.h> #include <linux/platform_device.h> -#include <linux/shdma-base.h> +#include "../dmaengine.h" /* * DMA register @@ -41,317 +37,286 @@ /* Default MEMCPY transfer size = 2^2 = 4 bytes */ #define LOG2_DEFAULT_XFER_SIZE 2 -#define AUDMAPP_SLAVE_NUMBER 256 -#define AUDMAPP_LEN_MAX (16 * 1024 * 1024) +struct audmapp_priv; struct audmapp_chan { - struct shdma_chan shdma_chan; - void __iomem *base; - dma_addr_t slave_addr; + struct dma_chan chan; + struct dma_async_tx_descriptor async_tx; + + dma_addr_t src; + dma_addr_t dst; u32 chcr; -}; -struct audmapp_device { - struct shdma_dev shdma_dev; - struct audmapp_pdata *pdata; - struct device *dev; - void __iomem *chan_reg; + int id; }; -struct audmapp_desc { - struct shdma_desc shdma_desc; - dma_addr_t src; - dma_addr_t dst; +struct audmapp_priv { + struct dma_device dma; + void __iomem *achan_reg; + + struct audmapp_chan achan[AUDMAPP_MAX_CHANNELS]; }; -#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan) +#define chan_to_achan(chan) container_of(chan, struct audmapp_chan, chan) +#define achan_to_priv(achan) container_of(achan - achan->id, \ + struct audmapp_priv, achan[0]) + +#define priv_to_dev(priv) ((priv)->dma.dev) +#define priv_to_dma(priv) (&(priv)->dma) -#define to_chan(chan) container_of(chan, struct audmapp_chan, shdma_chan) -#define to_desc(sdesc) container_of(sdesc, struct audmapp_desc, shdma_desc) -#define to_dev(chan) container_of(chan->shdma_chan.dma_chan.device, \ - struct audmapp_device, shdma_dev.dma_dev) +#define audmapp_reg(achan, _reg) (achan_to_priv(achan)->achan_reg + \ + 0x20 + (0x10 * achan->id) + _reg) -static void audmapp_write(struct audmapp_chan *auchan, u32 data, u32 reg) +#define audmapp_for_each_achan(achan, priv, i) \ + for (i = 0; \ + (i < AUDMAPP_MAX_CHANNELS && ((achan) = priv->achan + i)); \ + i++) + +static void audmapp_write(struct audmapp_chan *achan, u32 data, u32 _reg) { - struct audmapp_device *audev = to_dev(auchan); - struct device *dev = audev->dev; + struct audmapp_priv *priv = achan_to_priv(achan); + struct device *dev = priv_to_dev(priv); + void __iomem *reg = audmapp_reg(achan, _reg); - dev_dbg(dev, "w %p : %08x\n", auchan->base + reg, data); + dev_dbg(dev, "w %p : %08x\n", reg, data); - iowrite32(data, auchan->base + reg); + iowrite32(data, reg); } -static u32 audmapp_read(struct audmapp_chan *auchan, u32 reg) +static u32 audmapp_read(struct audmapp_chan *achan, u32 _reg) { - return ioread32(auchan->base + reg); + return ioread32(audmapp_reg(achan, _reg)); } -static void audmapp_halt(struct shdma_chan *schan) +static void audmapp_halt(struct audmapp_chan *achan) { - struct audmapp_chan *auchan = to_chan(schan); int i; - audmapp_write(auchan, 0, PDMACHCR); + audmapp_write(achan, 0, PDMACHCR); for (i = 0; i < 1024; i++) { - if (0 == audmapp_read(auchan, PDMACHCR)) + if (0 == audmapp_read(achan, PDMACHCR)) return; udelay(1); } } -static void audmapp_start_xfer(struct shdma_chan *schan, - struct shdma_desc *sdesc) +static int audmapp_alloc_chan_resources(struct dma_chan *chan) { - struct audmapp_chan *auchan = to_chan(schan); - struct audmapp_device *audev = to_dev(auchan); - struct audmapp_desc *desc = to_desc(sdesc); - struct device *dev = audev->dev; - u32 chcr = auchan->chcr | PDMACHCR_DE; + if (chan->private) + return -ENODEV; - dev_dbg(dev, "src/dst/chcr = %pad/%pad/%08x\n", - &desc->src, &desc->dst, chcr); + chan->private = chan_to_achan(chan); - audmapp_write(auchan, desc->src, PDMASAR); - audmapp_write(auchan, desc->dst, PDMADAR); - audmapp_write(auchan, chcr, PDMACHCR); + return 0; } -static int audmapp_get_config(struct audmapp_chan *auchan, int slave_id, - u32 *chcr, dma_addr_t *dst) +static void audmapp_free_chan_resources(struct dma_chan *chan) { - struct audmapp_device *audev = to_dev(auchan); - struct audmapp_pdata *pdata = audev->pdata; - struct audmapp_slave_config *cfg; - int i; - - *chcr = 0; - *dst = 0; - - if (!pdata) { /* DT */ - *chcr = ((u32)slave_id) << 16; - auchan->shdma_chan.slave_id = (slave_id) >> 8; - return 0; - } - - /* non-DT */ - - if (slave_id >= AUDMAPP_SLAVE_NUMBER) - return -ENXIO; - - for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++) - if (cfg->slave_id == slave_id) { - *chcr = cfg->chcr; - *dst = cfg->dst; - return 0; - } - - return -ENXIO; + chan->private = NULL; } -static int audmapp_set_slave(struct shdma_chan *schan, int slave_id, - dma_addr_t slave_addr, bool try) +static struct dma_async_tx_descriptor * +audmapp_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, + size_t buf_len, size_t period_len, + enum dma_transfer_direction dir, unsigned long flags) { - struct audmapp_chan *auchan = to_chan(schan); - u32 chcr; - dma_addr_t dst; - int ret; - - ret = audmapp_get_config(auchan, slave_id, &chcr, &dst); - if (ret < 0) - return ret; - - if (try) - return 0; - - auchan->chcr = chcr; - auchan->slave_addr = slave_addr ? : dst; + struct audmapp_chan *achan = chan_to_achan(chan); - return 0; + return &achan->async_tx; } -static int audmapp_desc_setup(struct shdma_chan *schan, - struct shdma_desc *sdesc, - dma_addr_t src, dma_addr_t dst, size_t *len) +static void audmapp_slave_config(struct audmapp_chan *achan, + struct dma_slave_config *cfg) { - struct audmapp_desc *desc = to_desc(sdesc); - - if (*len > (size_t)AUDMAPP_LEN_MAX) - *len = (size_t)AUDMAPP_LEN_MAX; - - desc->src = src; - desc->dst = dst; - - return 0; + achan->src = cfg->src_addr; + achan->dst = cfg->dst_addr; } -static void audmapp_setup_xfer(struct shdma_chan *schan, - int slave_id) +static int audmapp_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd, + unsigned long arg) { + struct audmapp_chan *achan = chan_to_achan(chan); + + switch (cmd) { + case DMA_TERMINATE_ALL: + audmapp_halt(achan); + break; + case DMA_SLAVE_CONFIG: + audmapp_slave_config(achan, (struct dma_slave_config *)arg); + break; + default: + return -ENXIO; + } + + return 0; } -static dma_addr_t audmapp_slave_addr(struct shdma_chan *schan) +static enum dma_status audmapp_tx_status(struct dma_chan *chan, + dma_cookie_t cookie, + struct dma_tx_state *txstate) { - struct audmapp_chan *auchan = to_chan(schan); - - return auchan->slave_addr; + return dma_cookie_status(chan, cookie, txstate); } -static bool audmapp_channel_busy(struct shdma_chan *schan) +static void audmapp_issue_pending(struct dma_chan *chan) { - struct audmapp_chan *auchan = to_chan(schan); - u32 chcr = audmapp_read(auchan, PDMACHCR); + struct audmapp_chan *achan = chan_to_achan(chan); + struct audmapp_priv *priv = achan_to_priv(achan); + struct device *dev = priv_to_dev(priv); + u32 chcr = achan->chcr | PDMACHCR_DE; - return chcr & ~PDMACHCR_DE; -} + dev_dbg(dev, "src/dst/chcr = %pad/%pad/%08x\n", + &achan->src, &achan->dst, chcr); -static bool audmapp_desc_completed(struct shdma_chan *schan, - struct shdma_desc *sdesc) -{ - return true; + audmapp_write(achan, achan->src, PDMASAR); + audmapp_write(achan, achan->dst, PDMADAR); + audmapp_write(achan, chcr, PDMACHCR); } -static struct shdma_desc *audmapp_embedded_desc(void *buf, int i) +static bool audmapp_chan_filter(struct dma_chan *chan, void *arg) { - return &((struct audmapp_desc *)buf)[i].shdma_desc; + struct dma_device *dma = chan->device; + struct of_phandle_args *dma_spec = arg; + + /* + * FIXME: Using a filter on OF platforms is a nonsense. The OF xlate + * function knows from which device it wants to allocate a channel from, + * and would be perfectly capable of selecting the channel it wants. + * Forcing it to call dma_request_channel() and iterate through all + * channels from all controllers is just pointless. + */ + if (dma->device_control != audmapp_control || + dma_spec->np != dma->dev->of_node) + return false; + + /* + * see + * audmapp_alloc_chan_resources() + * audmapp_free_chan_resources() + */ + return !chan->private; } -static const struct shdma_ops audmapp_shdma_ops = { - .halt_channel = audmapp_halt, - .desc_setup = audmapp_desc_setup, - .set_slave = audmapp_set_slave, - .start_xfer = audmapp_start_xfer, - .embedded_desc = audmapp_embedded_desc, - .setup_xfer = audmapp_setup_xfer, - .slave_addr = audmapp_slave_addr, - .channel_busy = audmapp_channel_busy, - .desc_completed = audmapp_desc_completed, -}; - -static int audmapp_chan_probe(struct platform_device *pdev, - struct audmapp_device *audev, int id) +static struct dma_chan *audmapp_of_xlate(struct of_phandle_args *dma_spec, + struct of_dma *ofdma) { - struct shdma_dev *sdev = &audev->shdma_dev; - struct audmapp_chan *auchan; - struct shdma_chan *schan; - struct device *dev = audev->dev; + struct audmapp_chan *achan; + struct dma_chan *chan; + dma_cap_mask_t mask; - auchan = devm_kzalloc(dev, sizeof(*auchan), GFP_KERNEL); - if (!auchan) - return -ENOMEM; + if (dma_spec->args_count != 1) + return NULL; - schan = &auchan->shdma_chan; - schan->max_xfer_len = AUDMAPP_LEN_MAX; + dma_cap_zero(mask); + dma_cap_set(DMA_SLAVE, mask); - shdma_chan_probe(sdev, schan, id); + chan = dma_request_channel(mask, audmapp_chan_filter, dma_spec); + if (!chan) + return NULL; - auchan->base = audev->chan_reg + 0x20 + (0x10 * id); - dev_dbg(dev, "%02d : %p / %p", id, auchan->base, audev->chan_reg); + achan = chan_to_achan(chan); + achan->chcr = dma_spec->args[0] << 16; - return 0; + return chan; } -static void audmapp_chan_remove(struct audmapp_device *audev) +static dma_cookie_t audmapp_tx_submit(struct dma_async_tx_descriptor *tx) { - struct shdma_chan *schan; - int i; - - shdma_for_each_chan(schan, &audev->shdma_dev, i) { - BUG_ON(!schan); - shdma_chan_remove(schan); - } + return dma_cookie_assign(tx); } -static struct dma_chan *audmapp_of_xlate(struct of_phandle_args *dma_spec, - struct of_dma *ofdma) +static int audmapp_chan_desc_probe(struct platform_device *pdev, + struct audmapp_priv *priv) + { - dma_cap_mask_t mask; + struct dma_device *dma = priv_to_dma(priv); + struct device *dev = priv_to_dev(priv); + struct audmapp_chan *achan; struct dma_chan *chan; - u32 chcr = dma_spec->args[0]; + int i; - if (dma_spec->args_count != 1) - return NULL; + audmapp_for_each_achan(achan, priv, i) { + chan = &achan->chan; - dma_cap_zero(mask); - dma_cap_set(DMA_SLAVE, mask); + achan->id = i; - chan = dma_request_channel(mask, shdma_chan_filter, NULL); - if (chan) - to_shdma_chan(chan)->hw_req = chcr; + /* + * Initialize the DMA engine channel and add it to the DMA + * engine channels list. + */ + chan->private = NULL; + chan->device = dma; + dma_cookie_init(chan); + list_add_tail(&chan->device_node, &dma->channels); - return chan; + achan->async_tx.tx_submit = audmapp_tx_submit; + dma_async_tx_descriptor_init(&achan->async_tx, chan); + + dev_dbg(dev, "%02d : %p\n", i, audmapp_reg(achan, 0)); + } + + return 0; } static int audmapp_probe(struct platform_device *pdev) { - struct audmapp_pdata *pdata = pdev->dev.platform_data; - struct device_node *np = pdev->dev.of_node; - struct audmapp_device *audev; - struct shdma_dev *sdev; - struct dma_device *dma_dev; + struct device *dev = &pdev->dev; + struct audmapp_priv *priv; + struct dma_device *dma; struct resource *res; - int err, i; + int ret; - if (np) - of_dma_controller_register(np, audmapp_of_xlate, pdev); - else if (!pdata) - return -ENODEV; + of_dma_controller_register(dev->of_node, audmapp_of_xlate, pdev); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - audev = devm_kzalloc(&pdev->dev, sizeof(*audev), GFP_KERNEL); - if (!audev) + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) return -ENOMEM; - audev->dev = &pdev->dev; - audev->pdata = pdata; - audev->chan_reg = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(audev->chan_reg)) - return PTR_ERR(audev->chan_reg); + priv->achan_reg = devm_ioremap_resource(dev, res); + if (IS_ERR(priv->achan_reg)) + return PTR_ERR(priv->achan_reg); - sdev = &audev->shdma_dev; - sdev->ops = &audmapp_shdma_ops; - sdev->desc_size = sizeof(struct audmapp_desc); + dev_dbg(dev, "%llx => %p\n", (u64)res->start, priv->achan_reg); - dma_dev = &sdev->dma_dev; - dma_dev->copy_align = LOG2_DEFAULT_XFER_SIZE; - dma_cap_set(DMA_SLAVE, dma_dev->cap_mask); + dma = priv_to_dma(priv); + dma->copy_align = LOG2_DEFAULT_XFER_SIZE; + INIT_LIST_HEAD(&dma->channels); + dma_cap_set(DMA_SLAVE, dma->cap_mask); - err = shdma_init(&pdev->dev, sdev, AUDMAPP_MAX_CHANNELS); - if (err < 0) - return err; + dma->device_alloc_chan_resources = audmapp_alloc_chan_resources; + dma->device_free_chan_resources = audmapp_free_chan_resources; + dma->device_prep_dma_cyclic = audmapp_prep_dma_cyclic; + dma->device_control = audmapp_control; + dma->device_tx_status = audmapp_tx_status; + dma->device_issue_pending = audmapp_issue_pending; + dma->dev = dev; - platform_set_drvdata(pdev, audev); + platform_set_drvdata(pdev, priv); - /* Create DMA Channel */ - for (i = 0; i < AUDMAPP_MAX_CHANNELS; i++) { - err = audmapp_chan_probe(pdev, audev, i); - if (err) - goto chan_probe_err; - } - - err = dma_async_device_register(dma_dev); - if (err < 0) - goto chan_probe_err; + ret = audmapp_chan_desc_probe(pdev, priv); + if (ret) + return ret; - return err; + ret = dma_async_device_register(dma); + if (ret) + return ret; -chan_probe_err: - audmapp_chan_remove(audev); - shdma_cleanup(sdev); + dev_info(dev, "probed\n"); - return err; + return ret; } static int audmapp_remove(struct platform_device *pdev) { - struct audmapp_device *audev = platform_get_drvdata(pdev); - struct dma_device *dma_dev = &audev->shdma_dev.dma_dev; + struct audmapp_priv *priv = platform_get_drvdata(pdev); + struct dma_device *dma = priv_to_dma(priv); - dma_async_device_unregister(dma_dev); + dma_async_device_unregister(dma); - audmapp_chan_remove(audev); - shdma_cleanup(&audev->shdma_dev); + of_dma_controller_free(pdev->dev.of_node); return 0; } diff --git a/include/linux/platform_data/dma-rcar-audmapp.h b/include/linux/platform_data/dma-rcar-audmapp.h deleted file mode 100644 index 471fffe..0000000 --- a/include/linux/platform_data/dma-rcar-audmapp.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * This is for Renesas R-Car Audio-DMAC-peri-peri. - * - * Copyright (C) 2014 Renesas Electronics Corporation - * Copyright (C) 2014 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> - * - * This file is based on the include/linux/sh_dma.h - * - * Header for the new SH dmaengine driver - * - * Copyright (C) 2010 Guennadi Liakhovetski <g.liakhovetski@gmx.de> - * - * 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 SH_AUDMAPP_H -#define SH_AUDMAPP_H - -#include <linux/dmaengine.h> - -struct audmapp_slave_config { - int slave_id; - dma_addr_t src; - dma_addr_t dst; - u32 chcr; -}; - -struct audmapp_pdata { - struct audmapp_slave_config *slave; - int slave_num; -}; - -#endif /* SH_AUDMAPP_H */