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 Likely wrote @ Fri, 15 Nov 2013 08:06:27
> >> +0100:
> >>> On Mon, 11 Nov 2013 10:47:23 +0100, Hiroshi Doyu wr
(2013/11/19 8:30), Sumner, William wrote:
> Thank you for testing this RFC patch. It is great to have confirmation that
> the code works in a different test environment.
>
> You asked: "What is the status of this patch?"
> I have made a few changes since the RFC version of this patch:
>
> 1. Co
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 11:25:07
> > +0100:
> >
> >> From earlier discussions I thought the goal was to actually defer this
> >> until all nodes referr
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/19/2013 11:35 AM, Will Deacon wrote:
> On Tue, Nov 19, 2013 at 09:40:54AM +, Hiroshi Doyu wrote:
>> Grant Likely wrote @ Fri, 15 Nov 2013 08:06:27
>> +0100:
>>> On Mon, 11 Nov 2013 10:47:23 +0100, Hiroshi Doyu wrote:
1, When a device is populated, it checks if that device is IOMMU
On Tue, Nov 19, 2013 at 09:40:54AM +, Hiroshi Doyu wrote:
> Grant Likely wrote @ Fri, 15 Nov 2013 08:06:27
> +0100:
> > On Mon, 11 Nov 2013 10:47:23 +0100, Hiroshi Doyu wrote:
> > > 1, When a device is populated, it checks if that device is IOMMU'able
> > >or not. This is identified by "
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 checks that the phandles can be resolved to
> valid struct
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
Hi Grant,
Grant Likely wrote @ Fri, 15 Nov 2013 08:06:27
+0100:
> On Mon, 11 Nov 2013 10:47:23 +0100, Hiroshi Doyu wrote:
> > Missed some MLs. Resending
> >
> > Grant Likely wrote @ Fri, 8 Nov 2013 14:20:46
> > +0100:
> >
> > > Early Init, Deferred Probe and Init Order
> > ...
> > > Th
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__ASID_0 register offset and MC__HOTRESET_*_0
register bit. This will allow the same header to be used by bo
Use the correct term for SWGROUP related variables and macros.
The term "swgroup" is the collection of "memory client". A "memory
client" usually represents a HardWare Accelerator(HWA) like
GPU. Sometimes a strut device can belong to multiple "swgroup" so that
"swgroup's'" is used here. This "swgr
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:
MC_SMMU__ASID_0 = MC_SMMU_AFI_ASID_0 + ID * 4;
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 to populate that device till an iommu device is populate
"iommus" binding implies that a device can be attached to IOMMU
devices. An iommu device needs to set #iommus-cells in it. "iommus"
can have multiple iommu device phandles as below if needed.
iommus = <&smmu arg1 arg2>,
<&gart arg1 arg2>;
Not yet ready for merge. Need to add iommus f
724.html
v2:
Updated based on Thierry Reding's and Stephen Warren's feedback
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181888.html
v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/180267.html
Available in the git repository at:
git://g.
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.
Signed-off-by: Hiroshi Doyu
---
v5:
"iommu=" in a device DT is used instead of "mmu-masters" in a
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 can be attached to devices later. We reserve 2 of them for
The following pattern of code is tempting:
for (i = 0; !of_parse_phandle_with_args(np, list, cells, i, args); i++)
Signed-off-by: Hiroshi Doyu
---
v5:
New patch for v5.
---
include/linux/of.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index
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.
Signed-off-by: Hiroshi Doyu
---
v4:
This was the part of v3, which isn
22 matches
Mail list logo
