public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <shuah.khan@hp.com>
To: Mark Salter <msalter@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	a-jacquiot@ti.com, linux-c6x-dev@linux-c6x.org,
	LKML <linux-kernel@vger.kernel.org>,
	shuahkhan@gmail.com
Subject: Re: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
Date: Thu, 15 Nov 2012 10:45:00 -0700	[thread overview]
Message-ID: <1353001500.2532.29.camel@lorien2> (raw)
In-Reply-To: <1351890491.3161.23.camel@lorien2>

On Fri, 2012-11-02 at 15:08 -0600, Shuah Khan wrote:
> 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.

Mark/Marek,

This is for c6x to go through Marek's tree with all the other arch
patches. Hope that is ok with you Mark.

https://lkml.org/lkml/2012/11/3/219 fixes the debug_dma_mapping_error()
dependency on get_dma_ops() that caused compile errors on c6x.

Thanks,
-- Shuah


  reply	other threads:[~2012-11-15 17:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25 23:01 [PATCH RFT] c6x: dma-mapping: support debug_dma_mapping_error Shuah Khan
2012-10-26 15:40 ` [PATCH RFT RESEND linux-next] " Shuah Khan
2012-11-02 16:44   ` Shuah Khan
2012-11-02 19:10     ` Mark Salter
2012-11-02 19:53       ` Shuah Khan
2012-11-02 20:15         ` Mark Salter
2012-11-02 20:26           ` Shuah Khan
2012-11-02 20:59             ` Mark Salter
2012-11-02 21:08               ` Shuah Khan
2012-11-15 17:45                 ` Shuah Khan [this message]
2012-11-15 18:02                   ` Mark Salter

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=1353001500.2532.29.camel@lorien2 \
    --to=shuah.khan@hp.com \
    --cc=a-jacquiot@ti.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-c6x-dev@linux-c6x.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=msalter@redhat.com \
    --cc=shuahkhan@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox