mmc: davinci_mmc: add warnings for edma failures

Add warnings in case the edma engine driver fails to allocate slots or channels requested from the davinci_mmc driver.

Some ti-davinci based boards (i.e. board-da850-evm.c) are asking for some reserved chans / slots at board init stage. Later, the mmc driver results in a silent locked state.

index 5d4c5e0..65d4990 100644
@@ -439,8 +439,8 @@ static int mmc_davinci_send_dma_request(struct mmc_davinci_host *host,
                                DMA_MEM_TO_DEV,
                                DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
                if (!desc) {
-                       dev_dbg(mmc_dev(host->mmc),
-                               "failed to allocate DMA TX descriptor");
+                       WARN(1, KERN_WARNING
+                               "failed to allocate DMA TX descriptor\n");
                        ret = -1;
                        goto out;
                }

@@ -461,8 +461,8 @@ static int mmc_davinci_send_dma_request(struct mmc_davinci_host *host,
                                DMA_DEV_TO_MEM,
                                DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
                if (!desc) {
-                       dev_dbg(mmc_dev(host->mmc),
-                               "failed to allocate DMA RX descriptor");
+                       WARN(1, KERN_WARNING
+                               "failed to allocate DMA RX descriptor\n");
                        ret = -1;
                        goto out;
                }

Dear all,

would like some feedback / comment to this patch.

Even a NACK is good if you find it nonsense or un-useful, just to close the loop.

Regards
angelo

-------- Original Message --------
Message-ID: <[email protected]>
Date: Sat, 22 Nov 2014 01:00:28 +0100
From: Angelo Dureghello <[email protected]>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: [email protected]
Subject: [PATCH] mmc: davinci_mmc: add warnings for edma failures
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Add warnings in case the edma engine driver fails to allocate slots or channels requested from the davinci_mmc driver.

Some ti-davinci based boards (i.e. board-da850-evm.c) are asking for some reserved chans / slots at board init stage. Later, the mmc driver results in a silent locked state.

index 5d4c5e0..65d4990 100644
@@ -439,8 +439,8 @@ static int mmc_davinci_send_dma_request(struct

mmc_davinci_host *host,

                                DMA_MEM_TO_DEV,
                                DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
                if (!desc) {

- dev_dbg(mmc_dev(host->mmc),
- "failed to allocate DMA TX descriptor");
+ WARN(1, KERN_WARNING
+ "failed to allocate DMA TX descriptor\n");

                        ret = -1;
                        goto out;
                }
@@ -461,8 +461,8 @@ static int mmc_davinci_send_dma_request(struct
mmc_davinci_host *host,
                                DMA_DEV_TO_MEM,
                                DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
                if (!desc) {

- dev_dbg(mmc_dev(host->mmc),
- "failed to allocate DMA RX descriptor");
+ WARN(1, KERN_WARNING
+ "failed to allocate DMA RX descriptor\n");

                        ret = -1;
                        goto out;
                }

So why does davinci_acquire_dma_channels() succeed then? Isn't that real problem you should be looking into?

Kind regards
Uffe

Hi Uffe,

many hanks for the reply,

i explain with more details,

my custom am1808 board initialization, based on arch/arm/mach-davinci/board-da850-evm.c, reserves some dma chans / slots for the audio at early boot.

While on kernel 3.5.1 mmc was working properly, moving to kernel 3.17.0, due to the dma-engine wrapper introduction (to be selected into menuconfig), the mmc host driver locks silently. System cannot even "reboot" after the failed attempt to reserve the dma slots.

I hardly found out the reason due to missing of clear warnings.

So there is nothing to fix in any other place. Simply, i am suggesting a more visible warning so the driver, instead of lock-up silently, throws a problem.

Feel free to add or discard the patch, as you can see it is nothing functional.

Regards,
Angelo

I understand, thanks for clarifying.

So apparently the error handling for this path isn't working. I think we should fix that instead of just WARN about it.

Kind regards
Uffe