Quoting Kuogee Hsieh (2021-07-06 10:20:14)
> DP cable should always connect to DPU during the entire PHY compliance
> testing run. Since DP PHY compliance test is executed at irq_hpd event
> context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off().
> dp_ctrl_off() is used for unpl
Add a compatible and platform datas to support HDMI for rk3568 SoC.
version 2:
- Add the clocks needed for the phy.
Benjamin Gaignard (2):
dt-bindings: display: rockchip: Add compatible for rk3568 HDMI
drm/rockchip: dw_hdmi: add rk3568 support
.../display/rockchip/rockchip,dw-hdmi.yaml
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
This version of the HDMI hardware block need two clocks to provide
phy reference clock: hclk_vio and hclk.
Signed-off-by: Benjamin Gaignard
---
version 2:
- Add the clocks needed for the phy.
drivers/gpu/drm/rockchip/dw_hdmi-rock
Hi
I'm getting this oops (on commit a180bd1d7e16):
[ 17.711520] BUG: kernel NULL pointer dereference, address:
0010
[ 17.739451] RIP: 0010:qxl_bo_move_notify+0x35/0x80 [qxl]
[ 17.827345] RSP: 0018:c9457c08 EFLAGS: 00010286
[ 17.827350] RAX: 000
On Tue, Jul 6, 2021 at 10:12 PM John Stultz wrote:
>
> On Sun, Jul 4, 2021 at 11:16 AM Rob Clark wrote:
> >
> > I suspect you are getting a dpu fault, and need:
> >
> > https://lore.kernel.org/linux-arm-msm/CAF6AEGvTjTUQXqom-xhdh456tdLscbVFPQ+iud1H1gHc8A2=h...@mail.gmail.com/
> >
> > I suppose Bj
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/i915/gt/intel_engine_cs.c:882: warning: expecting prototype for
intel_engines_init_common(). Prototype was for engine_init_common() instead
drivers/gpu/drm/i915/gt/intel_engine_cs.c:959: warning: expecting prototype for
intel_engin
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/i915/display/intel_display_power.c:2300: warning: expecting
prototype for intel_display_power_put_async(). Prototype was for
__intel_display_power_put_async() instead
Signed-off-by: zhaoxiao
---
drivers/gpu/drm/i915/display/inte
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
---
version 2:
- Add the clocks needed for the phy.
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml |
My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:
drm_gem_vram_create()<-- drm_gem_vram_object kzalloced
(bo embedded in this object)
ttm_bo_init()
On 6/1/21 5:43 PM, Anisse Astier wrote:
Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit :
On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote:
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it
On Thu, Jul 8, 2021 at 8:56 AM Christian König wrote:
>
> Am 07.07.21 um 18:32 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 2:58 PM Christian König
> > wrote:
> >> Am 07.07.21 um 14:13 schrieb Daniel Vetter:
> >>> On Wed, Jul 7, 2021 at 1:57 PM Christian König
> >>> wrote:
> Am 07.07
Quoting Kuogee Hsieh (2021-07-06 10:20:18)
> Response with correct edid checksum saved at connector after corrupted edid
> checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_panel.c | 9 +++--
> 1 file changed, 7
On Thu, Jul 8, 2021 at 9:09 AM Daniel Vetter wrote:
> On Thu, Jul 8, 2021 at 8:56 AM Christian König
> wrote:
> > Am 07.07.21 um 18:32 schrieb Daniel Vetter:
> > > On Wed, Jul 7, 2021 at 2:58 PM Christian König
> > > wrote:
> > >> Am 07.07.21 um 14:13 schrieb Daniel Vetter:
> > >>> On Wed, Jul
Quoting Kuogee Hsieh (2021-07-06 10:20:20)
> Main link symbol locked is achieved at end of link training 2. Some
> dongle main link symbol may become unlocked again if host did not end
> link training soon enough after completion of link training 2. Host
> have to re train main link if loss of symb
Hi Frank,
On 06.07.21 11:54, Frank Wunderlich wrote:
Hi,
i've noticed that HDMI is broken at least on my board (Bananapi-r2,mt7623) on
5.13.
after some research i noticed that it is working till
commit 2e477391522354e763aa62ee3e281c1ad9e8eb1b
Author: Dafna Hirschfeld
Date: Tue Mar 30 13:
Quoting Kuogee Hsieh (2021-07-06 10:20:15)
> Reduce link rate and re start link training if link training 1
> failed due to loss of clock recovery done to fix Link Layer
> CTS case 4.3.1.7. Also only update voltage and pre-emphasis
> swing level after link training started to fix Link Layer CTS
>
Quoting Kuogee Hsieh (2021-07-06 10:20:16)
> Aux hardware calibration sequence requires resetting the aux controller
> in order for the new setting to take effect. However resetting the AUX
> controller will also clear HPD interrupt status which may accidentally
> cause pending unplug interrupt to
From: ChunyouTang
The exception_code in register is only 8 bits,So if
fault_status in panfrost_gpu_irq_handler() don't
(& 0xFF),it can't get correct exception reason.
and it's better to show all of the register value
to custom,so it's better fault_status don't (& 0xFF).
Signed-off-by: ChunyouTa
Am 08.07.21 um 06:20 schrieb Christoph Hellwig:
On Wed, Jul 07, 2021 at 12:35:23PM -0700, John Stultz wrote:
So, as Christian mentioned, on the TTM side it's useful, as they are
trying to avoid TLB flushes when changing caching attributes.
For the dmabuf system heap purposes, the main benefit i
Am 08.07.21 um 09:19 schrieb Daniel Vetter:
On Thu, Jul 8, 2021 at 9:09 AM Daniel Vetter wrote:
On Thu, Jul 8, 2021 at 8:56 AM Christian König wrote:
Am 07.07.21 um 18:32 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 2:58 PM Christian König wrote:
Am 07.07.21 um 14:13 schrieb Daniel Vetter
> Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
> Von: "Dafna Hirschfeld"
> We also encountered that warning on mt8173 device - Acer Chromebook R13. It
> happen after resuming from suspend to ram.
> We could not find a version that works and we were not able to find the fix
> of the bug.
> It
The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
in backlight.c") says that gpio-backlight uses brightness as power state.
Other backlight drivers do not, so limit this workaround to gpio-backlight.
This fixes the case where e.g. pwm-backlight can perfectly well be set to
Creating a vkms_config_debufs file in vkms_drv.c to get/track vkms config
data, for the long-term plan of making vkms configurable and have multiple
different instances.
Reviewed-by: Melissa Wen
Signed-off-by: Beatriz Martins de Carvalho
---
Changes in v2:
- corrected subject to make clear i
Hi
just a small update, added debug in the vendor-specific functions for page_flip
and vblank and it seems they never get called
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -87,21 +87,25 @@ static void mtk_drm_crtc_finish_page_flip(struct
mtk_d
Hi Dave & Daniel -
I'll be out for a bit, so I'm sending the first batch of changes for
v5.15 early. Nothing unusual here, I just don't want to have a huge pile
waiting. :)
Rodrigo will cover me.
BR,
Jani.
drm-intel-next-2021-07-08:
drm/i915 changes for v5.15:
Features:
- Enable pipe DMC l
On Thu, Jul 08, 2021 at 09:53:00AM +0200, Christian König wrote:
> Am 08.07.21 um 09:19 schrieb Daniel Vetter:
> > On Thu, Jul 8, 2021 at 9:09 AM Daniel Vetter wrote:
> > > On Thu, Jul 8, 2021 at 8:56 AM Christian König
> > > wrote:
> > > > Am 07.07.21 um 18:32 schrieb Daniel Vetter:
> > > > > O
On Thu, 8 Jul 2021 11:37:01 +0300
Pavel Skripkin wrote:
> On Thu, 8 Jul 2021 08:49:48 +0200
> Christian König wrote:
>
> > Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> > > My local syzbot instance hit GPF in ttm_bo_release().
> > > Unfortunately, syzbot didn't produce a reproducer for this, b
On Wed, Jul 07, 2021 at 04:36:49PM +, Roberto Sassu wrote:
> Hi
>
> I'm getting this oops (on commit a180bd1d7e16):
>
> [ 17.711520] BUG: kernel NULL pointer dereference, address:
> 0010
> [ 17.739451] RIP: 0010:qxl_bo_move_notify+0x35/0x80 [qxl]
> [ 17.827345]
Am 08.07.21 um 12:02 schrieb Daniel Vetter:
On Thu, Jul 08, 2021 at 09:53:00AM +0200, Christian König wrote:
Am 08.07.21 um 09:19 schrieb Daniel Vetter:
On Thu, Jul 8, 2021 at 9:09 AM Daniel Vetter wrote:
On Thu, Jul 8, 2021 at 8:56 AM Christian König wrote:
Am 07.07.21 um 18:32 schrieb Dan
Am 08.07.21 um 12:09 schrieb Pavel Skripkin:
On Thu, 8 Jul 2021 11:37:01 +0300
Pavel Skripkin wrote:
On Thu, 8 Jul 2021 08:49:48 +0200
Christian König wrote:
Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't prod
On Thu, 8 Jul 2021 12:56:19 +0200
Christian König wrote:
> Am 08.07.21 um 12:09 schrieb Pavel Skripkin:
> > On Thu, 8 Jul 2021 11:37:01 +0300
> > Pavel Skripkin wrote:
> >
> >> On Thu, 8 Jul 2021 08:49:48 +0200
> >> Christian König wrote:
> >>
> >>> Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the sequence
values.
Then we should always also wait
On Thu, Jul 8, 2021 at 12:54 PM Christian König
wrote:
>
> Am 08.07.21 um 12:02 schrieb Daniel Vetter:
> > On Thu, Jul 08, 2021 at 09:53:00AM +0200, Christian König wrote:
> >> Am 08.07.21 um 09:19 schrieb Daniel Vetter:
> >>> On Thu, Jul 8, 2021 at 9:09 AM Daniel Vetter
> >>> wrote:
> On T
My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:
drm_gem_vram_create()<-- drm_gem_vram_object kzalloced
(bo embedded in this object)
ttm_bo_init()
Am 08.07.21 um 13:20 schrieb Daniel Vetter:
On Thu, Jul 8, 2021 at 12:54 PM Christian König
wrote:
[SNIP]
As far as I know that not completely correct. The rules around atomics i
once learned are:
1. Everything which modifies something is a write barrier.
2. Everything which returns someth
Am 08.07.21 um 13:25 schrieb Pavel Skripkin:
My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:
drm_gem_vram_create()<-- drm_gem_vram_object kzalloced
Yeah, that's an already known issue.
When the allocation fails bo->resource might be NULL now and we need to
add checks for that corner case as well.
Christian.
Am 08.07.21 um 12:14 schrieb Daniel Vetter:
On Wed, Jul 07, 2021 at 04:36:49PM +, Roberto Sassu wrote:
Hi
I'm getting this oo
On Thu, 8 Jul 2021 at 09:56, Stephen Boyd wrote:
>
> Add some missing newlines to the various DRM printks in this file.
> Noticed while looking at logs. While we're here unbreak quoted
> strings so grepping them is easier.
>
> Signed-off-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
> ---
>
Sorry that was the wrong patch.
Still not feeling that well :(
Christian.
Am 08.07.21 um 13:19 schrieb Christian König:
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the
From: Mikel Rychliski
radeon_ttm_bo_destroy() is attempting to access the resource object to
update memory counters. However, the resource object is already freed when
ttm calls this function via the destroy callback. This causes an oops when
a bo is freed:
BUG: kernel NULL pointer deref
When allocations fails that can be NULL now.
Signed-off-by: Christian König
Reported-by: Daniel Bristot de Oliveira
Tested-by: Daniel Bristot de Oliveira
---
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/driver
On 22/06/2021 11:03, Dmitry Baryshkov wrote:
Fix undefined symbols errors arising from 64-bit division on 32-bit
arm targets. Add 64-bit version of mult_frac and use it for calculating
bandwidth.
ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
ERROR: modpost: "__aeabi_u
Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail&id=7
Signed-off-by: Alistair Francis
Acked-by: Rob Herring
---
.../bindings/display/panel/panel-simple.yaml | 2 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 ++
drivers/gpu/drm/p
ping for review
Am 24.06.21 um 11:55 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective rockchip functions are being removed. The file_operations
structure fops is now being created b
ping for review
Am 24.06.21 um 11:53 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective xen functions are being removed. The file_operations
structure fops is now being created by the
ping for review
Am 24.06.21 um 11:03 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective msm functions are being removed. The file_operations
structure fops is now being created by the
ping for review
Am 24.06.21 um 11:01 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective mediatek functions are being removed. The file_operations
structure fops is now being created b
ping for review
Am 24.06.21 um 11:00 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective exynos functions are being removed. The file_operations
structure exynos_drm_driver_fops is now
> From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
> Sent: Thursday, July 8, 2021 1:47 PM
> When allocations fails that can be NULL now.
>
> Signed-off-by: Christian König
> Reported-by: Daniel Bristot de Oliveira
> Tested-by: Daniel Bristot de Oliveira
Hi Christian
thanks, it
Am 05.07.21 um 11:32 schrieb Daniel Vetter:
On Mon, Jul 05, 2021 at 10:29:48AM +0200, Boris Brezillon wrote:
This should help limit the number of ioctls when submitting multiple
jobs. The new ioctl also supports syncobj timelines and BO access flags.
v4:
* Implement panfrost_ioctl_submit() as a
Am 08.07.21 um 14:04 schrieb Thomas Zimmermann:
ping for review
Nevermind, there's a newer version of this patch at
https://lore.kernel.org/dri-devel/20210706084753.8194-1-tzimmerm...@suse.de/
Best regards
Thomas
Am 24.06.21 um 11:03 schrieb Thomas Zimmermann:
Moving the driver-specific
This patchseries adds support for independent DSI config to DPU1 display
subdriver. Also drop one of msm_kms_funcs callbacks, made unnecessary
now.
Tested on RB5 (dpu, dsi). Previous iteration was tested by Alexey
Minnekhanov.
Changes since v1:
- renamed dual DSI to bonded DSI as suggsted by Abh
We are preparing to support two independent DSI hosts in the DSI/DPU
code. To remove possible confusion (as both configurations can be
referenced as dual DSI) let's rename old "dual DSI" (two DSI hosts
driving single device, with clocks being locked) to "bonded DSI".
Signed-off-by: Dmitry Baryshko
Move setting up encoders from set_encoder_mode to
_dpu_kms_initialize_dsi() / _dpu_kms_initialize_displayport(). This
allows us to support not only "single DSI" and "bonded DSI" but also "two
independent DSI" configurations. In future this would also help adding
support for multiple DP connectors.
Add two helper functions to be used by display drivers for setting up
encoders.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 7 +++
drivers/gpu/drm/msm/dsi/dsi_manager.c | 14 ++
drivers/gpu/drm/msm/msm_drv.h | 12 ++--
3 files chan
Move a call to mdp5_encoder_set_intf_mode() after
msm_dsi_modeset_init(), removing set_encoder_mode callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5
set_encoder_mode callback is completely unused now. Drop it from
msm_kms_func().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_kms.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 086a2d59b8c8..9484e8b62630
None of the display drivers now implement set_encoder_mode callback.
Stop calling it from the modeset init code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 2 --
drivers/gpu/drm/msm/dsi/dsi.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 ---
None of the display drivers now implement set_encoder_mode callback.
Stop calling it from the modeset init code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/d
Hi
On 08.07.21 11:35, Frank Wunderlich wrote:
Hi
just a small update, added debug in the vendor-specific functions for page_flip
and vblank and it seems they never get called
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -87,21 +87,25 @@ static
Am 03.07.21 um 01:01 schrieb Daniel Vetter:
On Fri, Jul 02, 2021 at 01:16:42PM +0200, Christian König wrote:
Drivers also need to to sync to the exclusive fence when
a shared one is present.
Completely untested since the driver won't even compile on !ARM.
It's really not that hard to set up a
Add Raphael Gallais-Pou as STM32 DRM maintainer.
Signed-off-by: Raphael Gallais-Pou
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f1171ceaf8b..4fa3bfc00f57 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6165,6 +6165,7 @@ DRM DRIVERS FOR STM
From: Guangming Cao
For dma-heap users, they can't bypass cache sync when map/unmap iova
with dma heap. But they can do it by adding DMA_ATTR_SKIP_CPU_SYNC
into dma_alloc_attrs.
To keep alignment, at dma_heap side, also use
dma_buf_attachment.dma_map_attrs to do iova map & unmap.
Signed-off-by:
On 08.07.2021 01:25, Matthew Brost wrote:
> CTB writes are now in the path of command submission and should be
> optimized for performance. Rather than reading CTB descriptor values
> (e.g. head, tail) which could result in accesses across the PCIe bus,
> store shadow local copies and only read/
Hi Thomas,
On Tue, Jul 6, 2021 at 9:45 AM Thomas Zimmermann wrote:
>
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
>
> Signed-off-by: Thomas Zimmermann
Tested-by: Martin Blume
Den 03.07.2021 21.24, skrev Peter Stuge:
> Hi Noralf,
>
> Noralf Trønnes wrote:
>> Add VID/PID for the Raspberry Pi Pico implementation.
>> Source: https://github.com/notro/gud-pico
>>
>> +++ b/drivers/gpu/drm/gud/gud_drv.c
>> @@ -660,6 +660,7 @@ static int gud_resume(struct usb_interface *intf
Hi
Am 08.07.21 um 15:31 schrieb Martin Blumenstingl:
Hi Thomas,
On Tue, Jul 6, 2021 at 9:45 AM Thomas Zimmermann wrote:
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
Signed-off
> Gesendet: Donnerstag, 08. Juli 2021 um 14:30 Uhr
> Von: "Dafna Hirschfeld"
> > i see both messages, but mtk_crtc_ddp_irq is never called and so the other
> > 2 not.
>
> Yes, In my case the irq isr is also not called after resume which cause the
> warning
> even though "enable_vblank" do get ca
From: Thierry Reding
As of commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling
clocks"), module resets are no longer automatically deasserted when the
module clock is enabled. To make sure that the gr2d module continues to
work, we need to explicitly control the module reset.
Fixe
Den 08.07.2021 01.43, 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
08.07.2021 17:37, Thierry Reding пишет:
> From: Thierry Reding
>
> As of commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling
> clocks"), module resets are no longer automatically deasserted when the
> module clock is enabled. To make sure that the gr2d module continues to
> work, w
08.07.2021 18:13, Dmitry Osipenko пишет:
>> #include "drm.h"
>> #include "gem.h"
>> @@ -19,6 +21,7 @@ struct gr2d_soc {
>> struct gr2d {
>> struct tegra_drm_client client;
>> struct host1x_channel *channel;
>> +struct reset_control *rst;
> Unused variable?
Ah, I haven't noticed th
> Gesendet: Donnerstag, 08. Juli 2021 um 11:35 Uhr
> Von: "Frank Wunderlich"
> i guess not, but is watchdog somehow involved? i ask because i see this on
> reboot/poweroff:
>
> "watchdog: watchdog0: watchdog did not stop!"
>
> i see this with my 5.13, 5.12-drm (5.12.0+mtk/core drm-patches) and 5.
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE A
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
Previously, we were storing the ring size in the ring pointer before it
was actually allocated. We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and Bei
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
bitstream
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would he
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 --
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was rea
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was orig
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero data
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 +++
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/g
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other.
This is the VM equivalent of i915_gem_context_lookup. It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c |
What we really want to check is that size of the engines array, i.e.
args->size - sizeof(*user) is divisible by the element size, i.e.
sizeof(*user->engines) because that's what's required for computing the
array length right below the check. However, we're currently not doing
this and instead doi
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
There's an extra bit of fun here when it comes to setting
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/g
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In f6e8aa38717
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other.
When the APIs were added to manage the engine set on a GEM context
directly from userspace, the questionable choice was made to allow
changing the engine set on a context at any time. This is horribly racy
and there's absolutely no reason why any userspace would want to do this
outside of trying t
When the APIs were added to manage VMs more directly from userspace, the
questionable choice was made to allow changing out the VM on a context
at any time. This is horribly racy and there's absolutely no reason why
any userspace would want to do this outside of testing that exact race.
By removin
1 - 100 of 166 matches
Mail list logo
