* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-18 8:49 ` Javier Martinez Canillas
0 siblings, 0 replies; 52+ messages in thread
From: Javier Martinez Canillas @ 2012-07-18 8:49 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-18 8:49 ` Javier Martinez Canillas
@ 2012-07-18 9:11 ` Shilimkar, Santosh
-1 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-07-18 9:11 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: S, Venkatraman, Tony Lindgren, Javier Martinez Canillas,
Kevin Hilman, Russell King, linux-omap, linux-arm-kernel,
Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-18 9:11 ` Shilimkar, Santosh
0 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-07-18 9:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-18 9:11 ` Shilimkar, Santosh
@ 2012-07-18 9:16 ` Javier Martinez Canillas
-1 siblings, 0 replies; 52+ messages in thread
From: Javier Martinez Canillas @ 2012-07-18 9:16 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: S, Venkatraman, Tony Lindgren, Javier Martinez Canillas,
Kevin Hilman, Russell King, linux-omap, linux-arm-kernel,
Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-18 9:16 ` Javier Martinez Canillas
0 siblings, 0 replies; 52+ messages in thread
From: Javier Martinez Canillas @ 2012-07-18 9:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-18 9:16 ` Javier Martinez Canillas
@ 2012-07-18 9:38 ` S, Venkatraman
-1 siblings, 0 replies; 52+ messages in thread
From: S, Venkatraman @ 2012-07-18 9:38 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Shilimkar, Santosh, Tony Lindgren, Javier Martinez Canillas,
Kevin Hilman, Russell King, linux-omap, linux-arm-kernel,
Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-18 9:38 ` S, Venkatraman
0 siblings, 0 replies; 52+ messages in thread
From: S, Venkatraman @ 2012-07-18 9:38 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-18 9:38 ` S, Venkatraman
@ 2012-07-18 9:44 ` Shilimkar, Santosh
-1 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-07-18 9:44 UTC (permalink / raw)
To: S, Venkatraman
Cc: Javier Martinez Canillas, Tony Lindgren,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-18 9:44 ` Shilimkar, Santosh
0 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-07-18 9:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-18 9:44 ` Shilimkar, Santosh
@ 2012-07-19 11:32 ` Tony Lindgren
-1 siblings, 0 replies; 52+ messages in thread
From: Tony Lindgren @ 2012-07-19 11:32 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: S, Venkatraman, Javier Martinez Canillas,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
* 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-19 11:32 ` Tony Lindgren
0 siblings, 0 replies; 52+ messages in thread
From: Tony Lindgren @ 2012-07-19 11:32 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-19 11:32 ` Tony Lindgren
@ 2012-07-20 9:28 ` S, Venkatraman
-1 siblings, 0 replies; 52+ messages in thread
From: S, Venkatraman @ 2012-07-20 9:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: Shilimkar, Santosh, Javier Martinez Canillas,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
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;
^ permalink raw reply related [flat|nested] 52+ messages in thread* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-20 9:28 ` S, Venkatraman
0 siblings, 0 replies; 52+ messages in thread
From: S, Venkatraman @ 2012-07-20 9:28 UTC (permalink / raw)
To: linux-arm-kernel
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;
^ permalink raw reply related [flat|nested] 52+ messages in thread* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-20 9:28 ` S, Venkatraman
@ 2012-07-20 10:01 ` S, Venkatraman
-1 siblings, 0 replies; 52+ messages in thread
From: S, Venkatraman @ 2012-07-20 10:01 UTC (permalink / raw)
To: Tony Lindgren
Cc: Shilimkar, Santosh, Javier Martinez Canillas,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-07-20 10:01 ` S, Venkatraman
0 siblings, 0 replies; 52+ messages in thread
From: S, Venkatraman @ 2012-07-20 10:01 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-07-18 8:49 ` Javier Martinez Canillas
@ 2012-08-23 21:00 ` Peter Meerwald
-1 siblings, 0 replies; 52+ messages in thread
From: Peter Meerwald @ 2012-08-23 21:00 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Shilimkar, Santosh, S, Venkatraman, Tony Lindgren,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
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)
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-23 21:00 ` Peter Meerwald
0 siblings, 0 replies; 52+ messages in thread
From: Peter Meerwald @ 2012-08-23 21:00 UTC (permalink / raw)
To: linux-arm-kernel
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)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-23 21:00 ` Peter Meerwald
@ 2012-08-24 7:10 ` Shilimkar, Santosh
-1 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-08-24 7:10 UTC (permalink / raw)
To: Peter Meerwald
Cc: Javier Martinez Canillas, S, Venkatraman, Tony Lindgren,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 7:10 ` Shilimkar, Santosh
0 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-08-24 7:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 7:10 ` Shilimkar, Santosh
@ 2012-08-24 7:51 ` Peter Meerwald
-1 siblings, 0 replies; 52+ messages in thread
From: Peter Meerwald @ 2012-08-24 7:51 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Javier Martinez Canillas, S, Venkatraman, Tony Lindgren,
Javier Martinez Canillas, Kevin Hilman, Russell King, linux-omap,
linux-arm-kernel, Chris Ball, linux-mmc
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)
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 7:51 ` Peter Meerwald
0 siblings, 0 replies; 52+ messages in thread
From: Peter Meerwald @ 2012-08-24 7:51 UTC (permalink / raw)
To: linux-arm-kernel
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)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 7:51 ` Peter Meerwald
@ 2012-08-24 9:42 ` Russell King - ARM Linux
-1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-08-24 9:42 UTC (permalink / raw)
To: Peter Meerwald
Cc: Shilimkar, Santosh, Javier Martinez Canillas, S, Venkatraman,
Tony Lindgren, Javier Martinez Canillas, Kevin Hilman,
linux-omap, linux-arm-kernel, Chris Ball, linux-mmc
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 9:42 ` Russell King - ARM Linux
0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-08-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 9:42 ` Russell King - ARM Linux
@ 2012-08-24 10:21 ` Shilimkar, Santosh
-1 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-08-24 10:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Peter Meerwald, Javier Martinez Canillas, S, Venkatraman,
Tony Lindgren, Javier Martinez Canillas, Kevin Hilman,
linux-omap, linux-arm-kernel, Chris Ball, linux-mmc
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/
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 10:21 ` Shilimkar, Santosh
0 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-08-24 10:21 UTC (permalink / raw)
To: linux-arm-kernel
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/
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 10:21 ` Shilimkar, Santosh
@ 2012-08-24 10:39 ` Russell King - ARM Linux
-1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-08-24 10:39 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Peter Meerwald, Javier Martinez Canillas, S, Venkatraman,
Tony Lindgren, Javier Martinez Canillas, Kevin Hilman,
linux-omap, linux-arm-kernel, Chris Ball, linux-mmc
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 10:39 ` Russell King - ARM Linux
0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-08-24 10:39 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 10:39 ` Russell King - ARM Linux
@ 2012-08-24 10:45 ` Shilimkar, Santosh
-1 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-08-24 10:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Peter Meerwald, Javier Martinez Canillas, S, Venkatraman,
Tony Lindgren, Javier Martinez Canillas, Kevin Hilman,
linux-omap, linux-arm-kernel, Chris Ball, linux-mmc
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 10:45 ` Shilimkar, Santosh
0 siblings, 0 replies; 52+ messages in thread
From: Shilimkar, Santosh @ 2012-08-24 10:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 10:45 ` Shilimkar, Santosh
@ 2012-08-24 12:10 ` Peter Meerwald
-1 siblings, 0 replies; 52+ messages in thread
From: Peter Meerwald @ 2012-08-24 12:10 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Russell King - ARM Linux, Javier Martinez Canillas, S,
Venkatraman, Tony Lindgren, Javier Martinez Canillas,
Kevin Hilman, linux-omap, linux-arm-kernel, Chris Ball,
linux-mmc
> >> > > 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)
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-24 12:10 ` Peter Meerwald
0 siblings, 0 replies; 52+ messages in thread
From: Peter Meerwald @ 2012-08-24 12:10 UTC (permalink / raw)
To: linux-arm-kernel
> >> > > 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)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
2012-08-24 12:10 ` Peter Meerwald
@ 2012-08-25 7:57 ` Russell King - ARM Linux
-1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-08-25 7:57 UTC (permalink / raw)
To: Peter Meerwald
Cc: Kevin Hilman, Javier Martinez Canillas, linux-omap,
Tony Lindgren, linux-mmc, Shilimkar, Santosh, Chris Ball,
Javier Martinez Canillas, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
@ 2012-08-25 7:57 ` Russell King - ARM Linux
0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-08-25 7:57 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 52+ messages in thread