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

[Shilimkar, Santosh]

On Fri, Aug 24, 2012 at 4:09 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> 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
>> <linux at arm.linux.org.uk> 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