On 2022-04-07 18:51, Dmitry Osipenko wrote:
On 4/6/22 21:06, Robin Murphy wrote:
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.
Signed-off
-by: Robin Murphy
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v8:
- new patch
drivers/clk/rockchip/clk-rk3568.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3568.c
b/drivers/clk/rockchip/clk-rk3568.c
index 63dfbeeeb06d9..62694d95173ab 100644
this is somewhat of a logical cleanup, the main motivation is
to prepare for a change in the iommu_domain_alloc() interface.
Signed-off-by: Robin Murphy
---
Lightly tested on RK3288. This does stand to collide with the in-flight
VOP2 driver a little, if only that that will want an equivalent
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1 file
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file changed, 4 deletions
iommu_get_domain_for_dev() is already perfectly happy to return NULL
if the given device has no IOMMU. Drop the unnecessary check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/arm/malidp_planes.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu
On 2022-03-28 13:55, Jonathan Marek wrote:
This matches the implementation of iommu_map_sgtable() used for the
non-per-process page tables path.
This works around the dma_map_sgtable() call (used to invalidate cache)
overwriting sgt->nents with 1 (which is probably a separate issue).
FWIW
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to
On 2022-03-16 13:01, Dmitry Osipenko wrote:
On 3/16/22 12:12, Sascha Hauer wrote:
On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote:
On 3/14/22 11:18, Sascha Hauer wrote:
On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote:
On 3/11/22 11:33, Sascha Hauer wrote:
The
On 2022-03-14 22:42, Dmitry Osipenko wrote:
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that
On 2022-03-14 11:31, Robin Murphy wrote:
On 2022-03-13 12:56, Peter Geis wrote:
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
Wiadomość napisana przez Peter Geis w dniu
26.01.2022, o godz. 21:24:
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after
On 2022-03-13 12:56, Peter Geis wrote:
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
Wiadomość napisana przez Peter Geis w dniu 26.01.2022, o
godz. 21:24:
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after enabling the clock we set it in order for
On 2022-02-25 07:51, Sascha Hauer wrote:
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Further to the clarification of the underlying
On 2022-03-09 08:37, elaine.zhang wrote:
hi,
在 2022/3/9 下午4:18, Sascha Hauer 写道:
Hi Elaine,
On Wed, Mar 09, 2022 at 09:41:39AM +0800, zhangq...@rock-chips.com wrote:
hi，all：
Let me explain the clock dependency：
From the clock tree, pclk_vo0 and hclk_vo0 are completely
On 2022-03-07 20:53, Geert Uytterhoeven wrote:
- sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but
does define __sparc__, hence replace the check for SPARC by a check
for __sparc__,
- powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__,
but
:49 a.m., Robin Murphy wrote:
On 2022-02-25 19:27, Michael Cheng wrote:
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a
good thing to do from the start ]
* Thanks for adding the arm64 maintainer and sorry I didn't rope them
in sooner.
Why does i915 need
to be valid.
Robin.
On 2022-02-25 10:24 a.m., Robin Murphy wrote:
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush
est choice.
Reviewed-by: Robin Murphy
Cheers,
Robin.
+usable stream IDs.
+
required:
- reg-names
On 2022-02-28 14:19, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 02:11:54PM +0100, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
On 2022-02-25 13:11, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет:
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The
On 2022-02-22 16:21, Christoph Hellwig wrote:
On Fri, Feb 18, 2022 at 01:39:45PM +0200, Mikko Perttunen wrote:
The context bus is a "dummy" bus that contains struct devices that
correspond to IOMMU contexts assigned through Host1x to processes.
Even when host1x itself is built as a module, the
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Implement the get_streamid_offset required for supporting context
isolation. Since old firmware cannot support context isolation
without hacks that we don't want to implement, check the firmware
binary to see if context isolation should be
On 2022-02-21 15:28, Mikko Perttunen wrote:
On 2/21/22 17:23, Robin Murphy wrote:
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node.
Couldn't you simply make "iommu-map" an allowed property on the host1x
node itself?
On 2022-02-11 20:27, alyssa.rosenzw...@collabora.com wrote:
From: Alyssa Rosenzweig
From the kernel's perspective, pre-CSF Valhall is more or less
compatible with Bifrost, although they differ to userspace. Add a
compatible for Valhall to the existing Bifrost bindings documentation.
On 2022-02-14 20:31, Alyssa Rosenzweig wrote:
MT8192 requires 5 power domains. Rather than bump MAX_PM_DOMAINS and
waste memory on every supported Panfrost chip, instead dynamically
allocate pm_domain_devs and pm_domain_links. This adds some flexibility;
it seems inevitable a new MediaTek device
On 2022-01-30 00:46, Linus Walleij wrote:
On Thu, Jan 20, 2022 at 4:00 PM Paul Kocialkowski
wrote:
There are lots of different versions of the logicvc block and it
makes little sense to list them all in compatibles since all versions
with the same major are found to be register-compatible.
On 2022-01-28 08:11, Yong Wu wrote:
[...]
diff --git a/include/linux/component.h b/include/linux/component.h
index 16de18f473d7..5a7468ea827c 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -2,6 +2,8 @@
#ifndef COMPONENT_H
#define COMPONENT_H
+#include
On 2022-01-26 18:44, Peter Geis wrote:
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
1 file changed, 36 insertions(+), 1
On 2022-01-25 19:12, Helge Deller wrote:
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.
On 2022-01-20 15:27, Keith Busch wrote:
On Thu, Jan 20, 2022 at 02:56:02PM +0100, Christoph Hellwig wrote:
- on the input side to dma mapping the bio_vecs (or phyrs) are chained
as bios or whatever the containing structure is. These already exist
and have infrastructure at least in
On 2021-12-23 11:06, asheplya...@basealt.ru wrote:
From: Alexey Sheplyakov
T62x/T60x GPUs are known to not work with panfrost as of now.
One of the reasons is wrong/incomplete memory attributes which
the panfrost driver sets in the page tables:
- MEMATTR_IMP_DEF should be 0x48ULL, not
e than a year after
that commit ;)
As an improvement rather than a fix, though,
Reviewed-by: Robin Murphy
Signed-off-by: Lu Baolu
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/
Include dma-mapping.h directly in the remaining places that touch the
DMA API, to avoid imminent breakage from refactoring other headers.
Signed-off-by: Robin Murphy
---
This makes arm64 allmodconfig build cleanly for me with the IOVA series,
so hopefully is the last of it...
drivers/gpu/drm
On 2021-11-08 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom mechanism
***
this series adds support for Host1x 'context isolation'. Since
when programming engines
transitive
inclusion currently providing it is going to break soon.
Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding
CC: Mikko Perttunen
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy
---
It also doesn't appear to hand
-off-by: Robin Murphy
---
v2: No change
drivers/gpu/host1x/bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 218e3718fd68..881fad5c3307 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -5,6 +5,7
On 2021-12-08 15:12, Sascha Hauer wrote:
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
On 2021-11-17 14:33, Sascha Hauer wrote:
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
---
On 2021-12-06 15:00, Biju Das wrote:
The Renesas RZ/G2{L, LC} SoC (a.k.a R9A07G044) has a Bifrost Mali-G31 GPU,
add a compatible string for it.
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
---
v1->v2:
* Updated minItems for resets as 2
* Documented optional property reset-names
*
On 2021-12-01 13:41, Lucas Stach wrote:
Hi Robin,
Am Mittwoch, dem 01.12.2021 um 12:50 + schrieb Robin Murphy:
Sorry I missed this earlier...
On 2021-09-07 17:49, Michael Walle wrote:
The STLB and the first command buffer (which is used to set up the TLBs)
has a 32 bit size restriction
Sorry I missed this earlier...
On 2021-09-07 17:49, Michael Walle wrote:
The STLB and the first command buffer (which is used to set up the TLBs)
has a 32 bit size restriction in hardware. There seems to be no way to
specify addresses larger than 32 bit. Keep it simple and restict the
addresses
nge itself:
Reviewed-by: Robin Murphy
Thanks,
Robin.
Signed-off-by: Guangming
---
drivers/dma-buf/heaps/system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..8660508f3
On 2021-11-25 12:46, guangming@mediatek.com wrote:
From: Guangming
Use (sg_table.orig_nents) rather than (sg_table.nents) to traverse
sg_table to free sg_table.
Use (sg_table.nents) maybe will casuse some pages can't be freed.
...and this sort of bug is precisely why we have the
of it around). So from the IOMMU perspective,
Acked-by: Robin Murphy
Perhaps the AGP driver could also be tweaked and intel_iommu_gfx_mapped
cleaned away entirely, but I'll leave that for Baolu to think about :)
Cheers,
Robin.
It was suggested to additionally check
transitive
inclusion currently providing it is going to break soon.
Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
Signed-off-by: Robin Murphy
---
It also doesn't appear to handle failure of the tegra_drm_alloc() path
either, but that's a loose thread I have
On 2021-11-23 14:10, Robin Murphy wrote:
Host1x seems to be relying on picking up dma-mapping.h transitively from
iova.h, which has no reason to include it in the first place. Fix the
former issue before we totally break things by fixing the latter one.
CC: Thierry Reding
CC: Mikko Perttunen
: linux-te...@vger.kernel.org
Signed-off-by: Robin Murphy
---
Feel free to pick this into drm-misc-next or drm-misc-fixes straight
away if that suits - it's only to avoid a build breakage once the rest
of the series gets queued.
Robin.
drivers/gpu/host1x/bus.c | 1 +
1 file changed, 1 insertion
On 2021-11-22 17:47, Alex Bee wrote:
Am 22.11.21 um 09:10 schrieb Sascha Hauer:
Hi Alex,
On Mon, Nov 22, 2021 at 12:18:47AM +0100, Alex Bee wrote:
Hi Sascha,
Am 17.11.21 um 15:33 schrieb Sascha Hauer:
This series adds initial graphics support for the Rockchip RK356[68]
SoCs. Graphics
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin
On 2021-11-10 09:35, Tvrtko Ursulin wrote:
On 10/11/2021 07:25, Lu Baolu wrote:
On 2021/11/10 1:35, Tvrtko Ursulin wrote:
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears
Hi Daniel,
On 2021-10-13 18:08, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 10:36:54AM -0400, Alyssa Rosenzweig wrote:
From: Robin Murphy
drm_gem_cma_mmap() cannot assume every implementation of dma_mmap_wc()
will end up calling remap_pfn_range() (which happens to set the relevant
vma flag
On 2021-09-10 11:09, Guchun Chen wrote:
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
v2: lower check level to
On 2021-08-26 16:17, Lucas Stach wrote:
Am Donnerstag, dem 26.08.2021 um 16:00 +0100 schrieb Robin Murphy:
On 2021-08-26 13:10, Michael Walle wrote:
The DMA configuration of the virtual device is inherited from the first
actual etnaviv device. Unfortunately, this doesn't work with an IOMMU
On 2021-08-26 13:10, Michael Walle wrote:
The DMA configuration of the virtual device is inherited from the first
actual etnaviv device. Unfortunately, this doesn't work with an IOMMU:
[5.191008] Failed to set up IOMMU for device (null); retaining platform DMA
ops
This is because there is
implementations do.
This avoids repeated warnings on a small minority of systems where the
display is behind an IOMMU, and has a simple driver which does not
override drm_gem_cma_default_funcs.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/drm_gem_cma_helper.c | 1 +
1 file changed, 1 insertion
On 2021-08-23 22:30, Christophe JAILLET wrote:
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
Hi,
FWIW this patch itself looks fine, but it does highlight some things
which could be further cleaned up if anyone's interested...
On 2021-08-22 22:06, Christophe JAILLET wrote:
[...]
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
On 2021-07-14 10:19, Michael Riesch wrote:
Hello Heiko,
On 7/13/21 10:49 AM, Heiko Stübner wrote:
Hi Michael,
Am Dienstag, 13. Juli 2021, 10:44:00 CEST schrieb Michael Riesch:
The HDMI TX block in the RK3568 requires two power supplies, which have
to be enabled in some cases (at least on the
On 2021-07-07 13:03, Benjamin Gaignard wrote:
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Do you know what hclk_vio is and whether it's actually necessary? I
don't see any mention of it
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-06-28 11:48, Steven Price wrote:
On 25/06/2021 10:49, Chunyou Tang wrote:
Hi Steve,
Thinks for your reply.
When I only set the pte |= ARM_LPAE_PTE_SH_NS;there have no "GPU
Fault",When I set the pte |= ARM_LPAE_PTE_SH_IS(or
ARM_LPAE_PTE_SH_OS);there have "GPU Fault".I
On 2021-06-27 09:47, Andy Yan wrote:
When iommu itself is disabled in dts, we should
fallback to non-iommu buffer, check iommu parent
is meanless here.
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced
On 2021-06-08 18:18, Eero Lehtinen wrote:
This patch removes Panfrost spamming messages to syslog that causes a
poor performance and crashes of the Xfce desktop with a Amlogic S912
TV box. See the old bug in:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3143
There is certainly an argument
On 2021-06-03 10:17, Tvrtko Ursulin wrote:
Hi,
On 03/06/2021 09:40, Joonas Lahtinen wrote:
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
Hi all,
swiotlb_max_segment is a rather strange "API"
On 2021-06-02 09:02, Souptick Joarder wrote:
Kernel test robot throws below warning when CONFIG_OF
is not set.
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34:
warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable]
static const struct of_device_id
On 2021-05-17 10:27, Joerg Roedel wrote:
On Fri, Apr 30, 2021 at 08:20:10PM +0800, Kevin Tang wrote:
Cc Robin & Joerg
This is just some GPU internal MMU being used here, it seems. It doesn't
use the IOMMU core code, so no Ack needed from the IOMMU side.
Except the actual MMU being used is
On 2021-04-22 09:15, Claire Chang wrote:
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory
On 2021-04-22 09:15, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c |
On 2021-04-22 09:15, Claire Chang wrote:
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c|
On 2021-04-09 14:39, David Hildenbrand wrote:
On 09.04.21 15:35, Arnd Bergmann wrote:
On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand
wrote:
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
which
On 2021-03-16 15:38, Christoph Hellwig wrote:
[...]
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f1e38526d5bd40..996dfdf9d375dd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++
On 2021-03-31 16:32, Will Deacon wrote:
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure
On 2021-03-29 00:53, Bhaskar Chowdhury wrote:
s/Synopsys/Synopsis/ .two different places.
Erm, that is definitely not a typo... :/
..and for some unknown reason it introduce a empty line deleted and added
back.
Presumably your editor is configured to trim trailing whitespace on save.
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the author
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their
On 2021-01-05 13:46, Kevin Tang wrote:
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
v2:
- Use drm_xxx to replace all
Hi Mikko,
On 2021-02-08 16:38, Mikko Perttunen wrote:
To allow for more customized device tree bindings that point to IOMMUs,
allow manual specification of iommu_spec to of_dma_configure.
The initial use case for this is with Host1x, where the driver manages
a set of device tree-defined IOMMU
On 2021-02-03 02:01, Qiang Yu wrote:
On Tue, Feb 2, 2021 at 10:02 PM Lukasz Luba wrote:
On 2/2/21 1:01 AM, Qiang Yu wrote:
Hi Lukasz,
Thanks for the explanation. So the deferred timer option makes a mistake that
when GPU goes from idle to busy for only one poll periodic, in this
case
On 2021-02-04 07:29, Christoph Hellwig wrote:
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and
On 2020-12-22 19:54, isa...@codeaurora.org wrote:
On 2020-12-22 11:27, Robin Murphy wrote:
On 2020-12-22 00:44, Isaac J. Manjarres wrote:
The io-pgtable code constructs an array of init functions for each
page table format at compile time. This is not ideal, as this
increases the footprint
On 2020-12-22 19:49, isa...@codeaurora.org wrote:
On 2020-12-22 11:27, Robin Murphy wrote:
On 2020-12-22 00:44, Isaac J. Manjarres wrote:
The SMMU driver depends on the availability of the ARM LPAE and
ARM V7S io-pgtable format code to work properly. In preparation
Nit: we don't really
101 - 200 of 532 matches
Mail list logo
