| Message ID | 0c5001cd5e41$87daa1b0$978fe510$%kim@samsung.com |
|---|---|
| State | New |
| Headers | show |
On Tuesday 10 July 2012, Kukjin Kim wrote: > Hi Arnd, Olof, > > Here is updating DMA common operation for Samsung SoCs. > > Since some DMA client driver such as spi needs to change the configuration > after dma_request() so this branch adds dma_config() can configure DMA > transmit option which is included in dma_request() after that. > > Note, according to the changes, needs to update spi and ASoC drivers for > Samsung SoCs and only got the ack from Mark Brown not Grant Likely and as I > know, he is busy for moving. But I think, the spi change has no problem and > it is simple. > > If any problems, please kindly let me know. > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next/devel-dma-ops I've applied this to a new next/dma branch for now, as it sounds that you need these changes. However, my feeling is that the s3c-dma-ops support is moving in the wrong direction, or at least I do not see where you're heading with it. >From what I see, there is the * arch/arm/plat-s3c24xx/dma.c driver with a proprietary s3c2410_dma_* interface, used by s3cmci and some asoc drivers. * arch/arm/mach-s3c64xx/dma.c implementing the same interface and exporting the same symbols. * The arch/arm/plat-samsung/dma-ops.c which is a wrapper around the generic dmaengine API, hardcoding the pl330 DMA driver * The arch/arm/plat-samsung/include/plat/dma-ops.h interface abstraction that gets used to pick between the two at compile time, and being used by the spi driver and again other asoc drivers Can you (or someone on the Cc list) explain what the plan is for this? Are you moving over the s3c2410_dma*() function to a dmaengine driver eventually? Do you expect to see more users of the nonstandard intefaces in the samsung code, or are they going away? Arnd
Arnd Bergmann wrote: > > On Tuesday 10 July 2012, Kukjin Kim wrote: > > Hi Arnd, Olof, > > > > Here is updating DMA common operation for Samsung SoCs. > > > > Since some DMA client driver such as spi needs to change the > configuration > > after dma_request() so this branch adds dma_config() can configure DMA > > transmit option which is included in dma_request() after that. > > > > Note, according to the changes, needs to update spi and ASoC drivers for > > Samsung SoCs and only got the ack from Mark Brown not Grant Likely and > as I > > know, he is busy for moving. But I think, the spi change has no problem > and > > it is simple. > > > > If any problems, please kindly let me know. > > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > next/devel-dma-ops > > I've applied this to a new next/dma branch for now, as it sounds that you > need these changes. > Arnd, thanks. > However, my feeling is that the s3c-dma-ops support is moving in the wrong > direction, or at least I do not see where you're heading with it. > > From what I see, there is the > > * arch/arm/plat-s3c24xx/dma.c driver with a proprietary s3c2410_dma_* > interface, used by s3cmci and some asoc drivers. > * arch/arm/mach-s3c64xx/dma.c implementing the same interface and > exporting > the same symbols. > * The arch/arm/plat-samsung/dma-ops.c which is a wrapper around the > generic > dmaengine API, hardcoding the pl330 DMA driver > * The arch/arm/plat-samsung/include/plat/dma-ops.h interface abstraction > that gets used to pick between the two at compile time, and being used > by > the spi driver and again other asoc drivers > > Can you (or someone on the Cc list) explain what the plan is for this? > Are you moving over the s3c2410_dma*() function to a dmaengine driver > eventually? Do you expect to see more users of the nonstandard intefaces > in the samsung code, or are they going away? > Yeah, let me explain the status for Samsung SoCs' DMA. There are 3 different DMA IPs, samsung specific s3c24xx dma, pl080 and pl330. As you know, pl330 already moved in drivers/dma for using common DMA engine and Alim is re-working on pl080 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg10954.html ) and let me check its progress. But s3c24xx dma is not ready yet. When pl330 was moving, my colleague, Boojin Kim posted to use common DMA APIs for Samsung drivers which are using DMA such as spi and ASoC. But it was including too many ifdef for checking which DMA is used and it can occur breakage for multiplatform (http://www.spinics.net/lists/arm-kernel/msg131137.html). So we implemented to use some dma_ops after discussing with Grant Likely (http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/058171.html ). Anyway, we will try to use common DMA APIs for all Samsung SoCs. But need more time ;) Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
On Wednesday 11 July 2012, Kukjin Kim wrote: > Yeah, let me explain the status for Samsung SoCs' DMA. There are 3 different > DMA IPs, samsung specific s3c24xx dma, pl080 and pl330. As you know, pl330 > already moved in drivers/dma for using common DMA engine and Alim is > re-working on pl080 > (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg10954.html > ) and let me check its progress. But s3c24xx dma is not ready yet. When > pl330 was moving, my colleague, Boojin Kim posted to use common DMA APIs for > Samsung drivers which are using DMA such as spi and ASoC. But it was > including too many ifdef for checking which DMA is used and it can occur > breakage for multiplatform > (http://www.spinics.net/lists/arm-kernel/msg131137.html). So we implemented > to use some dma_ops after discussing with Grant Likely > (http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/058171.html > ). > > Anyway, we will try to use common DMA APIs for all Samsung SoCs. But need > more time ;) Ok, sounds good. Thanks for the background information! Arnd
2012/7/11 Kukjin Kim <kgene.kim@samsung.com>: > Yeah, let me explain the status for Samsung SoCs' DMA. There are 3 different > DMA IPs, samsung specific s3c24xx dma, pl080 and pl330. As you know, pl330 > already moved in drivers/dma for using common DMA engine and Alim is > re-working on pl080 > (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg10954.html > ) and let me check its progress. But s3c24xx dma is not ready yet. I'm going to poke again on this. I think a bunch of changes to the PL080 driver from Russell is going upstream this merge window and the S3C patch series need to be rebased onto that, but it should be pretty straight-forward. Can we please have something moving the S3C over to dmaengine *early* next kernel cycle? Yours, Linus Walleij
Hi Arnd, Olof, Here is updating DMA common operation for Samsung SoCs. Since some DMA client driver such as spi needs to change the configuration after dma_request() so this branch adds dma_config() can configure DMA transmit option which is included in dma_request() after that. Note, according to the changes, needs to update spi and ASoC drivers for Samsung SoCs and only got the ack from Mark Brown not Grant Likely and as I know, he is busy for moving. But I think, the spi change has no problem and it is simple. If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next/devel-dma-ops Boojin Kim (3): ARM: SAMSUNG: Add config() function in DMA common operations spi/s3c64xx: Add the use of DMA config operation ASoC: follow the updated samsung DMA common operations Sachin Kamat (1): ARM: SAMSUNG: Fix compiler warning in dma-ops.c file arch/arm/plat-samsung/dma-ops.c | 76 ++++++++++++++------------ arch/arm/plat-samsung/include/plat/dma-ops.h | 20 ++++--- arch/arm/plat-samsung/s3c-dma-ops.c | 39 ++++++++------ drivers/spi/spi-s3c64xx.c | 33 +++++++----- sound/soc/samsung/dma.c | 18 ++++--- 5 files changed, 105 insertions(+), 81 deletions(-)