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

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

[Shilimkar, Santosh]

Hi,

On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
> engine API instead of the previous private DMA API implementation.
>
> So, if the kernel is built with support for any of these hosts but it
> doesn't support DMA devices nor OMAP DMA support, it fails when trying
> to obtain a DMA channel which leads to the following error on an OMAP3
> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>
> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>
> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>
> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> ---
Considering, we are updating drivers to select the DMA engine, can you
also include
"drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.

Regards
Santosh

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

[Javier Martinez Canillas]

On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> Hi,
>
> On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>> engine API instead of the previous private DMA API implementation.
>>
>> So, if the kernel is built with support for any of these hosts but it
>> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>> to obtain a DMA channel which leads to the following error on an OMAP3
>> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>>
>> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>
>> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>> ---
> Considering, we are updating drivers to select the DMA engine, can you
> also include
> "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>
> Regards
> Santosh

Hi Santosh,

Ok, I'll send a v2 now which includes spi-omap2-mcspi then.

Thanks a lot and best regards,
Javier

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

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
> > Hi,
> >
> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
> > <javier@dowhile0.org> wrote:
> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
> >> engine API instead of the previous private DMA API implementation.
> >>
> >> So, if the kernel is built with support for any of these hosts but it
> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
> >> to obtain a DMA channel which leads to the following error on an OMAP3
> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
> >>
> >> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> >>
> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
> >>
> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> >> ---
> > Considering, we are updating drivers to select the DMA engine, can you
> > also include
> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
> >
> > Regards
> > Santosh
> 
> Hi Santosh,
> 
> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.

I don't think we should do this, the drivers should work with and without
dma. This just needs to be added to the omap2plus_defconfig.

Regards,

Tony

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

[Shilimkar, Santosh]

On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>> <santosh.shilimkar@ti.com> wrote:
>> > Hi,
>> >
>> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>> > <javier@dowhile0.org> wrote:
>> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>> >> engine API instead of the previous private DMA API implementation.
>> >>
>> >> So, if the kernel is built with support for any of these hosts but it
>> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>> >> to obtain a DMA channel which leads to the following error on an OMAP3
>> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>> >>
>> >> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> >>
>> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>> >>
>> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>> >> ---
>> > Considering, we are updating drivers to select the DMA engine, can you
>> > also include
>> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>> >
>> > Regards
>> > Santosh
>>
>> Hi Santosh,
>>
>> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>
> I don't think we should do this, the drivers should work with and without
> dma. This just needs to be added to the omap2plus_defconfig.
>
Well this was not decided based on any DMA CONFIG option before for
the subject drivers. It is already by default enabled if the DMA is supported
by the driver IP. There is a possibility to disable it from driver platform/dt
data so that still remains.

Regards
Santosh

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

[Tony Lindgren]

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
> >> <santosh.shilimkar@ti.com> wrote:
> >> > Hi,
> >> >
> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
> >> > <javier@dowhile0.org> wrote:
> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
> >> >> engine API instead of the previous private DMA API implementation.
> >> >>
> >> >> So, if the kernel is built with support for any of these hosts but it
> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
> >> >>
> >> >> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> >> >>
> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
> >> >>
> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> >> >> ---
> >> > Considering, we are updating drivers to select the DMA engine, can you
> >> > also include
> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
> >> >
> >> > Regards
> >> > Santosh
> >>
> >> Hi Santosh,
> >>
> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
> >
> > I don't think we should do this, the drivers should work with and without
> > dma. This just needs to be added to the omap2plus_defconfig.
> >
> Well this was not decided based on any DMA CONFIG option before for
> the subject drivers. It is already by default enabled if the DMA is supported
> by the driver IP. There is a possibility to disable it from driver platform/dt
> data so that still remains.

I think it should rather be that if the driver is broken and does not work
without DMA, it should have depends on CONFIG_DMA_OMAP.

Regards,

Tony

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

[S, Venkatraman]

On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>> >> <santosh.shilimkar@ti.com> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>> >> > <javier@dowhile0.org> wrote:
>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>> >> >> engine API instead of the previous private DMA API implementation.
>> >> >>
>> >> >> So, if the kernel is built with support for any of these hosts but it
>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>> >> >>
>> >> >> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> >> >>
>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>> >> >>
>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>> >> >> ---
>> >> > Considering, we are updating drivers to select the DMA engine, can you
>> >> > also include
>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>> >> >
>> >> > Regards
>> >> > Santosh
>> >>
>> >> Hi Santosh,
>> >>
>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>> >
>> > I don't think we should do this, the drivers should work with and without
>> > dma. This just needs to be added to the omap2plus_defconfig.
>> >
>> Well this was not decided based on any DMA CONFIG option before for
>> the subject drivers. It is already by default enabled if the DMA is supported
>> by the driver IP. There is a possibility to disable it from driver platform/dt
>> data so that still remains.
>
> I think it should rather be that if the driver is broken and does not work
> without DMA, it should have depends on CONFIG_DMA_OMAP.
>
I can confirm that omap MMC can't work without DMA; polled mode is not
supported / implemented.

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

[Shilimkar, Santosh]

