Re: [PATCH v3 5/7] drm/sun4i: Rely on dma interconnect for our RAM offset

On 13/02/2019 15:41, Maxime Ripard wrote: Hi Robin, Thanks for your feedback! On Tue, Feb 12, 2019 at 06:46:40PM +, Robin Murphy wrote: On 11/02/2019 15:02, Maxime Ripard wrote: Now that we can express our DMA topology, rely on those property instead of hardcoding an offset from

Re: [PATCH v3 2/7] dt-bindings: bus: Add binding for the Allwinner MBUS controller

On 11/02/2019 15:02, Maxime Ripard wrote: The MBUS controller drives the MBUS that other devices in the SoC will use to perform DMA. It also has a register interface that allows to monitor and control the bandwidth and priorities for masters on that bus. Signed-off-by: Maxime Ripard ---

Re: [PATCH v3 5/7] drm/sun4i: Rely on dma interconnect for our RAM offset

On 11/02/2019 15:02, Maxime Ripard wrote: Now that we can express our DMA topology, rely on those property instead of hardcoding an offset from the dma_addr_t which wasn't really great. We still need to add some code to deal with the old DT that would lack that property, but we move the offset

Re: [PATCH v3 4/7] of: address: Add support for the parent DMA bus

On 11/02/2019 15:02, Maxime Ripard wrote: Some SoCs have devices that are using a separate bus from the main bus to perform DMA. These buses might have some restrictions and/or different mapping than from the CPU side, so we'd need to express those using the usual dma-ranges, but using a

Re: [PATCH v3 3/7] of: address: Add parent pointer to the __of_translate_address args

On 11/02/2019 15:02, Maxime Ripard wrote: The __of_translate_address function is used to translate the device tree addresses to physical addresses using the various ranges property to create the offset. However, it's shared between the CPU addresses (based on the ranges property) and the DMA

Re: [PATCH 02/10] arm64/iommu: don't remap contiguous allocations for coherent devices

On 08/12/2018 17:36, Christoph Hellwig wrote: There is no need to have an additional kernel mapping for a contiguous allocation if the device already is DMA coherent, so skip it. FWIW, the "need" was that it kept the code in this path simple and the mapping behaviour consistent with the

