On 24/11/16 13:29, Russell King - ARM Linux wrote:
> On Thu, Nov 24, 2016 at 01:18:39PM +0000, Robin Murphy wrote:
>> Hi Liviu, Russell,
>>
>> I'd been meaning to try digging into this if it hadn't gone away since I
>> first noticed it, but I don't really
On 24/11/16 13:49, Robin Murphy wrote:
> On 24/11/16 13:29, Russell King - ARM Linux wrote:
>> On Thu, Nov 24, 2016 at 01:18:39PM +0000, Robin Murphy wrote:
>>> Hi Liviu, Russell,
>>>
>>> I'd been meaning to try digging into this if it hadn't gone
context. The rest is just proactively
blatting address arguments with "arbitrary definitely-invalid value",
which is more paranoia than anything else (and arguably unnecessary).
It's not the biggest deal, though, so either way:
Reviewed-by: Robin Murphy
> Signed-off-by: Christoph
welcome.
I'm happy to be a reviewer, since I've been working in this area for
some time, particularly with the dma-iommu code and arm64 DMA ops.
Robin.
> Stephen, can you add this to linux-next?
>
> ---
> From 335979c41912e6c101a20b719862b2d837370df1 Mon Sep 17 00:00:00 2001
&
it's down to the callers or the heap
implementations to decide and enforce that granularity is another
question, but provided allocations are at least naturally aligned to
whatever the granularity is (which is a reasonable assumption to bake
in) then it's all good.
Robin.
>
> -Brian
gt; that arm64 which is the only current user of dma-iommu.
It would be fine to just use 0, since dma-iommu already makes sure that
that will never be allocated for a valid DMA address.
Otherwise, looks good!
Robin.
> Signed-off-by: Christoph Hellwig
> ---
> drivers/iommu/dma-iommu.c
On 08/06/17 14:25, Christoph Hellwig wrote:
> The dma alloc interface returns an error by return NULL, and the
> mapping interfaces rely on the mapping_error method, which the dummy
> ops already implement correctly.
>
> Thus remove the DMA_ERROR_CODE define.
Reviewed-by: Robin Mu
When adding an extra argument to a function, one really should try a bit
harder to catch *all* the callers...
CC: Marek Szyprowski
CC: Inki Dae
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Robin Murphy
---
Ideally, this should be squashed into "iommu/dma: Avoi
52.427644] [] SyS_write+0x44/0xa0
[ 52.432578] [] __sys_trace_return+0x0/0x4
[ 52.438114] Code: 910003fd f9000bf3 aa0003f3 f9800011 (885ffc01)
[ 52.444229] ---[ end trace 34b87a5fb9453f65 ]---
Acked-by: Liviu Dudau
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++
well, although there it's merely a
case of skipping unnecessary work.
CC: Liviu Dudau
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_cr
Hi Daniel,
On 05/05/16 18:06, Daniel Vetter wrote:
> On Thu, May 05, 2016 at 05:13:38PM +0100, Robin Murphy wrote:
>> The current PM ops simply unconditionally enable/disable the HDLCD,
>> which proves problematic when there is no display plugged in - since
>> without a crt
has no business with IOMMU_DMA. If there's an IOMMU dependency in
general it should be on MTK_IOMMU, not underlying implementation details.
Robin.
> drivers/gpu/drm/mediatek/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> b/
Use the optional form of platform_get_irq() for blocks that legitimately
may not be present, to avoid getting an annoying barrage of spurious
warnings for non-existent PPs on configurations like Mali-450 MP2.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/lima/lima_device.c | 7 +--
1 file
There's no point explicitly tracking the platform device when it can be
trivially derived from the regular device pointer in the couple of
places it's ever used.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/lima/lima_devfreq.c | 7 +++
drivers/gpu/drm/lima/lima_dev
r one reason or the other, renaming
would stand to help review and maintenance in terms of making it far
more obvious when the implementation and the intent don't match.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
ob Herring
Cc: Sumit Semwal
Cc: "Andrew F. Davis"
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Pratik Patel
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Sandeep Patil
Cc: Hridya Valsaraju
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
C
7;s possible to hard-wire any old dumb device to behave
coherently without even realising. Thus this is another property that
could legitimately turn up more or less anywhere.
Robin.
Signed-off-by: Andre Przywara
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++
1 f
operating directly
Nit: "let's"
on the struct sg_table objects, which take care of the proper use of
the nents and orig_nents entries.
A few more documentation nitpicks below, but either way the
implementation itself (modulo Christoph's fixup) looks good;
Reviewed-by: Robin
care of the proper use of
the nents and orig_nents entries.
While touching this, lets clarify some ambiguities in the comments for
the existing for_each helpers.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_
the nents and orig_nents entries.
Modulo Joerg's comments,
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/dri-devel/2020051
're overridden by its own IOMMU mapping.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM_MSM fails to build with DRM_MSM_DP=n; add the missing stub.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/msm/msm_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..0b2686b060c7 100644
--- a
e = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
+ a6xx_gpu->have_mmu500 = (phandle &&
+ of_device_is_compatible(phandle, "arm,mmu500"));
Note that this should never match, since the compatible string defined
by the binding is "arm,mmu-50
true when it was already true is
still harmless ;)
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
on of LC_HS_TX_EN, it looks like
this is doing something more than simply testing if a single bit is set.
Robin.
}
static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
___
dri-devel mailing list
dri-devel@lists.
sired offset is already in place).
+ if (!map)
+ return -ENOMEM;
+
+ map->pfn_offset = pfn_offset;
+ map->cpu_start = 0;
+ map->cpu_end = PHYS_ADDR_MAX;
+ map->dma_start = 0;
+ map->dma_end = ~(dma_addr_t)0;
As above, allow
o be any good reason for that.
Plus AFAICS it could potentially let false-positives through if someone
were to pass in a table with non-page-aligned lengths (I assume that's
expected never to happen, but still...)
Robin.
+ }
+ return size;
+}
+EXPORT_SYMBOL(drm_prime_get_con
e, this will happen later when the
* prepare() memop is called.
*/
- sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
- if (!sgt->nents)
+ if (dma_map_sgtable(buf->dev,
return probe_err(d->dev, d->buffer, "failed to init buffer\n");
}
and allowing that to compile without any hint of an error seems a
little... unfair.
Robin.
Signed-off-by: Andrzej Hajda
---
drivers/base/core.c| 25 ++---
include/linux
On 2020-06-24 13:55, Andy Shevchenko wrote:
On Wed, Jun 24, 2020 at 3:37 PM Robin Murphy wrote:
On 2020-06-24 12:41, Andrzej Hajda wrote:
Many resource acquisition functions return error value encapsulated in
pointer instead of integer value. To simplify coding we can use macro
which will
lose really useful
>> data in the logs.
>
> I seem to never manage to end up using any of the systems which generate
> excessive deferrals.
Be thankful... And count me in as one of those miserable users; here's one
of mine being bad enough without even printing any specific mes
On 2020-06-24 16:04, Mark Brown wrote:
On Wed, Jun 24, 2020 at 03:25:33PM +0100, Robin Murphy wrote:
And yeah, anyone who pipes up suggesting that places where an ERR_PTR value
could be passed to probe_err() could simply refactor IS_ERR() checks with
more uses of the god-awful PTR_ERR_OR_ZERO
size -= 4096;
+ }
+
+ iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
+
+ return (unmapped == size) ? 0 : -EINVAL;
+}
Remember in patch #1 when you said "Then 'domain' can be used like any
other iommu domain to map and unmap iova
ma_len = 0
I'm not sure that any non-IOMMU DMA API implementations actually take
advantage of this, but they are *allowed* to ;)
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
o stable without that dependency, since this behaviour is
arguably a regression since 221bc77914cb ("drm/panfrost: Use generic
code for devfreq"), and does appear to have been causing subtle problems
for users.
Robin.
___
dri-devel m
over or not.
Sounds like the most logical thing to do is to shuffle things around so
we start by trying to set up an OPP table, then fall back to explicitly
claiming clocks and regulators if necessary. Then we can easily make the
devfreq decision later in probe based on how that turned out.
a drm-misc, provided Will's OK with that.
Robin.
Robin Murphy (3):
iommu/io-pgtable-arm: Support coherency for Mali LPAE
drm/panfrost: Support cache-coherent integrations
arm64: dts: meson: Describe G12b GPU as coherent
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
drivers/g
the appropriate cacheable outer-shareable attributes in
order to generate the requisite snoop signals, and that CPU mappings
don't create a mismatch by using a non-cacheable type either.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/p
eable accesses. As such, setting the TTBR_SHARE_OUTER bit does
indeed get coherent pagetable walks working nicely for the coherent
T620 in the Arm Juno SoC.
Reviewed-by: Steven Price
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm.c | 5 -
1 file changed, 4 insertions(+), 1 del
snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.
Signed-off-by: Robin Murphy
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
b/arch
is that it adds latency to
every access, but if you already have a coherent interconnect anyway
then the sensible answer to that is implementing decent snoop filters,
rather than making software more complicated.
Robin.
___
dri-devel maili
On 2020-09-21 18:57, Will Deacon wrote:
On Wed, Sep 16, 2020 at 12:51:05AM +0100, Robin Murphy wrote:
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its
ility
domains being a bit wonky; the cacheability attributes there are
actually reasonably normal (other than not having a non-cacheable type
at all, only a choice of allocation policies...)
Robin.
However, Sai, your email setup went wrong when you posted this so you
probably need to repos
eable accesses. As such, setting the TTBR_SHARE_OUTER bit does
indeed get coherent pagetable walks working nicely for the coherent
T620 in the Arm Juno SoC.
Reviewed-by: Steven Price
Tested-by: Neil Armstrong
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm.c | 11 ++-
1 file ch
Hi all,
Here's a quick v2 with the tags so far picked up and some inline
commentary about the shareability domains for the pagetable code.
Robin.
Robin Murphy (3):
iommu/io-pgtable-arm: Support coherency for Mali LPAE
drm/panfrost: Support cache-coherent integrations
arm64: dts:
snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.
Reviewed-by: Neil Armstrong
Tested-by: Neil Armstrong
Signed-off-by: Robin Murphy
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
1 file changed, 4 insertions(+)
diff
the appropriate cacheable outer-shareable attributes in
order to generate the requisite snoop signals, and that CPU mappings
don't create a mismatch by using a non-cacheable type either.
Reviewed-by: Steven Price
Tested-by: Neil Armstrong
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfro
se to simply not enable the DisplayPort node in
the upstream DT, until the type-C phy work has been done to make it
usable at all? AIUI the "official" Manjaro kernel is carrying a bunch of
hacks to make type-C work via extcon, but they know that isn't an
upstreamable solution.
Robin
0" },
+ { .compatible = "qcom,sm8250-smmu-500" },
+ { }
+};
Can you push the table itself into arm-smmu-qcom? That way you'll be
free to add new SoCs willy-nilly without any possibility of conflicting
with anything else.
Bonus points if you can fold in the
patch #1
makes any difference there.
Thanks,
Robin.
Changes since v1:
Use alternative clock rounding code proposed by Doug Anderson
Vicente Bergas (3):
drm: rockchip: hdmi: fix clock rounding code
drm: rockchip: hdmi: allow any clock that is within the range
drm: rockchip: hdmi: ad
On 2020-08-23 22:34, Dmitry Osipenko wrote:
21.08.2020 03:11, Robin Murphy пишет:
...
Hello, Robin! Thank you for yours work!
Some drivers, like this Tegra VDE (Video Decoder Engine) driver for
example, do not want to use implicit IOMMU domain.
That isn't (intentionally) changing here
ops series, so if I'm going to hack something up anyway I may as
well take responsibility for polishing it into a proper patch as well :)
Robin.
Tom Murphy (8):
iommu/vt-d: clean up 32bit si_domain assignment
iommu/vt-d: Use default dma_direct_* mapping functions for direct
On 2020-08-27 16:45, Thierry Reding wrote:
On Thu, Aug 20, 2020 at 04:08:32PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra
ut to the common
sgtable API level, but let's get the individual subsystems straightened
out first then worry about consolidation later.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/drm_gem_cma_hel
ither way.
I'm also assuming this isn't called in performance-critical paths with
massive lists such that the two separate iterations might have a
noticeable impact.
Nits aside,
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
Reviewed-by: Andrzej Hajda
---
drivers/gpu/
sg_free_table(sgt);
+ kfree(sgt);
Should this be a separate patch to add the missing error handling to the
existing code first?
Otherwise the rest of the mechanical conversion looks straightforward
enough, and I'm not the separation-of-concerns police (for this
subsystem, at least)
path to for_each_sgtable_sg() for completeness - AFAICS it
should only need an extra "if (sg_page(sg))..." check in that loop. Then
"count" could possibly be squashed into its one remaining use as well,
but maybe it's worth keeping for readability.
Robin.
loser look to figure this out, but AFAICS it does
indeed work out as a simpler way of achieving the exact same result, and
in fact neatly mirrors how etnaviv_context_map() itself cleans up.
Reviewed-by: Robin Murphy
return ret;
}
@@ -113,7 +106,7 @@ static void etnaviv_iommu_unmap
es the common DMA-mapping wrappers operating
directly on the struct sg_table objects to the dmabuf related functions,
so the other drivers, which might share buffers with i915 could rely on
the properly set nents and orig_nents values.
This one looks mechanical enough :)
Reviewed-by: Robin
On 2020-08-26 07:32, Marek Szyprowski wrote:
Use common helper for checking the contiguity of the imported dma-buf and
do this check before allocating resources, so the error path is simpler.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/mediatek
On 2020-08-26 07:32, Marek Szyprowski wrote:
Use common helper for converting a sg_table object into struct
page pointer array.
Reviewed-by: Robin Murphy
Side note: is mtk_drm_gem_prime_vmap() missing a call to
sg_free_table(sgt) before its kfree(sgt)?
Signed-off-by: Marek Szyprowski
gpummu->table[idx++] = i + addr | prot_bits;
?
Or alternatively perhaps some more aggressive #ifdefs or makefile tweaks
to prevent the GPUMMU code building for arm64 at all if it's only
relevant to 32-bit platforms (which I believe might be the case).
Robin.
, but either way,
Reviewed-by: Robin Murphy
omap_gem_free_object(obj);
obj = ERR_PTR(-ENOMEM);
goto done;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
h omapdrm clarify what exactly the case is here?
I know that IOMMUs might be involved to some degree, and I've skimmed
the interconnect chapters of enough OMAP TRMs to be scared by the
reference to the tiler aperture in the context below :)
Robin.
*
* - buffers mapped thr
On 2020-08-26 07:33, Marek Szyprowski wrote:
Use common helper for checking the contiguity of the imported dma-buf.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 +--
1 file changed, 1 insertion(+), 18
: Bartlomiej Zolnierkiewicz ; David Airlie
; intel-...@lists.freedesktop.org; Robin Murphy
; Christoph Hellwig ; linux-arm-
ker...@lists.infradead.org; Marek Szyprowski
Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
related issues
The Documentation/DMA-API-HOWTO.txt
/paste safe.
Reviewed-by: Robin Murphy
(Until now I hadn't noticed the crimes against the API that
rockchip_gem_get_pages() is committing, but it's not this patch's
fault... I'll have to take a closer look at that)
Signed-off-by: Marek Szyprowski
---
driv
/paste safe.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/tegra/gem.c | 27 ++-
drivers/gpu/drm/tegra/plane.c | 15 +--
2 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b
/paste safe.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/gpu/host1x/job.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 89b6c14b7392..82d0a60ba3f7 100644
--- a
/paste safe.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/misc/fastrpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 7939c55daceb..9d6867749316 100644
--- a/drivers/misc/fastrpc.c
/paste safe.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/rapidio/devices/rio_mport_cdev.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c
b/drivers/rapidio/devices/rio_mport_cdev.c
index
/paste safe.
While touching this code, also add missing call to dma_unmap_sgtable.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
samples/vfio-mdev/mbochs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev
properly did all the
scaterlist related calls.
^^ typo
Otherwise,
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
.../common/videobuf2/videobuf2-dma-contig.c | 34 ---
.../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++--
.../common
;sglist, buf->sglen, PCI_DMA_FROMDEVICE);
+ dma_unmap_sg(&dev->pci->dev, buf->sglist, buf->nr_pages,
PCI_DMA_FROMDEVICE);
If we're touching these lines anyway, we should update them to use the
modern DMA_FROM_DEVICE definitions too.
Robin.
buf->sglen = 0;
Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 1 +
1
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy
---
FYI, get_maintainer.pl seems to be choking on you
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ---
drive
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Also the DMA segment size is simply a size, not a bitmask.
Signed-off-by: Ro
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Also the DMA segment size is simply a size, not a bitmask.
Signed-off-by: Ro
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Also the DMA segment size is simply a size, not a bitmask.
Signed-off-by: Ro
On 2020-09-03 21:36, Robin Murphy wrote:
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy
---
FYI, get_mai
ven't added support for at the moment), thus
the second case is currently empty.
This change actively obfuscates that distinction.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
one's taste :/
and while at it fix the
checkpatch warning for space required before the open
parenthesis.
That one, however, was not ;)
BTW am I supposed to have received 3 copies of everything? Because I did...
Robin.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smm
On 2020-09-11 17:21, Sai Prakash Ranjan wrote:
On 2020-09-11 21:37, Will Deacon wrote:
On Fri, Sep 11, 2020 at 05:03:06PM +0100, Robin Murphy wrote:
BTW am I supposed to have received 3 copies of everything? Because I
did...
Yeah, this seems to be happening for all of Sai's e
fo.priv = heap;
+ heap->heap = dma_heap_add(&exp_info);
+ if (IS_ERR(heap->heap)) {
+ int ret = PTR_ERR(heap->heap);
+
+ kfree(heap);
+ return ret;
+ }
+ dma_heap_get_dev(heap->heap)->dma_mask = &dummy_mask;
+ dma_set_mask(dma_heap_get_dev(heap->heap), DMA_BIT_MASK(64));
Much as I'd hate to encourage using dma_coerce_mask_and_coherent(), I'm
not sure this is really any better :/
Robin.
+
+ return 0;
+}
+device_initcall(uncached_heap_create);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
e-existing condition...) Confirmation that the
Mediatek, OMAP and Tegra changes work will be most welcome.
Patches are based on 5.9-rc1, branch available here:
git://linux-arm.org/linux-rm arm/dma
Robin.
Robin Murphy (18):
ARM/dma-mapping: Drop .dma_supported for IOMMU ops
ARM/dma-mappin
When an IOMMU is present, we trust that it should be capable
of remapping any physical memory, and since the device masks
represent the input (virtual) addresses to the IOMMU it makes
no sense to validate them against physical PFNs anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
---
arch/arm/Kconfig | 4 +-
arch/arm/mm/dma-mapping.c |
gh
an ugly transitional phase. That starts with exposing some hooks into
iommu-dma's internals so that it can start to do most of the heavy
lifting.
Before you start thinking about how horrible that is, here's a zebra:
,
c@
`)\
< /
Signed-off-by: Robin Murphy
---
drivers
The dma_sync_* operations are now the only difference between the
coherent and non-coherent IOMMU ops. Some minor tweaks to make those
safe for coherent devices with minimal overhead, and we can condense
down to a single set of DMA ops.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c
Now that arch/arm is wired up for default domains and iommu-dma, remove
the shared mapping workaround and rely on groups there as well.
Signed-off-by: Robin Murphy
---
drivers/iommu/ipmmu-vmsa.c | 69 --
1 file changed, 69 deletions(-)
diff --git a/drivers
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-smmu.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm
drivers and consumers to work with IOMMU API default
domains instead.
Signed-off-by: Robin Murphy
---
arch/arm/Kconfig | 24 +-
arch/arm/include/asm/dma-iommu.h | 8 -
arch/arm/mm/dma-mapping.c| 887 +--
drivers/iommu/Kconfig| 8
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/staging/media/tegra-vde/iommu.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/staging/media/tegra-vde
Now that arch/arm is wired up for default domains and iommu-dma, devices
behind IOMMUs will get mappings set up automatically as appropriate, so
there is no need for drivers to do so manually.
Signed-off-by: Robin Murphy
---
drivers/media/platform/omap3isp/isp.c | 68
With no users left and generic iommu-dma now doing all the work,
clean up the last traces of the arch-specific API, plus the temporary
workarounds that you'd forgotten about because you were thinking about
zebras instead.
Signed-off-by: Robin Murphy
---
arch/arm/common/dmabounce.c
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/omap-iommu.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-gart.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/tegra
Now that iommu-dma is wired up, we can let it work as normal
without the dma_iommu_mapping hacks if the IOMMU driver already
supports default domains.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a
301 - 400 of 570 matches
Mail list logo