On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com> wrote:
> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>>> >> <santosh.shilimkar@ti.com> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>>> >> > <javier@dowhile0.org> wrote:
>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>>> >> >> engine API instead of the previous private DMA API implementation.
>>> >> >>
>>> >> >> So, if the kernel is built with support for any of these hosts but it
>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>>> >> >>
>>> >> >> [    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>> >> >>
>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>>> >> >>
>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>>> >> >> ---
>>> >> > Considering, we are updating drivers to select the DMA engine, can you
>>> >> > also include
>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>>> >> >
>>> >> > Regards
>>> >> > Santosh
>>> >>
>>> >> Hi Santosh,
>>> >>
>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>>> >
>>> > I don't think we should do this, the drivers should work with and without
>>> > dma. This just needs to be added to the omap2plus_defconfig.
>>> >
>>> Well this was not decided based on any DMA CONFIG option before for
>>> the subject drivers. It is already by default enabled if the DMA is supported
>>> by the driver IP. There is a possibility to disable it from driver platform/dt
>>> data so that still remains.
>>
>> I think it should rather be that if the driver is broken and does not work
>> without DMA, it should have depends on CONFIG_DMA_OMAP.
>>
> I can confirm that omap MMC can't work without DMA; polled mode is not
> supported / implemented.

Same case for SPI driver as well. It uses DMA for everything except the cases
where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable,

At least considering this, it is better we do this per driver than enabling
it at SOC config.

Regards
Santosh

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

[Javier Martinez Canillas]

On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
>>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>>>> >> <santosh.shilimkar@ti.com> wrote:
>>>> >> > Hi,
>>>> >> >
>>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>>>> >> > <javier@dowhile0.org> wrote:
>>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>>>> >> >> engine API instead of the previous private DMA API implementation.
>>>> >> >>
>>>> >> >> So, if the kernel is built with support for any of these hosts but it
>>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>>>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>>>> >> >>
>>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>>> >> >>
>>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>>>> >> >>
>>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>>>> >> >> ---
>>>> >> > Considering, we are updating drivers to select the DMA engine, can you
>>>> >> > also include
>>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>>>> >> >
>>>> >> > Regards
>>>> >> > Santosh
>>>> >>
>>>> >> Hi Santosh,
>>>> >>
>>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>>>> >
>>>> > I don't think we should do this, the drivers should work with and without
>>>> > dma. This just needs to be added to the omap2plus_defconfig.
>>>> >
>>>> Well this was not decided based on any DMA CONFIG option before for
>>>> the subject drivers. It is already by default enabled if the DMA is supported
>>>> by the driver IP. There is a possibility to disable it from driver platform/dt
>>>> data so that still remains.
>>>
>>> I think it should rather be that if the driver is broken and does not work
>>> without DMA, it should have depends on CONFIG_DMA_OMAP.
>>>
>> I can confirm that omap MMC can't work without DMA; polled mode is not
>> supported / implemented.
>
> Same case for SPI driver as well. It uses DMA for everything except the cases
> where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable,
>
> At least considering this, it is better we do this per driver than enabling
> it at SOC config.
>
> Regards
> Santosh
> --

Hi Santosh,

And what about enabling it at the SoC config level but making the
drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
agree I can send something like this in two different patches (one for
the omap2plus_defconfig and another to make the drivers dependant on
the config option):

diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index b152de7..e58edc3 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_TWL92330=y
 CONFIG_RTC_DRV_TWL4030=y
+CONFIG_DMADEVICES=y
+CONFIG_DMA_OMAP=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index aa131b3..314c7bd 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA

 config MMC_OMAP
 	tristate "TI OMAP Multimedia Card Interface support"
-	depends on ARCH_OMAP
+	depends on ARCH_OMAP && DMADEVICES && DMA_OMAP
 	select TPS65010 if MACH_OMAP_H2
 	help
 	  This selects the TI OMAP Multimedia card Interface.
@@ -242,7 +242,8 @@ config MMC_OMAP

 config MMC_OMAP_HS
 	tristate "TI OMAP High Speed Multimedia Card Interface support"
-	depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4
+	depends on (SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4) && \
+		    DMADEVICES && DMA_OMAP
 	help
 	  This selects the TI OMAP High Speed Multimedia card Interface.
 	  If you have an OMAP2430 or OMAP3 board or OMAP4 board with a
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index cd2fe35..1c23242 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -237,7 +237,7 @@ config SPI_OMAP_UWIRE

 config SPI_OMAP24XX
 	tristate "McSPI driver for OMAP"
-	depends on ARCH_OMAP2PLUS
+	depends on ARCH_OMAP2PLUS && DMADEVICES && DMA_OMAP
 	help
 	  SPI master controller for OMAP24XX and later Multichannel SPI
 	  (McSPI) modules.

Best regards,
Javier

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

[Shilimkar, Santosh]

On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas
<martinez.javier@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>>> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
>>>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>>>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>>>>> >> <santosh.shilimkar@ti.com> wrote:
>>>>> >> > Hi,
>>>>> >> >
>>>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>>>>> >> > <javier@dowhile0.org> wrote:
>>>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>>>>> >> >> engine API instead of the previous private DMA API implementation.
>>>>> >> >>
>>>>> >> >> So, if the kernel is built with support for any of these hosts but it
>>>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>>>>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>>>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>>>>> >> >>
>>>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>>>> >> >>
>>>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>>>>> >> >>
>>>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>>>>> >> >> ---
>>>>> >> > Considering, we are updating drivers to select the DMA engine, can you
>>>>> >> > also include
>>>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>>>>> >> >
>>>>> >> > Regards
>>>>> >> > Santosh
>>>>> >>
>>>>> >> Hi Santosh,
>>>>> >>
>>>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>>>>> >
>>>>> > I don't think we should do this, the drivers should work with and without
>>>>> > dma. This just needs to be added to the omap2plus_defconfig.
>>>>> >
>>>>> Well this was not decided based on any DMA CONFIG option before for
>>>>> the subject drivers. It is already by default enabled if the DMA is supported
>>>>> by the driver IP. There is a possibility to disable it from driver platform/dt
>>>>> data so that still remains.
>>>>
>>>> I think it should rather be that if the driver is broken and does not work
>>>> without DMA, it should have depends on CONFIG_DMA_OMAP.
>>>>
>>> I can confirm that omap MMC can't work without DMA; polled mode is not
>>> supported / implemented.
>>
>> Same case for SPI driver as well. It uses DMA for everything except the cases
>> where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable,
>>
>> At least considering this, it is better we do this per driver than enabling
>> it at SOC config.
>>
>> Regards
>> Santosh
>> --
>
> Hi Santosh,
>
> And what about enabling it at the SoC config level but making the
> drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
> agree I can send something like this in two different patches (one for
> the omap2plus_defconfig and another to make the drivers dependant on
> the config option):
>
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index b152de7..e58edc3 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_TWL92330=y
>  CONFIG_RTC_DRV_TWL4030=y
> +CONFIG_DMADEVICES=y
> +CONFIG_DMA_OMAP=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>  # CONFIG_EXT3_FS_XATTR is not set
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index aa131b3..314c7bd 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA
>
>  config MMC_OMAP
>         tristate "TI OMAP Multimedia Card Interface support"
> -       depends on ARCH_OMAP
> +       depends on ARCH_OMAP && DMADEVICES && DMA_OMAP

May be. But since for sure a driver knows that it needs DMA
support to be enabled, I will just select it rather than depends
on.

Regards
santosh

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

[Javier Martinez Canillas]

On Wed, Jul 18, 2012 at 11:11 AM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas
> <martinez.javier@gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
>> <santosh.shilimkar@ti.com> wrote:
>>> On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>>>> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
>>>>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>>>>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>>>>>> >> <santosh.shilimkar@ti.com> wrote:
>>>>>> >> > Hi,
>>>>>> >> >
>>>>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>>>>>> >> > <javier@dowhile0.org> wrote:
>>>>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>>>>>> >> >> engine API instead of the previous private DMA API implementation.
>>>>>> >> >>
>>>>>> >> >> So, if the kernel is built with support for any of these hosts but it
>>>>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>>>>>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>>>>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>>>>>> >> >>
>>>>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>>>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>>>>> >> >>
>>>>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>>>>>> >> >>
>>>>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>>>>>> >> >> ---
>>>>>> >> > Considering, we are updating drivers to select the DMA engine, can you
>>>>>> >> > also include
>>>>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>>>>>> >> >
>>>>>> >> > Regards
>>>>>> >> > Santosh
>>>>>> >>
>>>>>> >> Hi Santosh,
>>>>>> >>
>>>>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>>>>>> >
>>>>>> > I don't think we should do this, the drivers should work with and without
>>>>>> > dma. This just needs to be added to the omap2plus_defconfig.
>>>>>> >
>>>>>> Well this was not decided based on any DMA CONFIG option before for
>>>>>> the subject drivers. It is already by default enabled if the DMA is supported
>>>>>> by the driver IP. There is a possibility to disable it from driver platform/dt
>>>>>> data so that still remains.
>>>>>
>>>>> I think it should rather be that if the driver is broken and does not work
>>>>> without DMA, it should have depends on CONFIG_DMA_OMAP.
>>>>>
>>>> I can confirm that omap MMC can't work without DMA; polled mode is not
>>>> supported / implemented.
>>>
>>> Same case for SPI driver as well. It uses DMA for everything except the cases
>>> where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable,
>>>
>>> At least considering this, it is better we do this per driver than enabling
>>> it at SOC config.
>>>
>>> Regards
>>> Santosh
>>> --
>>
>> Hi Santosh,
>>
>> And what about enabling it at the SoC config level but making the
>> drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
>> agree I can send something like this in two different patches (one for
>> the omap2plus_defconfig and another to make the drivers dependant on
>> the config option):
>>
>> diff --git a/arch/arm/configs/omap2plus_defconfig
>> b/arch/arm/configs/omap2plus_defconfig
>> index b152de7..e58edc3 100644
>> --- a/arch/arm/configs/omap2plus_defconfig
>> +++ b/arch/arm/configs/omap2plus_defconfig
>> @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
>>  CONFIG_RTC_CLASS=y
>>  CONFIG_RTC_DRV_TWL92330=y
>>  CONFIG_RTC_DRV_TWL4030=y
>> +CONFIG_DMADEVICES=y
>> +CONFIG_DMA_OMAP=y
>>  CONFIG_EXT2_FS=y
>>  CONFIG_EXT3_FS=y
>>  # CONFIG_EXT3_FS_XATTR is not set
>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> index aa131b3..314c7bd 100644
>> --- a/drivers/mmc/host/Kconfig
>> +++ b/drivers/mmc/host/Kconfig
>> @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA
>>
>>  config MMC_OMAP
>>         tristate "TI OMAP Multimedia Card Interface support"
>> -       depends on ARCH_OMAP
>> +       depends on ARCH_OMAP && DMADEVICES && DMA_OMAP
>
> May be. But since for sure a driver knows that it needs DMA
> support to be enabled, I will just select it rather than depends
> on.
>
> Regards
> santosh

Yes I agree with you, I was just exploring other options :-)

