Hi Peter,
yes, that is one of the differences to the EVM that the SD card is on
MMCSD1. This is due to the pin multiplexer and other peripherals we're
using.
Your patch is correct, however the edma_callback() is using the channel
number parameter for debug messages only. For the actual work
echan->ch_num is used. BTW is that correct? Could there be a mismatch
between the echan->ch_num and the ch_num parameter?
Something else seems to be odd in edma_alloc_chan_resources():
/* Alloc channel resources */
static int edma_alloc_chan_resources(struct dma_chan *chan)
{
struct edma_chan *echan = to_edma_chan(chan);
struct device *dev = chan->device->dev;
int ret;
int a_ch_num;
LIST_HEAD(descs);
a_ch_num = edma_alloc_channel(echan->ch_num, edma_callback,
chan, EVENTQ_DEFAULT);
The third parameter to edma_alloc_channel() should be echan, not chan,
since the edma_callback() interprets the callback data parameter as
struct edma_chan *.
Let me know if you find something or if you have an advice for more debug.
Cheers
Petr
On 20.03.2015 14:59, Peter Ujfalusi wrote:
Petr,
On 03/18/2015 11:33 PM, Petr Kulhavy wrote:
Hi Peter,
Yes, we do not use DT.
Our board design is very close to the da850evm reference board. So if you have
a chance of getting hold of it you could try on that one.
I have been trying to reproduce this on my OMAP-L138-EVM (da850evm) but was
not able.
There is a big difference in your an my setup: the MMC on my EVM is connected
to MMC/SD0 interface while in your setup it seams to be connected to MMC/SD1.
The DMA requests for MMC/SD0 is eDMA CC0 16/17, while the MMC/SD1 is eDMA CC1
28/29.
So they are handled by different channel controllers. I would not rule out
that the support for the second CC has issues.
The information from you logs just points to this direction also:
You are writing to the MMC, so CC1 ch29 is active most of the time.
In your log the channel number sometimes 65565 ((1 << 16) | 29) sometimes it
is 29. In my case it is 17 every time.
I think there is something funny regarding to how these channels on CC1 are
working and this might be causing the leak for you.
Unfortunately I do not have HW where I could use any channel on CC1 so I can
not debug this further, but I'll look at the code to see if anything obvious
stands out.
And something does stand out:
arch/arm/common/edma.c: dma_irq_handler()
It calls the callback with a wrong interrupt number since it does not take
into account the different CC.
Can you try something similar to see if it helps:
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 6c49887d326e..e1d413c61e9e 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -405,7 +405,8 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
BIT(slot));
if (edma_cc[ctlr]->intr_data[channel].callback)
edma_cc[ctlr]->intr_data[channel].callback(
- channel, EDMA_DMA_COMPLETE,
+ EDMA_CTLR_CHAN(ctlr, channel),
+ EDMA_DMA_COMPLETE,
edma_cc[ctlr]->intr_data[channel].data);
}
} while (sh_ipr);
--
--
Petr Kulhavy, MSc
System Architect
*BARIX*
petr@xxxxxxxxx <mailto:petr@xxxxxxxxx> | Skype: brain.barix
Barix AG, Seefeldstrasse 303 | 8008 Zurich, Switzerland
T +41 43 43322 11 | www.barix.com <http://www.barix.com>
You have received this email because of your relationship Barix AG and
its affiliated companies. Barix AG and its affiliated companies do not
sell or exchange email addresses, or any other personal contact
information provided by you with any third parties. All email
distributions are managed and controlled by Barix AG and its affiliated
companies.
Barix AG, Seefeldstr. 303, 8008 Zürich, Switzerland. Company Reg. No:
CH-020.3.023.869-8, VAT Reg. No: CHE-105.687.663.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
