Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
warnings. This is useful for example in KASAN builds. Make the dml
Makefile respect this config.
Fixes the following build warnings with CONFIG_KASAN=y and
CONFIG_FRAME_WARN=0:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/
Hi Jagan,
> Subject: [RFC PATCH 0/9] arm64: imx8mm: Add MIPI DSI support
>
> This series support MIPI DSI on i.MX8MM.
>
> It worked directly with existing mxsfb driver but the SEC DSIM timings has to
> be validate and tested through all platforms, ie reason I'm sending it as RFC.
>
> Tested on
The documentation is a bit vague and doesn't really describe what the
->timedout_job() is expected to do. Let's add a few more details.
v5:
* New patch
Suggested-by: Daniel Vetter
Signed-off-by: Boris Brezillon
---
include/drm/gpu_scheduler.h | 14 ++
1 file changed, 14 insertions(
Hello,
This is a merge of [1] and [2] since the second series depends on
patches in the preparatory series.
Main changes in this v5:
* Document what's excepted in the ->timedout_job() hook
* Add a patch increasing the AS_ACTIVE polling timeout
* Fix a few minor things here and there (see each c
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
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
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
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
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 --
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
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 53 ++
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
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
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 +
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.
v5:
* Add a panfrost_exception_is_fault() helper and the
DRM_PANFROST_EXCEPTION_MAX_NON_FAULT value
v4:
* Don't disable/restore irqs when taking the job_l
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
Reviewed-by: Steven Price
---
driver
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.
v5:
* Fix a comment in panfrost_job_init()
v3:
* Fix the done/err job dequeuing logic to get a valid active state
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/
Experience has shown that 1ms is sometimes not enough, even when the GPU
is running at its maximum frequency, not to mention that an MMU operation
might take longer if the GPU is running at a lower frequency, which is
likely to be the case if devfreq is active.
Let's pick a significantly bigger ti
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
Be more defensive and raise error on wrong mem_type
argument in amdgpu_gtt_mgr_has_gart_addr().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/driver
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.
v2: merge if-conditions
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
1 file changed, 2 insert
Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
> 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 Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
wrote:
> yes, I think this makes sense, even if it is a property that one can't
> tell for sure what it does before hand.
>
> Using a pair of properties, preference and active, to ask for something
> and then check what actually worked is good
On Mon, Jun 28, 2021 at 07:45:31PM +, Ruhl, Michael J wrote:
> >-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; Thom
On Mon, Jun 28, 2021 at 04:46:22PM +0200, 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
> performance-based migratio
On Tue, Jun 29, 2021 at 09:34:56AM +0200, 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 wor
On Tue, 29 Jun 2021 10:50:36 +0200
Daniel Vetter wrote:
> On Tue, Jun 29, 2021 at 09:34:56AM +0200, 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 re
On Tue, Jun 29, 2021 at 09:34:55AM +0200, Boris Brezillon wrote:
> The documentation is a bit vague and doesn't really describe what the
> ->timedout_job() is expected to do. Let's add a few more details.
>
> v5:
> * New patch
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Boris Brezillon
Re
Hello Thomas,
thanks for the patch.
Tested-by: Yannick Fertre
Best regards
On 6/25/21 10:22 AM, Thomas Zimmermann wrote:
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in stm.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pi
On 6/29/21 10:43 AM, Daniel Vetter wrote:
On Mon, Jun 28, 2021 at 07:45:31PM +, Ruhl, Michael J wrote:
-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.la
ttps://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Bjorn-Andersson/drm-msm-dp-Make-it-possible-to-enable-the-test-pattern/20210629-082507
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
9840cfcb97fc8b6aa7b36cec3cc3fd763f14052e
con
Am 28.06.21 um 19:03 schrieb Werner Sembach:
> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>> Add a new general drm property "active bpc" which can be used by graphic
>> drivers to report the applied bit depth per pixel back to userspace.
>>
>> While "max bpc" can be used to change the color depth
Am 29.06.21 um 09:34 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 workqueue at the driver leve
Am 29.06.21 um 09:36 schrieb Nirmoy Das:
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.
v2: merge if-conditions
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu
Am 29.06.21 um 09:36 schrieb Nirmoy Das:
Be more defensive and raise error on wrong mem_type
argument in amdgpu_gtt_mgr_has_gart_addr().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drive
On 6/29/2021 1:05 PM, Christian König wrote:
Am 29.06.21 um 09:36 schrieb Nirmoy Das:
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.
v2: merge if-conditions
Signed-off-by:
On Tue, 29 Jun 2021 08:12:54 +
Simon Ser wrote:
> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
> wrote:
>
> > yes, I think this makes sense, even if it is a property that one can't
> > tell for sure what it does before hand.
> >
> > Using a pair of properties, preference and active
Hi Christian,
On Tue, 29 Jun 2021 13:03:58 +0200
Christian König wrote:
> Am 29.06.21 um 09:34 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 rese
Am 29.06.21 um 13:18 schrieb Boris Brezillon:
Hi Christian,
On Tue, 29 Jun 2021 13:03:58 +0200
Christian König wrote:
Am 29.06.21 um 09:34 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 syn
On Tue, 29 Jun 2021 09:35:03 +0200
Boris Brezillon wrote:
> @@ -379,57 +370,72 @@ void panfrost_job_enable_interrupts(struct
> panfrost_device *pfdev)
> job_write(pfdev, JOB_INT_MASK, irq_mask);
> }
>
> -static bool panfrost_scheduler_stop(struct panfrost_queue_state *queue,
> -
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
performance-based migration.
v2:
- Verify that the memory region given as an id really exists.
(R
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.
v4:
- Initialize buffers and check contents after migration
(Suggested by Matthew Auld)
- Perform async migration (if implemented)
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
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/g
Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
>> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
>> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
Am 29.06.21 um 13:44 schrieb Jing Xiangfeng:
radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
an error path. Add the missed function call to fix it.
Signed-off-by: Jing Xiangfeng
I'm pretty sure that I already reviewed the same patch a few weeks ago,
but it looks like
On 6/29/2021 1:06 PM, Christian König wrote:
Am 29.06.21 um 09:36 schrieb Nirmoy Das:
Be more defensive and raise error on wrong mem_type
argument in amdgpu_gtt_mgr_has_gart_addr().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +-
1 file changed, 5 i
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.
v3: remove extra braces.
v2: merge if-conditions.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/a
radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
an error path. Add the missed function call to fix it.
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/radeon/radeon_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/
Hi Robin:
On 6/28/21 5:54 PM, Robin Murphy wrote:
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
psb_user_framebuffer_create() misses to call drm_gem_object_put() in an
error path. Add the missed function call to fix it.
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/gma500/framebuffer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/fram
Hi Christian,
Could you please pick this up for drm-misc-next or fixes ?
Regards,
Nirmoy
On 6/29/2021 1:44 PM, Nirmoy Das wrote:
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type
On Tue, 29 Jun 2021 at 12:37, 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
> performance-based migration.
>
> v2
We don't want to print an error message each time
devm_snd_soc_register_card() returns -EPROBE_DEFER, the function will
most likely succeed some time in the future, once the missing resources
are available. So use dev_err_probe(), which will redirect the messages
to the debug log level in such case
Hi Alex,
On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
> 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 Gar
Hi,
This series aims at fixing a complete and silent hang when one tries to use CEC
while the display output is off.
This can be tested with:
echo off > /sys/class/drm/card0-HDMI-A-1/status
cec-ctl --tuner -p 1.0.0.0
cec-compliance
This series addresses it by making sure the HDMI controller is
In the vc4_hdmi_encoder_pre_crtc_configure() function error path we
never actually call pm_runtime_put() even though
pm_runtime_resume_and_get() is our very first call.
Fixes: 4f6e3d66ac52 ("drm/vc4: Add runtime PM support to the HDMI encoder
driver")
Signed-off-by: Maxime Ripard
---
drivers/gp
If we detect the device as running we make sure we get the reference
count right for clocks, but we don't do as such for the runtime PM
count, let's call pm_runtime_enable to make sure it's accurate.
Fixes: 5b0060004236 ("drm/vc4: hdmi: Prevent clock unbalance")
Signed-off-by: Maxime Ripard
---
In order to ease further additions to the CEC enable and disable, let's
split the function into two functions, one to enable and the other to
disable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 73 --
1 file changed, 44 insertions(+), 29 del
Similarly to what we encountered with the detect hook with DRM, nothing
actually prevents any of the CEC callback from being run while the HDMI
output is disabled.
However, this is an issue since any register access to the controller
when it's powered down will result in a silent hang.
Let's make
Bugzilla ticket: https://intbugzilla.st.com/show_bug.cgi?id=60620
Gerrit patch: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/208093/
In the LTDC driver, pm_runtime_get_sync was wrongly used and caused the
LTDC pixel clock to be systematically enabled in the clock summary.
After one simple use
Yes, please see this page for more information:
https://www.x.org/wiki/XorgEVoC/
Alex
On Mon, Jun 21, 2021 at 2:26 PM shashank singh
wrote:
>
> Hello everyone, my name is Shashank Singh. I hope this is the right platform
> to reach out to the 'X.org' community. I was curious about the X.org End
Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
change.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_d
On Tue, Jun 29, 2021 at 01:24:53PM +0200, Christian König wrote:
> Am 29.06.21 um 13:18 schrieb Boris Brezillon:
> > Hi Christian,
> >
> > On Tue, 29 Jun 2021 13:03:58 +0200
> > Christian König wrote:
> >
> > > Am 29.06.21 um 09:34 schrieb Boris Brezillon:
> > > > Mali Midgard/Bifrost GPUs have
Applied. Thanks.
Alex
On Mon, Jun 28, 2021 at 6:53 AM Lukas Bulwahn wrote:
>
> Commit 6b36fa6143f6 ("drm/amdgpu: add umc v8_7_0 IP headers") adds the new
> file ./drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h with
> DOS line endings, which is very uncommon for the kernel reposito
Applied. Thanks!
Alex
On Tue, Jun 29, 2021 at 7:42 AM Christian König
wrote:
>
> Am 29.06.21 um 13:44 schrieb Jing Xiangfeng:
> > radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
> > an error path. Add the missed function call to fix it.
> >
> > Signed-off-by: Jing Xiangf
On Mon 28 Jun 20:07 CDT 2021, abhin...@codeaurora.org wrote:
> 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
On 2021-06-28 9:27 p.m., Reka Norman wrote:
> Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
> warnings. This is useful for example in KASAN builds. Make the dml
> Makefile respect this config.
>
> Fixes the following build warnings with CONFIG_KASAN=y and
> CONFIG_FRAME_WARN
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
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.
v4:
- Initialize buffers and check contents after migration
(Suggested by Matthew Auld)
- Perform async migration (if implemented)
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
performance-based migration.
v2:
- Verify that the memory region given as an id really exists.
(R
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
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/g
LGTM
Acked-by: Nirmoy Das
On 6/29/2021 3:58 PM, Thomas Zimmermann wrote:
Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
chang
On Tue, Jun 29, 2021 at 05:12:01PM +0200, 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
> performance-based migratio
On Sun, Jun 27, 2021 at 05:40:12PM -0700, Randy Dunlap wrote:
> Fix kernel-doc function name warning:
>
> ../include/linux/dma-resv.h:227: warning: expecting prototype for
> dma_resv_exclusive(). Prototype was for dma_resv_excl_fence() instead
>
> Fixes: 6edbd6abb783d ("ma-buf: rename and cleanu
On Sat, Jun 26, 2021 at 03:32:27AM -0400, Hamza Mahfooz wrote:
> 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 ac
On Tue, Jun 29, 2021 at 9:58 PM Thomas Zimmermann wrote:
>
> Print the name of the DRM driver when taking over fbdev devices. Makes
> the output to dmesg more consistent. Note that the driver name is only
> used for printing a string to the kernel log. No UAPI is affected by this
> change.
>
> Sig
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
> 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
On Tue, Jun 29, 2021 at 05:55:15PM +0200, Daniel Vetter wrote:
> On Sun, Jun 27, 2021 at 05:40:12PM -0700, Randy Dunlap wrote:
> > Fix kernel-doc function name warning:
> >
> > ../include/linux/dma-resv.h:227: warning: expecting prototype for
> > dma_resv_exclusive(). Prototype was for dma_resv_e
On Fri, Jun 25, 2021 at 10:47:40AM +0200, Thomas Zimmermann wrote:
> Remove all references to DRM's IRQ midlayer.
>
> The code in xcs_resume() probably didn't work as intended. It uses
> struct drm_device.irq, which is allocated to 0, but never initialized
> by i915 to the device's interrupt numbe
On 6/29/21 9:10 AM, Daniel Vetter wrote:
> On Tue, Jun 29, 2021 at 05:55:15PM +0200, Daniel Vetter wrote:
>> On Sun, Jun 27, 2021 at 05:40:12PM -0700, Randy Dunlap wrote:
>>> Fix kernel-doc function name warning:
>>>
>>> ../include/linux/dma-resv.h:227: warning: expecting prototype for
>>> dma_res
On Tue, Jun 29, 2021 at 6:11 PM Ville Syrjälä
wrote:
>
> On Fri, Jun 25, 2021 at 10:47:40AM +0200, Thomas Zimmermann wrote:
> > Remove all references to DRM's IRQ midlayer.
> >
> > The code in xcs_resume() probably didn't work as intended. It uses
> > struct drm_device.irq, which is allocated to 0
Applied. Thanks!
Alex
On Tue, Jun 29, 2021 at 11:10 AM Harry Wentland wrote:
>
> On 2021-06-28 9:27 p.m., Reka Norman wrote:
> > Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
> > warnings. This is useful for example in KASAN builds. Make the dml
> > Makefile respect this
Hi,
On 29/06/2021 15:58, Thomas Zimmermann wrote:
> Print the name of the DRM driver when taking over fbdev devices. Makes
> the output to dmesg more consistent. Note that the driver name is only
> used for printing a string to the kernel log. No UAPI is affected by this
> change.
>
> Signed-off-
On Tue, 29 Jun 2021 at 16:50, Daniel Vetter wrote:
>
> On Tue, Jun 29, 2021 at 05:12:01PM +0200, 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
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2021-06-29:
The biggest fix is the restoration of mmap ioctl for gen12 integrated parts
which lack was breaking ADL-P with media stack.
Besides that a small selftest fix and a theoretical overflow on
i915->pipe_to_crtc_mapping.
Thanks,
Rodrigo.
During board bringups its useful to have a DSI test pattern
generator to isolate a DPU vs a DSI issue and focus on the relevant
hardware block.
To facilitate this, add an API which triggers the DSI controller
test pattern. The expected output is a rectangular checkered pattern.
This has been vali
Add entry for i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
v3:
(Marcin Ślusarz):
- Lot's of typos / bad english fixed
Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.
v2:
(Daniel Vetter)
- Expand explaination of why bonding isn't supported for GuC
submission
- CC some of the DRM scheduler maintainers
- Add priority
Subject and patches say it all.
v2: Address comments, patches have details of changes
v3: Address comments, patches have details of changes
v4: Address comments, patches have details of changes
v5: Fix checkpatch and docs warnings
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/doc/rfc: i
From: Rajkumar Subbiah
The commit 2f015ec6eab69301fdcf54d397810d72362d7223 added some debug
code for sideband message tracing. But it seems to have unintentionally
changed the behavior on sideband message failure. It catches and returns
failure only if DRM_UT_DP is enabled. Otherwise it ignores t
+Lyude, author of fixed commit. Please add relevant folks in the future.
Quoting Kuogee Hsieh (2021-06-29 13:08:56)
> From: Rajkumar Subbiah
>
> The commit 2f015ec6eab69301fdcf54d397810d72362d7223 added some debug
Please write
Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing
On Tue, 29 Jun 2021 at 22:04, Abhinav Kumar wrote:
>
> During board bringups its useful to have a DSI test pattern
> generator to isolate a DPU vs a DSI issue and focus on the relevant
> hardware block.
>
> To facilitate this, add an API which triggers the DSI controller
> test pattern. The expect
On 6/24/2021 00:04, Matthew Brost wrote:
Add new GuC interface defines and structures while maintaining old ones
in parallel.
Cc: John Harrison
Signed-off-by: Matthew Brost
I think there was some difference of opinion over whether these
additions should be squashed in to the specific patches
On 6/25/2021 10:26, Matthew Brost wrote:
On Fri, Jun 25, 2021 at 03:17:51PM +0200, Michal Wajdeczko wrote:
On 24.06.2021 09:04, Matthew Brost wrote:
Add lrc descriptor context lookup array which can resolve the
intel_context from the lrc descriptor index. In addition to lookup, it
can determine
JFYI this is on my radar and I'll take a look asap
On Tue, 2021-06-29 at 13:41 -0700, Stephen Boyd wrote:
> +Lyude, author of fixed commit. Please add relevant folks in the future.
>
> Quoting Kuogee Hsieh (2021-06-29 13:08:56)
> > From: Rajkumar Subbiah
> >
> > The commit 2f015ec6eab69301fdcf5
On 6/24/2021 00:04, Matthew Brost wrote:
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a single tasklet submits is used for the submission path.
Re-word? 'a single tasklet submits is used...' does
On 6/24/2021 00:04, Matthew Brost wrote:
Add bypass tasklet submission path to GuC. The tasklet is only used if H2G
channel has backpresure.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed,
From: Rajkumar Subbiah
Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
selftests") added some debug code for sideband message tracing. But
it seems to have unintentionally changed the behavior on sideband message
failure. It catches and returns failure only if DRM_UT_DP is e
1 - 100 of 136 matches
Mail list logo