Best regards,
Javier

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

[S, Venkatraman]

On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas
<martinez.javier@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 11:11 AM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas
>> <martinez.javier@gmail.com> wrote:
>>> On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
>>> <santosh.shilimkar@ti.com> wrote:
>>>> On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>>>>> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
>>>>>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>>>>>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>>>>>>> >> <santosh.shilimkar@ti.com> wrote:
>>>>>>> >> > Hi,
>>>>>>> >> >
>>>>>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>>>>>>> >> > <javier@dowhile0.org> wrote:
>>>>>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>>>>>>> >> >> engine API instead of the previous private DMA API implementation.
>>>>>>> >> >>
>>>>>>> >> >> So, if the kernel is built with support for any of these hosts but it
>>>>>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>>>>>>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>>>>>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>>>>>>> >> >>
>>>>>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>>>>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>>>>>> >> >>
>>>>>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>>>>>>> >> >>
>>>>>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>>>>>>> >> >> ---
>>>>>>> >> > Considering, we are updating drivers to select the DMA engine, can you
>>>>>>> >> > also include
>>>>>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>>>>>>> >> >
>>>>>>> >> > Regards
>>>>>>> >> > Santosh
>>>>>>> >>
>>>>>>> >> Hi Santosh,
>>>>>>> >>
>>>>>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>>>>>>> >
>>>>>>> > I don't think we should do this, the drivers should work with and without
>>>>>>> > dma. This just needs to be added to the omap2plus_defconfig.
>>>>>>> >
>>>>>>> Well this was not decided based on any DMA CONFIG option before for
>>>>>>> the subject drivers. It is already by default enabled if the DMA is supported
>>>>>>> by the driver IP. There is a possibility to disable it from driver platform/dt
>>>>>>> data so that still remains.
>>>>>>
>>>>>> I think it should rather be that if the driver is broken and does not work
>>>>>> without DMA, it should have depends on CONFIG_DMA_OMAP.
>>>>>>
>>>>> I can confirm that omap MMC can't work without DMA; polled mode is not
>>>>> supported / implemented.
>>>>
>>>> Same case for SPI driver as well. It uses DMA for everything except the cases
>>>> where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable,
>>>>
>>>> At least considering this, it is better we do this per driver than enabling
>>>> it at SOC config.
>>>>
>>>> Regards
>>>> Santosh
>>>> --
>>>
>>> Hi Santosh,
>>>
>>> And what about enabling it at the SoC config level but making the
>>> drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
>>> agree I can send something like this in two different patches (one for
>>> the omap2plus_defconfig and another to make the drivers dependant on
>>> the config option):
>>>
>>> diff --git a/arch/arm/configs/omap2plus_defconfig
>>> b/arch/arm/configs/omap2plus_defconfig
>>> index b152de7..e58edc3 100644
>>> --- a/arch/arm/configs/omap2plus_defconfig
>>> +++ b/arch/arm/configs/omap2plus_defconfig
>>> @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
>>>  CONFIG_RTC_CLASS=y
>>>  CONFIG_RTC_DRV_TWL92330=y
>>>  CONFIG_RTC_DRV_TWL4030=y
>>> +CONFIG_DMADEVICES=y
>>> +CONFIG_DMA_OMAP=y
>>>  CONFIG_EXT2_FS=y
>>>  CONFIG_EXT3_FS=y
>>>  # CONFIG_EXT3_FS_XATTR is not set
>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>> index aa131b3..314c7bd 100644
>>> --- a/drivers/mmc/host/Kconfig
>>> +++ b/drivers/mmc/host/Kconfig
>>> @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA
>>>
>>>  config MMC_OMAP
>>>         tristate "TI OMAP Multimedia Card Interface support"
>>> -       depends on ARCH_OMAP
>>> +       depends on ARCH_OMAP && DMADEVICES && DMA_OMAP
>>
>> May be. But since for sure a driver knows that it needs DMA
>> support to be enabled, I will just select it rather than depends
>> on.
>>
>> Regards
>> santosh
>
> Yes I agree with you, I was just exploring other options :-)
>
For MMC atleast, there's already a patch in mmc-next to do a "Depends On"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=7c68046c99f0b96d965c31cf42814b9a0f15ad46

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

