Re: bnx2 fails to compile on parisc because of missing get_dma_ops()

FUJITA Tomonori
2010-06-22T06:30:27Z

On Fri, 18 Jun 2010 00:30:51 +0900
Paul Mundt <lethal@linux-sh.org> wrote:

> On Thu, Jun 17, 2010 at 11:50:35PM +0900, FUJITA Tomonori wrote:
> > On Thu, 17 Jun 2010 07:36:53 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> > > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > > Date: Thu, 17 Jun 2010 21:21:13 +0900
> > >
> > > > On Wed, 16 Jun 2010 23:24:44 -0700
> > > > "Michael Chan" <mchan@broadcom.com> wrote:
> > > >
> > > >> David, why is dma_is_consistent() always returning 1 on sparc? The
> > > >> streaming DMA is not consistent.
> > > >
> > > > I think that there are some confusion about dma_is_consistent(). Some
> > > > architectures think that dma_is_consistent() is supposed to return 1
> > > > if they can allocate coherent memory (note that some architectures
> > > > can't allocate coherent memory).
> > >
> > > Right, and that's why it's defined this way.
> > >
> > > If the desired meaning is different, just me know and I'll fix the
> > > sparc definition.
> >
> > I think that there are some other architectures do the same. We need
> > to make sure that all the architectures define dma_is_consistent() in
> > the same meaning if drivers need it. However, I'm not sure we really
> > need dma_is_consistent(). There is only one user of it (and I think we
> > could remove it).
> >
> > In the bnx2 case, we can simply prefetch on all the archs (or just
> > remove the optimization).
>
> I think its worthwhile keeping, especially since the consistency can vary
> on a per struct device level. If there's a benefit with these sorts of
> prefetch micro-optimizations in drivers when it doesn't cost us that much
> to provide the hint, I don't really see the harm. If dma_is_consistent()
> is suddenly supposed to take on other meanings, or it's supposed to mean
> something entirely different, then this is something we should deal with
> separately.
>
> I don't see any harm in letting drivers know whether we can support
> consistent DMA allocs for a given struct device or not though, even if
> the micro-optimization is marginal at best.

I'm happier with exporting less DMA APIs to drivers because looks like
new original ways to use the APIs wrongly can be always invented.

> At least I've conditionalized the definition on SH, and it seems other
> archictures have done so too. It's not clear what we'd gain from throwing

>From a quick look, except for SH and POWERPC (and always-coherent
architectures), everyone does differently?

There are architectures that need to turn off the CPU cache for
coherent memory, I can't find none of them that see if an address is
coherent or not in dma_is_consistent().

As I wrote, there is only one user of this API and we can remove it
easily. Then I'm not sure it's worth fixing dma_is_consistent() in
many architectures. I prefer to add this to
feature-removal-schedule.txt to see if driver writers oppose.

> that away as long as they're generally in agreement on what it means.