On 09/18/2018 12:16 PM, Stephen Warren wrote:
On 09/18/2018 04:59 AM, Robin Murphy wrote:
Hi Stephen,
On 17/09/18 22:36, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware
will need to explicitly manage its IOVA space
On 09/18/2018 04:59 AM, Robin Murphy wrote:
Hi Stephen,
On 17/09/18 22:36, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware
will need to explicitly manage its IOVA space more than current APIs
allow. I'd li
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware will
need to explicitly manage its IOVA space more than current APIs allow.
I'd like to discuss how to make that possible.
First some background on our hardware:
NVIDIA's Xavier SoC contains a
On 06/26/2014 02:49 PM, Thierry Reding wrote:
> 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.
On 06/26/2014 02:49 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, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed
On 06/27/2014 05:15 AM, Thierry Reding wrote:
> 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 06/27/2014 05:08 AM, Thierry Reding wrote:
> 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 a
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, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed
On 04/29/2014 03:00 PM, Arnd Bergmann wrote:
...
> Yes. It's very complicated unfortunately, because we have to be
> able to deal with arbitrary combinations of a lot of oddball cases
> that can show up in random SoCs:
...
> - a device may have DMA access to a bus that is invisible to the CPU
The
On 04/28/2014 05:18 AM, Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
...
>> A lot of drivers probably only support one
>> master, so they can just set #iommu-cells=<0>, others might require
>> IDs that do not fit into one cell.
>
> You mean "#iommu-cells =
On 12/20/2013 05:35 AM, Thierry Reding wrote:
> 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 b
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
>> supports. This unique ID can be used to calculate MC_SMMU_> name>_AS
On 12/05/2013 05:25 AM, Hiroshi Doyu wrote:
> T124 has some new register bits in {TLB,PTC}_CONFIG:
>
> - TLB_RR_ARB and PTC_REQ_LIMIT
> - TLB_ACTIVE_LINES 0x20 instead of 0x10
>
> They are defined as platform data now.
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> @@
On 12/05/2013 05:25 AM, Hiroshi Doyu wrote:
> SMMU used to depend on AHB bus. AHB driver needs to be populated and
> AHB_XBAR_CTRL_SMMU_INIT_DONE bit needs to be set earliear than SMMU
> being populated. Later Tegra SoC (>= T124) doesn't need AHB to enable
> SMMU on AHB_XBAR_CTRL for AHB_XBAR_CTRL_
On 12/05/2013 05:25 AM, Hiroshi Doyu wrote:
> The later Tegra SoC(>= T124) has more registers for
> MC_SMMU_TRANSLATION_ENABLE_*. Now those info is provided as platfrom
> data. If those varies a lot on SoCs in the future, we can consider
> putting them into DT later.
This shouldn't be called "plat
On 12/12/2013 12:57 AM, Hiroshi Doyu wrote:
> The device, which belongs to the same ASID, can try to enable the same
> ASID as the other swgroup devices. This should be allowed but just
> skip the actual register write. If the write value is different, it
> will return -EINVAL.
I guess this simpli
On 12/12/2013 12:57 AM, Hiroshi Doyu wrote:
> This provides the info about which swgroups a device belongs to. This
> info is passed from DT. This is necessary for the unified SMMU driver
> among Tegra SoCs since each has different H/W accelerators.
> diff --git a/Documentation/devicetree/bindings
On 12/12/2013 12:57 AM, Hiroshi Doyu wrote:
> ASID register offset is caclulated by SWGROUP ID so that we can get
> rid of old SoC specific MACROs. This ID conversion is needed for the
> unified SMMU driver over Tegra SoCs. We use dt-bindings MACRO instead
> of SoC dependent MACROs. The formula is:
On 12/12/2013 12:57 AM, Hiroshi Doyu wrote:
> platform_devices are registered as IOMMU'able dynamically via
> add_device() and remove_device().
That says {add,remove}_device() ...
> Tegra SMMU can have multiple address spaces(AS). IOMMU'able devices
> can belong to one of them. Multiple IOVA maps
On 12/12/2013 12:57 AM, Hiroshi Doyu wrote:
> ops->{bound,unbind}_driver() functions are called at
> BUS_NOTIFY_{BOUND,UNBIND}_DRIVER respectively.
Some explanation re: why the existing {add,remove}_device hooks aren't
enough would be useful. I didn't really get that from the current commit
descri
On 12/12/2013 12:57 AM, 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 can, we'll
> defer
On 12/12/2013 12:57 AM, Hiroshi Doyu wrote:
> This enables to find an populated IOMMU device via a device node. This
> can be used to see if an dependee IOMMU is populated or not to keep
> correct device population order. Client devices need to wait an IOMMU
> to be populated.
>
> Suggested by Thi
s good to me.
Reviewed-by: Stephen Warren
But if you want to rewrite it to use a struct to store state between
_init()/_iter(), that'd probably be fine too.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 12/12/2013 07:14 PM, 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.
>>>
>>> With CONFIG_OF_IOMMU, "i
On 12/14/2013 08:51 AM, Hiroshi Doyu wrote:
> Hiroshi Doyu wrote @ Thu, 12 Dec 2013 14:14:04 +0200 (EET):
>
From 8f7c0404aa68f0e8dbe0babc240590f6528ecc1f Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu
Date: Fri, 15 Nov 2013 10:52:53 +0200
Subject: [PATCH] of: introduce of_proper
On 12/02/2013 04:02 AM, Hiroshi Doyu wrote:
...
> Iterating over a property containing a list of phandles with arguments
> is a common operation for device drivers. This patch adds a new
> of_property_for_each_phandle_with_args() macro to make the iteration
> simpler.
> diff --git a/drivers/of/bas
On 11/29/2013 04:46 AM, Hiroshi Doyu wrote:
...
> Iterating over a property containing a list of phandles with arguments
> is a common operation for device drivers. This patch adds a new
> of_property_for_each_phandle_with_args() macro to make the iteration
> simpler.
>
> Introduced a new struct "
On 11/22/2013 12:41 AM, Grant Likely wrote:
> On Thu, 21 Nov 2013 12:04:18 -0700, Stephen Warren
> wrote:
>> On 11/21/2013 06:15 AM, Grant Likely wrote:
>>> On Tue, 19 Nov 2013 11:33:06 +0200, Hiroshi Doyu wrote:
>>>> IOMMU devices on the bus need to be poplula
On 11/21/2013 06:15 AM, Grant Likely wrote:
> On Tue, 19 Nov 2013 11:33:06 +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
On 11/21/2013 10:20 AM, Hiroshi Doyu wrote:
> Grant Likely wrote @ Thu, 21 Nov 2013 16:56:49
> +0100:
>
>> On Thu, 21 Nov 2013 15:12:18 +0200, Hiroshi Doyu wrote:
>>> On Thu, 21 Nov 2013 13:43:28 +0100
>>> Grant Likely wrote:
>>>
On Tue, 19 Nov 2013 11:33:05 +0200, Hiroshi Doyu wrote:
>>
On 11/21/2013 10:17 AM, Hiroshi Doyu wrote:
> Iterating over a property containing a list of phandles with arguments
> is a common operation for device drivers. This patch adds a new
> of_property_for_each_phandle_with_args() macro to make the iteration
> simpler.
>
> Signed-off-by: Hiroshi Doyu
On 11/21/2013 04:00 AM, Will Deacon wrote:
> On Wed, Nov 20, 2013 at 08:02:10PM +, Rob Herring wrote:
>> On Wed, Nov 20, 2013 at 12:39 AM, Hiroshi Doyu wrote:
>>> smmu_a: iommu@ {
>>> #iommu-cells = <2>;
>>>
>>> };
>>>
>>> smmu_b: iommu@ {
>>>
On 11/20/2013 01:02 PM, Rob Herring wrote:
> On Wed, Nov 20, 2013 at 12:39 AM, Hiroshi Doyu wrote:
>> Hi Rob,
>>
>> Rob Herring wrote @ Tue, 19 Nov 2013 21:45:02 +0100:
>>
>>> On 11/19/2013 11:35 AM, Will Deacon wrote:
On Tue, Nov 19, 2013 at 09:40:54AM +, Hiroshi Doyu wrote:
> Grant
On 11/20/2013 07:03 AM, Hiroshi Doyu wrote:
> Thierry Reding wrote @ Wed, 20 Nov 2013 14:14:48
> +0100:
(Yes, what Thierry said)
>
>>> Does the above mean the following?
>>>
>>> int of_iommu_attach(struct device *dev)
>>> {
>>> int i;
>>> struct of_phandle_args args;
>>>
>>> of
On 11/19/2013 02:33 AM, Hiroshi Doyu wrote:
> This provides the info about which swgroups a device belongs to. This
> info is passed from DT. This is necessary for the unified SMMU driver
> among Tegra SoCs since each has different H/W accelerators.
> diff --git a/Documentation/devicetree/bindings
On 11/19/2013 02:33 AM, Hiroshi Doyu wrote:
> platform_devices are registered as IOMMU'able dynamically via
> add_device() and remove_device().
>
> Tegra SMMU can have multiple address spaces(AS). IOMMU'able devices
> can belong to one of them. Multiple IOVA maps are created at boot-up,
> which ca
On 11/19/2013 02:33 AM, 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
> supports. This unique ID can be used to calculate MC_SMMU_ name>_ASID_0 register offset and MC__HOTRESET_*_0
> regi
On 11/19/2013 05:03 AM, Hiroshi Doyu wrote:
> Hi Thierry,
>
> Thierry Reding wrote @ Tue, 19 Nov 2013 11:25:07
> +0100:
>
>> From earlier discussions I thought the goal was to actually defer this
>> until all nodes referred to by the iommus property were actually
>> registered. The above only c
On 11/15/2013 03:29 AM, Hiroshi Doyu wrote:
> On Tue, 12 Nov 2013 23:48:22 +0100
> Stephen Warren wrote:
>
>> On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
>>> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
>>> binding. "swgroup"
On 11/13/2013 11:41 PM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 13 Nov 2013 18:58:23
> +0100:
>
>>> smmu: iommu@xx {
>>>#iommu-cells = <3>;
>>>^^
>>>};
>>>
>>>host
On 11/13/2013 12:45 AM, Hiroshi Doyu wrote:
> On Wed, 13 Nov 2013 01:17:22 +0100
> Stephen Warren wrote:
>
>>> + mmu-masters = <&host1x TEGRA_SWGROUP_HC>,
>>> + <&mpe TEGRA_SWGROUP_MPE>,
>
On 11/13/2013 10:31 AM, Will Deacon wrote:
> On Wed, Nov 13, 2013 at 04:06:10PM +, Hiroshi Doyu wrote:
>> Will Deacon wrote @ Wed, 13 Nov 2013 15:38:04 +0100:
>>
>>> On Tue, Nov 12, 2013 at 11:34:20PM +, Stephen Warren wrote:
>>>> SMMU:
>>>
On 11/13/2013 12:23 AM, Hiroshi Doyu wrote:
> On Wed, 13 Nov 2013 00:34:20 +0100
> Stephen Warren wrote:
>
>> On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
>>> An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
>>> are d
On 11/13/2013 07:38 AM, Will Deacon wrote:
> On Tue, Nov 12, 2013 at 11:34:20PM +0000, Stephen Warren wrote:
>> On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
>>> An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
>>> are done la
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> The device, which belongs to the same ASID, can try to enable the same
> ASID as the other swgroup devices. This should be allowed but just
> skip the actual register write. If the write value is different, it
> will return -EINVAL.
That's pretty confu
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> Follow arm,smmu's "mmu-masters" binding.
> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> +- mmu-masters : A list of phandles to device nodes repres
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> ASID register offset is caclulated by SWGROUP ID so that we can get
> rid of old SoC specific MACROs. This ID conversion is needed for the
> unified SMMU driver over Tegra SoCs. We use dt-bindings MACRO instead
> of SoC dependent MACROs. The formula is:
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> platform_devices are registered as IOMMU'able dynamically via
> add_device() and remove_device().
>
> Tegra SMMU can have multiple address spaces(AS). IOMMU'able devices
> can belong to one of them. Multiple IOVA maps are created at boot-up,
> which ca
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> platform_devices are registered as IOMMU'able dynamically via
> add_device() and remove_device().
>
> Tegra SMMU can have multiple address spaces(AS). IOMMU'able devices
> can belong to one of them. Multiple IOVA maps are created at boot-up,
> which ca
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
> are done later.
>
> With CONFIG_OF_IOMMU, "#stream-id-cells" DT binding would be used to
> identify whether a device is IOMMU'able or not. If a device is
> IOMMU'able, we'll defer
On 11/11/2013 04:39 AM, Will Deacon wrote:
> On Mon, Nov 11, 2013 at 08:31:53AM +, Hiroshi Doyu wrote:
>> An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
>> are done later.
>>
>> With CONFIG_OF_IOMMU, "#stream-id-cells" DT binding would be used to
>> identify whether a de
On 11/11/2013 01:31 AM, 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
> supports. This unique ID can be used to calculate MC_SMMU_ name>_ASID_0 register offset and MC__HOTRESET_*_0
> regi
On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> Hi,
>
> This series provides:
>
> (1) Unified SMMU driver among Tegra SoCs
> (2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
> (3) Tegra IOMMU'able devices, most of platform devices are IOMMU'able.
>
> There's been some discussion[1] about
On 11/01/2013 03:59 AM, Hiroshi Doyu wrote:
...
> One idea is that, rather than inserting a hook(function) per
> subsystems in driver core, if we invent a new /special section/ which
> collects all hooks in sequence like initcalls, the subsystem just
> would declare a hook function for that special
On 11/01/2013 12:49 AM, 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. expan
On 11/01/2013 10:34 AM, Will Deacon wrote:
> On Fri, Nov 01, 2013 at 04:08:52PM +0000, Stephen Warren wrote:
>> On 10/31/2013 01:39 PM, Will Deacon wrote:
>>> On Thu, Oct 31, 2013 at 07:25:25PM +0000, Stephen Warren wrote:
>>>> On 10/31/2013 01:16 PM, Stephen W
On 11/01/2013 10:34 AM, Will Deacon wrote:
> On Fri, Nov 01, 2013 at 04:08:52PM +0000, Stephen Warren wrote:
>> On 10/31/2013 01:39 PM, Will Deacon wrote:
>>> On Thu, Oct 31, 2013 at 07:25:25PM +0000, Stephen Warren wrote:
>>>> On 10/31/2013 01:16 PM, Stephen W
On 10/31/2013 02:16 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:15:00
> +0100:
>
>> On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
>>> SMMU expects ARM_DMA_USE_IOMMU to be enabled to use DMA mapping API by
>>> default.
>>
>>
On 10/31/2013 02:17 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:33:32
> +0100:
...
> Right.
> "memory client ID" is used to find out MC_SMMU__ASID_0
> register. This register is used to associate to address
> space(AS). == H/W. can be
On 10/31/2013 01:39 PM, Will Deacon wrote:
> On Thu, Oct 31, 2013 at 07:25:25PM +0000, Stephen Warren wrote:
>> On 10/31/2013 01:16 PM, Stephen Warren wrote:
>>> Hmm. That's interesting. I see that the ARM SMMU has a list of the
>>> clients it affects, whereas th
On 11/01/2013 02:06 AM, Hiroshi Doyu wrote:
> On Thu, 31 Oct 2013 18:46:06 +0100
> Mark Rutland wrote:
>
>> On Thu, Oct 31, 2013 at 08:19:42AM +, Hiroshi Doyu wrote:
>>> Stephen Warren wrote @ Wed, 30 Oct 2013 23:48:38
>>> +0100:
>>>
>&
On 10/31/2013 01:16 PM, Stephen Warren wrote:
> On 10/31/2013 11:40 AM, Mark Rutland wrote:
>> On Thu, Oct 31, 2013 at 08:18:08AM +, Hiroshi Doyu wrote:
>>> Stephen Warren wrote @ Wed, 30 Oct 2013 23:44:04
>>> +0100:
>>>
>>>>> + host1x {
On 10/31/2013 11:46 AM, Mark Rutland wrote:
> On Thu, Oct 31, 2013 at 08:19:42AM +, Hiroshi Doyu wrote:
>> Stephen Warren wrote @ Wed, 30 Oct 2013 23:48:38
>> +0100:
>>
>>> On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
>>>> Create a header file to def
On 10/31/2013 02:18 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:44:04
> +0100:
>
>>> + host1x {
>>> + compatible = "nvidia,tegra30-host1x", "simple-bus";
>>> +
On 10/31/2013 11:40 AM, Mark Rutland wrote:
> On Thu, Oct 31, 2013 at 08:18:08AM +, Hiroshi Doyu wrote:
>> Stephen Warren wrote @ Wed, 30 Oct 2013 23:44:04
>> +0100:
>>
>>>> + host1x {
>>>> + compatible = "nvidia,tegra30-host1x&quo
On 10/31/2013 12:02 PM, Will Deacon wrote:
> On Thu, Oct 31, 2013 at 05:40:29PM +, Mark Rutland wrote:
>> For the ARM SMMU binding, each device has a #stream-id-cells property
>> describing how many IDs it has, and then the SMMU node has a phandle+args
>> linkage to each of the devices attached
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_phandle is ready. Exactly the sam
On 10/31/2013 02:12 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 22:58:58
> +0100:
>
>> 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 reso
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
>> tries to solve that problem within the core. Essentially what it does is
>> add a new function that gets called
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> binding. "swgroups" is a group of H/W clients which Tegra SoCs
> support. This unique ID can be used to calculate MC_SMMU_ name>_ASID_0 register offset and MC__HOTRESET_*_0
> regis
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> This provides the info about which swgroups a device belongs to. This
> info is passed from DT. This is necessary for the unified SMMU driver
> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> b/Documentation/devicetree/b
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Make PCIe work as it is. IOMMU support can be implemented later. We
> need the same kind of registration framework for PCIe as platform_bus
> does currently.
Some more explanation is needed here re: exactly why PCIe doesn't work,
and how this patch mak
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> This is a bitmap that indicates which HardWare Accelerators(HWA) are
> supported on Tegra30 SoC.
Feel free to squash patches 11 and 12 into one. They're doing the same
logical thing.
Also, can you please separate the series into separate series for th
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> This provides the info about which H/W Accelerators are supported on
> Tegra SoC. This info is passed from DT. This is necessary to have the
> unified SMMU driver among Tegra SoCs. Instead of using platform data,
> DT passes "nvidia,swgroups" now. DT is
On 10/24/2013 02:58 AM, Grant Likely wrote:
> On Fri, 18 Oct 2013 13:26:51 +0300, Hiroshi Doyu wrote:
>> This provides the info about which H/W Accelerators are supported on
>> Tegra SoC. This info is passed from DT. This is necessary to have the
>> unified SMMU driver among Tegra SoCs. Instead of
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> v3:
> Updated based on Stephen Warren's feedback
Updated how? The last series was posted a long time ago, and I have no
idea what feedback I gave...
___
iommu mailing list
iommu@lists.linux-foundation.org
ht
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Create default IOVA maps at boot-up which can be attached to devices.
What's the content of those default maps? I assume no RAM is mapped,
judging by the code. If so, perhaps s/default/default empty/ in the
patch description?
> @@ -1236,7 +1261,7 @@ s
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> SMMU expects ARM_DMA_USE_IOMMU to be enabled to use DMA mapping API by
> default.
Is the select required for the driver to be useful at all (in which case
it's fine), or simply for things to work "better" (define "better"), in
which case perhaps leavin
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Fix IOMMU register address.
That's quite unfortunate. Why do we always have trouble getting the
IOMMU register address correct in DT; I think we had a similar issue
with the Tegra30 DT.
Anyway, I guess I should take this for 3.13 and stable since it's
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Populate AHB/IOMMU earlier than others. IOMMU depends on AHB. IOMMU
> needs to be instanciated earlier than others so that IOMMU can
> register other platform devices as IOMMU'able. Once IOMMU is
> populated, IOMMU/AHB nodes are detached to prevent anot
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 the core the issue is the same. A device requires the services
> of an IOMMU so that it can be put into th
On 10/25/2013 07:20 AM, 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 various
>>> IOMMU implementations that we won't be able to ha
On 10/30/2013 10:34 AM, Hiroshi Doyu wrote:
> Hiroshi Doyu wrote @ Fri, 18 Oct 2013 12:26:41 +0200:
>
>> Hi,
>>
>> This series provides:
>>
>> (1) Unified SMMU driver among Tegra SoCs
>> (2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
>> (3) Tegra IOMMU'able devices, most of platform de
From: Stephen Warren
I believe that Joerg Roedel is at least the path through which
drivers/iommu changes should be merged. Add a MAINTAINERS entry to
make this clear, so that he's Cd'd on all relevant patches. This is
relevant for non-AMD/Intel IOMMUs, where get_maintainers.pl doesn&#
From: Stephen Warren
Tegra only supports, and always enables, device tree. Remove all ifdefs
for DT support from the driver.
Signed-off-by: Stephen Warren
---
drivers/iommu/tegra-smmu.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b
From: Stephen Warren
Tegra only supports, and always enables, device tree. Remove all ifdefs
for DT support from the driver.
Signed-off-by: Stephen Warren
---
drivers/iommu/tegra-gart.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/iommu/tegra-gart.c b
On 02/06/2013 10:38 AM, Hiroshi Doyu wrote:
> This fixes kernel crash because of BUG() in register address
> validation.
>
> Signed-off-by: Hiroshi Doyu
Tested-by: Stephen Warren
(on Tegra30 Cardhu, with this patch applied on top of next-20130206 plus
some other build a
On 02/04/2013 01:31 PM, Hiroshi Doyu wrote:
> Hi Joerg,
>
> Joerg Roedel wrote @ Mon, 4 Feb 2013 20:53:32 +0100:
>
>>> static inline u32 smmu_read(struct smmu_device *smmu, size_t offs)
>>> {
>>> - BUG_ON(offs < 0x10);
>>> - if (offs < 0x3c)
>>> - return readl(smmu->regs[0] + off
On 01/29/2013 01:30 AM, Hiroshi Doyu wrote:
> Use functional name for DT entry instead of h/w name.
Applied patches 1, 2 to Tegra's for-3.9/dt branch, and squashed patch 3
into Tegra's for-3.9/soc-t114 branch.
___
iommu mailing list
iommu@lists.linux-fou
SMMU register accesses are not so frequent,
> this would be acceptable. This patch is necessary to unify
> "tegra-smmu.ko" over some Tegra SoC generations.
Reviewed-by: Stephen Warren
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 01/29/2013 10:40 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Tue, 29 Jan 2013 18:03:51
> +0100:
>
>>> + /* Same as "mc" 1st regiter block start address */
>>> + smmu->regbase = (void __iomem *)((u32)smmu->regs[0] & ~PAGE_MASK);
>>
On 01/29/2013 01:34 AM, Hiroshi Doyu wrote:
> Presently SMMU registers are located in discontiguous 3 blocks. They
> are interleaved by MC registers. Ideally SMMU register blocks should
> be in an independent one block, but it is too late to change this H/W
> design. In the future Tegra chips over
On 01/15/2013 01:17 AM, Hiroshi Doyu wrote:
> Add AHB entry.
I've applied patches 5/6 and 6/6 to Tegra's for-3.9/soc-t114 branch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 01/21/2013 12:36 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Fri, 18 Jan 2013 17:44:13
> +0100:
>
>>> Even the checks if "offs" is in some of register blocks could be
>>> ifdef'ed out with DEBUG. "smmu->regbase" can be calculated in
On 01/18/2013 02:05 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 16 Jan 2013 22:12:24
> +0100:
>
>> On 01/15/2013 01:17 AM, Hiroshi Doyu wrote:
>>> There are 3 SMMU MMIO register blocks. They may get bigger as new
>>> Tegra SoC comes. This patch en
On 01/15/2013 06:22 AM, Hiroshi Doyu wrote:
> TEGRA_IOMMU_SMMU depends on ARCH_TEGRA_114_SOC too.
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> config TEGRA_IOMMU_SMMU
> bool "Tegra SMMU IOMMU Support"
> - depends on ARCH_TEGRA_3x_SOC && TEGRA_AHB
> + depends on (A
On 01/15/2013 01:17 AM, Hiroshi Doyu wrote:
> Add SMMU entry.
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> + smmu {
> + compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu";
> + reg = <0x7000f010 0x02c
> +
On 01/15/2013 01:17 AM, Hiroshi Doyu wrote:
> There are 3 SMMU MMIO register blocks. They may get bigger as new
> Tegra SoC comes. This patch enables to support variable size of those
> register blocks.
Why would the register blocks move around? In the HW, there's one single
chunk of memory contai
On 01/15/2013 01:17 AM, Hiroshi Doyu wrote:
> Pass available H/W client component(software client group) info from
> DT in bitmap. This info is specific to a certain generation of Tegra
> SoC. With this, Tegra SMMU driver could be identical among Tegra
> generations. This also removes the old way o
On 12/07/2012 03:12 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 5 Dec 2012 22:11:40 +0100:
>
>> On 12/04/2012 11:37 AM, Hiroshi Doyu wrote:
>>> Most of platform devices are IOMMU'able in Tegra30 SoC. Registering
>>> all IOMMU'able device
1 - 100 of 159 matches
Mail list logo
