From: Thierry Reding
The linux/iommu.h and linux/iova.h headers belong to the IOMMU subsystem
but scripts/get_maintainers.pl currently fails to assign them because
they aren't listed in MAINTAINERS.
Signed-off-by: Thierry Reding
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
From: Thierry Reding
Currently, building code which uses the API guarded by the IOMMU_IOVA
will fail to link if IOMMU_IOVA is not enabled. Often this code will be
using the API provided by the IOMMU_API Kconfig symbol, but support for
this can be optional, with code falling back to contiguous
On Mon, Mar 20, 2017 at 08:11:28PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Currently, building code which uses the API guarded by the IOMMU_IOVA
> will fail to link if IOMMU_IOVA is not enabled. Often this code will be
> using the API provided by the IOMMU_API Kcon
On Wed, Mar 22, 2017 at 03:55:30PM +0100, Joerg Roedel wrote:
> Hi Thierry
>
> On Mon, Mar 20, 2017 at 08:14:31PM +0100, Thierry Reding wrote:
> > I've got a series of patches that I'd like to merge for v4.12 that have
> > a build-time dependency on this patch.
On Thu, Mar 23, 2017 at 02:28:27AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git core
> head: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992
> commit: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992 [3/3] iommu: Add dummy
> implementations for !IOMMU
On Thu, Jun 08, 2017 at 03:25:26PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not supposed to be used by drivers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/firmware/tegra/ivc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry
On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote:
> Add "nvidia,memory-clients" to identify which swgroup ID a device
> belongs to.
Why not call the property "nvidia,swgid" instead? That seems a lot more
intuitive.
Thierry
pgpsrF4R4_pOe.pgp
Description: PGP signature
___
On Wed, Jun 26, 2013 at 12:28:04PM +0300, Hiroshi Doyu wrote:
[...]
> +#define SWGID_AFI 0
> +#define SWGID_AVPC 1
> +#define SWGID_DC 2
> +#define SWGID_DCB 3
> +#define SWGID_EPP 4
> +#define SWGID_G2 5
> +#define SWGID_HC 6
> +#define SWGID_HDA 7
> +#define SWGID_ISP 8
> +#define SWGID_ISP2 SWGI
On Wed, Jun 26, 2013 at 01:09:06PM +0200, Hiroshi Doyu wrote:
> Thierry Reding wrote @ Wed, 26 Jun 2013 13:06:27
> +0200:
>
> > * PGP Signed by an unknown key
> >
> > On Wed, Jun 26, 2013 at 12:28:21PM +0300, Hiroshi Doyu wrote:
> > > Make PCIe work as it
On Wed, Jun 26, 2013 at 12:28:22PM +0300, Hiroshi Doyu wrote:
> Support multiple generation of Tegra SoCs with this unified
> SMMU driver. Necessary info is expected to be passed from DT.
>
> Signed-off-by: Hiroshi Doyu
> ---
> drivers/iommu/tegra-smmu.c | 80
> ++---
On Wed, Jun 26, 2013 at 12:28:14PM +0300, Hiroshi Doyu wrote:
> Add of_mach_id for T114
I don't think of_mach_id is the right word. Why not use a subject such
as "iommu/tegra: smmu: Add Tegra114 support". And instead of duplicating
the subject in the commit message, perhaps you can say instead tha
On Wed, Jun 26, 2013 at 12:28:21PM +0300, Hiroshi Doyu wrote:
> Make PCIe work as it is. IOMMU support can be implemented later.
>
> Signed-off-by: Hiroshi Doyu
> ---
> drivers/iommu/tegra-smmu.c | 3 +++
> 1 file changed, 3 insertions(+)
Can you provide more information about what the problem
On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
[...]
> @@ -23,3 +24,13 @@ Example:
> nvidia,swgroups = <0x 0
On Wed, Jun 26, 2013 at 12:28:20PM +0300, Hiroshi Doyu wrote:
> Instead of using platfrom data, DT passes "nvidia,swgroups".
>
> Signed-off-by: Hiroshi Doyu
> ---
> drivers/iommu/tegra-smmu.c | 24 +++-
> 1 file changed, 7 insertions(+), 17 deletions(-)
Could this patch not
On Wed, Jun 26, 2013 at 12:28:07PM +0300, Hiroshi Doyu wrote:
> Move up AHB/IOMMU to register them earlier than others. IOMMU needs
> AHB, and IOMMU needs to register all platform devices as
> IOMMU'able. So AHB/IOMMU needs to be instanciated at very beginning.
>
> Signed-off-by: Hiroshi Doyu
> -
On Wed, Jun 26, 2013 at 12:18:17PM +0200, Thierry Reding wrote:
> On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote:
> [...]
> > diff --git
> > a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> > b/Documentation/devicetree/bindings/iommu
On Wed, Jun 26, 2013 at 12:31:41PM +0200, Hiroshi Doyu wrote:
> Hi Thierry,
>
> Thierry Reding wrote @ Wed, 26 Jun 2013 12:06:49
> +0200:
> ...
> > I'm not entirely sure where to find these mappings in the TRM. I see
> > that there's a list of the groups
On Wed, Jun 26, 2013 at 12:28:24PM +0300, Hiroshi Doyu wrote:
> Get swgroup ID from DT. "nvidia,swgroups" indicates which swgroup IDs
> a device belongs to.
>
> Signed-off-by: Hiroshi Doyu
> ---
> arch/arm/boot/dts/tegra30.dtsi | 1 -
> drivers/iommu/tegra-smmu.c | 20 +++-
>
On Wed, Jun 26, 2013 at 12:28:09PM +0300, Hiroshi Doyu wrote:
> This is a bitmap that indicates which HardWare Accelerators(HWA) are
> supported on Tegra114 SoC.
>
> Signed-off-by: Hiroshi Doyu
> ---
> arch/arm/boot/dts/tegra114.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On Wed, Jun 26, 2013 at 12:28:05PM +0300, Hiroshi Doyu wrote:
> This is a bitmap that indicates which HardWare Accelerators(HWA) are
> supported on Tegra30 SoC.
>
> Signed-off-by: Hiroshi Doyu
> ---
> Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt | 6 +-
> arch/arm/boot/dts
On Tue, Jul 16, 2013 at 04:57:03PM -0600, Stephen Warren wrote:
> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > To prevent of_platform_populate() from trying to populate duplicate
> > devices if a device has been already populated.
>
> You need to send drivers/of patches to the DT maintainer and
On Tue, Jul 16, 2013 at 05:18:29PM -0600, Stephen Warren wrote:
> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Fix IOMMU register address.
>
> Oh dear, how serious is this?
>
> That incorrect node got added in v3.9 - a long time ago. Does the SMMU
> driver touch registers during probe() or und
When enabling LPAE on ARM, phys_addr_t becomes 64 bits wide and printing
a variable of that type using a simple %x format specifier causes the
compiler to complain. Change the format specifier to %pa, which is used
specifically for variables of type phys_addr_t.
Signed-off-by: Thierry Reding
On Fri, Oct 25, 2013 at 01:10:38AM +0100, Grant Likely wrote:
> On Thu, 24 Oct 2013 11:21:15 +0200, Hiroshi Doyu wrote:
> > Hi Grant,
> >
> > Grant Likely wrote @ Thu, 24 Oct 2013 10:55:31
> > +0200:
> >
> > > > diff --git a/include/linux/of.h b/include/linux/of.h
> > > > index f95aee3..63
On Fri, Oct 25, 2013 at 10:25:49AM +0200, Hiroshi Doyu wrote:
> Thierry Reding wrote @ Fri, 25 Oct 2013 09:56:55
> +0200:
>
> > > > This patch is a part of HACK to control device instanciation order. We
> > > > have an IOMMU device(platform) which needs to be
On Fri, Oct 25, 2013 at 11:49:05AM +0200, Hiroshi Doyu wrote:
> Thierry Reding wrote @ Fri, 25 Oct 2013 11:11:05
> +0200:
>
> > > > This is actually "the other problem that I'm aware of that could benefit
> > > > from [interrupt resolution at probe tim
On Fri, Oct 25, 2013 at 02:20:51PM +0100, Will Deacon wrote:
> On Fri, Oct 25, 2013 at 09:22:02AM +0100, Hiroshi Doyu wrote:
> > Thierry Reding wrote @ Fri, 25 Oct 2013 09:56:55
> > +0200:
> >
> > > I suspect that there will be enough differences between the vario
On Fri, Oct 25, 2013 at 08:01:36PM +0100, Grant Likely wrote:
> On Fri, 25 Oct 2013 12:49:38 +0200, Thierry Reding
> wrote:
> > On Fri, Oct 25, 2013 at 11:49:05AM +0200, Hiroshi Doyu wrote:
> > > Thierry Reding wrote @ Fri, 25 Oct 2013
> > > 11:11:05 +0200:
>
On Wed, Oct 30, 2013 at 03:58:58PM -0600, Stephen Warren wrote:
> On 10/25/2013 03:11 AM, Thierry Reding wrote:
> ...
> > So my proposed solution for the IOMMU case is to treat it the same
> > as any other resources. Perhaps resource isn't the right word, but
> > at t
On Thu, Oct 31, 2013 at 11:53:22AM -0600, Stephen Warren wrote:
> On 10/31/2013 10:46 AM, Hiroshi Doyu wrote:
> > Stephen Warren wrote @ Thu, 31 Oct 2013 17:35:24
> > +0100:
> >
> > ...
> ... and for the driver to explicitly parse that property, and wait
> until the driver for iommu_ph
On Fri, Nov 01, 2013 at 08:49:09AM +0200, Hiroshi Doyu wrote:
> On Thu, 31 Oct 2013 18:53:22 +0100
> Stephen Warren wrote:
> ...
> > We're talking about memory-mapped on-SoC devices here, that generally
> > only exist inside Tegra SoCs.
> >
> > Even ignoring that (i.e. expanding the argument to a
On Thu, Oct 31, 2013 at 10:37:40AM -0600, Stephen Warren wrote:
> On 10/31/2013 02:14 AM, Hiroshi Doyu wrote:
> > Thierry Reding wrote @ Wed, 30 Oct 2013 23:41:09
> > +0100:
> >
> >> My earlier proposal for deferred interrupt reference resolution actually
> >
On Tue, Nov 19, 2013 at 11:33:06AM +0200, Hiroshi Doyu wrote:
> IOMMU devices on the bus need to be poplulated first, then iommu
> master devices are done later.
>
> With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
> whether a device can be an iommu msater or not. If a device c
On Wed, Nov 20, 2013 at 04:17:08AM +0100, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Tue, 19 Nov 2013 22:22:47
> +0100:
>
> > On 11/19/2013 05:03 AM, Hiroshi Doyu wrote:
> > > Hi Thierry,
> > >
> > > Thierry Reding wrote @ Tue, 19 Nov 2013
> &
On Wed, Nov 20, 2013 at 10:31:11AM +, Will Deacon wrote:
> On Tue, Nov 19, 2013 at 08:45:02PM +, Rob Herring wrote:
> > On 11/19/2013 11:35 AM, Will Deacon wrote:
> > > Adding Andreas and Rob for input on potential binding additions to the
> > > SMMU.
> >
> > The above proposal would be a
On Thu, Dec 12, 2013 at 06:14:02PM -0800, Greg KH wrote:
> On Thu, Dec 12, 2013 at 11:39:20AM +, Grant Likely wrote:
> > On Thu, 12 Dec 2013 09:57:05 +0200, Hiroshi Doyu wrote:
> > > IOMMU devices on the bus need to be poplulated first, then iommu
> > > master devices are done later.
> > >
>
On Wed, Dec 18, 2013 at 09:27:29AM -0700, Stephen Warren wrote:
> On 12/18/2013 01:02 AM, Mark Zhang wrote:
> > On 12/12/2013 03:57 PM, Hiroshi Doyu wrote:
> >> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> >> binding. "swgroup" is a group of H/W clients which a Tegra SoC
On Tue, Jan 07, 2014 at 01:25:37PM +0800, Mark Zhang wrote:
> On 12/05/2013 08:25 PM, Hiroshi Doyu wrote:
[...]
> > @@ -526,6 +530,21 @@ static int smmu_setup_regs(struct smmu_device *smmu)
> > return 0;
> > }
> >
> > +static void flush_ptc_by_addr(struct smmu_device *smmu, unsigned long *pt
On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote:
> On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
> > +- mmu-masters: A phandle to device nodes representing the master for which
> > + the System MMU can provide a translation. Any additional
> > values
> > +
On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
> On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
> > On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote:
> > > On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
> > > > +- mm
On Mon, Apr 28, 2014 at 02:05:30PM +0200, Arnd Bergmann wrote:
> On Monday 28 April 2014 13:18:03 Thierry Reding wrote:
> > On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
> > > On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
> > > > And possib
On Mon, Apr 28, 2014 at 02:05:30PM +0200, Arnd Bergmann wrote:
[...]
> let me clarify by example:
>
> iommu@1 {
> compatible = "some,simple-iommu";
> reg = <1>;
> #iommu-cells = <0>; /* supports only one master */
> };
>
> iommu@2 {
>
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
More
On Sat, May 17, 2014 at 05:04:55PM +0900, Cho KyongHo wrote:
> On Fri, 16 May 2014 14:23:18 +0200, Thierry Reding wrote:
[...]
> > +Examples:
> > +=
> > +
> > +Single-master IOMMU:
> > +
> > +
> >
On Mon, May 19, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote:
> On Friday 16 May 2014 14:23:18 Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This commit introduces a generic device tree binding for IOMMU devices.
> > Only a very minimal subset is describe
On Mon, May 19, 2014 at 06:22:31PM +0100, Dave Martin wrote:
> On Mon, May 19, 2014 at 01:53:37PM +0100, Thierry Reding wrote:
[...]
> > My understanding here is mostly based on the OpenFirmware working group
> > proposal for the dma-ranges property[0]. I'll give another ex
On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote:
> On Monday 19 May 2014 14:53:37 Thierry Reding wrote:
> > On Mon, May 19, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote:
> > > On Friday 16 May 2014 14:23:18 Thierry Reding wrote:
> > > > From: Thierry
On Tue, May 20, 2014 at 12:04:54PM +0200, Arnd Bergmann wrote:
> On Monday 19 May 2014 22:59:46 Thierry Reding wrote:
> > On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote:
> > > On Monday 19 May 2014 14:53:37 Thierry Reding wrote:
> > > > On Mon, May 19,
On Tue, May 20, 2014 at 01:15:48PM +0200, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 13:05:37 Thierry Reding wrote:
> > On Tue, May 20, 2014 at 12:04:54PM +0200, Arnd Bergmann wrote:
> > > On Monday 19 May 2014 22:59:46 Thierry Reding wrote:
> > > > On Mon, Ma
On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote:
[...]
> > Couldn't a single-master IOMMU be windowed?
>
> Ah, yes. That would actually be like an IBM pSeries, which has a windowed
> IOMMU but uses
On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote:
> > On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote:
> > [...]
> > > &g
On Tue, May 20, 2014 at 10:31:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 16:00:02 Thierry Reding wrote:
> > On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote:
> > > > On Tue, Ma
On Tue, May 20, 2014 at 10:26:12PM +0200, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 16:24:59 Dave Martin wrote:
> > On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote:
[...]
> > &
On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> > On Tue, May 20, 2014 at 10:26:12PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 20 May 2014 16:24:59 Dave Martin wrote:
> > > > On Tue, Ma
On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 10:16:09 Thierry Reding wrote:
> > On Tue, May 20, 2014 at 10:31:29PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 20 May 2014 16:00:02 Thierry Reding wrote:
> > > > On Tue, Ma
On Wed, May 21, 2014 at 11:36:32AM +0200, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 11:00:38 Thierry Reding wrote:
> > On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > > On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
>
> > > > >
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
Signed
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
Signed
On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This commit introduces a generic device tree binding for IOMMU devices.
> > Only a very minimal subset is described here
On Sun, Jun 01, 2014 at 10:55:46AM +0100, Will Deacon wrote:
> On Fri, May 30, 2014 at 08:54:37PM +0100, Arnd Bergmann wrote:
> > On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> > > Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
> > > bit) to afford 64 stream IDs so t
On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> >
> > IIUC the original problem, "a master with 8 streamIDs" means something
> > like below, where some devices have multiple IDs but some have a
> > single. A sinle #address-cells
014 08:16:05 Rob Herring wrote:
> > > >> On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
> > > >> wrote:
> > > >> > From: Thierry Reding
> > > >> > +IOMMU master node:
> > > >> > +==
> > > &
On Wed, Jun 04, 2014 at 05:41:32PM +0100, Will Deacon wrote:
> On Wed, Jun 04, 2014 at 03:35:10PM +0100, Thierry Reding wrote:
> > On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote:
> > > In the strictest sense, no.
> > >
> > > But for a large set o
On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
[...]
> > Arnd, can you take another look at this binding and see if there's
> > anything else missing? If not I'll go through the document
On Fri, May 30, 2014 at 09:01:19PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 12:22:32 Dave Martin wrote:
> > > +
> > > +Examples:
> > > +=
> > > +
> > > +Single-master IOMMU:
> > > +
> > > +
> > > + iommu {
> > > + #address-cells = <0>;
> > > +
This is somewhat off-topic, but given the various concepts discussed in
this thread I'm beginning to wonder how they will be implemented. The
current implementation hooks the IOMMU API into the DMA mapping API, and
the way this is done is by setting a single IOMMU (or rather a set of
IOMMU operatio
On Sat, Jun 07, 2014 at 03:22:13PM +0200, Arnd Bergmann wrote:
> On Saturday 07 June 2014 00:45:45 Thierry Reding wrote:
> > This is somewhat off-topic, but given the various concepts discussed in
> > this thread I'm beginning to wonder how they will be implemented.
>
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
> On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
> > On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
> > > On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> > [...]
&g
On Tue, Jun 17, 2014 at 01:18:11PM +0100, Will Deacon wrote:
> On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
> > On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
> > > On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
> > > >
From: Thierry Reding
This structure is read-only data and should never be modified.
Signed-off-by: Thierry Reding
---
drivers/iommu/amd_iommu.c | 4 ++--
drivers/iommu/arm-smmu.c| 2 +-
drivers/iommu/exynos-iommu.c| 2 +-
drivers/iommu/fsl_pamu_domain.c | 2 +-
drivers
From: Thierry Reding
Add the memory controller and wire up the interrupt that is used to
report errors. Also add an #iommu-cells property to make the device
as an IOMMU.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 9 +
1 file changed, 9 insertions(+)
diff
From: Thierry Reding
Add an IOMMU device registry for drivers to register with and implement
a method for users of the IOMMU API to attach to an IOMMU device. This
allows to support deferred probing and gives the IOMMU API a convenient
hook to perform early initialization of a device if
From: Thierry Reding
The memory controller on NVIDIA Tegra124 exposes various knobs that can
be used to tune the behaviour of the clients attached to it.
In addition, the memory controller implements an SMMU (IOMMU) which can
translate I/O virtual addresses to physical addresses for clients
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
Signed
From: Thierry Reding
The memory controller on NVIDIA Tegra124 exposes various knobs that can
be used to tune the behaviour of the clients attached to it.
Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
From: Thierry Reding
Add an iommus property to each of the display controllers and encode the
SWGROUP in the specifier.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot
From: Thierry Reding
This series adds support for the IOMMU found on Tegra124 SoCs. The SMMU
groups memory clients into SWGROUPs and each SWGROUP can be assigned to
one I/O virtual address space. Translation of virtual addresses can be
enabled per memory client.
Patch 1 adds an IOMMU device
From: Thierry Reding
This enables IOMMU interoperation with the DMA mapping API so that
clients that use the DMA mapping API can seemlessly make use of an
existing IOMMU.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm
From: Thierry Reding
The SDMMC controllers can use the IOMMU to avoid the need for bounce
buffers.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index
From: Thierry Reding
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm
From: Thierry Reding
Attach to the device's master interface of the IOMMU at .probe() time.
IOMMU support becomes available via the DMA mapping API interoperation
code, but this explicit attachment is necessary to ensure proper probe
order.
Signed-off-by: Thierry Reding
---
drivers/mmc
On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add an IOMMU device registry for drivers to register with and implement
> a method for users of the IOMMU API to attach to an IOMMU device. This
> allows to support deferred probing and give
From: Thierry Reding
This structure is read-only data and should never be modified.
Signed-off-by: Thierry Reding
---
Changes in v2:
- add missing hunk from include/device.h
drivers/iommu/amd_iommu.c | 4 ++--
drivers/iommu/arm-smmu.c| 2 +-
drivers/iommu/exynos-iommu.c
On Fri, Jun 27, 2014 at 03:41:20PM +0800, Joseph Lo wrote:
> Hi Thierry,
>
> On 06/27/2014 04:49 AM, Thierry Reding wrote:
> [snip]
> >+
> >+#define MC_INTSTATUS 0x000
> >+#define MC_INT_DECERR_MTS (1 << 16)
> >+#define MC_INT_SECERR_SEC (1 <
On Thu, Jun 26, 2014 at 09:04:54PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This structure is read-only data and should never be modified.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/iommu/amd_iommu.c | 4 ++--
> drivers/iommu/arm-smmu.c
On Fri, Jun 27, 2014 at 12:46:14PM +0300, Hiroshi DOyu wrote:
> Thierry Reding writes:
[...]
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
[...]
> > + if (tegra->domain) {
> > + err = iommu_attach_device(tegra->domain, dc-&
On Fri, Jun 27, 2014 at 12:46:02PM +0300, Hiroshi DOyu wrote:
>
> Thierry Reding writes:
>
> > From: Thierry Reding
> >
> > Attach to the device's master interface of the IOMMU at .probe() time.
> > IOMMU support becomes available via the DMA mapping
On Fri, Jun 27, 2014 at 12:46:38PM +0300, Hiroshi DOyu wrote:
>
> Thierry Reding writes:
>
> > From: Thierry Reding
> >
> > The memory controller on NVIDIA Tegra124 exposes various knobs that can
> > be used to tune the behaviour of the clients attached to
On Fri, Jun 27, 2014 at 01:07:04PM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2014 22:49:44 Thierry Reding wrote:
> > +static const struct tegra_mc_client tegra124_mc_clients[] = {
> > + {
> > + .id = 0x01,
> > +
On Mon, Jun 30, 2014 at 09:51:51AM -0700, Olav Haugan wrote:
[...]
> +int iommu_map_range(struct iommu_domain *domain, unsigned int iova,
> + struct scatterlist *sg, unsigned int len, int prot)
> +{
> + if (unlikely(domain->ops->map_range == NULL))
> + return -ENODEV
On Mon, Jun 30, 2014 at 09:51:52AM -0700, Olav Haugan wrote:
[...]
> diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
[...]
> +/**
> + * readl_poll_timeout - Periodically poll an address until a condition is
> met or a timeout occurs
> + * @addr: Address to poll
> + * @val: Variable to
On Fri, Jul 04, 2014 at 01:05:30PM +0200, Joerg Roedel wrote:
> On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> > Add an IOMMU device registry for drivers to register with and implement
> > a method for users of the IOMMU API to attach to an IOMMU device. Thi
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
Signed
On Sun, Jul 06, 2014 at 08:17:22PM +0200, Arnd Bergmann wrote:
> On Friday 04 July 2014, Will Deacon wrote:
> > On Fri, Jul 04, 2014 at 02:47:10PM +0100, Thierry Reding wrote:
> > > On Fri, Jul 04, 2014 at 01:05:30PM +0200, Joerg Roedel wrote:
> > > > On Thu, Ju
On Wed, Jul 09, 2014 at 02:40:50PM +0100, Will Deacon wrote:
> On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This commit introduces a generic device tree binding for IOMMU devices.
> > Only a very minimal subset i
On Wed, Jul 09, 2014 at 08:40:21PM -0400, Rob Clark wrote:
> On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan wrote:
> > On 7/8/2014 4:49 PM, Rob Clark wrote:
> >> On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan wrote:
> >>> Hi Hiroshi,
> >>>
> >>> On 7/3/2014 9:29 PM, Hiroshi Doyu wrote:
> Hi Olav,
On Wed, Jul 09, 2014 at 07:10:48PM +0100, Will Deacon wrote:
> Hi Thierry,
>
> On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote:
> > On Wed, Jul 09, 2014 at 02:40:50PM +0100, Will Deacon wrote:
> > > I would like to move the ARM SMMU driver over to this for
On Thu, Jul 10, 2014 at 11:23:34AM +0100, Will Deacon wrote:
> On Thu, Jul 10, 2014 at 10:49:10AM +0100, Thierry Reding wrote:
> > On Wed, Jul 09, 2014 at 07:10:48PM +0100, Will Deacon wrote:
> > > On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote:
> > >
On Sat, Jul 12, 2014 at 02:22:01PM +0200, Arnd Bergmann wrote:
> On Saturday 12 July 2014, Rob Clark wrote:
> > >> Was there actually a good reason for having the device link to the
> > >> iommu rather than the other way around? How much would people hate it
> > >> if I just ignore the generic bin
1 - 100 of 716 matches
Mail list logo
