linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: avorontsov@mvista.com, miltonm@bga.com,
	linux-kernel@vger.kernel.org, paulus@samba.org,
	scottwood@freescale.com, nacc@us.ibm.com,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 03/11] ppc: Create ops to choose between direct window and iommu based on device mask
Date: Mon, 11 Oct 2010 10:41:41 +1100	[thread overview]
Message-ID: <1286754101.2463.515.camel@pasglop> (raw)
In-Reply-To: <20101011000903R.fujita.tomonori@lab.ntt.co.jp>

On Mon, 2010-10-11 at 00:09 +0900, FUJITA Tomonori wrote:
> On Sat, 09 Oct 2010 10:44:53 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Fri, 2010-10-08 at 10:33 -0700, Nishanth Aravamudan wrote:
> > > Also allow the coherent ops to be iommu if only the coherent mask is too
> > > small, mostly for driver that do not set set the coherent mask but also
> > > don't use the coherent api.
> > 
> > You are doing the transition at map_sg time which is a hot path, I don't
> > like that. Also you add all those "choose" variants of the dma ops...
> > not very nice at all.
> 
> Agreed, looks hacky.
> 
> 
> > You may want to look at the patches I posted to the list a while back
> > for doing direct DMA on Bimini:
> > 
> > [PATCH 1/2] powerpc/dma: Add optional platform override of dma_set_mask()
> 
> Would it be cleaner if each ppc dma_map_ops has the own set_dma_mask
> and dma_set_mask simply calls dma_map_ops->set_dma_mask?

I'm not sure I parse what you wrote above :-)

I did try with various methods back then, and what ended up sucking the
less was basically to hookup dma_set_mask() at the arch level.

In fact, it makes sense to the extent that the arch is the one that
knows that there are multiple regions configured potentially with
different capabilities.

You can still do the switch within the dma_ops->set_dma_mask if you want
I suppose, especially if you end up hitting different attribute regions
within a single bus or such but from my experience, it gets really hacky
with multiple ops structures etc...
> 
> > [PATCH 2/2] powerpc/dart_iommu: Support for 64-bit iommu bypass window on PCIe
> 

Cheers,
Ben.

  reply	other threads:[~2010-10-10 23:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08 17:33 [RFC PATCH 00/11] ppc: enable dynamic dma window support Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 01/11] macio: ensure all dma routines get copied over Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 02/11] ppc: allow direct and iommu to coexist Nishanth Aravamudan
2010-10-08 23:38   ` Benjamin Herrenschmidt
2010-10-08 17:33 ` [RFC PATCH 03/11] ppc: Create ops to choose between direct window and iommu based on device mask Nishanth Aravamudan
2010-10-08 23:43   ` Benjamin Herrenschmidt
2010-10-08 23:44   ` Benjamin Herrenschmidt
2010-10-10 15:09     ` FUJITA Tomonori
2010-10-10 23:41       ` Benjamin Herrenschmidt [this message]
2010-10-08 17:33 ` [RFC PATCH 04/11] ppc: add memory_hotplug_max Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 05/11] ppc: do not search for dma-window property on dlpar remove Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 06/11] ppc: checking for pdn->parent is redundant Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 07/11] ppc/iommu: do not need to check for dma_window == NULL Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 08/11] ppc/iommu: remove unneeded pci_dma_bus_setup_pSeriesLP Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 09/11] ppc/iommu: pass phb only to iommu_table_setparms_lpar Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 10/11] ppc/iommu: add routines to pseries iommu to map tces 1-1 Nishanth Aravamudan
2010-10-08 17:33 ` [RFC PATCH 11/11] ppc: add dynamic dma window support Nishanth Aravamudan

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=1286754101.2463.515.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=akpm@linux-foundation.org \
    --cc=avorontsov@mvista.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=nacc@us.ibm.com \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.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;
as well as URLs for NNTP newsgroup(s).