From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shilimkar, Santosh" Subject: Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default Date: Fri, 24 Aug 2012 16:15:26 +0530 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=ISO-8859-1 Return-path: In-Reply-To: <20120824103913.GB25765@n2100.arm.linux.org.uk> Sender: linux-omap-owner@vger.kernel.org To: Russell King - ARM Linux Cc: Peter Meerwald , 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 List-Id: linux-mmc@vger.kernel.org On Fri, Aug 24, 2012 at 4:09 PM, Russell King - ARM Linux wrote: > On Fri, Aug 24, 2012 at 03:51:26PM +0530, Shilimkar, Santosh wrote: >> On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux >> wrote: >> > >> > On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: >> > > 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. Regards santosh Regards Santosh From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Shilimkar, Santosh) Date: Fri, 24 Aug 2012 16:15:26 +0530 Subject: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default In-Reply-To: <20120824103913.GB25765@n2100.arm.linux.org.uk> 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 On Fri, Aug 24, 2012 at 4:09 PM, Russell King - ARM Linux wrote: > On Fri, Aug 24, 2012 at 03:51:26PM +0530, Shilimkar, Santosh wrote: >> On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux >> wrote: >> > >> > On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: >> > > 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. Regards santosh Regards Santosh