0xff90 0x0 0x3efc>;
+ reg = <0x0 0xff90 0x0 0x2000>, <0x0 0xff902000 0x0 0x1000>;
Doesn't the second range still need to be shorter than 0xf00 to avoid
overlapping the IOMMU?
Robin.
interrupts = ;
assigned-c
On 2022-09-15 17:53, Hugh Cole-Baker wrote:
On 15 Sep 2022, at 15:40, Robin Murphy wrote:
On 2021-10-19 22:58, Hugh Cole-Baker wrote:
Define the memory region on RK3399 VOPs containing the gamma LUT at
base+0x2000.
Signed-off-by: Hugh Cole-Baker
---
Changes from v1: no changes in this
ith that being wrong - dma_map_single() cleans the
cache, coherent DMA write hits the still-present cache lines,
dma_unmap_single() invalidates the cache, and boom, the data is gone and
you read back the previous content of the buffer that was cleaned out to
DRAM beforehand.
Robin.
--Sean
diff
less and until anyone
actually demands to be able to do cross-endian post-mortem GPU
debugging, the realistic extent of the complexity in Mesa is that it
doesn't recognise the foreign dump format and gives up, which I assume
is already implemented :)
Cheers,
Robin.
Steve
On Tue,
On 25/08/2022 12:40 pm, Sascha Hauer wrote:
On Wed, Aug 24, 2022 at 05:07:50PM +0100, Robin Murphy wrote:
On 2022-08-22 16:20, Sascha Hauer wrote:
The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a
t also warrant backporting to stable. I believe Carsten's
stuck on an older kernel thanks to constraints of the rest of that
project ;)
Cheers,
Robin.
involve another goto. Oh well, at
least it's robust...
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu
ome across a system with more than
one Mali in it ;)
And FWIW note that "GPU" really is the specific hardware name of that
IRQ output; it's not just a generic fill-in for "the one that isn't the
Job or MMU IRQ".
Thanks,
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
, you said *upstream*? Are there oh no
Heh, fear not - I'm only thinking of the "Juno board with FPGA
prototyping stack" setup, and the people using those in anger are all
working on some other driver anyway ;)
Robin.
___
dri-dev
. Are you sure it's okay to make the change you're
proposing?
Various code uses tricks like just iterating the mapped list until the
first segment with zero sg_dma_len(). Others may well simply have bugs.
Robin.
Anyway, due to the time of year and all, I'd like to ask yo
on my box at least). With panfrost on RK3399 I do see the
supply voltage scaling accordingly, but I don't know my way around
devfreq well enough to know what matters in the difference :/
Thanks,
Robin.
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/lima/Kconfig| 1 +
On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
Hi Robin,
On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy wrote:
Hi Martin,
On 2019-12-27 5:37 pm, Martin Blumenstingl wrote:
Most platforms with a Mali-400 or Mali-450 GPU also have support for
changing the GPU clock frequency. Add devfreq
On 2019-12-31 2:17 pm, Martin Blumenstingl wrote:
Hi Robin,
On Mon, Dec 30, 2019 at 1:47 AM Robin Murphy wrote:
On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
Hi Robin,
On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy wrote:
Hi Martin,
On 2019-12-27 5:37 pm, Martin Blumenstingl wrote
On 2019-12-31 4:47 pm, Martin Blumenstingl wrote:
Hi Robin,
On Tue, Dec 31, 2019 at 5:40 PM Robin Murphy wrote:
On 2019-12-31 2:17 pm, Martin Blumenstingl wrote:
Hi Robin,
On Mon, Dec 30, 2019 at 1:47 AM Robin Murphy wrote:
On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
Hi Robin
dev_pm_opp_of_add_table(), which
means having a check for "is devfreq enabled" that is not tied to
dev_pm_opp_of_add_table() makes things easier).
Hmm, what about cases like the SCMI DVFS protocol where the OPPs are
dynamically discovered rather than statically defined in DT?
Robin.
Sig
[ +Sudeep ]
On 08/01/2020 12:38 pm, Martin Blumenstingl wrote:
Hi Robin,
On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy wrote:
On 07/01/2020 11:06 pm, Martin Blumenstingl wrote:
Decouple the check to see whether we want to enable devfreq for the GPU
from dev_pm_opp_set_regulators(). This is
e that just dropping it from panfrost unless and until
it proves necessary is probably preferable to adding more logic and
inscrutable register-magic.
Robin.
Steve
So the GPU is probed, but there's an issue when powering up the STACK,
not
quite sure why, I'll try to
As brought up on IRC, logging a vague and unattributed message for a
normal and expected operation looks a bit spammy. Use a dev_* variant
to clarify it as a driver message, and downgrade the level to debug to
avoid cluttering up end users' logs.
Signed-off-by: Robin Murphy
---
drivers/gp
uld try hooking up the GPU SMMU on my Juno to serve as
a cheeky DMA-API-mishap detector...)
Robin.
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 20
1 file cha
i
Cc: Robin Murphy
Fixes: f4a3c6a44b35 ("drm/panfrost: Disable PM on probe failure")
I think that commit was right at the time, but actually we missed
reordering the cleanup path to match the change in 635430797d3f.
Otherwise, though,
Reviewed-by: Robin Murphy
---
drivers/g
this actually means, but
the dissonance is enough to make my reviewer-sense tingle ;)
Robin.
+ if (ret < 0) \
+ return ret; \
+ }
t;mem_iface_clk"? I would have naively assumed
something like "core" would be most logical.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
gistration call, and the standard removal call
just automatically cleaned up an energy model as well if one was present.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
kernel warnings and further faults.
Either way,
Reviewed-by: Robin Murphy
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfros
something apparently deadlocked because some weird SCMI
mailbox errors and continual RCU stalls in __switch_to() followed. Those
exact symptoms are probably particular to the Juno FPGA setup, but it
does seem to point to the GPU getting into an unhappy state.
Robin.
Reported-by: Icecream95
Fixes
obably want to
double-check the domain type as well.
Robin.
if (!tdev->func->iommu_bit)
return;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 16/09/2019 16:57, Thierry Reding wrote:
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since No
currently pass. This causes the code to directly jump
into PCI's parent node when checking for 'dma-ranges' and misses
whatever was set there.
To address this I create a new API in OF - inspired from Robin Murphys
original proposal[2] - which accepts a bus DT node as it's input i
On 25/09/2019 17:16, Rob Herring wrote:
On Wed, Sep 25, 2019 at 10:30 AM Nicolas Saenz Julienne
wrote:
On Wed, 2019-09-25 at 16:09 +0100, Robin Murphy wrote:
On 25/09/2019 15:52, Nicolas Saenz Julienne wrote:
On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
On Tue, Sep 24, 2019 at 1
On 2019-09-26 11:44 am, Nicolas Saenz Julienne wrote:
Robin, have you looked into supporting multiple dma-ranges? It's the
next thing
we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in
the
works already.
Multiple dma-ranges as far as configuring inbound
CC: Liviu Dudau
CC: Sudeep Holla
CC: Lorenzo Pieralisi
Signed-off-by: Robin Murphy
---
.../bindings/gpu/arm,mali-midgard.yaml| 5 +++-
arch/arm64/boot/dts/arm/juno-base.dtsi| 27 +++
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance for pagetables.
CC: Rob Herring
CC: Tomeu Vizoso
Signed-off-by: Robin Murphy
On 30/09/2019 17:26, Steven Price wrote:
On 30/09/2019 16:24, Robin Murphy wrote:
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance
On 01/10/2019 09:59, Sudeep Holla wrote:
On Mon, Sep 30, 2019 at 12:46:33PM -0500, Rob Herring wrote:
On Mon, Sep 30, 2019 at 10:25 AM Robin Murphy wrote:
Since we now have bindings for Mali Midgard GPUs, let's use them to
describe Juno's GPU subsystem, if only because we can. Jun
When we have devfreq, also try to register a basic cooling device in
case GPU workloads manage to hit thermal throttling thresholds.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 32 ++---
1 file changed, 21 insertions(+), 11 deletions(-)
diff
ount_t API
rather than bare atomic_t?
Robin.
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
drivers/gpu/drm/panfrost/panfrost_gem.h | 6 ++
driv
v->dev);
+ pm_runtime_use_autosuspend(pfdev->dev);
+ pm_runtime_set_autosuspend_delay(pfdev->dev, 0); /* ~3 frames */
Hmm... different timeout, same comment - something seems amiss there,
unless perhaps it's all within rounding error anyway?
Other than that, the overall change looks s
about powering things down.
Robin.
+
+ mmu_hw_do_operation(pfdev, mmu, iova, size, AS_COMMAND_FLUSH_PT);
+
+ pm_runtime_mark_last_busy(pfdev->dev);
+ pm_runtime_put_autosuspend(pfdev->dev);
+}
+
static int mmu_map_sg(struct panfrost_device *pfdev, stru
but it might be worth moving the flush to
mmu_disable() for complete peace of mind (which kind of preempts the
sort of thing that per-process AS switching will want anyway).
Robin.
There is also a problem that we could be accessing the h/w when suspended.
Cc: Tomeu Vizoso
Cc: Steven Pr
On 23/08/2019 14:18, Rob Herring wrote:
On Fri, Aug 23, 2019 at 7:56 AM Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
FWI
On 23/08/2019 15:26, Rob Herring wrote:
On Fri, Aug 23, 2019 at 9:05 AM Robin Murphy wrote:
On 23/08/2019 14:18, Rob Herring wrote:
On Fri, Aug 23, 2019 at 7:56 AM Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
tlb_inv_context() hook is only called when freeing the page
On 23/08/2019 16:05, Steven Price wrote:
On 23/08/2019 12:11, Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the
shrinker.
Rework the flush
On 23/08/2019 16:57, Rob Herring wrote:
On Fri, Aug 23, 2019 at 10:44 AM Robin Murphy wrote:
On 23/08/2019 16:05, Steven Price wrote:
On 23/08/2019 12:11, Robin Murphy wrote:
On 23/08/2019 03:12, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing
o they are
all in one place and are done after all initialization.
Other the nitpick of whether the pm_runtime_enable() call should come at
the end after the autosuspend setup,
Reviewed-by: Robin Murphy :robin.mur...@arm.com>
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: David Airlie
Cc: Daniel
On 26/08/2019 23:33, Rob Herring wrote:
There's no need to serialize io-pgtable calls and the as_lock is
sufficient to serialize flush operations, so we can remove the per
page table lock.
Reviewed-by: Robin Murphy
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD addr
associated with resuming which trigger
lockdep warnings.
Dunno if it's worth explicitly commenting that this is because resume
already implies a full flush, but regardless,
Reviewed-by: Robin Murphy
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc: Tomeu Viz
nv_context() hook is only called when freeing the page tables and
we do a flush before disabling the AS, lets remove the flush from
tlb_inv_context and avoid any runtime PM issues.
Reviewed-by: Robin Murphy
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: Tome
to be a performance bottleneck,
having both does make things seem more robust and easier to reason about.
Reviewed-by: Robin Murphy
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc
Hi Neil,
On 28/08/2019 12:28, Neil Armstrong wrote:
Hi Robin,
On 31/05/2019 15:47, Robin Murphy wrote:
On 31/05/2019 13:04, Tomeu Vizoso wrote:
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
On 29/05/2019 16:09, Tomeu Vizoso wrote:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote
0036bc73ccbe - that looks like something that CONFIG_DMA_API_DEBUG
should have been screaming about anyway.
Robin.
Thanks,
Fabio Estevam
[2.083249] 8<--- cut here ---
[2.086460] Unable to handle kernel paging request at virtual
address 50001000
[2.094174] pgd = (ptrval)
[2.096
r of
which sounds like a thing that should legitimately happen. Are you sure
this isn't all just hiding a subtle bug elsewhere? After all, if what
was being unmapped wasn't right, who says that what's now being synced is?
Robin.
In the mean time, it is a bit ugly, but I guess somet
On 05/09/2019 20:05, Rob Clark wrote:
On Thu, Sep 5, 2019 at 10:03 AM Rob Clark wrote:
On Wed, Sep 4, 2019 at 11:06 AM Robin Murphy wrote:
On 04/09/2019 01:12, Rob Clark wrote:
On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
Hi Jonathan,
On Tue, Sep 3, 2019 at 4:25 PM Jonathan
avoid a related problem with GPU, caused by
the DMA domain claiming the context bank that the GPU firmware expects
to use.
Careful bringing that up again, or I really will rework the context bank
allocator to avoid this default domain problem entirely... ;)
Robin.
And it avoids spurious
and driver
probe order as to whether you catch the "proper" call from
iommu_bus_notifier()/iommu_bus_init() or the late "replay" from
of_iommu_configure(). I wouldn't make any assumptions of consistency.
Robin.
ber of DMA mapping is normal ?
Yeah seems perfectly fine for a gpu.
That is a lot and apparently overwhelm the dma-debug tracking. Robin
rewrote this code in Linux 4.21 to work a little better, so I'm curious
why this might have changes in 4.19, as dma-debug did not change at
all there.
FWIW
which lead to these warnings in the first place.
Robin.
Reported-by: kernel test robot
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/dr
ircumstances), or a
value considerably larger than what the longest mappable SG segment
actually is. Neither seems particularly useful, and to be honest I
suspect the forced-bounce cases only set it to a page as a sledgehammer
to make things work *because* the "normal" value is nonsense.
Robin.
p along
in spite of them might be OK as a local hack, but it is not reasonable
for the mainline kernel.
Thanks,
Robin.
Signed-off-by: Eero Lehtinen
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -36,8 +36,8 @@
ret = readl_relaxed_poll
up to any relevant structure member in that dereference chain :/
Robin.
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
to avoid poking at
the DT at all here, or is it that you need to check remote graph
endpoints whose struct device may not be ready yet?
Robin.
DRM_DEV_DEBUG(dev,
"no iommu attached for %pOF, using
er-shareable, so
it's not clear how the GPU could observe a mismatch in the first place
(other than major integration issues causing data corruption).
Robin.
Steve
于 Thu, 24 Jun 2021 14:22:04 +0100
Steven Price 写道:
On 22/06/2021 02:40, Chunyou Tang wrote:
Hi Steve,
I wil
no harm in this being backported further than it
strictly needs to be, and it's clearly better having the
!GENERIC_ATOMIC64 split out. So I'll merge this to drm-misc-fixes.
Thanks both!
Robin.
Reviewed-by: Steven Price
Thanks!
Steve
Signed-off-by: Arnd Bergmann
---
dri
main for any level of
the API internals to pick up as appropriate, rather than propagate
per-call gfp flags everywhere. As it stands we're still missing
potential pagetable and other domain-related allocations by drivers in
.attach_dev and even (in probably-shouldn't-really-happen cases)
.
, but it doesn't work for me, so let's add
4k@30 as a first step.
Sascha
Changes since v1:
- Allow non standard clock rates only on Synopsys phy as suggested by
Ro
etup to
IOMMU device registration") that bodge no longer works, but really the
GPU driver should be responsible for its own behaviour anyway. Make the
workaround explicit.
Reported-by: Jon Hunter
Suggested-by: Dmitry Osipenko
Signed-off-by: Robin Murphy
---
drivers/gpu/host1x/dev.c | 4
1 f
On 2022-10-20 13:25, Jon Hunter wrote:
Hi Robin,
On 19/10/2022 18:23, Robin Murphy wrote:
Since commit c7e3ca515e78 ("iommu/tegra: gart: Do not register with
bus") quite some time ago, the GART driver has effectively disabled
itself to avoid issues with the GPU driver expecting it
etup to
IOMMU device registration") that bodge no longer works, but really the
GPU driver should be responsible for its own behaviour anyway. Make the
workaround explicit.
Reported-by: Jon Hunter
Suggested-by: Dmitry Osipenko
Signed-off-by: Robin Murphy
---
v2: Cover DRM instance too, move
the BUG_ON(vma->vm_flags & VM_PFNMAP) in there.
Robin.
https://elixir.bootlin.com/linux/v6.1-rc6/source/mm/memory.c#L2518
More importantly, it does uncondtionally set VM_PFNMAP, so clearing
that does not make much sense.
Patch motived by discussions around enforcing VM_PFNMAP semantics for
al
On 2022-11-24 17:24, Daniel Vetter wrote:
On Thu, Nov 24, 2022 at 11:11:21AM +, Robin Murphy wrote:
On 2022-11-23 17:28, Daniel Vetter wrote:
This code was added in b65e64f7ccd4 ("drm/cma: Use
dma_mmap_writecombine() to mmap buffer"), but does not explain why
it's needed
On 2022-11-04 20:11, Dmitry Osipenko wrote:
On 8/23/22 01:01, Robin Murphy wrote:
Convert to io-pgtable's bulk {map,unmap}_pages() APIs, to help the old
single-page interfaces eventually go away. Unmapping heap BOs still
wants to be done a page at a time, but everything else can get the
On 2022-11-04 20:48, Dmitry Osipenko wrote:
On 11/4/22 23:37, Robin Murphy wrote:
On 2022-11-04 20:11, Dmitry Osipenko wrote:
On 8/23/22 01:01, Robin Murphy wrote:
Convert to io-pgtable's bulk {map,unmap}_pages() APIs, to help the old
single-page interfaces eventually go away. Unmapping
nko
Signed-off-by: Robin Murphy
---
The previous diff turned out to be not quite right, so I've not
included Dmitry's Tested-by given for that.
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/p
adeon_ttm_init()? Disabling highmem is
presumably just hiding whatever problem exists, by throwing away all
>32-bit RAM such that use_dma32 doesn't matter.
Robin.
On 2022-11-30 14:28, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 7:54 AM Robin Murphy wrote:
On 2022-11-29 17:11, Mikhail Krylov wrote:
On Tue, Nov 29, 2022 at 11:05:28AM -0500, Alex Deucher wrote:
On Tue, Nov 29, 2022 at 10:59 AM Mikhail Krylov wrote:
On Tue, Nov 29, 2022 at 09:44:19AM
On 2022-11-30 19:59, Mikhail Krylov wrote:
On Wed, Nov 30, 2022 at 11:07:32AM -0500, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 10:42 AM Robin Murphy wrote:
On 2022-11-30 14:28, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 7:54 AM Robin Murphy wrote:
On 2022-11-29 17:11, Mikhail Krylov
LL pointer may well be a sign that it's
worth a closer look to check whether it really is what the code intended
to do, but don't automatically assume it has to be a bug. Otherwise,
good luck with "fixing" every user of container_of() throughout the
entire kernel.
Th
On 2022-12-07 15:29, Liviu Dudau wrote:
On Wed, Dec 07, 2022 at 01:59:04PM +, Robin Murphy wrote:
On 2022-12-07 09:21, Jiasheng Jiang wrote:
As kzalloc may fail and return NULL pointer, it should be better to check
the return value in order to avoid the NULL pointer dereference in
ance to avoid coherency issues, and that in these particular
setups whatever that is might be assuming the memory is direct-mapped
and thus going wrong for highmem pages.
So as I said before, I really think this is not about using GFP_DMA32 at
all, but about *not* using GFP_HIGHUSER.
Tha
On 2022-12-14 22:02, Alex Deucher wrote:
On Wed, Dec 14, 2022 at 4:54 PM Robin Murphy wrote:
On 2022-12-12 02:08, Luben Tuikov wrote:
Fix screen corruption on older 32-bit systems using AGP chips.
On older systems with little memory, for instance 1.5 GiB, using an AGP chip,
the device'
Robin Murphy:
On 2022-12-14 22:02, Alex Deucher wrote:
On Wed, Dec 14, 2022 at 4:54 PM Robin Murphy
wrote:
On 2022-12-12 02:08, Luben Tuikov wrote:
Fix screen corruption on older 32-bit systems using AGP chips.
On older systems with little memory, for instance 1.5 GiB, using an
AGP chip,
the
like Mark suggested?
FWIW you'll need to rebase the IOMMU changes on 6.2-rc1 anyway -
mtk_iommu stops using component_match_add_release() at all.
Thanks,
Robin.
g/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=b5765a1b44bea9dfcae69c53ffeb4c689d0922a7
Thanks,
Robin.
}
/* Get smi-(sub)-common dev from the last larb. */
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 6e0e65831eb7..fb09ed6bf550 100644
---
On 03/01/2023 4:15 pm, Maxime Ripard wrote:
Hi Robin,
On Tue, Jan 03, 2023 at 01:01:07PM +, Robin Murphy wrote:
Hi Sean,
On 22/12/2022 11:37 pm, Sean Anderson wrote:
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of
place, I forget now).
Thanks,
Robin.
Signed-off-by: Jason Gunthorpe
---
arch/arm/mm/dma-mapping.c | 11 +++
.../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/host1x/cdma.c
providing readq/writeq if they
really want to, and drivers can also use the io-64-nonatomic headers for
portability. The build will still fail in a sufficiently obvious manner
if neither is true.
Thanks,
Robin.
+#define fb_writeb writeb
+#define fb_writew writew
+#define fb_writel writel
On 2023-05-05 15:50, Jason Gunthorpe wrote:
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote:
Although iommu-dma is a per-architecture chonce, that is currently
implemented in a rather haphazard way. Selecting from the arch Kconfig
was the original logical approach, but is
) on your platform when the
device is coherent and nothing is bounce-buffered, then the first thing
we can do is look at making that quicker (for everyone). Otherwise, this
seems like the famous bad kind of premature optimisation.
Thanks,
Robin.
dma_sync_sgtable_for
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
---
v2: Rebase to 6.4-rc1
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file
job->implicit_fences);
+ for (i = 0; i < job->bo_count; i++) {
+ struct apu_gem_object *apu_obj;
+
+ apu_obj = to_apu_bo(job->bos[i]);
+ if (job->apu->domain)
If the domain *did* ever exist, but could suddenly disappear at any
point afte
wrong one.
Especially when pretty much every other GPU driver is also just one big
top-level module to load for many different generations of hardware.
Plus it would mean that if someone did want to have a go at
deduplicating the resource-wrangling boilerplate for OPPs etc. in
future, there's more chance of being able to do so meaningfully.
Cheers,
Robin.
On 2023-08-11 17:56, Daniel Stone wrote:
Hi,
On 11/08/2023 17:35, Robin Murphy wrote:
On 2023-08-09 17:53, Boris Brezillon wrote:
+obj-$(CONFIG_DRM_PANTHOR) += panthor.o
FWIW I still think it would be nice to have a minor
directory/Kconfig/Makefile reshuffle and a trivial bit of extra
WIOTLB ;)
Also note that SKIP_CPU_SYNC is only a hint, so the DMA API
implementation is still at liberty to do the fatally dangerous things
you're hoping it won't (e.g. dereferencing sg_virt()...)
Thanks,
Robin.
+ if (!dma_map_sg_attrs(attachment->dev, table
o get to
the point of being able to fix it properly (FWIW that is now #2 on my
priority list after getting the bus ops stuff done, which should also
make it easier).
Thanks,
Robin.
Sadly, there are deeper technical problems with all of the places doing
this. There are several problemetic patter
rds with
the guy who originally suggested that code[1] ;)
Cheers,
Robin.
[1]
https://lore.kernel.org/dri-devel/b009b4c4-0396-58c2-7779-30c844f36...@arm.com/
On 2023-08-14 12:18, Steven Price wrote:
On 11/08/2023 20:26, Robin Murphy wrote:
On 2023-08-11 17:56, Daniel Stone wrote:
Hi,
On 11/08/2023 17:35, Robin Murphy wrote:
On 2023-08-09 17:53, Boris Brezillon wrote:
+obj-$(CONFIG_DRM_PANTHOR) += panthor.o
FWIW I still think it would be nice
in particular I should be looking out for? (Unfortunately the
only handy HDMI monitor is one of those slightly-out-of-spec ones which
has never really worked with the pixel clocks Juno provides)
Robin.
> I've tried to test on Juno, but the Juno situation seems to be a huge
> fail. (HBI0282
ole over
DVI is still working. I'm dubious that it's thorough enough to have
value (sadly I have neither the time nor the motivation to fight with
HDMI and I2S audio), but feel free to consider that a tested-by if you wish.
Robin.
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_dr
NVAL;
>> }
>> ---8<---
>>
>> A similar fix is required for the other driver in this series (patch
>> 2/5). I need some advise on whether I should introduce a common
>> function to get the machine name post kernel boot-up (I cannot see an
>> existing o
A_SIZE_MBYTES=1 and a sufficiently large monitor connected to
warrant a >1MB framebuffer.
Robin.
[4.107349] hdlcd 7ff6.hdlcd: failed to allocate buffer with size
768
[4.114459] hdlcd 7ff6.hdlcd: Failed to set initial hw configuration.
[4.121888] Unable to handle kernel N
201 - 300 of 571 matches
Mail list logo
