lkml.org 
[lkml]   [2012]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
    From
    Date
    On Fri, 2012-11-02 at 16:59 -0400, Mark Salter wrote:
    > On Fri, 2012-11-02 at 14:26 -0600, Shuah Khan wrote:
    > > On Fri, 2012-11-02 at 16:15 -0400, Mark Salter wrote:
    > > > On Fri, 2012-11-02 at 13:53 -0600, Shuah Khan wrote:
    > > > > On Fri, 2012-11-02 at 15:10 -0400, Mark Salter wrote:
    > > > > > On Fri, 2012-11-02 at 10:44 -0600, Shuah Khan wrote:
    > > > > > > On Fri, 2012-10-26 at 09:40 -0600, Shuah Khan wrote:
    > > > > > > > Add support for debug_dma_mapping_error() call to avoid warning from
    > > > > > > > debug_dma_unmap() interface when it checks for mapping error checked
    > > > > > > > status. Without this patch, device driver failed to check map error
    > > > > > > > warning is generated.
    > > > > > > >
    > > > > > > > Signed-off-by: Shuah Khan <shuah.khan@hp.com>
    > > > > > > > ---
    > > > > > > > arch/c6x/include/asm/dma-mapping.h | 1 +
    > > > > > > > 1 file changed, 1 insertion(+)
    > > > > >
    > > > > > > Would you like to this patch go through c6x arch tree or linux-next?
    > > > > > > Please let me know your preference.
    > > > > >
    > > > > > I tried to test this but I get a build error with CONFIG_DMA_API_DEBUG:
    > > > > >
    > > > > > /linux-next/lib/dma-debug.c: In function 'has_mapping_error':
    > > > > > /linux-next/lib/dma-debug.c:863:15: error: implicit declaration of function 'get_dma_ops' [-Werror=implicit-function-declaration]
    > > > > > /linux-next/lib/dma-debug.c:863:34: warning: initialization makes pointer from integer without a cast [enabled by default]
    > > > > >
    > > > > > C6X (along with some other architectures) doesn't have a get_dma_ops()
    > > > > > function defined.
    > > > >
    > > > > That is a problem I didn't think about. I did a check and looks like c6x
    > > > > and frv are the only ones that don't have get_dma_ops() defined. frv is
    > > >
    > > > By my count, there are 14 architectures with get_dma_ops() and 14
    > > > without.
    > > Right. I should have explained more. The following archs
    > >
    > > arch/avr32/include/asm/dma-mapping.h
    > > arch/blackfin/include/asm/dma-mapping.h
    > > arch/cris/include/asm/dma-mapping.h
    > > arch/mn10300/include/asm/dma-mapping.h
    > > arch/parisc/include/asm/dma-mapping.h
    > > arch/xtensa/include/asm/dma-mapping.h
    > >
    > > define dma_map_page() and dma_map_single() and not call
    > > debug_dma_map_page() interface. There is no risk of mis-matched debug
    > > and non-debug mapping and mapping error checks like in the case of other
    > > archs and c6x.
    >
    > Ah, okay. Not all architectures support HAVE_DMA_API_DEBUG. So, of those
    > that do, c6x seems to be the only one with dma_ops.
    >
    > >
    > > > > in a different category as it doesn't use dma_debug interfaces. IN the
    > > > > case c6x, now with my change to add debug_dma_mapping_error(), we will
    > > > > start seeing warnings since dma_map_page() and dma_map_single() are
    > > > > debugged with a call to debug_dma_map_page() and the corresponding
    > > > > dma_mapping_error() interface doesn't call debug_dma_mapping_error()
    > > > > interface
    > > > >
    > > > > - Does adding get_dma_ops() make sense? Doesn't look like c6x exports
    > > > > dma_ops?
    > > > >
    > > > > Any other ideas?
    > > >
    > > > I'm not sure. I don't know what get_dma_ops() does and it doesn't seem
    > > > to be documented anywhere.
    > >
    > > It returns pointer to dma_ops like the one on alpha:
    > >
    > > static inline struct dma_map_ops *get_dma_ops(struct device *dev)
    > > {
    > > return dma_ops;
    > > }
    >
    > Okay, so what is dma_ops used for? Looks like maybe supporting different
    > dma features/functionality on different busses/devices.
    >
    > >
    > > c6x doesn't define dma_ops looks like. Is that correct? Returning null
    > > from get_dma_ops() is not an option as get_dma_ops() return is assumed
    > > to be not null.
    >
    > As things stand, c6x DMA hw doesn't really need dma_ops and until this
    > patch, I could build in DMA debug support without dma_ops. So do we
    > really want to require dma_ops for dma debug support even for those
    > architectures which don't otherwise need it? I could add dma_ops, but
    > it seems silly to do so only for dma debug.

    I agree it doesn't make sense to add dma_ops when there is no need to.
    Until now dma-debug didn't depend on dma_ops. This dependency has been
    introduced with the debug_dma_mapping_error() interface I added :(

    Let me go back and see if I can come up with a way to not require
    dma_ops for debug-dma.

    Thanks,
    -- Shuah




    \
     
     \ /
      Last update: 2012-11-02 23:01    [W:3.430 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site