[Shilimkar, Santosh]

On Wed, Jul 18, 2012 at 3:08 PM, S, Venkatraman <svenkatr@ti.com> wrote:
> On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas
> <martinez.javier@gmail.com> wrote:

[...]

>>>>
>>>> And what about enabling it at the SoC config level but making the
>>>> drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
>>>> agree I can send something like this in two different patches (one for
>>>> the omap2plus_defconfig and another to make the drivers dependant on
>>>> the config option):
>>>>
>>>> diff --git a/arch/arm/configs/omap2plus_defconfig
>>>> b/arch/arm/configs/omap2plus_defconfig
>>>> index b152de7..e58edc3 100644
>>>> --- a/arch/arm/configs/omap2plus_defconfig
>>>> +++ b/arch/arm/configs/omap2plus_defconfig
>>>> @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
>>>>  CONFIG_RTC_CLASS=y
>>>>  CONFIG_RTC_DRV_TWL92330=y
>>>>  CONFIG_RTC_DRV_TWL4030=y
>>>> +CONFIG_DMADEVICES=y
>>>> +CONFIG_DMA_OMAP=y
>>>>  CONFIG_EXT2_FS=y
>>>>  CONFIG_EXT3_FS=y
>>>>  # CONFIG_EXT3_FS_XATTR is not set
>>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>>> index aa131b3..314c7bd 100644
>>>> --- a/drivers/mmc/host/Kconfig
>>>> +++ b/drivers/mmc/host/Kconfig
>>>> @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA
>>>>
>>>>  config MMC_OMAP
>>>>         tristate "TI OMAP Multimedia Card Interface support"
>>>> -       depends on ARCH_OMAP
>>>> +       depends on ARCH_OMAP && DMADEVICES && DMA_OMAP
>>>
>>> May be. But since for sure a driver knows that it needs DMA
>>> support to be enabled, I will just select it rather than depends
>>> on.
>>>
>>> Regards
>>> santosh
>>
>> Yes I agree with you, I was just exploring other options :-)
>>
> For MMC atleast, there's already a patch in mmc-next to do a "Depends On"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=7c68046c99f0b96d965c31cf42814b9a0f15ad46

