From: "cloudy.linux" <cloudy.linux@gmail.com>
To: Phil Sutter <phil.sutter@viprinet.com>
Cc: linux-crypto@vger.kernel.org, andrew@lunn.ch,
Simon Baatz <gmbnomis@gmail.com>
Subject: Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA
Date: Sun, 08 Jul 2012 13:38:47 +0800 [thread overview]
Message-ID: <4FF91CE7.7090205@gmail.com> (raw)
In-Reply-To: <20120706153018.GB24676@philter.vipri.net>
On 2012-7-6 23:30, Phil Sutter wrote:
> Hi Cloudy,
>
> On Sat, Jun 30, 2012 at 03:35:48PM +0800, cloudy.linux wrote:
>> Although I had no idea about what's wrong, I looked in the functional
>> errata (again), And I found what's attached (The doc I got from Internet
>> was a protected PDF, that's why I had to use screen capture).
>> Is this relevant? Or maybe you have already addressed this in the code
>> (I can just read some simple C code)?
>
> To me, doesn't read like a real problem, just a guideline for doing
> things. From the output you sent me in your previous mail, I'd rather
> suspect fetching the first descriptor to be faulty: the next descriptor
> pointer contains the first descriptor's DMA address, all other fields
> are zero (this is the situation when triggering the engine, as on
> kirkwood all I have to do is fill the first descriptor's address in and
> TDMA does the rest) and IDMA triggers an address miss interrupt at
> address 0x0. So probably IDMA starts up and tries to look up decoding
> windows for he up the still zero source and destination addresses.
>
> According to the specs, when using the next descriptor field for
> fetching the first descriptor one also has to set the FETCH_ND field in
> DMA_CTRL register, also for TDMA. Though, on my hardware the only
> working configuration is the implemented one, i.e. without FETCH_ND
> being set.
>
> I have implemented a separate approach just for IDMA, which instead of
> just writing the first descriptor's address to NEXT_DESC does:
> 1. clear CTRL_ENABLE bit
> 2. fill NEXT_DESC
> 3. set CTRL_ENABLE along with FETCH_ND
> hopefully this is the way to go on Orion. Since Marvell's BSP doesn't
> implement *DMA attached to CESA, I have nowhere to look this up. Getting
> it right for TDMA was just a matter of trial and error.
>
> My public git got a few updates, including the code described above.
> Would be great if you could give it a try.
>
> Greetings, Phil
>
>
>
> Phil Sutter
> Software Engineer
>
Hi
Newest result. Still couldn't boot up. This time the source was cloned
from your git repository.
MV-DMA: window at bar0: target 0, attr 14, base 0, size 8000000
MV-DMA: window at bar1: target 5, attr 0, base f2200000, size 10000
MV-DMA: IDMA engine up and running, IRQ 23
MV-DMA: idma_print_and_clear_irq: address miss @0!
MV-DMA: tpg.reg + DMA_CTRL = 0x80001d04
MV-DMA: tpg.reg + DMA_BYTE_COUNT = 0x0
MV-DMA: tpg.reg + DMA_SRC_ADDR = 0x0
MV-DMA: tpg.reg + DMA_DST_ADDR = 0x0
MV-DMA: tpg.reg + DMA_NEXT_DESC = 0x79b1000
MV-DMA: tpg.reg + DMA_CURR_DESC = 0x0
MV-DMA: DMA descriptor list:
MV-DMA: entry 0 at 0xffdbb000: dma addr 0x79b1000, src 0x79b4000, dst
0xf2200080, count 16, own 1, next 0x79b1010
MV-DMA: entry 1 at 0xffdbb010: dma addr 0x79b1010, src 0x799c28c, dst
0xf2200000, count 80, own 1, next 0x79b1020
MV-DMA: entry 2 at 0xffdbb020: dma addr 0x79b1020, src 0x0, dst 0x0,
count 0, own 0, next 0x79b1030
MV-DMA: entry 3 at 0xffdbb030: dma addr 0x79b1030, src 0xf2200080, dst
0x79b4000, count 16, own 1, next 0x0
MV-CESA:got an interrupt but no pending timer?
------------[ cut here ]------------
kernel BUG at drivers/crypto/mv_cesa.c:1126!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in:
CPU: 0 Not tainted (3.5.0-rc2+ #3)
pc : [<c01df8e0>] lr : [<c0015810>] psr: 20000093
sp : c79b9e58 ip : c79b9da8 fp : c79b9e6c
r10: c02f2164 r9 : c0306322 r8 : 0000001c
r7 : 00000000 r6 : 00000000 r5 : c0312988 r4 : 00000002
r3 : c799c200 r2 : 0000de20 r1 : fdd90000 r0 : fdd90000
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: a005317f Table: 00004000 DAC: 00000017
Process mv_crypto (pid: 276, stack limit = 0xc79b8270)
Stack: (0xc79b9e58 to 0xc79ba000)
9e40: c79afc40
0000001c
9e60: c79b9ea4 c79b9e70 c0047694 c01df858 c788929c 4bf287d9 00000000
c02f2164
9e80: 0000001c 00000000 c79b9f4c c79bbe18 c02ecc18 c02ef0a0 c79b9ebc
c79b9ea8
9ea0: c0047844 c0047650 00022000 c02f2164 c79b9ed4 c79b9ec0 c0049b4c
c0047824
9ec0: c0049ac4 c02ff738 c79b9ee4 c79b9ed8 c0046fd0 c0049ad4 c79b9f04
c79b9ee8
9ee0: c000985c c0046fb0 c01de804 c025db80 a0000013 fdd20200 c79b9f14
c79b9f08
9f00: c0008170 c0009834 c79b9f6c c79b9f18 c0008c14 c0008170 00000000
00000001
9f20: c79b9f60 0000de00 c0312988 c799c200 c7936cc0 c79ac780 c79bbe18
c02ecc18
9f40: c02ef0a0 c79b9f6c c79b9f70 c79b9f60 c01de804 c025db80 a0000013
ffffffff
9f60: c79b9fbc c79b9f70 c01de804 c025db80 00000000 c79b9f80 c025d904
c0035000
9f80: c78897a0 c7827de8 c79b8000 c02ecc18 00000013 c7827de8 c799c200
c01de620
9fa0: 00000013 00000000 00000000 00000000 c79b9ff4 c79b9fc0 c002da78
c01de630
9fc0: c7827de8 00000000 c799c200 00000000 c79b9fd0 c79b9fd0 00000000
c7827de8
9fe0: c002d9e8 c0018354 00000000 c79b9ff8 c0018354 c002d9f8 01e6e7fe
01e6e7ff
Backtrace:
Function entered at [<c01df848>] from [<c0047694>]
r5:0000001c r4:c79afc40
Function entered at [<c0047640>] from [<c0047844>]
Function entered at [<c0047814>] from [<c0049b4c>]
r4:c02f2164 r3:00022000
Function entered at [<c0049ac4>] from [<c0046fd0>]
r4:c02ff738 r3:c0049ac4
Function entered at [<c0046fa0>] from [<c000985c>]
Function entered at [<c0009824>] from [<c0008170>]
r6:fdd20200 r5:a0000013 r4:c025db80 r3:c01de804
Function entered at [<c0008160>] from [<c0008c14>]
Exception stack(0xc79b9f18 to 0xc79b9f60)
9f00: 00000000
00000001
9f20: c79b9f60 0000de00 c0312988 c799c200 c7936cc0 c79ac780 c79bbe18
c02ecc18
9f40: c02ef0a0 c79b9f6c c79b9f70 c79b9f60 c01de804 c025db80 a0000013
ffffffff
Function entered at [<c025db70>] from [<c01de804>]
Function entered at [<c01de620>] from [<c002da78>]
Function entered at [<c002d9e8>] from [<c0018354>]
r6:c0018354 r5:c002d9e8 r4:c7827de8
Code: e89da830 e59f000c eb01ec39 eaffffe9 (e7f001f2)
MV-DMA: idma_print_and_clear_irq: address miss @0!
MV-DMA: tpg.reg + DMA_CTRL = 0x80001d04
MV-DMA: tpg.reg + DMA_BYTE_COUNT = 0x0
MV-DMA: tpg.reg + DMA_SRC_ADDR = 0x0
MV-DMA: tpg.reg + DMA_DST_ADDR = 0x0
MV-DMA: tpg.reg + DMA_NEXT_DESC = 0x0
MV-DMA: tpg.reg + DMA_CURR_DESC = 0x0
MV-DMA: DMA descriptor list:
MV-DMA: entry 0 at 0xffdbb000: dma addr 0x79b1000, src 0x79b4000, dst
0xf2200080, count 16, own 1, next 0x79b1010
MV-DMA: entry 1 at 0xffdbb010: dma addr 0x79b1010, src 0x799c28c, dst
0xf2200000, count 80, own 1, next 0x79b1020
MV-DMA: entry 2 at 0xffdbb020: dma addr 0x79b1020, src 0x0, dst 0x0,
count 0, own 0, next 0x79b1030
MV-DMA: entry 3 at 0xffdbb030: dma addr 0x79b1030, src 0xf2200080, dst
0x79b4000, count 16, own 1, next 0x0
MV-DMA: idma_print_and_clear_irq: address miss @0!
MV-DMA: tpg.reg + DMA_CTRL = 0x80001d04
MV-DMA: tpg.reg + DMA_BYTE_COUNT = 0x0
MV-DMA: tpg.reg + DMA_SRC_ADDR = 0x0
MV-DMA: tpg.reg + DMA_DST_ADDR = 0x0
MV-DMA: tpg.reg + DMA_NEXT_DESC = 0x0
MV-DMA: tpg.reg + DMA_CURR_DESC = 0x0
MV-DMA: DMA descriptor list:
MV-DMA: entry 0 at 0xffdbb000: dma addr 0x79b1000, src 0x79b4000, dst
0xf2200080, count 16, own 1, next 0x79b1010
MV-DMA: entry 1 at 0xffdbb010: dma addr 0x79b1010, src 0x799c28c, dst
0xf2200000, count 80, own 1, next 0x79b1020
MV-DMA: entry 2 at 0xffdbb020: dma addr 0x79b1020, src 0x0, dst 0x0,
count 0, own 0, next 0x79b1030
MV-DMA: entry 3 at 0xffdbb030: dma addr 0x79b1030, src 0xf2200080, dst
0x79b4000, count 16, own 1, next 0x0
Regards
next prev parent reply other threads:[~2012-07-08 5:39 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 16:08 RFC: support for MV_CESA with TDMA Phil Sutter
2012-05-25 16:08 ` [PATCH 01/13] mv_cesa: do not use scatterlist iterators Phil Sutter
2012-05-25 16:08 ` [PATCH 02/13] mv_cesa: minor formatting cleanup, will all make sense soon Phil Sutter
2012-05-25 16:08 ` [PATCH 03/13] mv_cesa: prepare the full sram config in dram Phil Sutter
2012-05-25 16:08 ` [PATCH 04/13] mv_cesa: split up processing callbacks Phil Sutter
2012-05-25 16:08 ` [PATCH 05/13] add a driver for the Marvell TDMA engine Phil Sutter
2012-05-25 16:08 ` [PATCH 06/13] mv_cesa: use TDMA engine for data transfers Phil Sutter
2012-05-25 16:08 ` [PATCH 07/13] mv_cesa: have TDMA copy back the digest result Phil Sutter
2012-05-25 16:08 ` [PATCH 08/13] mv_cesa: fetch extra_bytes via TDMA engine, too Phil Sutter
2012-05-25 16:08 ` [PATCH 09/13] mv_cesa: implementing packet chain mode, only aes for now Phil Sutter
2012-05-25 16:08 ` [PATCH 10/13] mv_cesa: reorganise mv_start_new_hash_req a bit Phil Sutter
2012-05-25 16:08 ` [PATCH 11/13] mv_cesa: implement descriptor chaining for hashes, too Phil Sutter
2012-05-25 16:08 ` [PATCH 12/13] mv_cesa: drop the now unused process callback Phil Sutter
2012-05-25 16:08 ` [PATCH 13/13] mv_cesa, mv_tdma: outsource common dma-pool handling code Phil Sutter
2012-05-27 14:03 ` RFC: support for MV_CESA with TDMA cloudy.linux
2012-05-29 11:34 ` Phil Sutter
2012-06-12 10:04 ` Herbert Xu
2012-06-12 10:24 ` Phil Sutter
2012-06-12 11:39 ` Herbert Xu
2012-06-12 17:17 ` RFC: support for MV_CESA with IDMA or TDMA Phil Sutter
2012-06-12 17:17 ` [PATCH 01/13] mv_cesa: do not use scatterlist iterators Phil Sutter
2012-06-12 17:17 ` [PATCH 02/13] mv_cesa: minor formatting cleanup, will all make sense soon Phil Sutter
2012-06-12 17:17 ` [PATCH 03/13] mv_cesa: prepare the full sram config in dram Phil Sutter
2012-06-12 17:17 ` [PATCH 04/13] mv_cesa: split up processing callbacks Phil Sutter
2012-06-12 17:17 ` [PATCH 05/13] add a driver for the Marvell IDMA/TDMA engines Phil Sutter
2012-06-12 17:17 ` [PATCH 06/13] mv_cesa: use DMA engine for data transfers Phil Sutter
2012-06-12 17:17 ` [PATCH 07/13] mv_cesa: have DMA engine copy back the digest result Phil Sutter
2012-06-12 17:17 ` [PATCH 08/13] mv_cesa: fetch extra_bytes via DMA engine, too Phil Sutter
2012-06-12 17:17 ` [PATCH 09/13] mv_cesa: implementing packet chain mode, only aes for now Phil Sutter
2012-06-12 17:17 ` [PATCH 10/13] mv_cesa: reorganise mv_start_new_hash_req a bit Phil Sutter
2012-06-12 17:17 ` [PATCH 11/13] mv_cesa: implement descriptor chaining for hashes, too Phil Sutter
2012-06-12 17:17 ` [PATCH 12/13] mv_cesa: drop the now unused process callback Phil Sutter
2012-06-12 17:17 ` [PATCH 13/13] mv_cesa, mv_dma: outsource common dma-pool handling code Phil Sutter
2012-06-15 1:40 ` RFC: support for MV_CESA with IDMA or TDMA cloudy.linux
2012-06-15 9:51 ` Phil Sutter
2012-06-16 0:20 ` [PATCH 0/2] Fixes " Simon Baatz
2012-06-16 0:20 ` [PATCH 1/2] mv_dma: fix mv_init_engine() error case Simon Baatz
2012-06-16 0:20 ` [PATCH 2/2] ARM: Orion: mv_dma: Add support for clk Simon Baatz
2012-06-18 13:47 ` [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA Phil Sutter
2012-06-18 20:12 ` Simon Baatz
2012-06-19 11:51 ` Phil Sutter
2012-06-19 15:09 ` cloudy.linux
2012-06-19 17:13 ` Phil Sutter
2012-06-20 1:16 ` cloudy.linux
2012-07-16 9:32 ` Andrew Lunn
2012-07-16 13:52 ` Phil Sutter
2012-07-16 14:03 ` Andrew Lunn
2012-07-16 14:53 ` Phil Sutter
2012-07-16 17:32 ` Simon Baatz
2012-07-16 17:59 ` Andrew Lunn
2012-06-20 13:31 ` cloudy.linux
2012-06-20 15:41 ` Phil Sutter
2012-06-25 13:40 ` Phil Sutter
2012-06-25 14:25 ` cloudy.linux
2012-06-25 14:36 ` Phil Sutter
2012-06-25 16:05 ` cloudy.linux
2012-06-25 21:59 ` Phil Sutter
2012-06-26 11:24 ` cloudy.linux
2012-06-30 7:35 ` cloudy.linux
2012-07-06 15:30 ` Phil Sutter
2012-07-08 5:38 ` cloudy.linux [this message]
2012-07-09 12:54 ` Phil Sutter
2012-07-31 12:12 ` cloudy.linux
2012-10-23 17:11 ` Phil Sutter
2012-06-26 20:31 ` [PATCH 0/1] MV_CESA with DMA: Clk init fixes Simon Baatz
2012-06-26 20:31 ` [PATCH 1/1] mv_dma: mv_cesa: fixes for clock init Simon Baatz
2012-07-06 15:05 ` [PATCH 0/1] MV_CESA with DMA: Clk init fixes Phil Sutter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FF91CE7.7090205@gmail.com \
--to=cloudy.linux@gmail.com \
--cc=andrew@lunn.ch \
--cc=gmbnomis@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=phil.sutter@viprinet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).