From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Meerwald Subject: Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default Date: Fri, 24 Aug 2012 14:10:38 +0200 (CEST) Message-ID: References: <20120718071039.GI6522@atomide.com> <20120824094231.GA25765@n2100.arm.linux.org.uk> <20120824103913.GB25765@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: Received: from ns.pmeerw.net ([87.118.82.44]:46579 "EHLO pmeerw.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056Ab2HXMKk (ORCPT ); Fri, 24 Aug 2012 08:10:40 -0400 In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: "Shilimkar, Santosh" Cc: Russell King - ARM Linux , Javier Martinez Canillas , "S, Venkatraman" , Tony Lindgren , Javier Martinez Canillas , Kevin Hilman , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Chris Ball , linux-mmc@vger.kernel.org > >> > > the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in > >> > > omap2plus_defconfig; this does not help people updating the kernel while > >> > > keeping the config, nor does it help people in configuring the kernel > >> > > > >> > > there is a dependency (at least for beagleboard) between MMC_OMAP_HS and > >> > > DMA_OMAP, and I think this should be made explicit > >> > > >> > Well, this is where stuff starts to get really yucky, because that > >> > means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS > >> > as a module too. Or vice versa. Which is a real pain for further > >> > development of DMA_OMAP. > >> > > >> > Whatever, the solution here is NOT to add select statements to the > >> > Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. > >> > The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that > >> > will just mean that you'll end up with MMC_OMAP_HS disabled in your > >> > config witout DMA engine support. Another less desirable solution > >> > is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. > >> > >> Part of the patch [1] does the last part. > >> MMC_OMAP_HS select DMA engine and DMA_OMAP. > >> > >> Regards > >> Santosh > >> > >> [1] https://patchwork.kernel.org/patch/1203391/ > > > > Well, I never saw that patch. When I say "I'm going to be away for most > > of July, and I won't be reading email, and I won't catch up with email > > when I'm back" and when I get back I explicitly ask for stuff which needs > > my attention sending, that's hardly surprising... > > > > But anyway, as I said above, the "select" option is less desirable because > > it forces stuff. And if you've seen the kind of crap that you have to go > > through to figure out why the hell you can't disable an option, you'll > > understand why I consider that solution revolting. > > > > Take, for instance, a list of dependencies spits out by menuconfig that > > fills your entire screen, and you have to work out by reading carefully > > through 2K of characters which combination of options is forcing the one > > you want to turn off back on. That is why "select" used inappropriately > > is pure evil incarnate. > I fully agree on the select and it's undesirable side effects. > Since the polling mode isn't supported yet on OMAP MMC drivers, there > was no choice. As per the previous discussion on [1], MMC and SPI driver > folks are looking at supporting polling mode support which can remove > the force select needed for OMAP_DMA. with Linux 3.6-rc3: CONFIG_DMA_OMAP=m CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=m CONFIG_MMC_OMAP_HS=y CONFIG_SPI_OMAP24XX=y CONFIG_MTD_NAND_OMAP2=y LD init/built-in.o drivers/built-in.o: In function `omap2_mcspi_setup': /home/pmeerw/linux-pmeerw/drivers/spi/spi-omap2-mcspi.c:859: undefined reference to `omap_dma_filter_fn' drivers/built-in.o: In function `omap_nand_probe': /home/pmeerw/linux-pmeerw/drivers/mtd/nand/omap2.c:1371: undefined reference to `omap_dma_filter_fn' drivers/built-in.o: In function `omap_hsmmc_probe': /home/pmeerw/linux-pmeerw/drivers/mmc/host/omap_hsmmc.c:2039: undefined reference to `omap_dma_filter_fn' make: *** [vmlinux] Error 1 in addition to SPI and MMC, there seems to be also a NAND dependency regards, p. -- Peter Meerwald +43-664-2444418 (mobile) From mboxrd@z Thu Jan 1 00:00:00 1970 From: pmeerw@pmeerw.net (Peter Meerwald) Date: Fri, 24 Aug 2012 14:10:38 +0200 (CEST) Subject: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default In-Reply-To: References: <20120718071039.GI6522@atomide.com> <20120824094231.GA25765@n2100.arm.linux.org.uk> <20120824103913.GB25765@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > >> > > the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in > >> > > omap2plus_defconfig; this does not help people updating the kernel while > >> > > keeping the config, nor does it help people in configuring the kernel > >> > > > >> > > there is a dependency (at least for beagleboard) between MMC_OMAP_HS and > >> > > DMA_OMAP, and I think this should be made explicit > >> > > >> > Well, this is where stuff starts to get really yucky, because that > >> > means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS > >> > as a module too. Or vice versa. Which is a real pain for further > >> > development of DMA_OMAP. > >> > > >> > Whatever, the solution here is NOT to add select statements to the > >> > Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. > >> > The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that > >> > will just mean that you'll end up with MMC_OMAP_HS disabled in your > >> > config witout DMA engine support. Another less desirable solution > >> > is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. > >> > >> Part of the patch [1] does the last part. > >> MMC_OMAP_HS select DMA engine and DMA_OMAP. > >> > >> Regards > >> Santosh > >> > >> [1] https://patchwork.kernel.org/patch/1203391/ > > > > Well, I never saw that patch. When I say "I'm going to be away for most > > of July, and I won't be reading email, and I won't catch up with email > > when I'm back" and when I get back I explicitly ask for stuff which needs > > my attention sending, that's hardly surprising... > > > > But anyway, as I said above, the "select" option is less desirable because > > it forces stuff. And if you've seen the kind of crap that you have to go > > through to figure out why the hell you can't disable an option, you'll > > understand why I consider that solution revolting. > > > > Take, for instance, a list of dependencies spits out by menuconfig that > > fills your entire screen, and you have to work out by reading carefully > > through 2K of characters which combination of options is forcing the one > > you want to turn off back on. That is why "select" used inappropriately > > is pure evil incarnate. > I fully agree on the select and it's undesirable side effects. > Since the polling mode isn't supported yet on OMAP MMC drivers, there > was no choice. As per the previous discussion on [1], MMC and SPI driver > folks are looking at supporting polling mode support which can remove > the force select needed for OMAP_DMA. with Linux 3.6-rc3: CONFIG_DMA_OMAP=m CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=m CONFIG_MMC_OMAP_HS=y CONFIG_SPI_OMAP24XX=y CONFIG_MTD_NAND_OMAP2=y LD init/built-in.o drivers/built-in.o: In function `omap2_mcspi_setup': /home/pmeerw/linux-pmeerw/drivers/spi/spi-omap2-mcspi.c:859: undefined reference to `omap_dma_filter_fn' drivers/built-in.o: In function `omap_nand_probe': /home/pmeerw/linux-pmeerw/drivers/mtd/nand/omap2.c:1371: undefined reference to `omap_dma_filter_fn' drivers/built-in.o: In function `omap_hsmmc_probe': /home/pmeerw/linux-pmeerw/drivers/mmc/host/omap_hsmmc.c:2039: undefined reference to `omap_dma_filter_fn' make: *** [vmlinux] Error 1 in addition to SPI and MMC, there seems to be also a NAND dependency regards, p. -- Peter Meerwald +43-664-2444418 (mobile)