Change log assumes says .

"The patch simply make them depend on DMA_OMAP since DMA_OMAP
will select DMA_ENGINE automatically"

This won't be true if the DMA selection are not done
at ARCH_OMAP level as discussed in this thread.

Having said that, I think Russell and Tony need to
take call on how this needs to be handled.

Regards
Santosh

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

[Tony Lindgren]

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 02:49]:
> 
> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
> will select DMA_ENGINE automatically"
> 
> This won't be true if the DMA selection are not done
> at ARCH_OMAP level as discussed in this thread.
> 
> Having said that, I think Russell and Tony need to
> take call on how this needs to be handled.

As the DMA channels can run out, drivers should also work
without DMA. And building everything as modules should be
possible for the distro kernels.

So I'd rather not have either select or depends and have
the drivers fixed.

Tony

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

[S, Venkatraman]

On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 02:49]:
>>
>> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
>> will select DMA_ENGINE automatically"
>>
>> This won't be true if the DMA selection are not done
>> at ARCH_OMAP level as discussed in this thread.
>>
>> Having said that, I think Russell and Tony need to
>> take call on how this needs to be handled.
>
> As the DMA channels can run out, drivers should also work
> without DMA. And building everything as modules should be
> possible for the distro kernels.
>
> So I'd rather not have either select or depends and have
> the drivers fixed.
>

Ok - I'll work on getting polling mode to work, but as you know it's
not the mode to get the best performance out of the device.
I see that you've also merged the changes to omap2plus_defconfig, which should
get MMC working as before DMA Engine conversion.

There's a small patch needed to omap_hsmmc to return a non-zero error code
during the probe error path. This will atleast make probe failure
explicit when DMA
is not available.

Let me know if you want me to post it separately as a patch..

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2338703..892a046 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1773,7 +1773,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
        struct mmc_host *mmc;
        struct omap_hsmmc_host *host = NULL;
        struct resource *res;
-       int ret, irq;
+       int ret = -ENXIO, irq;
        const struct of_device_id *match;
        dma_cap_mask_t mask;
        unsigned tx_req, rx_req;

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

[S, Venkatraman]

On Fri, Jul 20, 2012 at 2:58 PM, S, Venkatraman <svenkatr@ti.com> wrote:
> On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 02:49]:
>>>
>>> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
>>> will select DMA_ENGINE automatically"
>>>
>>> This won't be true if the DMA selection are not done
>>> at ARCH_OMAP level as discussed in this thread.
>>>
>>> Having said that, I think Russell and Tony need to
>>> take call on how this needs to be handled.
>>
>> As the DMA channels can run out, drivers should also work
>> without DMA. And building everything as modules should be
>> possible for the distro kernels.
>>
>> So I'd rather not have either select or depends and have
>> the drivers fixed.
>>
>
> Ok - I'll work on getting polling mode to work, but as you know it's
> not the mode to get the best performance out of the device.
> I see that you've also merged the changes to omap2plus_defconfig, which should
> get MMC working as before DMA Engine conversion.
>
> There's a small patch needed to omap_hsmmc to return a non-zero error code
> during the probe error path. This will atleast make probe failure
> explicit when DMA
> is not available.
>
> Let me know if you want me to post it separately as a patch..
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 2338703..892a046 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1773,7 +1773,7 @@ static int __devinit omap_hsmmc_probe(struct
> platform_device *pdev)
>         struct mmc_host *mmc;
>         struct omap_hsmmc_host *host = NULL;
>         struct resource *res;
> -       int ret, irq;
> +       int ret = -ENXIO, irq;
>         const struct of_device_id *match;
>         dma_cap_mask_t mask;
>         unsigned tx_req, rx_req;

Please ignore this patch. The correct one was posted by Kevin last week [1].
An additional patch is needed on top of that to fix other error paths, I'll
send both now.

[1] http://marc.info/?l=linux-omap&m=134196391719430&w=2

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

[Peter Meerwald]

On Wed, 18 Jul 2012, Javier Martinez Canillas wrote:

