From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC] ARM DMA mapping TODO, v1
Date: Wed, 27 Apr 2011 22:21:48 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.39-rc4+; KDE/4.5.1; x86_64; ; )
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
        linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
References: <201104212129.17013.arnd@arndb.de> <201104271302.44249.arnd@arndb.de> <20110427201605.GW17290@n2100.arm.linux.org.uk>
In-Reply-To: <20110427201605.GW17290@n2100.arm.linux.org.uk>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201104272221.48601.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1266
Lines: 26

On Wednesday 27 April 2011 22:16:05 Russell King - ARM Linux wrote:
> > As for making the default being to do cache handling, I'm not completely
> > sure how that would work on architectures where most devices are coherent.
> > If I understood the DRM people correctly, some x86 machine have noncoherent
> > DMA in their GPUs while everything else is coherent.
> 
> Well, it sounds like struct device needs a flag to indicate whether it is
> coherent or not - but exactly how this gets set seems to be architecture
> dependent.  I don't see bus or driver code being able to make the necessary
> decisions - eg, tulip driver on x86 would be coherent, but tulip driver on
> ARM would be non-coherent.
> 
> Nevertheless, doing it on a per-device basis is definitely the right
> answer.

The flag would not get set by the driver that uses the device but
the driver that found it, e.g. the PCI bus or the platform code,
which should know about these things and also install the appropriate
iommu or mapping operations.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/