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/msm_iommu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/msm_iommu.c b
Now that arch/arm is wired up for default domains and iommu-dma, we can
consolidate the shared mapping code onto the generic IOMMU API version,
and retire the arch-specific implementation.
Signed-off-by: Robin Murphy
---
This is a cheeky revert of 07dc3678bacc ("drm/exynos: Fix cleanup of
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for groups and DMA
domains to replace the shared mapping workaround.
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.h| 2 -
drivers/iommu/mtk_iommu_v1.c | 153
Now that arch/arm is wired up for default domains and iommu-dma, remove
the add_device workaround.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm
;iommu/msm: Add
support for generic master bindings").
Robin.
BR,
-R
On Thu, Aug 20, 2020 at 8:09 AM 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
On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
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
On 2020-08-20 20:55, Sakari Ailus wrote:
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma, devices
On 2020-08-20 20:51, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
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
On 2020-08-20 21:16, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
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
submission/completion/timeout on different job slots.
Given that, should this actually be considered a fix for 9e62b885f715
("drm/panfrost: Simplify devfreq utilisation tracking")?
Robin.
___
dri-devel mailing list
dri-devel@lists.freed
defining it commonly as a
static __maybe_unused default_release_of() in component.h or drm_of.h
(and maybe default_compare_of() similarly)?
(Apologies if there's already been some strong argument against that
which I've not seen, but it seems like a reasonable thing to do.)
Robin.
reate a
framebuffer, drm_gem_cma_create() fails, unconditionally calls the
now-NULL drm->driver->gem_free_object() in its cleanup path, and fiery
death ensues...
Regards,
Robin.
x27;s regular DMA ops, if the allocation is provided by an
IOMMU then such assumptions can fall apart spectacularly.
To resolve this, reroute the fb_mmap call to the appropriate DMA API
implementation, as per the other cma_helper calls.
Acked-by: Daniel Vetter
Signed-off-by: Robin Murphy
---
Rese
Hi Liviu,
On 07/06/16 14:35, liviu.dudau at arm.com wrote:
> On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
>> Having just inadvertently merged -next into my working branch, I find
>> dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free callback") adversel
On 07/06/16 15:43, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote:
>> In the absence of an fb_mmap callback, the fbdev code falls back to a
>> naive implementation which relies upon the DMA address being the same
>> as the physical address,
On 07/06/16 15:40, Daniel Vetter wrote:
> On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
>> Hi Daniel, Liviu,
>>
>> Having just inadvertently merged -next into my working branch, I find
>> dev6d910bfa809e ("drm/hlcd: Use lockless gem BO free call
_ALLOC_SINGLE_PAGES, attrs))
> + if (attrs & DMA_ATTR_ALLOC_SINGLE_PAGES)
> alloc_sizes = min_size;
>
> count = PAGE_ALIGN(size) >> PAGE_SHIFT;
[...]
These all look appropriate to me; thanks!
For arm64 and dma-iommu:
Acked-by: Robin Murphy
--> iommu_map()
--> dma_alloc_coherent(IOMMU dev) // for pagetable
--> ops->alloc(IOMMU dev)
--> swiotlb_alloc(IOMMU dev)
There shouldn't be any need for this "virtual IOMMU" at all. I think the
Exynos DRM driver is
atch in both functions.
>
> Reported-by: Robin Murphy
> Signed-off-by: Liviu Dudau
> ---
>
> Robin,
>
> I believe this should fix your problems with HDLCD failing to allocate CMA
> memory and then crashing.
Heh, I'm not sure I'd even clocked that there was yet anot
Fixed several double space pointer notations, and added one newline
Signed-off-by: Robin Schroer
---
drivers/gpu/drm/i915/i915_dma.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915
On Mon, Jun 02, 2014 at 05:21:32PM +0200, Daniel Vetter wrote:
> On Mon, Jun 02, 2014 at 04:10:08PM +0100, Damien Lespiau wrote:
> > On Mon, Jun 02, 2014 at 04:59:39PM +0200, Robin Schroer wrote:
> > > Fixed several double space pointer notations, and added one newline
> &g
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu
Under a big-endian kernel, colours on the framebuffer all come out a
delightful shade of wrong, since we fail to take the reversed byte
order into account. Fortunately, the HDLCD has a control bit to make it
automatically byteswap big-endian data; let's use it as appropriate.
Signed-off-by:
On 07/12/16 15:57, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote:
>> Under a big-endian kernel, colours on the framebuffer all come out a
>> delightful shade of wrong, since we fail to take the reversed byte
>> order into account. Fortuna
On 07/12/16 16:42, Robin Murphy wrote:
> On 07/12/16 15:57, Daniel Vetter wrote:
>> On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote:
>>> Under a big-endian kernel, colours on the framebuffer all come out a
>>> delightful shade of wrong, since we fai
; Cc: David Airlie
> Cc: Robin Murphy
I've given this a spin on my Juno, and the first thing of note is this:
hdlcd 7ff6.hdlcd: master bind failed: -517
hdlcd 7ff5.hdlcd: master bind failed: -517
scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.9.0 version
[drm] found ARM HDLCD v
On 08/12/15 16:52, Liviu Dudau wrote:
> On Tue, Dec 08, 2015 at 04:25:27PM +0000, Robin Murphy wrote:
>> Hi Liviu,
>>
>> On 07/12/15 12:11, Liviu Dudau wrote:
>>> The HDLCD controller is a display controller that supports resolutions
>>> up to 4096x4096 pixel
le to find time for a full bisection next week if isn't
something sufficiently obvious to anyone who knows this driver.
Thanks,
Robin.
-- next part --
[===>] 13458 Kb
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from config
Hi Alex,
On 08/04/16 05:47, Alexandre Courbot wrote:
> Hi Robin,
>
> On 04/07/2016 08:50 PM, Robin Murphy wrote:
>> Hello,
>>
>> With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
>> look of it by dereferencing some offset from NULL i
On 20/04/16 11:44, Robin Murphy wrote:
> Hi Alex,
>
> On 20/04/16 05:35, Alexandre Courbot wrote:
> [...]
>>>> Bisection came down to 1733a2ad3674("drm/nouveau/device/pci: set as
>>>> non-CPU-coherent on ARM64"), and sure enough reverting that removes
e doing memcpy on a NULL pointer. We never caught this because we
>> typically do not use Nouveau's fbcon with an ARM setup.
>>
>> I don't really like this special access for coherent objects, and
>> actually had a patch in my tree to attempt to remove it (attached).
&g
for RTSMv8 is augmented accordingly.
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-simple.c | 30
Nit: binding doc?
1 file changed, 30 insertion
On 30/04/18 18:59, Sinan Kaya wrote:
On 4/30/2018 9:54 AM, Robin Murphy wrote:
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses which drm_prime_sg_to_page_addr_arrays
greater than the VOP usage
count (except before the VOP driver has probed, but I don't think that
matters), so although this looks like a sensible change in general I
can't help be a little bit puzzled at how and why the flow works.
Robin.
+*/
+ if (!pm
On 29/05/18 13:17, Heiko Stübner wrote:
Am Dienstag, 29. Mai 2018, 13:59:42 CEST schrieb Robin Murphy:
On 28/05/18 14:20, Heiko Stuebner wrote:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in
x27;t always right.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
be even more appropriate?
+ /* make sure we can use the IOMMU exclusively */
+ arm_dma_iommu_detach_device(dev);
As before, I would just use the existing infrastructure the same way the
Exynos DRM driver currently does in __exynos_iommu_attach() (albeit
without then reattaching to another
On 30/05/18 14:41, Thierry Reding wrote:
On Wed, May 30, 2018 at 02:30:51PM +0100, Robin Murphy wrote:
On 30/05/18 14:00, Thierry Reding wrote:
On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote:
On 30/05/18 09:03, Thierry Reding wrote:
From: Thierry Reding
Depending on the
On 30/05/18 14:00, Thierry Reding wrote:
On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote:
On 30/05/18 09:03, Thierry Reding wrote:
From: Thierry Reding
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that
On 30/05/18 14:12, Thierry Reding wrote:
On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote:
On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote:
On 30/05/18 09:03, Thierry Reding wrote:
From: Thierry Reding
Implement this function to enable drivers from detaching from
landscape changing around it, but it's clearly
not enough of a problem to consider stable backports :)
Reviewed-by: Robin Murphy
Signed-off-by: Thierry Reding
---
Changes in v4:
- new patch to fix existing arm_iommu_detach_device() to do what we need
arch/arm/mm/dma-mapping.c | 12 +
I guess this disappears again anyway once the refcounting gets
sorted out and the mapping releases itself properly, so:
Reviewed-by: Robin Murphy
+
+ arm_iommu_detach_device(dev);
+ arm_iommu_release_mapping(mapping);
+ }
+#endif
+
if (
On 26/04/18 08:52, Linus Walleij wrote:
On Mon, Apr 23, 2018 at 2:04 PM, Robin Murphy wrote:
I've given this a go on the nearest VExpress (with CA15_A7 tile) and sadly
it doesn't quite work for me :( With the HDLCD driver configure out, the
PL111 driver seems to repeatedly defer
NULL
and I've missed the tiny subtlety below. Does that fix matters?
Robin.
->8-
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index b8ca06ea7d80..6a31229e4611 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/dr
Hi Thomas,
On 25/04/18 14:21, Thomas Hellstrom wrote:
Hi, Robin,
Thanks for the patch. It was some time since I put together that code,
but I remember hitting something similar to
https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964
really
after is a generic way for drivers to say "Hey, I actually have my own
MMU (or want to control the one you already know about) so please give
me direct DMA ops", which the arch code handles as appropriate (maybe
it's also allowed to fail in cases like swiotlb=force or when th
On 27/04/18 18:39, Thomas Hellstrom wrote:
On 04/27/2018 06:56 PM, Robin Murphy wrote:
Hi Thomas,
On 25/04/18 14:21, Thomas Hellstrom wrote:
Hi, Robin,
Thanks for the patch. It was some time since I put together that
code, but I remember hitting something similar to
https
X can only use context bank N" condition is a real
hardware limitation which should be described by firmware, but I don't
have any immediate good ideas as to how :(
The matter of opting out of DMA ops which expect the default domain is a
separate and more general issue, so I won&#x
On 30/04/18 13:12, Thierry Reding wrote:
On Mon, Apr 30, 2018 at 12:41:52PM +0100, Robin Murphy wrote:
On 30/04/18 12:02, Thierry Reding wrote:
On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote:
On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote:
On Wed, Apr 25
On 27/04/18 20:42, Sinan Kaya wrote:
On 4/27/2018 11:54 AM, Robin Murphy wrote:
ubuntu@ubuntu:~/amdgpu$_./vectoradd_hip.exe
[ 834.002206] create_process:620
[ 837.413021] Unable to handle kernel NULL pointer dereference at virtual
address 0018
£5 says that's sg_dma_len(NULL),
g dma-contiguous segments such that it returns
0 < count < nents, we can relax the current count == nents check to
only consider genuine failure as other drivers do.
Reported-by: Sinan Kaya
Reviewed-by: Christian König
Signed-off-by: Robin Murphy
---
v3: No change
drivers/gpu/drm/amd/amdgpu/a
ap_sg() coalescing dma-contiguous segments such that it returns
0 < count < nents, we can relax the current count == nents check to
only consider genuine failure as other drivers do.
Suggested-by: Christian König
Reviewed-by: Christian König
Signed-off-by: Robin Murphy
---
v3: No change
driv
the total DMA length should still be equal to the
total buffer length. All we need is a second scatterlist cursor to
iterate through the DMA addresses independently of the page addresses.
Reviewed-by: Christian König
Signed-off-by: Robin Murphy
---
v3: Move dma_len == 0 logic earlier to avoid
On 27/04/18 19:51, Linus Walleij wrote:
On Fri, Apr 27, 2018 at 5:02 PM, Robin Murphy wrote:
I dug a little bit and it seems pl111_modeset_init() is deferring because it
can't find endpoint 0. And given that that's apparently pointing at some
non-existent panel rather than the DVI
location of the
video RAM depending on which chip select is used on
each platform.
This plays nicely with the new PL111 DRM driver and
follows the standard ways of assigning bridges and
memory pools for graphics.
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Robin Murphy
Signed-off-by: Linus Walleij
videomode *vm = &dsi->vm;
struct drm_display_mode *m = adjusted_mode;
FWIW you could just pass &dsi->vm and adjusted_mode directly to the
helper and get rid of these locals too.
Robin.
- vm->hactive = m->hdisplay;
- vm->vactive = m->vdisplay;
-
On 04/05/18 09:15, Satendra Singh Thakur wrote:
To avoid duplicate logic for the same
Reviewed-by: Robin Murphy
Please read section 13 of Documentation/process/submitting-patches.rst
for what this tag means; specifically, it is definitely not "this guy
read my patch".
FWIW,
grf.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Rockchip Generic Register Files definitions
Nit: s/Generic/General/
(that's what the TRMs say)
Robin.
+ *
+ * Copyright (c) 2018, Collabora Ltd.
+ * Author: Enric Balletbo i Serra
+ */
+
+#ifndef __SOC_RK3399_GRF
ize - 1) {
+ base += window->offset;
+ break;
+ }
+ }
+
Is this not pretty much just pcibios_bus_to_resource()?
Robin.
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = &dev->resource[i];
t it, so it's probably worth renaming one or the
other.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 15/08/18 20:56, Dmitry Osipenko wrote:
On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote:
On 02/08/18 19:24, Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
On Fri, Jul 27, 2018 at 05:02
"OF: Don't set default coherent DMA mask")
the OF core stops setting the default DMA mask on new devices,
especially those lines of the patch:
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
Robin Murphy solved a similar problem in
a55
o refcount domain users and
release hardware contexts for domains with no devices currently attached.
Robin.
doing that, except that we're doing it behind the back of the DMA
mapping subsystem, so that it keeps using the IOMMU version of the DMA
ops for the device and doing any mapping o
main will already have been allocated by the time
we get here, regardless of whether we pretend of_iommu_configure() did
nothing, I'm puzzled as to how this change is 'solving' that aspect as
claimed :/
Is CONFIG_IOMMU_DEFAULT_PASSTHROUGH a sufficient workaround for msm at
the mo
some version of the Arm Mali driver, possibly on RK3288).
Robin.
}
static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
also clean up a couple more places where you're not
already removing such checks)
Robin.
+
+ for (i = 0; i < page_count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[i]);
+ if (ret < 0)
+ return ret;
+ ua
On 2018-12-07 7:28 pm, Souptick Joarder wrote:
On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox wrote:
On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long
On 2018-12-07 8:30 pm, Souptick Joarder wrote:
On Fri, Dec 7, 2018 at 8:20 PM Robin Murphy wrote:
On 06/12/2018 18:42, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Tested-by: Heiko Stuebner
Acked-by
nto the
correct order...
Robin.
} else {
iommu_dma_unmap_page(dev, *handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page,
@@ -309,7 +314,9 @@ static void __iommu_free_attrs(struct device *dev, size_t
size
Now that the Host1x bus_type implements a .dma_configure callback,
subdevices should automatically get configured for DMA as their drivers
bind, so there's no need to also force it at device creation time.
CC: Thierry Reding
CC: Mikko Perttunen
Signed-off-by: Robin Murphy
---
I *believ
On 26/09/18 15:13, Thierry Reding wrote:
On Wed, Sep 26, 2018 at 04:10:54PM +0200, Thierry Reding wrote:
On Wed, Sep 12, 2018 at 05:47:54PM +0100, Robin Murphy wrote:
Now that the Host1x bus_type implements a .dma_configure callback,
subdevices should automatically get configured for DMA as
.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
Inki:
If possible, please consider this patch as a fix for v4.19-rc, this will
help doing a rework in IOMMU and DMA-IOMMU frameworks in v4.20 without
breaking Exynos DRM. It worked for current IOMMU code, but such usage is
considered as
.clcd failed with error -2
FWIW the same happens on PB-A8; looks like converting to OF graph
bindings falls foul of the "panel-dpi" check in clcdfb_of_get_mode().
Robin.
___
dri-devel mailing list
dri-devel@lists.freede
about the specific details of which devices
have magic associations with specific contexts, and we almost certainly
need a more expressive interface than iommu_domain_alloc() to have any
hope of reliable results.
Robin.
Some of the above is due to a SW driver model (and its work-in-progress
s
On 02/08/18 19:24, Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
On 27/07/18 15:10, Dmitry Osipenko wrote:
On Friday, 27 July 2018 12
,
And here?
Otherwise, assuming the table walk really isn't cache-coherent, and the
global and CB interrupts really do ha
t thinking ahead, might it be worth a logical "are SG segment limits
relevant?" wrapper around the dev->dma_parms reference? Not a big deal
for now if we think this site is the only user, so either way,
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
drive
ee "kernel" VA space impinging on usable process VAs. Even then
we're not sure that's a significant concern beyond OpenCL SVM.
Thanks,
Robin.
VA space is limited to 4G on a 32-bit build :-(. Robin, any
chance you could advise me on what to do here?
1. assume this limitation is here for a good reason, and limit the GPU
VA space to 32-bits on 32-bit kernels
or
2. update the interface to make iova an u64
I'm not sure I can answe
a particular driver" and don't actually
bear any relationship to firmware or hardware at all.
However, the fact that Linux's implementation of how to reuse reserved
memory areas is called CMA is indeed still irrelevant and has no place
in the binding itself.
Thanks,
Robin.
On 12/09/2023 4:53 pm, Rob Herring wrote:
On Tue, Sep 12, 2023 at 11:13:50AM +0100, Robin Murphy wrote:
On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote:
On 12/09/2023 08:16, Yong Wu (吴勇) wrote:
Hi Rob,
Thanks for your review.
On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote
alone just a non-broken build - than there are
for building this driver for x86. Using pm_ptr() is trivial, and if you
want to support COMPILE_TEST then there's really no justifiable excuse
not to.
Thanks,
Robin.
On 2024-03-11 1:22 pm, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:11:28 +
Robin Murphy wrote:
On 2024-03-11 11:52 am, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:49:56 +0200
Jani Nikula wrote:
On Mon, 11 Mar 2024, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:05:01 +0200
-
pm_ptr() already takes care of allowing the compiler to optimise out the
ops structure itself without any further annotations.
Thanks,
Robin.
static DEFINE_RUNTIME_DEV_PM_OPS(panthor_pm_ops,
panthor_device_suspend,
properly test this configuration does
worry me a little.
Well, as long as it doesn't regress the PM behavior, I think I'm happy
to take the risk. Worst case scenario, someone complains that this is
not working properly when they do the !PM bringup :-).
Indeed, I've no objection to this
!dummy_page_virt)
return -ENOMEM;
ptdev->pm.dummy_latest_flush = virt_to_page(dummy_page_virt);
Cheers,
Robin.
if (ret)
return ret;
@@ -184,7 +186,7 @@ int panthor_device_init(struct panthor_device *ptdev)
* happens while the dummy
this is the way it is?
[ just came across this code in the tree while trying to figure out what
to do with iommu_set_pgtable_quirks()... ]
Thanks,
Robin.
Fixes: 54af0ceb7595 ("arm64: dts: qcom: sm8350: add GPU, GMU, GPU CC and SMMU
nodes")
Reported-by: David Heidelberg
Signed
On 29/09/2023 4:45 pm, Will Deacon wrote:
On Mon, Sep 25, 2023 at 06:54:42PM +0100, Robin Murphy wrote:
On 2023-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
tible. It needs to describe *this* secure memory interface offered
by *this* TEE, so that software knows that to use it requires making
those particular SiP calls with that particular UUID etc.
Thanks,
Robin.
decisively seems more useful than deferring forever.
Signed-off-by: Robin Murphy
---
I realised that last time I sent this I probably should have CCed a
wider audience of reviewers, so here's one with an updated commit
message as well to make the resend more worthwhile.
drivers/gpu/drm/med
much less need to
serialise against it!
Thanks,
Robin.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 08f29a1dfcd5f8..9557c2ec08d
t theoretical bug becomes real.
There's really no practical value to be had from compile-testing IORT.
Thanks,
Robin.
y still not right... repeated words aren't *always*
redundant, sometimes they're meant to be other words ;)
Thanks,
Robin.
n't spread the "collect the resources" trick into those
subsystems as well.
Thanks,
Robin.
hmark on a
Neoverse N1, any difference I think I see is still well within the
noise, so maybe a handful of extra indirect calls isn't really enough to
worry about?
Cheers,
Robin.
Signed-off-by: Rob Clark
---
drivers/iommu/io-pgtable-arm.c | 51 --
i
aint as a workaround for a driver shortcoming is "the
right thing to do" ;)
Robin.
Signed-off-by: Sinan Kaya
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gmc_
On 11/04/18 15:33, Sinan Kaya wrote:
On 4/11/2018 8:03 AM, Robin Murphy wrote:
On 10/04/18 21:59, Sinan Kaya wrote:
Code is expecing to observe the same number of buffers returned
from dma_map_sg() function compared to
sg_alloc_table_from_pages(). This doesn't hold true universally
espec
Now that drm_prime_sg_to_page_addr_arrays() understands the case where
dma_map_sg() has coalesced segments and returns 0 < count < nents, we
can relax the check to only consider genuine failure.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file chan
ngth. All we need is a separate scatterlist cursor to iterate the DMA
addresses separately from the CPU addresses.
Signed-off-by: Robin Murphy
---
Off the back of Sinan's proposal for a workaround, I took a closer look
and this jumped out - I have no hardware to test it, nor do I really
k
On 11/04/18 18:11, Robin Murphy wrote:
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses may be packed into fewer entries than
ttm->sg->nents i
401 - 500 of 571 matches
Mail list logo
