arm: msm: Add System MMU support.
in [Kernel]
|
Prev: [PATCH 3/4] Checkpatch: prefer usleep_range over usleep
Next: [PATCH 0/4 -tip] delay documentation and checkpatch additions
From: Daniel Walker on 27 Jul 2010 18:50 On Tue, 2010-07-27 at 15:41 -0700, Stepan Moskovchenko wrote: > +/* Copyright (c) 2010, Code Aurora Forum. All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions are > + * met: > + * * Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above > + * copyright notice, this list of conditions and the following > + * disclaimer in the documentation and/or other materials provided > + * with the distribution. > + * * Neither the name of Code Aurora Forum, Inc. nor the names of its > + * contributors may be used to endorse or promote products derived > + * from this software without specific prior written permission. This should be GPLv2 .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 28 Jul 2010 04:50 On Wednesday 28 July 2010 00:41:06 Stepan Moskovchenko wrote: > > Add support for the System MMUs found on the 8x60 and 8x72 > families of Qualcomm chips. These SMMUs allow virtualization > of the address space used by most of the multimedia cores > on these chips. > How is this different from an IOMMU? From a very brief look, it seems that you should be using the existing dma-mapping APIs here instead of making up your own. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: stepanm on 28 Jul 2010 13:40 > On Wednesday 28 July 2010 00:41:06 Stepan Moskovchenko wrote: >> Add support for the System MMUs found on the 8x60 and 8x72 >> families of Qualcomm chips. These SMMUs allow virtualization >> of the address space used by most of the multimedia cores >> on these chips. > > How is this different from an IOMMU? > > From a very brief look, it seems that you should be using the > existing dma-mapping APIs here instead of making up your own. > > Arnd These are just SMMU APIs, and the DMA-mapping API is one layer above this. We have our own SMMU API for the MSM SoCs because we have muliple IOMMUs, each one having multiple contexts, or even having multiple instances of the same context. Our usage model is also quite a bit different from how the DMA APIs are set up. I believe only two IOMMU drivers actually make use of the DMA API (Intel and AMD) and the other ones (OMAP and other SoCs) have their own APIs for their specific use cases. Steve Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 28 Jul 2010 14:00 On Wednesday 28 July 2010, stepanm(a)codeaurora.org wrote: > > On Wednesday 28 July 2010 00:41:06 Stepan Moskovchenko wrote: > >> Add support for the System MMUs found on the 8x60 and 8x72 > >> families of Qualcomm chips. These SMMUs allow virtualization > >> of the address space used by most of the multimedia cores > >> on these chips. > > > > How is this different from an IOMMU? > > > > From a very brief look, it seems that you should be using the > > existing dma-mapping APIs here instead of making up your own. > > > > Arnd > > > These are just SMMU APIs, and the DMA-mapping API is one layer above this. > > We have our own SMMU API for the MSM SoCs because we have muliple IOMMUs, > each one having multiple contexts, or even having multiple instances of > the same context. Our usage model is also quite a bit different from how > the DMA APIs are set up. I believe only two IOMMU drivers actually make > use of the DMA API (Intel and AMD) and the other ones (OMAP and other > SoCs) have their own APIs for their specific use cases. The DMA API is extremely flexible, it works just fine with all the IOMMUs that I've seen so far. Please take a look at include/asm-generic/dma-mapping-common.h and its users to see how to use multiple IOMMUs depending on the device. If the OMAP developers got this wrong, that's not your problem :-) Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 28 Jul 2010 17:30
On Wed, Jul 28, 2010 at 07:50:20PM +0200, Arnd Bergmann wrote: > The DMA API is extremely flexible, it works just fine with all the > IOMMUs that I've seen so far. Please take a look at > include/asm-generic/dma-mapping-common.h and its users to see how > to use multiple IOMMUs depending on the device. We don't yet use those DMA API interface extensions because we haven't had the need. If someone who has the need wants to put the effort in though... One of the problems with it though is the abstraction of the sync* operations is the wrong way around for stuff like dmabounce - we want to be passed the base address of the buffer (so we can look this up), plus offset and length. We don't want to know just the region which is affected. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |