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

[FUJITA Tomonori]

On Fri, 18 Jun 2010 00:30:51 +0900
Paul Mundt <lethal@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
> > 
> > > From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
> > > Date: Thu, 17 Jun 2010 21:21:13 +0900
> > > 
> > > > On Wed, 16 Jun 2010 23:24:44 -0700
> > > > "Michael Chan" <mchan@xxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/