From: Arnd Bergmann <arnd@arndb.de> To: Kukjin Kim <kgene.kim@samsung.com>, 'Mark Brown' <broonie@opensource.wolfsonmicro.com> Cc: 'Olof Johansson' <olof@lixom.net>, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, 'Grant Likely' <grant.likely@secretlab.ca>, w.sang@pengutronix.de, Boojin Kim <boojin.kim@samsung.com>, Kyoungil Kim <ki0351.kim@samsung.com>, Vinod Koul <vinod.koul@intel.com>, Dan Williams <dan.j.williams@intel.com>, Ben Dooks <ben@simtec.co.uk> Subject: Re: [GIT PULL] Samsung devel-dma ops for v3.6 Date: Tue, 10 Jul 2012 12:42:41 +0000 [thread overview] Message-ID: <201207101242.41867.arnd@arndb.de> (raw) In-Reply-To: <0c5001cd5e41$87daa1b0$978fe510$%kim@samsung.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [GIT PULL] Samsung devel-dma ops for v3.6 Date: Tue, 10 Jul 2012 12:42:41 +0000 [thread overview] Message-ID: <201207101242.41867.arnd@arndb.de> (raw) In-Reply-To: <0c5001cd5e41$87daa1b0$978fe510$%kim@samsung.com> 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
next prev parent reply other threads:[~2012-07-10 12:42 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-10 2:13 [GIT PULL] Samsung devel-dma ops for v3.6 Kukjin Kim 2012-07-10 2:13 ` Kukjin Kim 2012-07-10 12:42 ` Arnd Bergmann [this message] 2012-07-10 12:42 ` Arnd Bergmann 2012-07-11 7:08 ` Kukjin Kim 2012-07-11 7:08 ` Kukjin Kim 2012-07-11 8:18 ` Arnd Bergmann 2012-07-11 8:18 ` Arnd Bergmann 2012-07-23 14:36 ` Linus Walleij 2012-07-23 14:36 ` Linus Walleij
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=201207101242.41867.arnd@arndb.de \ --to=arnd@arndb.de \ --cc=ben@simtec.co.uk \ --cc=boojin.kim@samsung.com \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=dan.j.williams@intel.com \ --cc=grant.likely@secretlab.ca \ --cc=kgene.kim@samsung.com \ --cc=ki0351.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=olof@lixom.net \ --cc=vinod.koul@intel.com \ --cc=w.sang@pengutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.