On Thursday 04 December 2014 12:26:58 Robin Murphy wrote:
+struct of_iommu_node {
+ struct hlist_node list;
+ struct device_node *np;
+ const struct iommu_ops *ops;
+};
+static HLIST_HEAD(of_iommu_list);
+static DEFINE_SPINLOCK(of_iommu_lock);
Looks good to me. For
On Tuesday 02 December 2014 14:16:57 Grant Likely wrote:
On Mon, Dec 1, 2014 at 11:54 PM, Rob Herring robherri...@gmail.com wrote:
On Mon, Dec 1, 2014 at 10:57 AM, Will Deacon will.dea...@arm.com wrote:
+static inline void of_iommu_set_ops(struct device_node *np,
+
On Monday 01 December 2014 16:58:09 Rob Herring wrote:
@@ -178,28 +180,21 @@ static void of_dma_configure(struct device *dev)
if (!dev-dma_mask)
dev-dma_mask = dev-coherent_dma_mask;
- /*
-* if dma-coherent property exist, call arch hook to setup
On Tuesday 02 December 2014 10:23:00 Marek Szyprowski wrote:
+static inline void of_iommu_set_ops(struct device_node *np,
+ const struct iommu_ops *ops)
+{
+ np-data = (struct iommu_ops *)ops;
+}
+
+static inline struct iommu_ops
-structure later which then describes a single
hardware iommu device.
so I second that and add my
Acked-by: Arnd Bergmann a...@arndb.de
Now, who should merge this series? I think someone should put all eight
patches into linux-next now, and if something goes wrong with the last
two, then we skip
On Friday 14 November 2014 18:56:29 Will Deacon wrote:
Here is the fourth iteration of the RFC I've previously posted here:
RFCv1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
RFCv2:
On Friday 14 November 2014 19:27:54 Will Deacon wrote:
At the moment, iommu_ops is a structure that can get used for any
number of iommus of the same type, but by putting per-device private
data into the same structure you have to duplicate it per instance.
I'm not sure I agree -- the
On Thursday 13 November 2014 10:32:25 Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This is the sixth installment in the Tegra IOMMU and memory controller
support series. This version addresses the final outstanding comments from
Olof about using proper Kconfig symbols to
On Tuesday 14 October 2014 16:07:38 Laurent Pinchart wrote:
On Tuesday 23 September 2014 09:44:25 Arnd Bergmann wrote:
On Tuesday 23 September 2014 09:02:39 Thierry Reding wrote:
I see two problems with using deferred probing here:
- we don't actually need to defer the probing
On Friday 10 October 2014 12:44:45 Mitchel Humpherys wrote:
Regarding the division, for the overwhelmingly common case where the
user of the API passes in a constant for sleep_us the compiler optimizes
out this calculation altogether and just sticks the final result in (I
verified this
On Tuesday 07 October 2014 18:47:59 Mitchel Humpherys wrote:
On Wed, Oct 01 2014 at 01:25:33 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 30 September 2014 18:28:12 Mitchel Humpherys wrote:
+ */
+#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us
On Tuesday 30 September 2014 18:28:12 Mitchel Humpherys wrote:
+ */
+#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ might_sleep_if(timeout_us); \
Does it make sense to call this with
On Tuesday 30 September 2014 18:28:13 Mitchel Humpherys wrote:
+ if (readl_poll_timeout_atomic(cb_base + ARM_SMMU_CB_ATSR, tmp,
+ !(tmp ATSR_ACTIVE), 50, 100)) {
This looks really bad.
You are doing up to 50 100us delays, each of which can be much longer,
On Monday 22 September 2014 11:36:15 Thierry Reding wrote:
On Fri, Sep 12, 2014 at 05:34:54PM +0100, Will Deacon wrote:
We need to ensure that the IOMMUs in the system have a chance to perform
some basic initialisation before we start adding masters to them.
This patch adds a call to
On Monday 22 September 2014 13:40:40 Thierry Reding wrote:
On Mon, Sep 22, 2014 at 01:08:27PM +0200, Arnd Bergmann wrote:
On Monday 22 September 2014 11:36:15 Thierry Reding wrote:
On Fri, Sep 12, 2014 at 05:34:54PM +0100, Will Deacon wrote:
We need to ensure that the IOMMUs
On Sunday 14 September 2014, Varun Sethi wrote:
master-id-bits property added to the IOMMU device node. This property can
be used by the IOMMU driver to match relevan bits in the master id expressed
by a DMA master.
This can be used to mask out certain bits that get added to the device
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
-- I have concerns that allocating one domain per master might be
too much, but it's hard to tell without an IOMMU driver ported over.
One domain per master is IMHO a sane default configuration. The only default
alternative
On Tuesday 02 September 2014 11:03:42 Will Deacon wrote:
On Mon, Sep 01, 2014 at 09:18:26PM +0100, Arnd Bergmann wrote:
On Monday 01 September 2014 17:40:00 Will Deacon wrote:
On Mon, Sep 01, 2014 at 03:46:18PM +0100, Arnd Bergmann wrote:
On Monday 01 September 2014 10:29:40 Thierry
On Tuesday 02 September 2014 12:42:13 Marek Szyprowski wrote:
Hi Arnd,
On 2014-09-02 10:56, Arnd Bergmann wrote:
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
-- I have concerns that allocating one domain per master might be
too much, but it's hard to tell without
On Tuesday 02 September 2014 14:24:18 Marek Szyprowski wrote:
For isolation purposes, it can only help to have more domains, but
I would guess that there is some space overhead in maintaining lots
of page tables.
I'm okay with both approaches (separate domain for each device vs. single
On Tuesday 02 September 2014 14:30:36 Marek Szyprowski wrote:
However we also need to figure out how to let drivers to make their own
configuration, like it is required by Exynos DRM subsystem, which consist
of several devices, each having its own IOMMU controller, but for
convenience
On Tuesday 02 September 2014 14:05:08 Will Deacon wrote:
On Tue, Sep 02, 2014 at 01:15:06PM +0100, Arnd Bergmann wrote:
Anyway, I'll try to hack something together shortly. I think the proposal
is:
- Make add_device_master_ids take a generic structure (struct iommu)
- Add
On Tuesday 02 September 2014 14:47:54 Varun Sethi wrote:
+void __init of_iommu_init(void)
+{
+ struct device_node *np;
+ const struct of_device_id *match, *matches = __iommu_of_table;
+
+ for_each_matching_node_and_match(np, matches, match) {
+ const int
On Tuesday 02 September 2014 18:56:26 Will Deacon wrote:
@@ -803,9 +804,11 @@ static int __init customize_machine(void)
if (machine_desc-init_machine)
machine_desc-init_machine();
#ifdef CONFIG_OF
- else
+ else {
+ of_iommu_init();
On Tuesday 02 September 2014 18:56:27 Will Deacon wrote:
This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
actually called outside of a few drivers) into arch_setup_dma_ops, so
that we can use IOMMUs for DMA transfers in a more generic fashion.
Since this significantly
On Tuesday 02 September 2014 18:56:24 Will Deacon wrote:
+struct iommu_dma_mapping *of_iommu_configure(struct device *dev)
+{
+ struct of_phandle_args iommu_spec;
+ struct iommu_dma_mapping *mapping;
+ struct bus_type *bus = dev-bus;
+ const struct iommu_ops *ops =
On Tuesday 02 September 2014 18:56:20 Will Deacon wrote:
The main difference since v1 is that I've introduced some generic
structures to represent IOMMUs and their mappings (struct iommu_data and
struct iommu_dma_mapping). This allows us to propagate the per-instance
data all the way down to
On Monday 01 September 2014 14:07:34 Marek Szyprowski wrote:
On 2014-09-01 13:56, Arnd Bergmann wrote:
On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote:
Who do you think needs to set this flag, and who needs to read it?
In the proposed solution Exynos IOMMU driver creates
On Friday 29 August 2014 16:54:25 Will Deacon wrote:
set_arch_dma_coherent_ops is called from of_dma_configure in order to
swizzle the architectural dma-mapping functions over to a cache-coherent
implementation. This is currently implemented only for ARM.
In anticipation of re-using this
On Monday 01 September 2014 09:52:19 Thierry Reding wrote:
I don't think this is the right direction. We've been preaching that
using initcall ordering is a bad thing and people should be using
deferred probe instead. Now we have a bunch of these OF tables that do
the exact opposite. Note that
On Monday 01 September 2014 10:13:22 Thierry Reding wrote:
On Fri, Aug 29, 2014 at 04:54:26PM +0100, Will Deacon wrote:
This patch adds a new function to the iommu_ops structure to allow a
device to be added to a specific IOMMU instance along with a set of
opaque IDs that are used
On Monday 01 September 2014 10:29:40 Thierry Reding wrote:
I think this could use a bit more formalization. As I said in another
reply earlier, there's very little standardization in the IOMMU API.
That certainly gives us a lot of flexibility but it also has the
downside that it's difficult
On Friday 29 August 2014 16:54:28 Will Deacon wrote:
static void of_dma_configure(struct platform_device *pdev)
{
- u64 dma_addr, paddr, size;
+ u64 dma_addr, paddr, size, mask;
int ret;
- bool coherent;
+ bool coherent, iommu;
unsigned long
On Monday 01 September 2014 17:34:00 Will Deacon wrote:
On Mon, Sep 01, 2014 at 03:39:16PM +0100, Arnd Bergmann wrote:
On Monday 01 September 2014 10:13:22 Thierry Reding wrote:
On Fri, Aug 29, 2014 at 04:54:26PM +0100, Will Deacon wrote:
diff --git a/include/linux/iommu.h b/include
On Monday 01 September 2014 17:40:00 Will Deacon wrote:
On Mon, Sep 01, 2014 at 03:46:18PM +0100, Arnd Bergmann wrote:
On Monday 01 September 2014 10:29:40 Thierry Reding wrote:
I think this could use a bit more formalization. As I said in another
reply earlier, there's very little
On Tuesday 19 August 2014, Will Deacon wrote:
+static int arm_smmu_parse_iommus_properties(struct arm_smmu_device *smmu,
+ int *num_masters)
+{
+ struct of_phandle_args iommuspec;
+ struct device_node *dn;
+
+
the device tree
bindings maintainers?
Will, perhaps you can get Pawel or Mark to look at this?
Arnd, I'm sure if we had your Acked-by that would go a long way too.
Sorry for missing this before my vacation.
Reviewed-by: Arnd Bergmann a...@arndb.de
Olof, please merge it into arm-soc so we can
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 bindings and use something that works for
me instead. I mean, it isn't exactly
On Friday 27 June 2014 12:46:14 Hiroshi DOyu wrote:
Thierry Reding thierry.red...@gmail.com writes:
From: Thierry Reding tred...@nvidia.com
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
On Thursday 26 June 2014 22:49:44 Thierry Reding wrote:
+static const struct tegra_mc_client tegra124_mc_clients[] = {
+ {
+ .id = 0x01,
+ .name = display0a,
+ .swgroup = TEGRA_SWGROUP_DC,
+ .smmu = {
+ .reg
On Wednesday 25 June 2014 10:17:02 Will Deacon wrote:
On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote:
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
We do describe the masked StreamID (SID) but we need
On Wednesday 25 June 2014 10:38:25 Will Deacon wrote:
On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote:
On Wednesday 25 June 2014 10:17:02 Will Deacon wrote:
On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote:
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote
On Wednesday 25 June 2014 10:57:36 Will Deacon wrote:
So far, I've been avoiding the hardcoding. However, you could potentially
build a system with a small number of SMRs (compared to the number of
StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic
configuration would
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master SMMUs and each master emits a variable number of
On Wednesday 18 June 2014 11:14:39 Will Deacon wrote:
On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
- Each master has a set of fixed StreamIDs
- StreamIDs can be remastered by adding a constant offset (this could also
be used to describe RequesterID - StreamID
On Friday 20 June 2014 18:50:51 Will Deacon wrote:
On Fri, Jun 20, 2014 at 04:53:08PM +0100, Arnd Bergmann wrote:
On Wednesday 18 June 2014 11:14:39 Will Deacon wrote:
On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
- Each master has a set of fixed StreamIDs
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.
I think it's good you raised the question.
The
current implementation hooks the IOMMU API into the
On Wednesday 04 June 2014 23:32:00 Thierry Reding wrote:
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
On Wednesday 04 June 2014 15:44:03 Thierry Reding wrote:
Well, the iommu specific binding could allow a variable #address-cells.
That way, you just need to know the number of stream IDs for that instance
of the iommu.
That sounds fairly complicated to me. I don't see what that buys us
On Friday 30 May 2014 12:22:32 Dave Martin wrote:
+
+Examples:
+=
+
+Single-master IOMMU:
+
+
+ iommu {
+ #address-cells = 0;
+ #size-cells = 0;
+ };
+
+ master {
+ iommus = /iommu;
+ };
+
On Friday 30 May 2014 08:16:05 Rob Herring wrote:
On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
thierry.red...@gmail.com wrote:
From: Thierry Reding tred...@nvidia.com
+IOMMU master node:
+==
+
+Devices that access memory through an IOMMU are called masters. A device
On Friday 30 May 2014 14:31:55 Rob Herring wrote:
On Fri, May 30, 2014 at 2:06 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 30 May 2014 08:16:05 Rob Herring wrote:
On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
thierry.red...@gmail.com wrote:
From: Thierry Reding tred...@nvidia.com
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, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
On Tuesday 20 May 2014 14:02:43 Thierry Reding 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, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote
On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
Right. As long as we always unmap the buffers from the IOMMU after they
have stopped being in use, it's very unlikely that even a broken device
driver causes a DMA
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:
For determining dma masks, it is the output address that it
important. Santosh's code can probably be taught
On Wednesday 21 May 2014 12:50:38 Thierry Reding wrote:
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
On Wednesday 21 May 2014 08:44:42 Grant Grundler wrote:
On Wed, May 21, 2014 at 2:32 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
Right. As long as we always unmap the buffers
On Wednesday 21 May 2014 18:09:54 Dave Martin wrote:
On Wed, May 21, 2014 at 11:00:38AM +0200, 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:
Similarily, should the IOMMU not be treated
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, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote:
On Friday 16 May 2014 14:23:18 Thierry Reding wrote
On Monday 19 May 2014 22:32:33 Thierry Reding wrote:
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
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, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote:
On Monday 19 May 2014 14:53:37 Thierry Reding wrote
On Tuesday 20 May 2014 14:07:09 Dave Martin wrote:
On Tue, May 20, 2014 at 12:08:44PM +0200, Arnd Bergmann wrote:
On Monday 19 May 2014 22:32:33 Thierry Reding wrote:
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
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 Tue, May 20, 2014 at 01:15:48PM +0200, Arnd Bergmann wrote:
Typical values for the above include:
- #address-cells
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, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote
On Tuesday 20 May 2014 17:39:12 Dave Martin wrote:
On Tue, May 20, 2014 at 04:26:59PM +0100, Will Deacon wrote:
On Tue, May 20, 2014 at 02:23:47PM +0100, Arnd Bergmann wrote:
Bit# 3322 1100
10987654 32109876 54321098 76543210
phys.hi cell
On Friday 16 May 2014 14:23:18 Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
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
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 Reding tred...@nvidia.com
This commit introduces a generic device tree binding for IOMMU devices
shaik.am...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Monday 12 May 2014 11:44:45 Shaik Ameer Basha wrote:
This is the subset of previous v12 series and includes only the fixes and
enhancements, leaving out the private DT bindings as discussed in the below
thread.
-- http://www.gossamer-threads.com/lists/linux/kernel/1918178
This patch
On Tuesday 06 May 2014 19:59:05 Joerg Roedel wrote:
On Wed, Apr 30, 2014 at 04:27:10PM +0530, Shaik Ameer Basha wrote:
This series is going on for quite a long time and most of the patches here
doesn't depend on dt bindings. As Exynos IOMMU h/w is introducing new
versions
very
On Thursday 01 May 2014 23:02:14 Cho KyongHo wrote:
- device can only do DMA to a limited address range
- DMA is noncoherent and needs manual cache management
- DMA address is at an offset from physical address
- some devices have an IOMMU
- some IOMMUs are shared between devices
-
On Thursday 01 May 2014 15:36:54 Dave Martin wrote:
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
I'm not sure whether there is actually a SoC today that is MSI-capable
and contains an IOMMU, but all the components
On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote:
On 01/05/14 15:36, Dave Martin wrote:
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
I don't understand
On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
On Mon, Apr 28, 2014 at 09:55:00PM +0200, Arnd Bergmann wrote:
On Monday 28 April 2014 20:30:56 Will Deacon wrote:
device@4 {
compatible = some,ethernet;
iommus = /iommu@1
On Tuesday 29 April 2014 13:07:54 Grant Grundler wrote:
On Tue, Apr 29, 2014 at 11:16 AM, Dave Martin dave.mar...@arm.com wrote:
...
An IOMMU is really a specialised bridge
Is a GART a bridge?
IOMMUs can provide three basic functions:
1) remap address space to reach phys mem ranges that
On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote:
The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is
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:
+- mmu-masters: A phandle to device nodes representing the master for
which
+ the System MMU
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 possibly with a iommu-names property to go along with that. The idea
being that a device can be a master
On Sunday 27 April 2014 13:07:47 Shaik Ameer Basha wrote:
@@ -542,14 +592,41 @@ static int __init exynos_sysmmu_probe(struct
platform_device *pdev)
}
}
+ /* Relation between master and System MMU is 1:1. */
+ node = of_parse_phandle(dev-of_node, mmu-masters,
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
+ after the phandle will be ignored because a System MMU never
+
On Thursday 27 February 2014, Ritesh Harjani wrote:
Hi Everyone,
I was going through some iommu code in arch/arm and of some other
archs code. I have some doubts on this for refactoring and may need
some suggestions from you guys.
1. So, looking at other arch code, looks like they have
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
might be cleaner. Considering that
On Wednesday 18 April 2012, Hiroshi Doyu wrote:
If we can consider IOMMU as one of the implementation of DMA(Direct
Memory Access), the prefix dma-(window) may make sense here. Then,
we don't have to introduce a new concept IO virtual address(iova) in
addition to the existing bus address(?)
On Thursday 12 April 2012, Marek Szyprowski wrote:
+
+/*
+ * s5p_sysmmu_late_init
+ * Create DMA-mapping IOMMU context for specified devices. This function
must
+ * be called later, once SYSMMU driver gets registered and probed.
+ */
+static int __init
On Thursday 12 April 2012, Marek Szyprowski wrote:
Scatter lists were initially designed for the disk based block io operations,
hence the presence of the in-page offsets and lengths for each chunk. For
multimedia use cases providing an array of struct pages and asking
dma-mapping
to map
On Wednesday 11 April 2012, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra
On Tuesday 10 April 2012, Marek Szyprowski wrote:
Replace all calls to printk with pr_* functions family.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
On Tuesday 10 April 2012, Marek Szyprowski wrote:
This patch modifies dma-mapping implementation on ARM architecture to
use common dma_map_ops structure and asm-generic/dma-mapping-common.h
helpers.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park
On Tuesday 10 April 2012, Marek Szyprowski wrote:
+/**
+ * arm_iommu_create_mapping
+ * @bus: pointer to the bus holding the client device (for IOMMU calls)
+ * @base: start address of the valid IO address space
+ * @size: size of the valid IO address space
+ * @order: accuracy of the IO
.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo
...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tuesday 10 April 2012, Marek Szyprowski wrote:
This patch removes dma bounce hooks from the common dma mapping
implementation on ARM architecture and creates a separate set of
dma_map_ops for dma bounce devices.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin
201 - 293 of 293 matches
Mail list logo
