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() do
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 to
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 failure.
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
---
Found by inspection while poking around TTM users.
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 2 +-
1 file changed, 1 insertion(+),
ought to happen so we use the core tile CLCD on some
other boards as well.
Barring custom FPGA images, I think V2P-CA9 *is* the only VExpress tile
implementing PL11x; all the more recent test chips had HDLCD instead.
Robin.
___
dri-devel mailing list
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
---
v2: Remember to iterate dma_len correctly as well.
drivers/gpu/drm/drm_
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.
This avoids a false negative on arm64 systems with an IOMMU.
Reported-by: Sinan Kaya
Signed-off-by: Robin Murphy
---
v2: Ex
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
Signed-off-by: Robin Murphy
---
v2: New
drivers/gpu/drm/radeon/radeon_ttm.c | 2
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
On 17/04/18 20:31, Linus Walleij wrote:
On Tue, Apr 17, 2018 at 3:12 PM, Robin Murphy 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 (4xA9)
that I am using. All the
false;
+ bool has_coretile_hdlcd = false;
+ bool mux_motherboard = true;
+ u32 val;
+ int ret;
+
+ /*
+* Check if we have a CLCD or HDLCD on the core tile by checking if a
+* CLCD or HDLCD is available in the root of the device tree.
+
due to
vexpress-v2p-ca15_a7.dts lacking any graph endpoint).
Config attached, just in case I'm missing something trivially dumb.
Robin.
Cc: Liviu Dudau
Cc: Pawel Moll
Cc: Robin Murphy
Acked-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
Anyway, the Mediatek-specific fix is in rc3 now - 1ff9b17cedb3
("iommu/mediatek: Limit the physical address in 32bit for v7s")
Robin.
> This reverts commit 76557391433c77d330cede1a531b358d2f90df66.
>
> Signed-off-by: Ulrich Hecht
> ---
> drivers/iommu/io-pgtable-arm-v7s.
in
many products. I'm guessing that's probably beyond the scope of this
binding, though.
Also does the size "full", "micro", "mini" matter to software?
If it means the user can look in sysfs to easily correlate logical ports
with physical connecto
mpatible = "samsung,exynos5-gsc",
> "samsung,exynos5250-gsc";
These should be the other way round - the most specific compatible
should come first, then the more general fallback afterwards.
(and similarly in all cases below)
Robin.
> reg =
nt gsc_probe(struct platform_device *pdev)
> dev_err(dev, "failed to init property list.\n");
> return ret;
> }
> + ctx->ippdrv.prop_list.rot_max = drv_data->rot_max;
>
> DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx
case.
Other than that, what kind of hardware operations would be needed
besides just updating the page tables from the CPU?
Domain attach/detach also require updating SMMU hardware state (and
possibly TLB maintenance), but don't logically require the master device
itself to be active
lating which clocks are necessary for a given
operation on a given system. That maintainability aspect is why we've
already nacked such a fine-grained approach in the past.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 13/02/18 12:54, Tomasz Figa wrote:
On Tue, Feb 13, 2018 at 9:00 PM, Robin Murphy wrote:
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
. For instance, msm doesn't enable its
gdsc power domains as irq-safe.
Is it something i am missing?
irq-safe would matter if there would exist a case when the call is
done from IRQ context and the power is off. As I explained in a), it
shouldn't happen.
Hi Robin, Will
Does adding pm_runti
#x27;s just that
for SMMU it needs to be implemented in a way that has zero impact on the
cases where it doesn't matter, because it's not viable to specialise
that driver for any particular IP implementation/use-case.
Robin.
*AFAICS it still makes some sense to have the get_supplier
failed at patch #6 with some
missing context (I tried checking drm-next for where rockchip_hdmi::hdmi
might have come from, but didn't see anything obvious)
Thanks,
Robin.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 5 -
1 file changed, 4 inser
this seems to imply the opposite of
what the patch actually does ;)
Robin.
re-use this phy_data pointer to hold the reference to the rockchip_hdmi
struct, similar to how meson-hdmi does it for example.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 9 +++-
is
configured out (and I believe introducing new uses of IS_ERR_OR_NULL()
is in general strongly discouraged.)
Robin.
+}
+
+static inline struct clk_bulk_data *devm_clk_bulk_alloc(struct device *dev,
+
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 a
h 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
changes in v2:
- phy: prevent overflow in tmdsclk calculation
as reported by Martin Ce
[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 wrote:
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
aring the VRAM as a CMA
region? That's certainly worked for stuff like local RAM on FPGA tiles
in the past, and I can't think offhand of any way in which VExpress is
wildly different (but I am of course open to being wrong...)
Robin.
Linus Walleij (4):
drm/pl111: Make the de
On 02/03/18 12:37, Linus Walleij wrote:
On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy 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 will need to figure out a way to work
nimising area and
stage-1-only isn't an option.
Robin.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 641aaf0f1b81..e2c49e583d8d 100644
--- a/include/linux/iommu.h
+++ b/i
efine IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS BIT(1)
#define IO_PGTABLE_QUIRK_TLBI_ON_MAPBIT(2)
#define IO_PGTABLE_QUIRK_ARM_MTK_4GBBIT(3)
#define IO_PGTABLE_QUIRK_NO_DMA BIT(4)
+ #define IO_PGTABLE_QUIRK
y the shortcomings of the
DMA API are for these use-cases, and extend it to address them properly.
Robin.
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
@@ -196,6 +202,13 @@ drm_flush_sg(struct sg_table *st)
for_each_sg_page(
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)
S
once, during
initialisation when we have the source data directly to hand. Just pass
data->clks into arm_smmu_init_clks() as an additional argument.
Otherwise, I think this looks reasonable; it's about as unobtrusive as
it's going to get.
Ro
much.
I'd also naively expect that anything this device was the last consumer
off would get turned off by core code anyway once it's removed, but
maybe things aren't that slick; I dunno :/
Robin.
+
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
smmu.
Don't we need to balance this with a device_link_del() in .remove_device
(like exynos-iommu does)?
Robin.
Signed-off-by: Sricharan R
---
drivers/iommu/arm-smmu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
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
Finally add the device link between the master device and
smmu, so that the smmu gets
parently. That particular effort ground to a halt upon realising
the number of the IOMMU and DRM drivers I'd have no way of testing - if
you're interested I've dug out the diff below from an old
work-in-progress branch (which probably doesn't even compile).
Robin.
>
>
of
the dmac_* cache maintenance functions by ARM drivers, I don't think
bringing all of that back is a good way to go - Personally I'd much
rather see several dozen lines of very similar looking (other than
highmem and outer cache stuff) arch-private code if it maintains a
robust and clear
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.
Signed-off-by: Robin Murphy
---
Hi dri-devel,
This is an empirica
On 16/03/16 19:14, Russell King - ARM Linux wrote:
> On Wed, Mar 16, 2016 at 04:28:25PM +0100, Daniel Vetter wrote:
>> On Wed, Mar 16, 2016 at 02:57:49PM +0000, Robin Murphy wrote:
>>> In the absence of an fb_mmap callback, the fbdev code falls back to a
>>> naive imple
r their usage. But new drivers should not use it anymore.
I'd certainly be keen for it to be gone ASAP, since I'm seeing
increasing demand for supporting multiple IOMMU drivers, and this is the
last bus-based thing standing in the way of that.
Thanks,
Robin.
[1]
https://git
break things? I posted a fix recently[1] having hit this problem with
segment_boundary_mask in IOMMU code.
> +
> +static inline int dma_set_max_seg_count(struct device *dev,
> + unsigned int count)
> +{
> + if (dev->dma_parms) {
> +
make the
field signed? That seems a bit bad as well...
Is that a problem? Signed->unsigned conversion is always well-defined
(6.3.1.3 again), since it doesn't depend on how the signed type
represents negatives.
Robin.
ur of
iommu_unmap() and fix up all the other drivers which behave still
differently (the statement in the commit message is incorrect -
io-pgtable-arm-v7s still splits; at least exynos fails the unmap entirely.)
Thanks,
Robin.
messing
with it any more.
Thanks,
Robin.
+
+ return ret;
}
static void rockchip_drm_platform_remove(struct platform_device *pdev)
ases in both sets of selftests,
so I think there's still a bit more to remove yet :)
Thanks,
Robin.
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 06ffc683b28fee..7e37459cd28332 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/i
es.
Otherwise userspace is still able to allocate massive amounts of memory
and incur some of the associated side-effects of that, it just doesn't
get to keep said memory for very long :)
Thanks,
Robin.
+
return dma_obj;
error:
kfree(dma_obj);
re
On 02/05/2025 10:59 am, Jens Wiklander wrote:
Export the global variable dma_contiguous_default_area so
dev_get_cma_area() can be called a module.
What dma_map_ops implementation is in a module? Without any other
context, I can't help thinking this smells of something sketchy.
Thanks,
to_page(pa), size, 0);
Where does "pa" come from here (i.e. what's the provenance of the
initial "paddr" passed to tee_protmem_static_pool_alloc())? In general
we can't call {phys,pfn}_to_page() an arbitrary addresses without
checking pfn_valid() first. A bogu
t the
very least, could the TEE delegation not be composed on top of the
existing CMA heap allocator?
Thanks,
Robin.
+
+ cma_release(cma, page, shm->size / PAGE_SIZE);
+#endif
+ } else if (shm->flags & TEE_SHM_DMA_BUF) {
struct tee_shm_dmabuf_ref *ref;
(!selftest_running);
+ WARN_ON(!selftest_running && !(cfg->quirks &
IO_PGTABLE_QUIRK_NO_WARN_ON));
If we are going to have this as a general mechanism then the selftests
should use it as well.
Thanks,
Robin.
return -EEXIST;
}
@@ -649,8 +649,10 @
= dev;
+ if (dev)
+ teedev->dev.dma_mask = dev->dma_mask;
...for instance, I don't see any obvious guarantee that "dev" can't go
away during the lifetime of "teedev" and leave this pointer dangling.
Thanks,
Robin.
teedev->dev.devt = MKDEV(MAJOR(tee_devt), teedev->id);
,
or...
Thanks,
Robin.
Let's provide an accessor for that region.
Signed-off-by: Maxime Ripard
---
include/linux/dma-direct.h | 2 ++
kernel/dma/direct.c| 8
2 files changed, 10 insertions(+)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-dire
On 2025-03-10 4:28 pm, Maxime Ripard wrote:
On Mon, Mar 10, 2025 at 02:56:37PM +, Robin Murphy wrote:
On 2025-03-10 12:06 pm, Maxime Ripard wrote:
Consumers of the direct DMA API will have to know which region their
device allocate from in order for them to charge the memory allocation
in
controlled by
userspace, attempting to map over a region that has not yet been
unmapped is an error. But not something that should spam dmesg.
Now that there is a quirk, we can also drop the selftest_running
flag, and use the quirk instead for selftests.
Signed-off-by: Rob Clark
Acked-by: Robin Murphy
dor Specific Information: ID=0001 Rev=1 Len=010
Capabilities: [150] Advanced Error Reporting
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu
--
Robin Hugh Johnson
E-Mail : robbat2 at orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.rob
Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
constants scattered in the kernel already used to detect QEMU.
They are defined in the QEMU codebase per docs/specs/pci-ids.txt.
Signed-off-by: Robin H. Johnson
---
This change prompted by a near-miss in the review of
On Wed, Nov 30, 2016 at 10:24:59PM +0100, Vlastimil Babka wrote:
> [add more CC's]
>
> On 11/30/2016 09:19 PM, Robin H. Johnson wrote:
> > Somewhere in the Radeon/DRM codebase, CMA page allocation has either
> > regressed in the timeline of 4.5->4.9, and/or the
3x 24" monitors
> >> > w/ 9
> >> > virtual desktops per monitor).
> >> So IIUC, except the messages, everything actually works fine?
> > There's high kernel CPU usage that seems to roughly correlate with the
> > messages, but I can't yet tel
Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
constants scattered in the kernel already used to detect QEMU.
They are defined in the QEMU codebase per docs/specs/pci-ids.txt.
Signed-off-by: Robin H. Johnson
Reviewed-by: Takashi Iwai
Reviewed-by: Gerd Hoffmann
TOR:16:HDMI-A-1]
[drm:radeon_process_i2c_ch], hw_i2c error
[drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:16:HDMI-A-1]
disconnected
[1] yes I know about the bonding error, that's a separate issue I need
to mail to LKML/netdev.
--
On Wed, Nov 06, 2013 at 12:16:31PM -0500, Alex Deucher wrote:
> On Wed, Nov 6, 2013 at 12:14 PM, Robin H. Johnson
> wrote:
> > (Resending to dri-devel because the first one didn't make it).
> >
> > I apologize for not sending this sooner, but I wanted to be reall
On Wed, Nov 06, 2013 at 05:37:11PM -0500, Jerome Glisse wrote:
> On Wed, Nov 06, 2013 at 05:48:55PM +0000, Robin H. Johnson wrote:
> > On Wed, Nov 06, 2013 at 12:16:31PM -0500, Alex Deucher wrote:
> > > On Wed, Nov 6, 2013 at 12:14 PM, Robin H. Johnson
> > > wrote
On Wed, Nov 06, 2013 at 05:43:45PM -0500, Jerome Glisse wrote:
> On Wed, Nov 06, 2013 at 05:48:55PM +0000, Robin H. Johnson wrote:
> > On Wed, Nov 06, 2013 at 12:16:31PM -0500, Alex Deucher wrote:
> > > On Wed, Nov 6, 2013 at 12:14 PM, Robin H. Johnson
> > > wrote
--r-- 1 root root 24 Jul 3 2011 /etc/modprobe.d/radeon.conf
options radeon hw_i2c=1
So that answers that. I'd forgotten I even had that set.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2 at gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Hi Sam,
On 2023-01-08 10:29, Sam Ravnborg wrote:
Hi Robin.
On Sat, Jan 07, 2023 at 10:02:38PM +0100, Miguel Ojeda wrote:
On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint
wrote:
>
> Introduce backlight_get_brightness() to simplify logic
> and avoid direct
Hi Thomas,
Thank you for submitting your patch, it looks fine to me.
Reviewed-by: Robin van der Gracht
On Wed, 13 Mar 2024 16:45:00 +0100
Thomas Zimmermann wrote:
> Replace the use of struct backlight_properties.fb_blank with a
> call to backlight_get_brightness(). The helper impleme
acklight_ops.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Robin van der Gracht
> ---
> drivers/auxdisplay/ht16k33.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
> index a90430b7d07ba..0a858db32486b 1006
On 2023-11-15 11:19, Thomas Zimmermann wrote:
The ht16k33 driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Cc: Robin van der Gracht
systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Cc: Robin van der Gracht
---
drivers/auxdisplay/Kconfig | 5 +
drivers/auxdisplay/ht16k33.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/auxdisplay/Kconfig b
501 - 571 of 571 matches
Mail list logo
