All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.