mmc: host: enable OMAP DMA engine support for omap hosts by default

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 <[email protected]>

---

Hi,

Quoted 13 lines · Javier Martinez Canillas

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.

Quoted 2 lines

Signed-off-by Javier Martinez Canillas <[email protected]>

---

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

Quoted 23 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[    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 <[email protected]>

---

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.

Quoted 2 lines

Regards
Santosh

Hi Santosh,

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

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[    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 <[email protected]>

---

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

Quoted 3 lines

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.

Quoted 33 lines · Tony Lindgren

Quoted 31 lines · Javier Martinez Canillas

Quoted 17 lines · Santosh

Hi,

Quoted 13 lines · Javier Martinez Canillas

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.

Quoted 8 lines

Quoted 2 lines

Signed-off-by Javier Martinez Canillas <[email protected]>

---

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.

Quoted 3 lines

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.

Quoted 37 lines · Shilimkar, Santosh

Quoted 36 lines · Tony Lindgren

Quoted 25 lines · Javier Martinez Canillas

Quoted 23 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[    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 <[email protected]>

---

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 43 lines · Tony Lindgren

Quoted 41 lines · Shilimkar, Santosh

Quoted 29 lines · Tony Lindgren

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[    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 <[email protected]>

---

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 44 lines · Venkatraman

Quoted 43 lines · Tony Lindgren

Quoted 41 lines · Shilimkar, Santosh

Quoted 29 lines · Tony Lindgren

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[ 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 <[email protected]>

---

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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

Quoted 54 lines · Santosh

Quoted 44 lines · Venkatraman

Quoted 43 lines · Tony Lindgren

Quoted 41 lines · Shilimkar, Santosh

Quoted 29 lines · Tony Lindgren

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[ 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 <[email protected]>

---

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 6 lines

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

arch/arm/configs/omap2plus_defconfig +2 -0

index b152de7..e58edc3 100644
@@ -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

drivers/mmc/host/Kconfig +0 -0

index aa131b3..314c7bd 100644

Quoted 90 lines · Javier Martinez Canillas

Quoted 54 lines · Santosh

Quoted 44 lines · Venkatraman

Quoted 43 lines · Tony Lindgren

Quoted 41 lines · Shilimkar, Santosh

Quoted 29 lines · Tony Lindgren

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[ 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 <[email protected]>

---

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 6 lines

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

arch/arm/configs/omap2plus_defconfig +2 -0

index b152de7..e58edc3 100644
@@ -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

drivers/mmc/host/Kconfig +0 -0

index aa131b3..314c7bd 100644

drivers/mmc/host/Kconfig config MMC_SDHCI_S3C_DMA · line 234

Quoted 5 lines

drivers/mmc/host/Kconfig +1 -1

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

Quoted 102 lines · Santosh

Quoted 90 lines · Javier Martinez Canillas

Quoted 54 lines · Santosh

Quoted 44 lines · Venkatraman

Quoted 43 lines · Tony Lindgren

Quoted 41 lines · Shilimkar, Santosh

Quoted 29 lines · Tony Lindgren

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[ 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 <[email protected]>

---

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 6 lines

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

arch/arm/configs/omap2plus_defconfig +2 -0

index b152de7..e58edc3 100644
@@ -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

drivers/mmc/host/Kconfig +0 -0

index aa131b3..314c7bd 100644

drivers/mmc/host/Kconfig config MMC_SDHCI_S3C_DMA · line 234

Quoted 5 lines

drivers/mmc/host/Kconfig +1 -1

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

Quoted 2 lines

Regards
santosh

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

On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas <[email protected]> wrote:

Quoted 36 lines

Quoted 36 lines

Quoted 26 lines

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

arch/arm/configs/omap2plus_defconfig +2 -0

index b152de7..e58edc3 100644
@@ -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

drivers/mmc/host/Kconfig +0 -0

index aa131b3..314c7bd 100644

drivers/mmc/host/Kconfig config MMC_SDHCI_S3C_DMA · line 234

Quoted 5 lines

drivers/mmc/host/Kconfig +1 -1

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

Quoted 5 lines

Quoted 2 lines

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

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

Quoted 9 lines · Shilimkar, Santosh

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

Quoted 11 lines · Tony Lindgren

Quoted 9 lines · Shilimkar, Santosh

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

Quoted 7 lines

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

drivers/mmc/host/omap_hsmmc.c +1 -1

index 2338703..892a046 100644
@@ -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;

Quoted 54 lines · Santosh

Quoted 44 lines · Venkatraman

Quoted 43 lines · Tony Lindgren

Quoted 41 lines · Shilimkar, Santosh

Quoted 29 lines · Tony Lindgren

Quoted 28 lines · Javier Martinez Canillas

Quoted 25 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[ 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 <[email protected]>

---

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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,

Quoted 6 lines

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

arch/arm/configs/omap2plus_defconfig +0 -0

index b152de7..e58edc3 100644

drivers/mmc/host/Kconfig +3 -2

index aa131b3..314c7bd 100644
@@ -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

drivers/spi/Kconfig +1 -1

index cd2fe35..1c23242 100644
@@ -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.

Quoted 99 lines · Javier Martinez Canillas

Quoted 75 lines · Santosh

Quoted 60 lines · Venkatraman

Quoted 58 lines · Tony Lindgren

Quoted 56 lines · Shilimkar, Santosh

Quoted 40 lines · Tony Lindgren

Quoted 39 lines · Javier Martinez Canillas

Quoted 36 lines · Santosh

Hi,

Quoted 17 lines · Javier Martinez Canillas

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

Quoted 7 lines

DMA engine channel 62

selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.

Signed-off-by Javier Martinez Canillas <[email protected]>

---

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 4 lines

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,

Quoted 7 lines

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

arch/arm/configs/omap2plus_defconfig +0 -0

index b152de7..e58edc3 100644

arch/arm/configs/omap2plus_defconfig CONFIG_MMC_OMAP_HS=y · line 200

Quoted 8 lines

arch/arm/configs/omap2plus_defconfig +2 -0

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

Quoted 117 lines · Peter Meerwald

Quoted 99 lines · Javier Martinez Canillas

Quoted 75 lines · Santosh

Quoted 60 lines · Venkatraman

Quoted 58 lines · Tony Lindgren

Quoted 56 lines · Shilimkar, Santosh

Quoted 40 lines · Tony Lindgren

Quoted 39 lines · Javier Martinez Canillas

Quoted 36 lines · Santosh

Hi,

Quoted 17 lines · Javier Martinez Canillas

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

Quoted 7 lines

DMA engine channel 62

selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.

Signed-off-by Javier Martinez Canillas <[email protected]>

---

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 4 lines

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,

Quoted 7 lines

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

arch/arm/configs/omap2plus_defconfig +0 -0

index b152de7..e58edc3 100644

arch/arm/configs/omap2plus_defconfig CONFIG_MMC_OMAP_HS=y · line 200

Quoted 8 lines

arch/arm/configs/omap2plus_defconfig +2 -0

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

Quoted 3 lines

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

Quoted 6 lines · Peter Meerwald

the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel

there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit

Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP.

Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP.

Quoted 14 lines · Russell King - ARM Linux

Quoted 6 lines · Peter Meerwald

the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel

there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit

Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP.

Quoted 6 lines

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/

Quoted 23 lines · Santosh

Quoted 14 lines · Russell King - ARM Linux

Quoted 6 lines · Peter Meerwald

the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel

there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit

Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP.

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 38 lines

Quoted 20 lines

Quoted 13 lines

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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

Quoted 25 lines · Javier Martinez Canillas

Quoted 23 lines · Santosh

Hi,

Quoted 8 lines · Javier Martinez Canillas

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

Quoted 7 lines

[ 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 <[email protected]>

---

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.

Quoted 6 lines

Quoted 2 lines

Regards
Santosh

Hi Santosh,

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

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

Regards,

Tony
--

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

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

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