[PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default

[Peter Meerwald]

> >> > > 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)