> On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
> > On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com> wrote:
> >> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
> >>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
> >>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
> >>>> >> <santosh.shilimkar@ti.com> wrote:
> >>>> >> > Hi,
> >>>> >> >
> >>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
> >>>> >> > <javier@dowhile0.org> wrote:
> >>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
> >>>> >> >> engine API instead of the previous private DMA API implementation.
> >>>> >> >>
> >>>> >> >> So, if the kernel is built with support for any of these hosts but it
> >>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
> >>>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
> >>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
> >>>> >> >>
> >>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
> >>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> >>>> >> >>
> >>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
> >>>> >> >>
> >>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> >>>> >> >> ---
> >>>> >> > Considering, we are updating drivers to select the DMA engine, can you
> >>>> >> > also include
> >>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
> >>>> >> >
> >>>> >> > Regards
> >>>> >> > Santosh
> >>>> >>
> >>>> >> Hi Santosh,
> >>>> >>
> >>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
> >>>> >
> >>>> > I don't think we should do this, the drivers should work with and without
> >>>> > dma. This just needs to be added to the omap2plus_defconfig.
> >>>> >
> >>>> Well this was not decided based on any DMA CONFIG option before for
> >>>> the subject drivers. It is already by default enabled if the DMA is supported
> >>>> by the driver IP. There is a possibility to disable it from driver platform/dt
> >>>> data so that still remains.
> >>>
> >>> I think it should rather be that if the driver is broken and does not work
> >>> without DMA, it should have depends on CONFIG_DMA_OMAP.
> >>>
> >> I can confirm that omap MMC can't work without DMA; polled mode is not
> >> supported / implemented.
> >
> > Same case for SPI driver as well. It uses DMA for everything except the cases
> > where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable,
> >
> > At least considering this, it is better we do this per driver than enabling
> > it at SOC config.
> >
> > Regards
> > Santosh
> > --
> 
> Hi Santosh,
> 
> And what about enabling it at the SoC config level but making the
> drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
> agree I can send something like this in two different patches (one for
> the omap2plus_defconfig and another to make the drivers dependant on
> the config option):
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index b152de7..e58edc3 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_TWL92330=y
>  CONFIG_RTC_DRV_TWL4030=y
> +CONFIG_DMADEVICES=y
> +CONFIG_DMA_OMAP=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>  # CONFIG_EXT3_FS_XATTR is not set

above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4
but I am missing the patches below in mainline (3.6-rc3) -- what happened?

as Javier pointed out in https://patchwork.kernel.org/patch/1203391/, 
MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined

I suggest to take below patches and help to avoid some extra gray hair for 
people looking for a fix for non-booting beagleboards

thanks, p.

> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index aa131b3..314c7bd 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA
> 
>  config MMC_OMAP
>  	tristate "TI OMAP Multimedia Card Interface support"
> -	depends on ARCH_OMAP
> +	depends on ARCH_OMAP && DMADEVICES && DMA_OMAP
>  	select TPS65010 if MACH_OMAP_H2
>  	help
>  	  This selects the TI OMAP Multimedia card Interface.
> @@ -242,7 +242,8 @@ config MMC_OMAP
> 
>  config MMC_OMAP_HS
>  	tristate "TI OMAP High Speed Multimedia Card Interface support"
> -	depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4
> +	depends on (SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4) && \
> +		    DMADEVICES && DMA_OMAP
>  	help
>  	  This selects the TI OMAP High Speed Multimedia card Interface.
>  	  If you have an OMAP2430 or OMAP3 board or OMAP4 board with a
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index cd2fe35..1c23242 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -237,7 +237,7 @@ config SPI_OMAP_UWIRE
> 
>  config SPI_OMAP24XX
>  	tristate "McSPI driver for OMAP"
> -	depends on ARCH_OMAP2PLUS
> +	depends on ARCH_OMAP2PLUS && DMADEVICES && DMA_OMAP
>  	help
>  	  SPI master controller for OMAP24XX and later Multichannel SPI
>  	  (McSPI) modules.


-- 

Peter Meerwald
+43-664-2444418 (mobile)

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

[Shilimkar, Santosh]

