On 6/28/21 6:28 PM, Matthew Auld wrote:
On 28/06/2021 15:46, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performanc
https://bugzilla.kernel.org/show_bug.cgi?id=213599
--- Comment #6 from Frank Kruger (fkrue...@mailbox.org) ---
Fixed with kernel 5.13, thanks.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>; lkp
>Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest fo
On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Thomas Hellström ; Auld, Matthew
; lkp
Subject: [PATCH v3 1/5] drm/
On Mon, 2021-06-28 at 18:53 +, Ruhl, Michael J wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of
> > Thomas Hellström
> > Sent: Monday, June 28, 2021 10:46 AM
> > To: intel-...@lists.freedesktop.org;
> > dri-devel@lists.freedesktop.org
> > Cc: Thomas Hellström ; Aul
Add support for alpha blending properties. Setup the plane blend state
according to those properties.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 43 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 10 --
2 files changed, 37 insertions(
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:15 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for
>the gem object mi
On 6/28/21 9:27 PM, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 3:15 PM
To: Ruhl, Michael J ; intel-
g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Auld, Matthew
Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Int
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ;
>maarten.lankho...@linux.intel.com; Thomas Hellström
>; Ruhl; Ruhl, Michael J
>
>Subject: [PATCH v3 4/5] drm/i915/gem
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map
>t
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:03 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 8:11 P
On 6/28/21 9:45 PM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Thomas Hellström ; Auld, Matthew
Subject: [PATCH v3 5/5] drm/i915/g
On 6/28/21 9:50 PM, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 3:03 PM
To: Ruhl, Michael J ; intel-
g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Auld, Matthew ; lkp
Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:54 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 9:50
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to drm-tip/drm-tip anholt/for-next v5.13 next-20210628]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Signed
On Mon, Jun 28, 2021 at 7:10 PM Linus Walleij wrote:
>
> On Wed, Mar 3, 2021 at 11:31 AM Nicolas Boichat wrote:
> > On Mon, Mar 1, 2021 at 4:59 PM Linus Walleij
> > wrote:
>
> > > > dsi->mode_flags =
> > > > MIPI_DSI_CLOCK_NON_CONTINUOUS |
> > > > -
Many of the DSI flags have names opposite to their actual effects,
e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
be disabled. Fix this by including _NO_ in the flag names, e.g.
MIPI_DSI_MODE_NO_EOT_PACKET.
Signed-off-by: Nicolas Boichat
---
I considered adding _DISABLE_ inste
The debugfs interface contains the knobs to make the DisplayPort
controller output a test pattern, unfortunately there's nothing
currently that actually enables the defined test pattern.
Fixes: de3ee25473ba ("drm/msm/dp: add debugfs nodes for video pattern tests")
Signed-off-by: Bjorn Andersson
-
Hi Bjorn
On 2021-06-28 17:22, Bjorn Andersson wrote:
The debugfs interface contains the knobs to make the DisplayPort
controller output a test pattern, unfortunately there's nothing
currently that actually enables the defined test pattern.
Fixes: de3ee25473ba ("drm/msm/dp: add debugfs nodes for
On Mon 28 Jun 19:31 CDT 2021, abhin...@codeaurora.org wrote:
> Hi Bjorn
>
> On 2021-06-28 17:22, Bjorn Andersson wrote:
> > The debugfs interface contains the knobs to make the DisplayPort
> > controller output a test pattern, unfortunately there's nothing
> > currently that actually enables the
On 2021-06-28 17:55, Bjorn Andersson wrote:
On Mon 28 Jun 19:31 CDT 2021, abhin...@codeaurora.org wrote:
Hi Bjorn
On 2021-06-28 17:22, Bjorn Andersson wrote:
> The debugfs interface contains the knobs to make the DisplayPort
> controller output a test pattern, unfortunately there's nothing
> c
On 6/28/21 10:09 AM, Lucas Stach wrote:
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb Marek Vasut:
On 6/24/21 2:01 PM, Lucas Stach wrote:
Am Dienstag, dem 22.06.2021 um 11:33 +0200 schrieb Marek Vasut:
On 6/22/21 9:28 AM, Lucas Stach wrote:
Am Montag, dem 21.06.2021 um 18:30 +0200 schrieb
Hi Steve,
thinks for your reply.
I set the pte in arm_lpae_prot_to_pte(),
***
/*
* Also Mali has its own notions of shareability wherein its
Inner
* domain covers the cores within the GPU,
Hi Robin,
thinks for you reply.
I had send more detal to Steve in another mail,thinks for your
messages.
?? Mon, 28 Jun 2021 15:17:51 +0100
Robin Murphy :
> On 2021-06-28 11:48, Steven Price wrote:
> > On 25/06/2021 10:49, Chunyou Tang wrote:
> >> Hi Steve,
> >>Th
This patch series addresses potential use-after-free errors when dereferencing
pointers to struct drm_master. These were identified after one such bug was
caught by Syzbot in drm_getunique():
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
The series is broken up in
In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by &dev->mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer i
Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to dr
On Sun, 27 Jun 2021 02:14:23 +0300
Aaro Koskinen wrote:
> Hi,
>
> On Sat, Jun 26, 2021 at 01:33:23AM +0300, Pavel Skripkin wrote:
> > In case of allocation failures, all code paths was jumping
> > to this code:
> >
> > err:
> > kfree(fbi);
> > kfree(var);
> > kfree(fbops);
> >
> >
As per commit 22be87401289 ("drm: TODO: Add DRM_MODESET_LOCK_ALL*
conversion to todo.rst"),
drm_modeset_lock_all()/drm_modeset_unlock_all() and boilerplate code
surronding instances of drm_modeset_lock_all_ctx() with a local acquire
context should be replaced with the relevant helper macros.
Signe
As per commit 22be87401289 ("drm: TODO: Add DRM_MODESET_LOCK_ALL*
conversion to todo.rst"),
drm_modeset_lock_all()/drm_modeset_unlock_all() and boilerplate code
surrounding instances of drm_modeset_lock_all_ctx() with a local acquire
context should be replaced with the relevant helper macros.
Sign
Hi Ezequiel,
Am 26.06.21 um 02:47 schrieb Ezequiel Garcia:
Hey Dafna,
Thanks a lot for reviewing this.
On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote:
Hi,
On 24.06.21 21:26, Ezequiel Garcia wrote:
From: Paul Kocialkowski
The Rockchip PX30 SoC has a Hantro VPU that features a dec
In case of allocation failures, all code paths was jumping
to this code:
err:
kfree(fbi);
kfree(var);
kfree(fbops);
return r;
Since all 3 pointers placed on stack and don't initialized, they
will be filled with some random values, which leads to
deferencing random
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 a/drivers/gpu/drm/rockchip/rockchip_drm_dr
Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
This series adds support for H.264 decoding on the PX30, RK3328
and RK3326 platforms, enabling the VDPU2 core.
Given it's tested on the Odroid Advance Go, patches 1 and 2
add the basic support to report the panel orientation to
userspace (Heiko, if
Hi,
On Sat, Jun 26, 2021 at 01:33:23AM +0300, Pavel Skripkin wrote:
> In case of allocation failures, all code paths was jumping
> to this code:
>
> err:
> kfree(fbi);
> kfree(var);
> kfree(fbops);
>
> return r;
>
> Since all 3 pointers placed on stack and don't initiali
From: Cai Huoqing
fix the warning- variable 'dev' set but not used
Signed-off-by: Cai Huoqing
Reviewed-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
Hi Ezequiel,
Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
(Adding Nicolas)
Hi Alex,
On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
Hi Ezequiel,
Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on
https://bugzilla.kernel.org/show_bug.cgi?id=213561
Marco Scardovi (ma...@scardovi.com) changed:
What|Removed |Added
CC||ma...@scardovi.com
On 6/25/21 2:27 PM, Matthew Auld wrote:
This is already the case for our kernel internal mappings, and since we
now only support a single mode this should always be WC if the object
can be placed in lmem.
v2: rebase and also update set_domain
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.
I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
for DGFX
Hello,
This is a merge of [1] and [2] since the second series depends on
patches in the preparatory series.
main changes in this v4:
* fixing the reset serialization
* fixing a deadlock in the reset path
* moving the exception enum to a private header
Regards,
Boris
Boris Brezillon (13):
drm
If the fence creation fail, we can return the error pointer directly.
The core will update the fence error accordingly.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
1 file changed, 1 insertion(+), 1
This should avoid switching to interrupt context when the GPU is under
heavy use.
v3:
* Don't take the job_lock in panfrost_job_handle_irq()
Signed-off-by: Boris Brezillon
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_job.c | 53 ++---
1 file changed, 38
Do the exception -> string translation using a table. This way we get
rid of those magic numbers and can easily add new fields if we need
to attach extra information to exception types.
v4:
* Don't expose exception type to userspace
* Merge the enum definition and the enum -> string table declarat
Exception types will be defined as an enum.
v4:
* Fix typo in the commit message
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/
This is not yet needed because we let active jobs be killed during by
the reset and we don't really bother making sure they can be restarted.
But once we start adding soft-stop support, controlling when we deal
with the remaining interrrupts and making sure those are handled before
the reset is iss
Things are unlikely to resolve until we reset the GPU. Let's not wait
for other faults/timeout to happen to trigger this reset.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --
Now that we can pass our own workqueue to drm_sched_init(), we can use
an ordered workqueue on for both the scheduler timeout tdr and our own
reset work (which we use when the reset is not caused by a fault/timeout
on a specific job, like when we have AS_ACTIVE bit stuck). This
guarantees that the
From: Steven Price
The hardware has a set of '_NEXT' registers that can hold a second job
while the first is executing. Make use of these registers to enqueue a
second job per slot.
v3:
* Fix the done/err job dequeuing logic to get a valid active state
* Only enable the second slot on GPUs suppo
If we can recover from a fault without a reset there's no reason to
issue one.
v3:
* Drop the mention of Valhall requiring a reset on JOB_BUS_FAULT
* Set the fence error to -EINVAL instead of having per-exception
error codes
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost
If we don't do that, we have to wait for the job timeout to expire
before the fault jobs gets killed.
v3:
* Make sure the AS is re-enabled when new jobs are submitted to the
context
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
reset. This leads to extra complexity when we need to synchronize timeout
works with the reset work. One solution to address that is to have an
ordered workqueue at the driver level that will be used by the different
schedulers
Expose a helper to trigger a GPU reset so we can easily trigger reset
operations outside the job timeout handler.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_device.h | 8
drivers/gpu/drm/panfrost/panfro
Currently unused. We'll add it back if we need per-GPU definitions.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_device.h | 2 +-
drivers/gpu/drm/panfrost/panfrost_gpu.c| 2 +-
drivers/gpu/d
If the process who submitted these jobs decided to close the FD before
the jobs are done it probably means it doesn't care about the result.
v4:
* Don't disable/restore irqs when taking the job_lock (not needed since
this lock is never taken from an interrupt context)
v3:
* Set fence error to E
The documentation around PrepareMp1ForUnload message says that
anything sent to SMU after this command would be stalled as the
PMFW would not be in a state to take further job requests.
Technically this is right in case of S3 scenario. But, this might
not be the case during s0ix as the PMC driver
Up requests are decoded by drm_dp_sideband_parse_req(), which operates
on a drm_dp_sideband_msg_rx, unlike down requests. Expand the existing
self-test helper sideband_msg_req_encode_decode() to copy the message
contents and length from a drm_dp_sideband_msg_tx to
drm_dp_sideband_msg_rx and use the
Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.
Reviewed-by: Lyude Paul
Signed-off-by: Sam McNally
---
(no changes since v4)
Changes in v4:
- Changed logging to use drm_dbg_kms()
- Added self-tes
With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.
When tunneling CEC through an MST port, CEC IRQs are delivered via a
sink event notify message; when a sink event notify message is received,
trigger CEC IRQ handling - ESI1 is not used for remote CEC IRQs so its
value
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb Marek Vasut:
> On 6/24/21 2:01 PM, Lucas Stach wrote:
> > Am Dienstag, dem 22.06.2021 um 11:33 +0200 schrieb Marek Vasut:
> > > On 6/22/21 9:28 AM, Lucas Stach wrote:
> > > > Am Montag, dem 21.06.2021 um 18:30 +0200 schrieb Marek Vasut:
> > > > > On
Hi Jagan,
On 24.06.21 10:30, Krzysztof Kozlowski wrote:
> On 24/06/2021 04:48, Fabio Estevam wrote:
>> Hi Jagan/Laurent,
>>
>> On Wed, Jun 23, 2021 at 7:23 PM Laurent Pinchart
>> wrote:
>>
>>> Looking at the register set, it seems to match the Exynos 5433,
>>> supported by drivers/gpu/drm/exynos/
Hi. This patch has been waiting in the list for quite some time now.
Can someone review this patch?
Same goes for the following:
https://lore.kernel.org/dri-devel/20210331180757.463479-1-y@phytec.de/
The corresponding dt-bindings are already acked by Rob Herring:
https://lore.kernel.org/linux
The downstream dts lists this value as 0x494, and not
0x45c.
Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog")
Signed-off-by: Robert Foss
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #34 from Jerome C (m...@jeromec.com) ---
Using 5.13.0 now and the issue is still here
(In reply to kolAflash from comment #32)
> Created attachment 296901 [details]
> dmesg via SSH, running amd-drm-next-5.14-2021-05-12 without
> ip_bl
Hi Rob,
Thanks for your work.
On 2021-06-23 10:43:44 -0600, Rob Herring wrote:
> In testing out under development json-schema 2020-12 support, there's a
> few issues with 'unevaluatedProperties' and the graph schema. If
> 'graph.yaml#/properties/port' is used, then neither the port nor the
> endp
We want to be able to explicitly migrate objects between gem memory
regions, initially for display and dma-buf, but there might be more
use-cases coming up.
Introduce a gem migrate interface, add a selftest and use it for
display fb pinning and dma-buf mapping.
This series should make accelerated
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
v2:
- Verify that the memory region given as an id really exists.
(R
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf map time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/g
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a live selft
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_g
[AMD Official Use Only]
Thanks update this patch and remove APU flag for avoiding over protection in
this case.
Reviewed-by: Prike Liang
> -Original Message-
> From: amd-gfx On Behalf Of
> Shyam Sundar S K
> Sent: Monday, June 28, 2021 3:55 PM
> To: Deucher, Alexander ; Koenig, Christ
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.
I915_GEM_DOMAIN_GTT looks like it'
Up requests are decoded by drm_dp_sideband_parse_req(), which operates
on a drm_dp_sideband_msg_rx, unlike down requests. Expand the existing
self-test helper sideband_msg_req_encode_decode() to copy the message
contents and length from a drm_dp_sideband_msg_tx to
drm_dp_sideband_msg_rx and use the
Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.
Reviewed-by: Lyude Paul
Signed-off-by: Sam McNally
---
(no changes since v4)
Changes in v4:
- Changed logging to use drm_dbg_kms()
- Added self-tes
With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.
When tunneling CEC through an MST port, CEC IRQs are delivered via a
sink event notify message; when a sink event notify message is received,
trigger CEC IRQ handling - ESI1 is not used for remote CEC IRQs so its
value
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
This fixes media on rkl/adl.
v2:
- Added a R-B.
- Fixed up the code comment a bit.
v3:
- Added an A-B.
- Point out in the commit m
On 28/06/2021 08:41, Boris Brezillon wrote:
> Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
> reset. This leads to extra complexity when we need to synchronize timeout
> works with the reset work. One solution to address that is to have an
> ordered workqueue at the driver
On 28/06/2021 08:42, Boris Brezillon wrote:
> This should avoid switching to interrupt context when the GPU is under
> heavy use.
>
> v3:
> * Don't take the job_lock in panfrost_job_handle_irq()
>
> Signed-off-by: Boris Brezillon
> Acked-by: Alyssa Rosenzweig
I thought I'd already reviewed thi
Den 25.06.2021 00.44, skrev Linus Walleij:
> This adds a driver for panels based on the WideChips WS2401 display
> controller. This display controller is used in the Samsung LMS380KF01
> display found in the Samsung GT-I8160 (Codina) mobile phone and
> possibly others.
>
> As is common with Sam
Hi,
On 6/28/21 11:12 AM, Matthew Auld wrote:
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should b
On Mon, 28 Jun 2021 10:26:39 +0100
Steven Price wrote:
> On 28/06/2021 08:42, Boris Brezillon wrote:
> > This should avoid switching to interrupt context when the GPU is under
> > heavy use.
> >
> > v3:
> > * Don't take the job_lock in panfrost_job_handle_irq()
> >
> > Signed-off-by: Boris Brez
On 28/06/2021 08:42, Boris Brezillon wrote:
> Now that we can pass our own workqueue to drm_sched_init(), we can use
> an ordered workqueue on for both the scheduler timeout tdr and our own
> reset work (which we use when the reset is not caused by a fault/timeout
> on a specific job, like when we
Am Donnerstag, dem 24.06.2021 um 16:08 +0200 schrieb Boris Brezillon:
> The panfrost driver tries to kill in-flight jobs on FD close after
> destroying the FD scheduler entities. For this to work properly, we
> need to make sure the jobs popped from the scheduler entities have
> been queued at the
On 28/06/2021 08:42, Boris Brezillon wrote:
> This is not yet needed because we let active jobs be killed during by
> the reset and we don't really bother making sure they can be restarted.
> But once we start adding soft-stop support, controlling when we deal
> with the remaining interrrupts and m
On 6/28/21 11:09 AM, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
v2:
- Verify that the
On 28/06/2021 08:42, Boris Brezillon wrote:
> If we can recover from a fault without a reset there's no reason to
> issue one.
>
> v3:
> * Drop the mention of Valhall requiring a reset on JOB_BUS_FAULT
> * Set the fence error to -EINVAL instead of having per-exception
> error codes
>
> Signed-o
Il 28/06/21 10:50, Robert Foss ha scritto:
The downstream dts lists this value as 0x494, and not
0x45c.
Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog")
Signed-off-by: Robert Foss
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file ch
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 a
Am Montag, dem 28.06.2021 um 09:41 +0200 schrieb Boris Brezillon:
> Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
> reset. This leads to extra complexity when we need to synchronize timeout
> works with the reset work. One solution to address that is to have an
> ordered wo
On 28/06/2021 08:42, Boris Brezillon wrote:
> If the process who submitted these jobs decided to close the FD before
> the jobs are done it probably means it doesn't care about the result.
>
> v4:
> * Don't disable/restore irqs when taking the job_lock (not needed since
> this lock is never take
1 - 100 of 160 matches
Mail list logo
