> >> > > 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) -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