On Fri, Aug 24, 2012 at 2:30 AM, Peter Meerwald <pmeerw@pmeerw.net> wrote:
>
> On Wed, 18 Jul 2012, Javier Martinez Canillas wrote:
>
> > On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
> > <santosh.shilimkar@ti.com> wrote:
> > > On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com>
> > > wrote:
> > >> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com>
> > >> wrote:
> > >>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
> > >>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com>
> > >>>> wrote:
> > >>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
> > >>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
> > >>>> >> <santosh.shilimkar@ti.com> wrote:
> > >>>> >> > Hi,
> > >>>> >> >
> > >>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
> > >>>> >> > <javier@dowhile0.org> wrote:
> > >>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely
> > >>>> >> >> the DMA
> > >>>> >> >> engine API instead of the previous private DMA API
> > >>>> >> >> implementation.
> > >>>> >> >>
> > >>>> >> >> So, if the kernel is built with support for any of these
> > >>>> >> >> hosts but it
> > >>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails
> > >>>> >> >> when trying
> > >>>> >> >> to obtain a DMA channel which leads to the following error on
> > >>>> >> >> an OMAP3
> > >>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC
> > >>>> >> >> support):
> > >>>> >> >>
> > >>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA
> > >>>> >> >> engine channel 48
> > >>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX
> > >>>> >> >> DMA engine channel 62
> > >>>> >> >>
> > >>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP
> > >>>> >> >> solves it.
> > >>>> >> >>
> > >>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> > >>>> >> >> ---
> > >>>> >> > Considering, we are updating drivers to select the DMA engine,
> > >>>> >> > can you
> > >>>> >> > also include
> > >>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA
> > >>>> >> > engine.
> > >>>> >> >
> > >>>> >> > Regards
> > >>>> >> > Santosh
> > >>>> >>
> > >>>> >> Hi Santosh,
> > >>>> >>
> > >>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
> > >>>> >
> > >>>> > I don't think we should do this, the drivers should work with and
> > >>>> > without
> > >>>> > dma. This just needs to be added to the omap2plus_defconfig.
> > >>>> >
> > >>>> Well this was not decided based on any DMA CONFIG option before for
> > >>>> the subject drivers. It is already by default enabled if the DMA is
> > >>>> supported
> > >>>> by the driver IP. There is a possibility to disable it from driver
> > >>>> platform/dt
> > >>>> data so that still remains.
> > >>>
> > >>> I think it should rather be that if the driver is broken and does
> > >>> not work
> > >>> without DMA, it should have depends on CONFIG_DMA_OMAP.
> > >>>
> > >> I can confirm that omap MMC can't work without DMA; polled mode is
> > >> not
> > >> supported / implemented.
> > >
> > > Same case for SPI driver as well. It uses DMA for everything except
> > > the cases
> > > where DMA doesn't make sense like 1 byte/2 byte etc. And its not
> > > configurable,
> > >
> > > At least considering this, it is better we do this per driver than
> > > enabling
> > > it at SOC config.
> > >
> > > Regards
> > > Santosh
> > > --
> >
> > Hi Santosh,
> >
> > And what about enabling it at the SoC config level but making the
> > drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
> > agree I can send something like this in two different patches (one for
> > the omap2plus_defconfig and another to make the drivers dependant on
> > the config option):
> >
> > diff --git a/arch/arm/configs/omap2plus_defconfig
> > b/arch/arm/configs/omap2plus_defconfig
> > index b152de7..e58edc3 100644
> > --- a/arch/arm/configs/omap2plus_defconfig
> > +++ b/arch/arm/configs/omap2plus_defconfig
> > @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
> >  CONFIG_RTC_CLASS=y
> >  CONFIG_RTC_DRV_TWL92330=y
> >  CONFIG_RTC_DRV_TWL4030=y
> > +CONFIG_DMADEVICES=y
> > +CONFIG_DMA_OMAP=y
> >  CONFIG_EXT2_FS=y
> >  CONFIG_EXT3_FS=y
> >  # CONFIG_EXT3_FS_XATTR is not set
>
> above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4
> but I am missing the patches below in mainline (3.6-rc3) -- what happened?
>
> as Javier pointed out in https://patchwork.kernel.org/patch/1203391/,
> MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined
>
> I suggest to take below patches and help to avoid some extra gray hair for
> people looking for a fix for non-booting beagleboards
>
May be I am missing something, but why you would need below patch
for beagle with "89269ef1f0abc72c551198123e19cd4edfd43cf4" commit
enabling the DMA_OMAP for all OMAP boards.

Regards
Santosh

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

[Peter Meerwald]

On Fri, 24 Aug 2012, Shilimkar, Santosh wrote:

