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: Sat, 30 Jun 2012 15:35:48 +0800 [thread overview]
Message-ID: <4FEEAC54.10503@gmail.com> (raw)
In-Reply-To: <20120625215928.GA3853@philter.vipri.net>
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
Hi Phil
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)?
Regards
Cloudy
On 2012-6-26 5:59, Phil Sutter wrote:
> Hi,
>
> On Tue, Jun 26, 2012 at 12:05:55AM +0800, cloudy.linux wrote:
>> This time the machine can't finish the boot again and the console was
>> flooded by the message like below:
>
> Oh well. I decided to drop that BUG_ON() again, since I saw it once
> being triggered while in interrupt context. But since the error is
> non-recovering anyway, I guess it may stay there as well.
>
>> Also, I had to make some modifications to the
>> arch/arm/mach-orion5x/common.c to let it compile successfully:
>> 1 Add including of mv_dma.h
>> 2 Add macro to define TARGET_SRAM as 9 (which is defined in addr-map.c,
>> so I think the clean solution should be modify the addr-map.h? Anyway,
>> as a quick solution the source finally got compiled)
>
> Hmm, yeah. Test-compiling for the platform one is writing code for is
> still a good idea. But it's even worse than that: according to the
> specs, for IDMA the SRAM target ID is 5, not 9 like it is for the CPU.
>
> Please apply the attached patch on top of the one I sent earlier,
> without your modifications (the necessary parts are contained in it).
> Also, I've added some log output to the decode window setter, so we see
> what's going on there.
>
> Anyway, thanks a lot for your help so far! I hope next try shows some
> progress at least.
>
> Greetings, Phil
>
>
> Phil Sutter
> Software Engineer
>
[-- Attachment #2: gl-cesa-110.PNG --]
[-- Type: image/png, Size: 62921 bytes --]
next prev parent reply other threads:[~2012-06-30 7:36 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 [this message]
2012-07-06 15:30 ` Phil Sutter
2012-07-08 5:38 ` cloudy.linux
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=4FEEAC54.10503@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.