Re: [PATCH v3 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range

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

Re: [PATCH v3 1/9] mm: Introduce new vm_insert_range API

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

Re: [PATCH v3 1/9] mm: Introduce new vm_insert_range API

On 06/12/2018 18:39, Souptick Joarder wrote: Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating a new

Re: [PATCH v3 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range

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: Heiko Stuebner --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++-- 1 file

Re: [PATCH] of/device: add blacklist for iommu dma_ops

Hi Rob, On 01/12/2018 16:53, Rob Clark wrote: This solves a problem we see with drm/msm, caused by getting iommu_dma_ops while we attach our own domain and manage it directly at the iommu API level: [0038] user address but active_mm is swapper Internal error: Oops: 9605

Re: [PATCH v3 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg*

On 29/11/2018 19:57, Tomasz Figa wrote: On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse wrote: On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote: On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote: On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote: Maybe the thing we

Re: [PATCH] drm/panel: Add simple panel mode for the ARM 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 insertions(+) diff

Re: [PATCH] drm/exynos: Use selected dma_dev default iommu domain instead of a fake one

. 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

Re: [PATCH] gpu: host1x: Remove redundant of_dma_configure() call

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

[PATCH] gpu: host1x: Remove redundant of_dma_configure() call

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 *believe* my

Re: [PATCH v3] of/platform: initialise AMBA default DMA masks

"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 a5516219

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

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

Re: [PATCH 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

On 08/08/18 23:47, Jordan Crouse wrote: Add the nodes to describe the Adreno GPU and GMU devices. Signed-off-by: Jordan Crouse --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++ 1 file changed, 121 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

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

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

On 27/07/18 15:10, Dmitry Osipenko wrote: On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote: On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote: On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote: The proposed solution adds a new option to the base device driver

Re: [PATCH 1/3 v4] ARM: dts: Modernize the Vexpress PL111 integration

On 13/07/18 10:50, Sudeep Holla wrote: It doesn't work. This change is breaking the working CLCD on the models. I just tested and CLCD driver returns It even fails to initialize CLCD on my TC2. clcd-pl11x 1c1f.clcd: PL111 designer 41 rev1 at 0x1c1f clcd-pl11x: probe of 1c1f.clcd

Re: [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

gain 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 (!tdev->func->iommu_bit)

Re: [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()

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 ++-- 1

Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

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

Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

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

Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

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

Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

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 transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed

Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

On 30/05/18 09:03, Thierry Reding wrote: From: Thierry Reding Implement this function to enable drivers from detaching from any IOMMU domains that architecture code might have attached them to so that they can take exclusive control of the IOMMU via the IOMMU API. Signed-off-by: Thierry

Re: [PATCH v2 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed

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

Re: [PATCH v2 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed

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 some cases lead to a stall if the irq is triggered while the vop driver still has it disabled, but the

Re: [PATCH v3 1/3] drm/prime: Iterate SG DMA addresses separately

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

Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 17/05/18 14:22, Sinan Kaya wrote: A host bridge is allowed to remap BAR addresses using _TRA attribute in _CRS windows. pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] (bus address [0x0010-0x1fff]) pci :02:00.0: reg 0x10: [mem

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

On 16/05/18 19:23, Sinan Kaya wrote: A host bridge is allowed to remap BAR addresses using _TRA attribute in _CRS windows. pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] (bus address [0x0010-0x1fff]) pci :02:00.0: reg 0x10: [mem

Re: [RFC PATCH 01/10] devfreq: rockchip-dfi: Move GRF definitions to a common place.

Hi Enric, On 14/05/18 22:16, Enric Balletbo i Serra wrote: Some rk3399 GRF (Generic Register Files) definitions can be used for different drivers. Move these definitions to a common include so we don't need to duplicate these definitions. Signed-off-by: Enric Balletbo i Serra

Re: [PATCH v1 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters

On 04/05/18 09:15, Satendra Singh Thakur wrote: To avoid duplicate logic for the same Reviewed-by: Robin Murphy <robin.mur...@arm.com> Please read section 13 of Documentation/process/submitting-patches.rst for what this tag means; specifically, it is definitely not "this guy re

Re: [PATCH 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters

On 03/05/18 09:39, Satendra Singh Thakur wrote: To avoid duplicate logic for the same Signed-off-by: Satendra Singh Thakur Cc: Madhur Verma Cc: Hemanshu Srivastava --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9

Re: [PATCH 2/2] ARM: dts: Modernize the Vexpress PL111 integration

t 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 <liviu.du...@arm.com> Cc: Mali DP Maintainers <mal...@foss.arm.co

Re: [PATCH 1/2 v4] drm/pl111: Support the Versatile Express

On 27/04/18 19:51, Linus Walleij wrote: On Fri, Apr 27, 2018 at 5:02 PM, Robin Murphy <robin.mur...@arm.com> 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

[PATCH v3 3/3] drm/radeon: Allow dma_map_sg() coalescing

com> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- v3: No change drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 8689fcca051c..7c099192c7fa 1006

[PATCH v3 1/3] drm/prime: Iterate SG DMA addresses separately

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 <christian.koe...@amd.com> Signed-off-by: Robin Murphy <robin.mur...@arm.

[PATCH v3 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

-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 <ok...@codeaurora.org> Reviewed-by: Christian König <christian.koe...@amd.com> Signed-off-by: Robin

Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

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), which

Re: [PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

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

Re: [VERY RFC 0/2] iommu: optionally skip attaching to a DMA domain

On 11/04/18 19:55, Jordan Crouse wrote: I've been struggling with a problem for a while and I haven't been able to come up with a clean solution. Rob convinced me to stop complaining and do _something_ and hopefully this can spur a good discussion. The scenario is basically this: The MSM GPU

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

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

Re: [PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

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, 2018 at 12:10:48PM +0200, Thierry Reding wrote: From: Thierry Reding The

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

d list will have the effect of just not syncing the tail end of the buffer, which is clearly bad. Robin. /Thomas On 04/13/2018 05:14 PM, Robin Murphy wrote: dma_unmap_sg() should be called with the same number of entries originally passed to dma_map_sg(), not the number it returned, which may be

Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

On 25/04/18 21:44, Sinan Kaya wrote: On 4/17/2018 5:13 PM, Sinan Kaya wrote: Tested-by: Sinan Kaya using QDF2400 and XFX Vega64 GPU for the first two patches. ./builddir/tests/amdgpu/amdgpu_test -s 1 Suite: Basic Tests Test: Userptr Test ...passed Userptr Test

Re: [PATCH 1/2 v4] drm/pl111: Support the Versatile Express

On 26/04/18 08:52, Linus Walleij wrote: On Mon, Apr 23, 2018 at 2:04 PM, Robin Murphy <robin.mur...@arm.com> 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

Re: [PATCH 1/2 v4] drm/pl111: Support the Versatile Express

any graph endpoint). Config attached, just in case I'm missing something trivially dumb. Robin. Cc: Liviu Dudau <liviu.du...@arm.com> Cc: Pawel Moll <pawel.m...@arm.com> Cc: Robin Murphy <robin.mur...@arm.com> Acked-by: Eric Anholt <e...@anholt.net> Signed-off-by: Linus

Re: [PATCH 1/2 v3] drm/pl111: Support the Versatile Express

On 18/04/18 09:52, Linus Walleij wrote: The Versatile Express uses a special configuration controller deeply embedded in the system motherboard FPGA to multiplex the two to three (!) display controller instances out to the single SiI9022 bridge. Set up an extra file with the logic to probe to

Re: [PATCH 1/2 v2] drm/pl111: Support the Versatile Express

On 17/04/18 20:31, Linus Walleij wrote: On Tue, Apr 17, 2018 at 3:12 PM, Robin Murphy <robin.mur...@arm.com> wrote: On 17/04/18 13:32, Linus Walleij wrote: [...] Unfortunately there is just one single vexpress core tile in the upstream kernel that define a CLCD controller, the CA9

Re: [PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

On 17/04/18 17:29, Christian König wrote: Am 17.04.2018 um 17:58 schrieb Robin Murphy: 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

[PATCH v2 3/3] drm/radeon: Allow dma_map_sg() coalescing

() 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 <christian.koe...@amd.com> Signed-off-by: Robin Murphy <robin.mur...@arm.co

[PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

-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. This avoids a false negative on arm64 systems with an IOMMU. Reported-by: Sinan Kaya <ok...@codeaurora.org> Signed-off-by:

[PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

he 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. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- v2: Remember to iterate dma_len correctly as well.

Re: [PATCH 1/2 v2] drm/pl111: Support the Versatile Express

On 17/04/18 13:32, Linus Walleij wrote: [...] Unfortunately there is just one single vexpress core tile in the upstream kernel that define a CLCD controller, the CA9 (4xA9) that I am using. All the others just use the MB CLCD. I am thinking there is some never finished DTS upstreaming here that

[PATCH] drm/vmwgfx: Fix scatterlist unmapping

to be correct, and it's trivially easy to fix by just restoring the SG table state before the call instead of afterwards. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- Found by inspection while poking around TTM users. drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 2 +- 1 file changed, 1 ins

Re: [PATCH 2/2] drm/amdgpu: Allow dma_map_sg() coalescing

On 11/04/18 19:28, Christian König wrote: Am 11.04.2018 um 19:11 schrieb Robin Murphy: 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 f

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On 12/04/18 10:42, Christian König wrote: Am 12.04.2018 um 08:26 schrieb Christoph Hellwig: On Wed, Apr 11, 2018 at 01:03:59PM +0100, 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

Re: [PATCH 1/2] drm/prime: Iterate SG DMA addresses separately

schrieb Robin Murphy: 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 implies. drm_prime_sg_to_page_addr_arrays(

Re: [1/2] drm/prime: Iterate SG DMA addresses separately

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

[PATCH 1/2] drm/prime: Iterate SG DMA addresses separately

ngth. All we need is a separate scatterlist cursor to iterate the DMA addresses separately from the CPU addresses. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- 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 i

[PATCH 2/2] drm/amdgpu: Allow dma_map_sg() coalescing

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 <robin.mur...@arm.com> --- drivers/gpu/drm/amd/amdgpu/amdg

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

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 especially

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

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 especially for systems with IOMMU. So why not fix said code? It's clearly not a real

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 12/03/18 10:41, Roger Quadros wrote: [...] @@ -0,0 +1,75 @@ +USB Connector += + +USB connector node represents physical USB connector. It should be +a child of USB interface controller. + +Required properties: +- compatible: describes type of the connector, must be one of: +

Re: [PATCH 02/14] iommu/arm-smmu: Add support for TTBR1

On 21/02/18 22:59, Jordan Crouse wrote: Allow a SMMU device to opt into allocating a TTBR1 pagetable. The size of the TTBR1 region will be the same as the TTBR0 size with the sign extension bit set on the highest bit in the region unless the upstream size is 49 bits and then the sign-extension

Re: [PATCH 01/14] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1

On 21/02/18 22:59, Jordan Crouse wrote: Add a new domain attribute to enable the TTBR1 pagetable for drivers and devices that support it. This will enabled using a TTBR1 (otherwise known as a "global" or "system" pagetable for devices that support a split pagetable scheme for switching

Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express

On 02/03/18 12:37, Linus Walleij wrote: On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.mur...@arm.com> wrote: On 02/03/18 09:09, Linus Walleij wrote: Also the Versatile Express CLCD on the motherboard has a dedicated video memory, and cannot use CMA (ha! complex!) and I wil

Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express

Hi Linus, On 02/03/18 09:09, Linus Walleij wrote: This is the base for finally getting RealView and Versatile Express supported in the PL111 DRM driver. We have then moved all the way up from the first ARM Integrator versions to the last Versatile Express reference designs using PL111. After

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[sorry, I had intended to reply sooner but clearly forgot] On 16/02/18 00:13, Tomasz Figa wrote: On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy <robin.mur...@arm.com> wrote: On 15/02/18 04:17, Tomasz Figa wrote: [...] Could you elaborate on what kind of locking you are concerned about

Re: [PATCH v2 0/8] drm/rockchip: hdmi support for rk3328

the separate phy and drm trees once deemed ready. So patches 1+2 are expected to go through the phy-tree and the rest should go through the drm tree. For patches 2, 3, 4, 6, 7, 8, Tested-by: Robin Murphy <robin.mur...@arm.com> changes in v2: - phy: prevent overflow in tmdsclk calcu

Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions

Hi Marek, On 20/02/18 09:36, Marek Szyprowski wrote: Hi Robin, On 2018-02-19 17:29, Robin Murphy wrote: Hi Maciej, On 19/02/18 15:43, Maciej Purski wrote: When a driver is going to use clk_bulk_get() function, it has to initialize an array of clk_bulk_data, by filling its id fields. Add

Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions

Hi Maciej, On 19/02/18 15:43, Maciej Purski wrote: When a driver is going to use clk_bulk_get() function, it has to initialize an array of clk_bulk_data, by filling its id fields. Add a new function to the core, which dynamically allocates clk_bulk_data array and fills its id fields. Add

Re: [PATCH v2 7/8] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object

On 16/02/18 20:41, Heiko Stuebner wrote: When using special phy handling operations we'll often need access to the rockchip_hdmi struct. As the chip-data that occupies the phy_data pointer initially gets assigned to the rockchip_hdmi struct we can not s/not/now/ (or s/not//) ? Again, this

Re: [PATCH v2 4/8] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching

Hi Heiko, On 16/02/18 20:41, Heiko Stuebner wrote: So far we always encountered socs with 2 output crtcs needing the driver to tell the hdmi block which output to connect to. But there also exist socs with only one crtc like the rk3228, rk3328 and rk3368. So adapt the register field to simply

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On 15/02/18 04:17, Tomasz Figa wrote: [...] Could you elaborate on what kind of locking you are concerned about? As I explained before, the normally happening fast path would lock dev->power_lock only for the brief moment of incrementing the runtime PM usage counter. My bad, that's not even

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On 14/02/18 10:33, Vivek Gautam wrote: On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa wrote: Adding Jordan to this thread as well. On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam wrote: Hi Tomasz, On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa

Re: [PATCH v7 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers

On 13/02/18 12:54, Tomasz Figa wrote: On Tue, Feb 13, 2018 at 9:00 PM, Robin Murphy <robin.mur...@arm.com> wrote: On 13/02/18 07:44, Tomasz Figa wrote: Hi Vivek, On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam <vivek.gau...@codeaurora.org> wrote: The device link allows the pm fram

Re: [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On 13/02/18 08:24, Tomasz Figa wrote: Hi Vivek, Thanks for the patch. Please see my comments inline. On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam wrote: From: Sricharan R The smmu device probe/remove and add/remove master device

Re: [PATCH v7 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers

On 13/02/18 07:44, Tomasz Figa wrote: Hi Vivek, On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam wrote: The device link allows the pm framework to tie the supplier and consumer. So, whenever the consumer is powered-on the supplier is powered-on first. There are

Re: [PATCH v6 4/6] iommu/arm-smmu: Add the device_link between masters and smmu

On 02/02/18 05:40, Sricharan R wrote: Hi Robin/Vivek, On 2/1/2018 2:23 PM, Vivek Gautam wrote: Hi, On 1/31/2018 6:39 PM, Robin Murphy wrote: On 19/01/18 11:43, Vivek Gautam wrote: From: Sricharan R <sricha...@codeaurora.org> Finally add the device link between the master device an

Re: [PATCH v6 4/6] iommu/arm-smmu: Add the device_link between masters and smmu

On 19/01/18 11:43, Vivek Gautam wrote: From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime enabled/disabled only when the master needs it. This is done from add_device callback which gets called once when the

Re: [PATCH v6 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On 19/01/18 11:43, Vivek Gautam wrote: From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those

Re: [PATCH v6 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

On 19/01/18 11:43, Vivek Gautam wrote: From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional dependencies, so that the iommu gets powered when the master device

Re: [PATCH 3/5] drm: add ARM64 flush implementations

On 24/01/18 12:36, Russell King - ARM Linux wrote: On Wed, Jan 24, 2018 at 12:00:59PM +, Robin Murphy wrote: On 24/01/18 02:56, Gurchetan Singh wrote: This patch uses the __dma_map_area function to flush the cache on ARM64. v2: Don't use DMA API, call functions directly (Daniel) Signed

Re: [PATCH 3/5] drm: add ARM64 flush implementations

On 24/01/18 02:56, Gurchetan Singh wrote: This patch uses the __dma_map_area function to flush the cache on ARM64. v2: Don't use DMA API, call functions directly (Daniel) Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/drm_cache.c | 13 + 1 file

Re: [RFC 11/11] hack: Revert "iommu/io-pgtable: Sanitise map/unmap addresses"

Hi Ulrich, On 29/09/17 14:09, Ulrich Hecht wrote: > This check breaks DRM initialization on Acer Chromebook R13, paddr is above > 4GB. Haven't looked into this yet. I think you mean "DRM initialisation was happening to still work with silently truncated addresses..." ;) Anyway, the

Re: [PATCH v3 3/6] drm/exynos/gsc: Add hardware rotation limits

On 08/09/17 07:02, Hoegeun Kwon wrote: > The gscaler has hardware rotation limits that need to be hardcoded > into driver. Distinguish them and add them to the property list. > > The hardware rotation limits are related to the cropped source size. > When swap occurs, use rot_max size instead of

Re: [PATCH v3 2/6] ARM: dts: exynos: Add clean name of compatible.

On 08/09/17 07:02, Hoegeun Kwon wrote: > Exynos 5250 and 5420 have different hardware rotation limits. However, > currently it uses only one compatible - "exynos5-gsc". Since we have > to distinguish between these two, we add different compatible. > > Signed-off-by: Hoegeun Kwon

Re: new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

Hi Christoph, On 20/06/17 13:41, Christoph Hellwig wrote: > On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote: >> I plan to create a new dma-mapping tree to collect all this work. >> Any volunteers for co-maintainers, especially from the iommu gang? > > Ok, I've created the new

Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

he 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 <robin.mur...@arm.com> > Signed-off-

Re: [PATCH 16/44] arm64: remove DMA_ERROR_CODE

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

Re: [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

Hi Christoph, On 08/06/17 14:25, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu > driver already implements a proper ->mapping_error method, so it's only > using the value internally. Add a new local define using the value > that arm64 which

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

On 10/03/17 10:31, Brian Starkey wrote: > Hi, > > On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote: >> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: > > [snip] > >>> >>> For me those patches are going in the right direction. >>> >>> I still have few questions: >>> - since

[PATCH] drm: hdlcd: Work properly in big-endian mode

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

[PATCH] drm: hdlcd: Work properly in big-endian mode

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. Fortu

[PATCH] drm: hdlcd: Work properly in big-endian mode

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: Robin

<    1   2   3   4   5   6   >