> On Fri, Aug 24, 2012 at 2:30 AM, Peter Meerwald <pmeerw@pmeerw.net> wrote:
> >
> > On Wed, 18 Jul 2012, Javier Martinez Canillas wrote:
> >
> > > On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
> > > <santosh.shilimkar@ti.com> wrote:
> > > > On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman <svenkatr@ti.com>
> > > > wrote:
> > > >> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren <tony@atomide.com>
> > > >> wrote:
> > > >>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [120718 00:09]:
> > > >>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren <tony@atomide.com>
> > > >>>> wrote:
> > > >>>> > * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
> > > >>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
> > > >>>> >> <santosh.shilimkar@ti.com> wrote:
> > > >>>> >> > Hi,
> > > >>>> >> >
> > > >>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
> > > >>>> >> > <javier@dowhile0.org> wrote:
> > > >>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely
> > > >>>> >> >> the DMA
> > > >>>> >> >> engine API instead of the previous private DMA API
> > > >>>> >> >> implementation.
> > > >>>> >> >>
> > > >>>> >> >> So, if the kernel is built with support for any of these
> > > >>>> >> >> hosts but it
> > > >>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails
> > > >>>> >> >> when trying
> > > >>>> >> >> to obtain a DMA channel which leads to the following error on
> > > >>>> >> >> an OMAP3
> > > >>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC
> > > >>>> >> >> support):
> > > >>>> >> >>
> > > >>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA
> > > >>>> >> >> engine channel 48
> > > >>>> >> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX
> > > >>>> >> >> DMA engine channel 62
> > > >>>> >> >>
> > > >>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP
> > > >>>> >> >> solves it.
> > > >>>> >> >>
> > > >>>> >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> > > >>>> >> >> ---
> > > >>>> >> > Considering, we are updating drivers to select the DMA engine,
> > > >>>> >> > can you
> > > >>>> >> > also include
> > > >>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA
> > > >>>> >> > engine.
> > > >>>> >> >
> > > >>>> >> > Regards
> > > >>>> >> > Santosh
> > > >>>> >>
> > > >>>> >> Hi Santosh,
> > > >>>> >>
> > > >>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
> > > >>>> >
> > > >>>> > I don't think we should do this, the drivers should work with and
> > > >>>> > without
> > > >>>> > dma. This just needs to be added to the omap2plus_defconfig.
> > > >>>> >
> > > >>>> Well this was not decided based on any DMA CONFIG option before for
> > > >>>> the subject drivers. It is already by default enabled if the DMA is
> > > >>>> supported
> > > >>>> by the driver IP. There is a possibility to disable it from driver
> > > >>>> platform/dt
> > > >>>> data so that still remains.
> > > >>>
> > > >>> I think it should rather be that if the driver is broken and does
> > > >>> not work
> > > >>> without DMA, it should have depends on CONFIG_DMA_OMAP.
> > > >>>
> > > >> I can confirm that omap MMC can't work without DMA; polled mode is
> > > >> not
> > > >> supported / implemented.
> > > >
> > > > Same case for SPI driver as well. It uses DMA for everything except
> > > > the cases
> > > > where DMA doesn't make sense like 1 byte/2 byte etc. And its not
> > > > configurable,
> > > >
> > > > At least considering this, it is better we do this per driver than
> > > > enabling
> > > > it at SOC config.
> > > >
> > > > Regards
> > > > Santosh
> > > > --
> > >
> > > Hi Santosh,
> > >
> > > And what about enabling it at the SoC config level but making the
> > > drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you
> > > agree I can send something like this in two different patches (one for
> > > the omap2plus_defconfig and another to make the drivers dependant on
> > > the config option):
> > >
> > > diff --git a/arch/arm/configs/omap2plus_defconfig
> > > b/arch/arm/configs/omap2plus_defconfig
> > > index b152de7..e58edc3 100644
> > > --- a/arch/arm/configs/omap2plus_defconfig
> > > +++ b/arch/arm/configs/omap2plus_defconfig
> > > @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y
> > >  CONFIG_RTC_CLASS=y
> > >  CONFIG_RTC_DRV_TWL92330=y
> > >  CONFIG_RTC_DRV_TWL4030=y
> > > +CONFIG_DMADEVICES=y
> > > +CONFIG_DMA_OMAP=y
> > >  CONFIG_EXT2_FS=y
> > >  CONFIG_EXT3_FS=y
> > >  # CONFIG_EXT3_FS_XATTR is not set
> >
> > above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4
> > but I am missing the patches below in mainline (3.6-rc3) -- what happened?
> >
> > as Javier pointed out in https://patchwork.kernel.org/patch/1203391/,
> > MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined
> >
> > I suggest to take below patches and help to avoid some extra gray hair for
> > people looking for a fix for non-booting beagleboards
> >
> May be I am missing something, but why you would need below patch
> for beagle with "89269ef1f0abc72c551198123e19cd4edfd43cf4" commit
> enabling the DMA_OMAP for all OMAP boards.

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

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

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

[Russell King - ARM Linux]

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.

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

[Shilimkar, Santosh]

On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux
<linux@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/

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

[Russell King - ARM Linux]

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@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.

[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@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@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

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

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

[Russell King - ARM Linux]

On Fri, Aug 24, 2012 at 02:10:38PM +0200, Peter Meerwald wrote:
> 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

Yes.  Unlike the PL08x driver, OMAP has no way to pass the filter function
into its drivers, and I didn't want the pain of fiddling around with DT
crap to try and work out how to do this.  So what you have here is
something that I got as far as I could, and TI then wanted it pushed into
mainline.

I have no solution for the above at present - the long term solution is
to sort out how to deal with DMA engine with DT etc.  At the moment,
there has been discussion about this but no solution.

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

[Javier Martinez Canillas]

On Wed, Jul 18, 2012 at 8:59 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Javier Martinez Canillas <javier@dowhile0.org> [120716 23:56]:
>> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>> <santosh.shilimkar@ti.com> wrote:
>> > Hi,
>> >
>> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>> > <javier@dowhile0.org> wrote:
>> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>> >> engine API instead of the previous private DMA API implementation.
>> >>
>> >> So, if the kernel is built with support for any of these hosts but it
>> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>> >> to obtain a DMA channel which leads to the following error on an OMAP3
>> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>> >>
>> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>> >> [    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> >>
>> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.
>> >>
>> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
>> >> ---
>> > Considering, we are updating drivers to select the DMA engine, can you
>> > also include
>> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>> >
>> > Regards
>> > Santosh
>>
>> Hi Santosh,
>>
>> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>
> I don't think we should do this, the drivers should work with and without
> dma. This just needs to be added to the omap2plus_defconfig.
>
> Regards,
>
> Tony
> --

Hi Tony,

That was my first approach in fact, I sent this patch:
https://patchwork.kernel.org/patch/1198401/

But then was told by Kevin Hilman that the right solution was to do
the select on the drives to fix not only omap2plus_defconfig but any
config.
So I sent this patch and Santosh agrees with Kevin.

I don't really know the hardware nor the driver well enough to have a
strong position on this.

Best regards,
Javier

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

[Tony Lindgren]

* Javier Martinez Canillas <martinez.javier@gmail.com> [120718 01:31]:
> That was my first approach in fact, I sent this patch:
> https://patchwork.kernel.org/patch/1198401/
> 
> But then was told by Kevin Hilman that the right solution was to do
> the select on the drives to fix not only omap2plus_defconfig but any
> config.
> So I sent this patch and Santosh agrees with Kevin.
> 
> I don't really know the hardware nor the driver well enough to have a
> strong position on this.

Ideally we would not select it or have depends on it. DMA channels
can run out, and drivers need to work also without DMA. For doing
distro kernels, building everything as modules should be an option
rather than forcing to build in all kinds of code.

Regards,

Tony