lkml.org 
[lkml]   [2009]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRE: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
    Date
    From

    >Subject: Re: [PATCH v2 2/2] Crypto: Talitos: Support for
    >Async_tx XOR offload
    >
    >On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote:
    >> Kumar Gala wrote:
    >> >>> Changes with respect to v1 as per comments received o.
    >Rebased to
    >> >>> linux-next as of 20091216 o. The selection is based exclusive of
    >> >>> fsldma o. Intoduced a new Kernel Configuration variable
    >> >>> *. This enables selecting the Cryptographic functionality
    >> >>> of Talitos along with fsldma.
    >> >>> *. Disables the XOR parity calculation offload, if
    >fsldma enabled
    >> >>> either as kernel in-built or as a module
    >> >>> *. Once the inter-operability with fsldma is resolved,
    >this option
    >> >>> can be removed
    >> >> wait, why can't the interoperability bug be fixed in the
    >first place?
    >> >
    >> > I agree w/Kim. We need to better understand what the bug
    >is and how to reproduce it so we can get to the root cause.
    >> >
    >> > Paper taping over it by disabling fsldma is not the right solution.
    >>
    >> Hopefully this prompts fsldma authors to get involved because the
    >> interoperability issue has been out there without comment*, just
    >> band-aids, since October.
    >>
    >> --
    >> Dan
    >>
    >> * well one comment from Ira saying the interrupt
    >functionality worked
    >> for him.
    >
    >Yes, I have used the device_prep_dma_interrupt() functionality
    >quite a while back. However, I found it to be pretty much
    >useless. Any functionality I need is covered by adding a
    >callback to the last DMA
    >memcpy() operation. Since the operations happen in-order, I
    >can be sure that the entire set of memcpy()s cas completed. I
    >never needed the capability to generate an interrupt without a
    >memcpy().
    >
    >I agree that the fsldma driver could use some love. There are
    >places where I am still not confident in the locking. Perhaps
    >I can find some time over Christmas to work on it, but I need
    >someone with 85xx/86xx hardware to test the changes. I only
    >have 83xx hardware.

    I can also help with the 85xx testing when I finish the busy project
    soon.

    - Leo


    \
     
     \ /
      Last update: 2009-12-18 15:49    [W:3.305 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site