From: Felix Radensky <hidden> Date: 2011-02-28 18:47:22
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
Hi Ira,<br>
<br>
Attached dmesg output.<br>
<br>
Felix.<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th>
<td>Re: [PATCH 0/8] fsldma: lockup fixes</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
<td>Mon, 28 Feb 2011 09:16:24 -0800</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
<td>Ira W. Snyder <a class="moz-txt-link-rfc2396E" href="mailto:iws@ovro.caltech.edu"><iws@ovro.caltech.edu></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
<td>Felix Radensky <a class="moz-txt-link-rfc2396E" href="mailto:felix@embedded-sol.com"><felix@embedded-sol.com></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">CC: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:linuxppc-dev@ozlabs.org"><linuxppc-dev@ozlabs.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>On Mon, Feb 28, 2011 at 01:36:38PM +0200, Felix Radensky wrote:
> Hi Ira,
>
> I've tried your patches with linux-2.6.38-rc6 on P2020RDB.
> DMA test fails with the following errors if threads_per_chan != 1
>
> dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0)
> dma0chan0-copy2: #0: test timed out
>
> I've run the test like this:
>
> modprobe dmatest threads_per_chan=2 iterations=1
>
Thanks Felix. This works fine on the 83xx DMA controller. When you have
a chance, can you add "#define DEBUG 1" as the first line of
drivers/dma/fsldma.c and then rerun your test with:
modprobe dmatest threads_per_chan=2 iterations=1 max_channels=1
And send me the dmesg output.
I don't quite understand the difference between links and lists in the
85xx controller yet. I'll work my way through the datasheet this morning
and send out a fixed patch.
Thanks very much for running the tests!
Ira
</pre>
</body>
</html>
From: Ira W. Snyder <hidden> Date: 2011-02-28 19:53:54
On Mon, Feb 28, 2011 at 08:47:42PM +0200, Felix Radensky wrote:
<br>
Hi Ira,<br>
<br>
Attached dmesg output.<br>
<br>
Felix.<br>
<br>
<pre>On Mon, Feb 28, 2011 at 01:36:38PM +0200, Felix Radensky wrote:
> Hi Ira,
>
> I've tried your patches with linux-2.6.38-rc6 on P2020RDB.
> DMA test fails with the following errors if threads_per_chan != 1
>
> dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0)
> dma0chan0-copy2: #0: test timed out
>
> I've run the test like this:
>
> modprobe dmatest threads_per_chan=2 iterations=1
>
Thanks Felix. This works fine on the 83xx DMA controller. When you have
a chance, can you add "#define DEBUG 1" as the first line of
drivers/dma/fsldma.c and then rerun your test with:
modprobe dmatest threads_per_chan=2 iterations=1 max_channels=1
And send me the dmesg output.
I don't quite understand the difference between links and lists in the
85xx controller yet. I'll work my way through the datasheet this morning
and send out a fixed patch.
Thanks very much for running the tests!
Ira
[ snip most of dmesg output ]
Freeing unused kernel memory: 136k init
__dma_request_channel: success (dma0chan0)
of:fsl-elo-dma ffe0c300.dma: chan0: idle, starting controller
dmatest: Started 2 threads using dma0chan0
of:fsl-elo-dma ffe0c300.dma: chan0: irq: stat = 0x8
of:fsl-elo-dma ffe0c300.dma: chan0: irq: End-of-link INT
of:fsl-elo-dma ffe0c300.dma: chan0: irq: Exit
of:fsl-elo-dma ffe0c300.dma: chan0: tasklet entry
of:fsl-elo-dma ffe0c300.dma: chan0: completed_cookie=1
of:fsl-elo-dma ffe0c300.dma: chan0: no pending LDs
of:fsl-elo-dma ffe0c300.dma: chan0: tasklet exit
dma0chan0-copy0: verifying source buffer...
dma0chan0-copy0: verifying dest buffer...
dma0chan0-copy0: #0: No errors with src_off=0x3a2 dst_off=0xc1e len=0x2ce5
dma0chan0-copy0: terminating after 1 tests, 0 failures (status 0)
of:fsl-elo-dma ffe0c300.dma: chan0: idle, starting controller
dma0chan0-copy1: #0: test timed out
dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0)
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Thanks again,
Ira
From 8935444cb18c921332ebe1d055531e54f0c100e9 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <redacted>
Date: Mon, 28 Feb 2011 11:33:17 -0800
Subject: [PATCH] fsldma: try and debug 85xx controller
1 - reduce the maximum transfer size to 1000 bytes to force chains
2 - re-enable end-of-segment interrupts to see what the hardware does
3 - enable end-of-list interrupts to see what the hardware does
4 - debug cookies (this shouldn't be a problem, but just in case)
NOT AT ALL Signed-off-by: Ira W. Snyder [off-list ref]
---
drivers/dma/fsldma.c | 16 ++++++++++++++++
drivers/dma/fsldma.h | 3 ++-
2 files changed, 18 insertions(+), 1 deletions(-)
@@ -397,6 +402,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)child->async_tx.cookie=cookie;}+dev_dbg(chan->dev,"%s: assign cookies: end=%d\n",chan->name,cookie);chan->common.cookie=cookie;/* put this transaction onto the tail of the pending queue */
@@ -1018,6 +1024,16 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)stat&=~FSL_DMA_SR_EOLNI;}+if(stat&FSL_DMA_SR_EOLSI){+dev_dbg(chan->dev,"%s: irq: End-of-list INT\n",name);+stat&=~FSL_DMA_SR_EOLSI;+}++if(stat&FSL_DMA_SR_EOSI){+dev_dbg(chan->dev,"%s: irq: End-of-segment INT\n",name);+stat&=~FSL_DMA_SR_EOSI;+}+/* check that the DMA controller is really idle */if(!dma_is_idle(chan))dev_err(chan->dev,"%s: irq: controller not idle!\n",name);
From: Felix Radensky <hidden> Date: 2011-02-28 20:15:32
Hi Ira,
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
From: Ira W. Snyder <hidden> Date: 2011-02-28 21:11:07
On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
Hi Ira,
quoted
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Attached relevant dmesg portion.
Ok, try this patch on top of the last one.
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
From 58bc23c3b68f8db0aa09434fdeb6aef641a5eadd Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <redacted>
Date: Mon, 28 Feb 2011 12:55:55 -0800
Subject: [PATCH] fsldma: enable end-of-segments interrupt on last descriptor
This is a hack to manually set the end-of-segments interrupt on the last
descriptor in each chain. It appears that the P2020RDB controller
doesn't generate the end-of-links interrupt as explained in the
datasheet.
Signed-off-by: Ira W. Snyder <redacted>
---
drivers/dma/fsldma.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
From: Felix Radensky <hidden> Date: 2011-02-28 21:27:22
Hi Ira,
On 02/28/2011 11:11 PM, Ira W. Snyder wrote:
On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
quoted
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Attached relevant dmesg portion.
Ok, try this patch on top of the last one.
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
From: Ira W. Snyder <hidden> Date: 2011-03-01 00:22:01
On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote:
Hi Ira,
On 02/28/2011 11:11 PM, Ira W. Snyder wrote:
quoted
On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
quoted
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Attached relevant dmesg portion.
Ok, try this patch on top of the last one.
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
Looks like this was not the last one. The test still fails, see below
From this log, it looks like the DMA controller is not generating an
interrupt after the second chain is started. The first chain is finished
before the second thread runs and starts its chain.
The end-of-segments interrupt is completely missing. The part is not
behaving as the datasheet explains it should. Are you sure you applied
the patch and rebuilt the kernel? (Just checking to be sure. I'm very
appreciative of the amount of help you've given me debugging this!)
Can you run this for me:
modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4
Thanks again,
Ira
From: Felix Radensky <hidden> Date: 2011-03-01 05:45:59
Hi Ira,
On 03/01/2011 02:21 AM, Ira W. Snyder wrote:
On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
On 02/28/2011 11:11 PM, Ira W. Snyder wrote:
quoted
On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
quoted
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Attached relevant dmesg portion.
Ok, try this patch on top of the last one.
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
Looks like this was not the last one. The test still fails, see below
From this log, it looks like the DMA controller is not generating an
interrupt after the second chain is started. The first chain is finished
before the second thread runs and starts its chain.
The end-of-segments interrupt is completely missing. The part is not
behaving as the datasheet explains it should. Are you sure you applied
the patch and rebuilt the kernel? (Just checking to be sure. I'm very
appreciative of the amount of help you've given me debugging this!)
I've double checked and I'm sure I've applied your patch and rebuilt
the kernel.
Can you run this for me:
modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4
Thanks again,
Ira
From: Felix Radensky <hidden> Date: 2011-03-01 05:52:13
Hi Ira,
On 03/01/2011 02:21 AM, Ira W. Snyder wrote:
On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
On 02/28/2011 11:11 PM, Ira W. Snyder wrote:
quoted
On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
quoted
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Attached relevant dmesg portion.
Ok, try this patch on top of the last one.
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
Looks like this was not the last one. The test still fails, see below
From this log, it looks like the DMA controller is not generating an
interrupt after the second chain is started. The first chain is finished
before the second thread runs and starts its chain.
The end-of-segments interrupt is completely missing. The part is not
behaving as the datasheet explains it should. Are you sure you applied
the patch and rebuilt the kernel? (Just checking to be sure. I'm very
appreciative of the amount of help you've given me debugging this!)
Can you run this for me:
modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4
Thanks again,
Ira
Without your patches applied the output of the test above looks
like this:
__dma_request_channel: success (dma0chan0)
dmatest: Started 1 threads using dma0chan0
of:fsl-elo-dma ffe0c300.dma: irq: channel 0, stat = 0xa
of:fsl-elo-dma ffe0c300.dma: irq: End-of-segments INT
of:fsl-elo-dma ffe0c300.dma: irq: clndar 0x2f34d000, nlndar 0x100000000
of:fsl-elo-dma ffe0c300.dma: irq: End-of-link INT
of:fsl-elo-dma ffe0c300.dma: no pending LDs
of:fsl-elo-dma ffe0c300.dma: irq: Exit
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 1
of:fsl-elo-dma ffe0c300.dma: LD ef34d000 callback
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 1
dma0chan0-copy0: verifying source buffer...
dma0chan0-copy0: verifying dest buffer...
dma0chan0-copy0: #0: No errors with src_off=0xb90 dst_off=0x101c len=0x2aea
of:fsl-elo-dma ffe0c300.dma: irq: channel 0, stat = 0xa
of:fsl-elo-dma ffe0c300.dma: irq: End-of-segments INT
of:fsl-elo-dma ffe0c300.dma: irq: clndar 0x2f34d000, nlndar 0x100000000
of:fsl-elo-dma ffe0c300.dma: irq: End-of-link INT
of:fsl-elo-dma ffe0c300.dma: no pending LDs
of:fsl-elo-dma ffe0c300.dma: irq: Exit
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 2
of:fsl-elo-dma ffe0c300.dma: LD ef34d000 callback
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 2
dma0chan0-copy0: verifying source buffer...
dma0chan0-copy0: verifying dest buffer...
dma0chan0-copy0: #1: No errors with src_off=0x74a dst_off=0x54d len=0x35f5
of:fsl-elo-dma ffe0c300.dma: irq: channel 0, stat = 0xa
of:fsl-elo-dma ffe0c300.dma: irq: End-of-segments INT
of:fsl-elo-dma ffe0c300.dma: irq: clndar 0x2f34d000, nlndar 0x100000000
of:fsl-elo-dma ffe0c300.dma: irq: End-of-link INT
of:fsl-elo-dma ffe0c300.dma: no pending LDs
of:fsl-elo-dma ffe0c300.dma: irq: Exit
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 3
of:fsl-elo-dma ffe0c300.dma: LD ef34d000 callback
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 3
dma0chan0-copy0: verifying source buffer...
dma0chan0-copy0: verifying dest buffer...
dma0chan0-copy0: #2: No errors with src_off=0x2ad dst_off=0x557 len=0x35e1
of:fsl-elo-dma ffe0c300.dma: irq: channel 0, stat = 0xa
of:fsl-elo-dma ffe0c300.dma: irq: End-of-segments INT
of:fsl-elo-dma ffe0c300.dma: irq: clndar 0x2f34d000, nlndar 0x100000000
of:fsl-elo-dma ffe0c300.dma: irq: End-of-link INT
of:fsl-elo-dma ffe0c300.dma: no pending LDs
of:fsl-elo-dma ffe0c300.dma: irq: Exit
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 4
of:fsl-elo-dma ffe0c300.dma: LD ef34d000 callback
of:fsl-elo-dma ffe0c300.dma: chan completed_cookie = 4
dma0chan0-copy0: verifying source buffer...
dma0chan0-copy0: verifying dest buffer...
dma0chan0-copy0: #3: No errors with src_off=0x0 dst_off=0x0 len=0x4000
dma0chan0-copy0: terminating after 4 tests, 0 failures (status 0)
Felix.
From: Ira W. Snyder <hidden> Date: 2011-03-01 16:55:19
On Tue, Mar 01, 2011 at 07:52:39AM +0200, Felix Radensky wrote:
Hi Ira,
On 03/01/2011 02:21 AM, Ira W. Snyder wrote:
quoted
On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
On 02/28/2011 11:11 PM, Ira W. Snyder wrote:
quoted
On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
quoted
Hi Ira,
quoted
Thank you very much Felix. The dmesg output shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
Attached relevant dmesg portion.
Ok, try this patch on top of the last one.
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
Looks like this was not the last one. The test still fails, see below
From this log, it looks like the DMA controller is not generating an
interrupt after the second chain is started. The first chain is finished
before the second thread runs and starts its chain.
The end-of-segments interrupt is completely missing. The part is not
behaving as the datasheet explains it should. Are you sure you applied
the patch and rebuilt the kernel? (Just checking to be sure. I'm very
appreciative of the amount of help you've given me debugging this!)
Can you run this for me:
modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4
Thanks again,
Ira
Without your patches applied the output of the test above looks
like this:
Thanks, this is exactly what I was going to ask for next. :)
I really don't understand why the P2020 DMA controller isn't behaving
nicely after my patches.
Can you run a git bisect to figure out which patch in the series causes
the problems. It should take three or four build + test cycles to narrow
down which patch breaks the driver. When it is finished, send me the
output of git bisect.
Like this (assuming you have two branches: master and
fsldma, where fsldma is master + my patches):
# setup the bisect
git bisect start
git bisect bad fsldma
git bisect good master
# build and test the kernel using the same test as before:
modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4
# if the test passes:
git bisect good
# if the test fails:
git bisect bad
# now build + test again, then mark that good or bad. Repeat until
# finished.
I really appreciate your help in testing this. You've been great at
providing everything I've asked for.
Thanks,
Ira
From: Ira W. Snyder <hidden> Date: 2011-03-01 19:52:11
On Tue, Mar 01, 2011 at 08:55:15AM -0800, Ira W. Snyder wrote:
[ big snip ]
Thanks, this is exactly what I was going to ask for next. :)
I really don't understand why the P2020 DMA controller isn't behaving
nicely after my patches.
Can you run a git bisect to figure out which patch in the series causes
the problems. It should take three or four build + test cycles to narrow
down which patch breaks the driver. When it is finished, send me the
output of git bisect.
Like this (assuming you have two branches: master and
fsldma, where fsldma is master + my patches):
# setup the bisect
git bisect start
git bisect bad fsldma
git bisect good master
# build and test the kernel using the same test as before:
modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4
# if the test passes:
git bisect good
# if the test fails:
git bisect bad
# now build + test again, then mark that good or bad. Repeat until
# finished.
I really appreciate your help in testing this. You've been great at
providing everything I've asked for.
I'd still like the bisect if you have a chance. I've re-reviewed the
patch series, and found the places that change register writes to the
controller.
The patch below changes the register operations back to the original
order. It doesn't make any sense why this would be required, but it is
worth a quick try.
I've added an "XXX" mark where you can comment out a single line if this
patch fails. It is highly unlikely to make any difference, but I'm
really having a hard time understanding what is wrong.
Ira
From 9e479ce27f8c1819694d7082bb4a27772b4baf52 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <redacted>
Date: Tue, 1 Mar 2011 11:43:00 -0800
Subject: [PATCH] fsldma: try and fix 85xx DMA controller
This is just a random guess at what might be wrong. The datasheet
doesn't say that a completed transfer must be aborted before starting a
new transfer (nor does it make much sense). However, the old code did it
anyway.
NOT AT ALL Signed-off-by: Ira W. Snyder [off-list ref]
---
drivers/dma/fsldma.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
From: Felix Radensky <hidden> Date: 2011-03-02 05:49:31
Hi Ira,
On 03/01/2011 09:52 PM, Ira W. Snyder wrote:
On Tue, Mar 01, 2011 at 08:55:15AM -0800, Ira W. Snyder wrote:
[ big snip ]
I'd still like the bisect if you have a chance. I've re-reviewed the
patch series, and found the places that change register writes to the
controller.
The patch below changes the register operations back to the original
order. It doesn't make any sense why this would be required, but it is
worth a quick try.
I've added an "XXX" mark where you can comment out a single line if this
patch fails. It is highly unlikely to make any difference, but I'm
really having a hard time understanding what is wrong.
From: Ira W. Snyder <hidden> Date: 2011-03-02 16:42:50
On Wed, Mar 02, 2011 at 07:49:57AM +0200, Felix Radensky wrote:
Hi Ira,
On 03/01/2011 09:52 PM, Ira W. Snyder wrote:
quoted
On Tue, Mar 01, 2011 at 08:55:15AM -0800, Ira W. Snyder wrote:
[ big snip ]
I'd still like the bisect if you have a chance. I've re-reviewed the
patch series, and found the places that change register writes to the
controller.
The patch below changes the register operations back to the original
order. It doesn't make any sense why this would be required, but it is
worth a quick try.
I've added an "XXX" mark where you can comment out a single line if this
patch fails. It is highly unlikely to make any difference, but I'm
really having a hard time understanding what is wrong.
This patch fixes the problem. See below
Excellent! I know what is happening now. The 85xx controller doesn't
clear the "channel start" bit at the end of a transfer. Sure enough,
buried near the end of the chapter, the datasheet implies this in a
table very far away from the register definitions. The 83xx datasheet
explicitly states that it clears this bit automatically.
I'll post an updated patch series later today. Thank you so much for
being patient and trying out all of these patches.
Ira