Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA

Hi Cloudy,

On Wed, Jun 20, 2012 at 09:31:10PM +0800, cloudy.linux wrote:

On 2012-6-19 4:12, Simon Baatz wrote:

quoted

I see one effect that I don't fully understand.
Similar to the previous implementation, the system is mostly in
kernel space when accessing an encrypted dm-crypt device:

Today I also compiled the patched 3.5.0-rc3 for another NAS box with 
MV88F6282-Rev-A0 (LS-WVL), I noticed one thing that when the CESA engine 
was used, the interrupt number of mv_crypto kept rising, but the 
interrupt number of mv_tdma was always zero.

Yes, that is exactly how it should be: the DMA engine is configured to
run "attached" to CESA, meaning that when CESA is triggered from
mv_cesa.c, it first enables the DMA engine. Using a special descriptor
in the chain, the DMA engine knows when to stop and signals CESA again
so it can start the crypto operation. Afterwards, CESA triggers the DMA
engine again for copying back the results (or more specific: process the
remaining descriptors in the chain after the special one). After a
descriptor with it's next descriptor field being zero has been handled,
CESA is signaled again which in turn generates the interrupt to signal
the software. So no DMA interrupt needed, and no software interaction in
between data copying and crypto operation, of course. :)

Greetings, Phil

PS: I am currently working at the address decoding problem, will get
back to in a few days when I have something to test. So stay tuned!

Phil Sutter
Software Engineer

-- 


Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany

Phone/Zentrale:         +49-6721-49030-0
Direct line/Durchwahl:  +49-6721-49030-134
Fax:                    +49-6721-49030-209

phil.sutter@viprinet.com
http://www.viprinet.com

Registered office/Sitz der Gesellschaft: Bingen am Rhein
Commercial register/Handelsregister: Amtsgericht Mainz HRB40380
CEO/Geschäftsführer: Simon Kissel