[PATCH v13 4/4] drm/panfrost: Add mt8183-mali compatible string

Add support for MT8183's G72 Bifrost. Signed-off-by: Nicolas Boichat Reviewed-by: Tomeu Vizoso Reviewed-by: Steven Price --- (no changes since v7) Changes in v7: - Fix GPU ID in commit message Changes in v6: - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too.

[PATCH v13 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1

GPUs with more than a single regulator (e.g. G72 on MT8183) will require platform-specific handling for devfreq, for 2 reasons: 1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator) does not support multiple regulators, so we'll need custom handlers. 2. Generally, platforms

[PATCH v13 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat --- (no changes since v12) Changes in v12: - binding: Fix min/maxItems logic (Rob Herring) Changes in v11: - binding: power-domain-names not power-domainS-names Changes in

[PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU

Hi! This is just a rebase of the v11, untested (but it seems like Neil Armstrong recently tested it), with small changes in binding and dts. v11 cover follows: Follow-up on the v5 [1], things have gotten significantly better in the last year, thanks to the efforts on Bifrost support by the

[PATCH] drm/i915/dp: Use slow and wide link training for everything

Screen flickers on Innolux eDP 1.3 panel when clock rate 54 is in use. According to the panel vendor, though clock rate 54 is advertised, but the max clock rate it really supports is 27. Ville Syrjälä mentioned that fast and narrow also breaks some eDP 1.4 panel, so use slow and wide

Re: [PATCH v12 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1

Argh sorry I messed up the rebase and this doesn't even build... I'll send v13. On Wed, Apr 21, 2021 at 8:19 AM Nicolas Boichat wrote: > > GPUs with more than a single regulator (e.g. G72 on MT8183) will > require platform-specific handling for devfreq, for 2 reasons: > 1. The opp core

Re: [PATCH 1/2] drm/mediatek: set panel orientation before drm_dev_register().

On Wed, Apr 21, 2021 at 7:47 AM Chun-Kuang Hu wrote: > > Hi, Hsin-Yi: > > Hsin-Yi Wang 於 2021年4月20日 週二 下午5:05寫道： > > > > On Fri, Apr 9, 2021 at 12:53 PM Hsin-Yi Wang wrote: > > > > > > drm_dev_register() sets connector->registration_state to > > > DRM_CONNECTOR_REGISTERED and dev->registered to

[PATCH v12 4/4] drm/panfrost: Add mt8183-mali compatible string

Add support for MT8183's G72 Bifrost. Signed-off-by: Nicolas Boichat Reviewed-by: Tomeu Vizoso Reviewed-by: Steven Price --- (no changes since v7) Changes in v7: - Fix GPU ID in commit message Changes in v6: - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too.

[PATCH v12 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1

GPUs with more than a single regulator (e.g. G72 on MT8183) will require platform-specific handling for devfreq, for 2 reasons: 1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator) does not support multiple regulators, so we'll need custom handlers. 2. Generally, platforms

[PATCH v12 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat --- Changes in v12: - binding: Fix min/maxItems logic (Rob Herring) Changes in v11: - binding: power-domain-names not power-domainS-names Changes in v10: - Fix the binding to

[PATCH v12 0/4] drm/panfrost: Add support for mt8183 GPU

Hi! This is just a rebase of the v11, untested (but it seems like Neil Armstrong recently tested it), with small changes in binding and dts. v11 cover follows: Follow-up on the v5 [1], things have gotten significantly better in the last year, thanks to the efforts on Bifrost support by the

Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

On Tue, Apr 20, 2021 at 9:01 PM Rob Herring wrote: > > On Mon, Jan 25, 2021 at 7:18 PM Nicolas Boichat wrote: > > > > Define a compatible string for the Mali Bifrost GPU found in > > Mediatek's MT8183 SoCs. > > > > Signed-off-by: Nicolas Boichat > > --- > > > > Changes in v11: > > - binding:

Re: [PATCH 35/40] drm/amd/amdgpu/amdgpu_cs: Repair some function naming disparity

Applied. Thanks! Alex On Fri, Apr 16, 2021 at 11:54 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:685: warning: expecting prototype > > for cs_parser_fini(). Prototype

Re: [PATCH 33/40] drm/amd/amdgpu/amdgpu_ring: Provide description for 'sched_score'

Applied. Thanks! Alex On Fri, Apr 16, 2021 at 11:54 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:169: warning: Function parameter > > or member 'sched_score' not

Re: [PATCH 32/40] drm/amd/amdgpu/amdgpu_ttm: Fix incorrectly documented function 'amdgpu_ttm_copy_mem_to_mem()'

Applied. Thanks! Alex On Fri, Apr 16, 2021 at 11:53 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:311: warning: expecting prototype > > for

Re: [PATCH 31/40] drm/amd/amdgpu/amdgpu_gart: Correct a couple of function names in the docs

Applied. thanks! Alex On Fri, Apr 16, 2021 at 11:53 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:73: warning: expecting prototype > > for amdgpu_dummy_page_init().

Re: [PATCH 29/40] drm/amd/amdgpu/amdgpu_fence: Provide description for 'sched_score'

Applied. Thanks! Alex On Fri, Apr 16, 2021 at 11:52 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:444: warning: Function > > parameter or member 'sched_score' not

Re: [PATCH 25/40] drm/radeon/radeon_device: Provide function name in kernel-doc header

Applied. Thanks! Alex On Fri, Apr 16, 2021 at 11:51 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts > > with '/**', but isn't a

Re: [PATCH 26/40] drm/amd/amdgpu/amdgpu_device: Remove unused variable 'r'

Applied. Thanks! Alex On Fri, Apr 16, 2021 at 10:38 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function > ‘amdgpu_device_suspend’: > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3733:6: warning: variable ‘r’ set

Re: [PATCH 1/2] drm/mediatek: set panel orientation before drm_dev_register().

Hi, Hsin-Yi: Hsin-Yi Wang 於 2021年4月20日 週二 下午5:05寫道： > > On Fri, Apr 9, 2021 at 12:53 PM Hsin-Yi Wang wrote: > > > > drm_dev_register() sets connector->registration_state to > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If > > drm_connector_set_panel_orientation() is first called

Re: [PATCH v3 3/3] drm/msm/dp: check main link status before start aux read

Quoting Kuogee Hsieh (2021-04-16 10:38:51) > Maybe when the cable is disconnected the DP phy should be shutdown and > some bit in the phy could effectively "cut off" the aux channel and then > NAKs would start coming through here in the DP controller I/O register > space. This patch have DP aux

Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints

On Tue, Apr 20, 2021 at 3:18 AM Daniel Stone wrote: > > Hi, > > On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote: >> >> I'm working on a Wayland extension [1] that, among other things, allows >> compositors to advertise the preferred device to be used by Wayland >> clients. >> >> In general,

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

On Tue, Apr 20, 2021 at 05:19:52PM +0200, Neil Armstrong wrote: > On 20/04/2021 17:13, Hans Verkuil wrote: > > On 16/04/2021 13:38, Neil Armstrong wrote: > >> On 16/04/2021 11:58, Laurent Pinchart wrote: > >>> Hi Neil, > >>> > >>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: >

Re: [PATCH 1/2] drm/msm/dp: service only one irq_hpd if there are multiple irq_hpd pending

Quoting Kuogee Hsieh (2021-04-16 13:27:57) > Some dongle may generate more than one irq_hpd events in a short period of > time. This patch will treat those irq_hpd events as single one and service > only one irq_hpd event. Why is it bad to get multiple irq_hpd events in a short period of time?

Re: [PATCH 23/40] drm/ttm/ttm_bo: Fix incorrectly documented function 'ttm_bo_cleanup_refs'

On Fri, Apr 16, 2021 at 11:32 AM Christian König wrote: > > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/ttm/ttm_bo.c:293: warning: expecting prototype for > > function ttm_bo_cleanup_refs(). Prototype was for

Re: 16 bpc fixed point (RGBA16) framebuffer support for core and AMD.

On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner wrote: > > Friendly ping to the AMD people. Nicholas, Harry, Alex, any feedback? > Would be great to get this in sooner than later. > No objections from me. Alex > Thanks and have a nice weekend, > -mario > > On Fri, Mar 19, 2021 at 10:03 PM

Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling wrote: > > > Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter: > >>> Whole series is Reviewed-by: Christian König > >> Thanks a lot. If I'm not mistaken, the patches at [1] need to go in first. > >> So it could take a a bit until this lands. > >> >

Re: [PATCH RESEND][next] drm/nouveau: Fix fall-through warnings for Clang

Hi all, Friendly ping: who can take this, please? Thanks -- Gustavo On 3/5/21 03:56, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple > of warnings by explicitly adding a couple of break statements instead > of letting the code fall through to

Re: [PATCH RESEND][next] drm/nouveau/therm: Fix fall-through warnings for Clang

Hi all, Friendly ping: who can take this, please? Thanks -- Gustavo On 3/5/21 03:58, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > >

Re: [PATCH RESEND][next] drm/nouveau/clk: Fix fall-through warnings for Clang

Hi all, Friendly ping: who can take this, please? Thanks -- Gustavo On 3/5/21 03:56, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 20:30, Daniel Vetter wrote: > The thing is, you can't do this in drm/scheduler. At least not without > splitting up the dma_fence in the kernel into separate memory fences > and sync fences I'm starting to think this thread needs its own glossary ... I propose we

Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter: >>> Whole series is Reviewed-by: Christian König >> Thanks a lot. If I'm not mistaken, the patches at [1] need to go in first. >> So it could take a a bit until this lands. >> >> Otherwise, this series could go through the same tree as [1] if

Re: [PATCH 1/1] video: hyperv_fb: Add ratelimit on error message

On Tue, 2021-04-20 at 08:44 -0700, Michael Kelley wrote: > Due to a full ring buffer, the driver may be unable to send updates to > the Hyper-V host. But outputing the error message can make the problem > worse because console output is also typically written to the frame > buffer. As a result,

Re: [PATCH 1/1] video: hyperv_fb: Add ratelimit on error message

On Tue, Apr 20, 2021 at 08:44:19AM -0700, Michael Kelley wrote: > Due to a full ring buffer, the driver may be unable to send updates to > the Hyper-V host. But outputing the error message can make the problem > worse because console output is also typically written to the frame > buffer. As a

[PATCH 1/1] video: hyperv_fb: Add ratelimit on error message

Due to a full ring buffer, the driver may be unable to send updates to the Hyper-V host. But outputing the error message can make the problem worse because console output is also typically written to the frame buffer. As a result, in some circumstances the error message is output continuously.

Re: [PATCH v2 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

On Tuesday, April 20, 2021 7:49:35 PM CEST Daniel Vetter wrote: > On Mon, Apr 19, 2021 at 05:03:40PM +0200, Fabio M. De Francesco wrote: > > Replace the deprecated API with new helpers, according to the TODO list > > of the DRM subsystem. The new API has been introduced with commit > >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 9:14 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 19:54, Daniel Vetter wrote: >> >> So I can mostly get behind this, except it's _not_ going to be >> dma_fence. That thing has horrendous internal ordering constraints >> within the kernel, and the one thing

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 9:17 PM Jason Ekstrand wrote: > > On Tue, Apr 20, 2021 at 1:54 PM Daniel Vetter wrote: > > > > On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote: > > > > > And something more concrete: > > > > > > dma_fence. > > > > > > This already has all of the properties described

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 2:39 PM Daniel Vetter wrote: > On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote: > > > > Daniel, imagine hardware that can only do what Windows does: future > fences signalled by userspace whenever userspace wants, and no kernel > queues like we have today. > > > > The

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 20:03, Bas Nieuwenhuizen wrote: > On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone wrote: > >> It's a jarring transition. If you take a very narrow view and say 'it's >> all GPU work in shared buffers so it should all work the same', then >> client<->winsys looks the

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 1:54 PM Daniel Vetter wrote: > > On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote: > > > And something more concrete: > > > > dma_fence. > > > > This already has all of the properties described above. Kernel-wise, it > > already devolves to CPU-side signaling when it

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 19:54, Daniel Vetter wrote: > So I can mostly get behind this, except it's _not_ going to be > dma_fence. That thing has horrendous internal ordering constraints > within the kernel, and the one thing that doesn't allow you is to make > a dma_fence depend upon a

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone wrote: > On Tue, 20 Apr 2021 at 19:00, Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 20.04.21 um 19:44 schrieb Daniel Stone: >> >> But winsys is something _completely_ different. Yes, you're using the GPU >> to do things with

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand wrote: >> >> It's still early in the morning here and I'm not awake yet so sorry if >> this comes out in bits and pieces... > > > No problem, it's helpful. If I weren't on this thread I'd

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote: > > Daniel, imagine hardware that can only do what Windows does: future fences > signalled by userspace whenever userspace wants, and no kernel queues like we > have today. > > The only reason why current AMD GPUs work is because they have a

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, 20 Apr 2021 at 19:00, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 19:44 schrieb Daniel Stone: > > But winsys is something _completely_ different. Yes, you're using the GPU > to do things with buffers A, B, and C to produce buffer Z. Yes, you're > using

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, 20 Apr 2021 at 17:25, Marek Olšák wrote: > Daniel, imagine hardware that can only do what Windows does: future fences > signalled by userspace whenever userspace wants, and no kernel queues like > we have today. > > The only reason why current AMD GPUs work is because they have a ring >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 19:44 schrieb Daniel Stone: Hi, On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand > wrote: It's still early in the morning here and I'm not awake yet so sorry if this comes out in bits and pieces... No problem, it's helpful. If I weren't on

Re: [PATCH v2 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

On Mon, Apr 19, 2021 at 05:03:40PM +0200, Fabio M. De Francesco wrote: > Replace the deprecated API with new helpers, according to the TODO list > of the DRM subsystem. The new API has been introduced with commit > b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset > locks

Re: [PATCH] drm/bochs: Add screen blanking support

Hi Am 20.04.21 um 18:56 schrieb Takashi Iwai: On bochs DRM driver, the execution of "setterm --blank force" results in a frozen screen instead of a blank screen. It's due to the lack of the screen blanking support in its code. Actually, the QEMU bochs vga side can switch to the blanking mode

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand wrote: > It's still early in the morning here and I'm not awake yet so sorry if > this comes out in bits and pieces... > No problem, it's helpful. If I weren't on this thread I'd be attempting to put together a 73-piece chest of drawers whose

Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin wrote: > > > On 19/04/2021 16:19, Jason Ekstrand wrote: > > On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote: > >> > >> On 16/04/2021 17:38, Jason Ekstrand wrote: > >>> On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld > >>> wrote: > >

[PATCH] drm/bochs: Add screen blanking support

On bochs DRM driver, the execution of "setterm --blank force" results in a frozen screen instead of a blank screen. It's due to the lack of the screen blanking support in its code. Actually, the QEMU bochs vga side can switch to the blanking mode when the bit 0x20 is cleared on VGA_ATT_IW

Re: [PATCH] drm/connector: demote connector force-probes for non-master clients

On Tuesday, April 20th, 2021 at 11:14 AM, Daniel Vetter wrote: > Do we have an igt for this? Timing test should do the job I think, > assuming we have at least one output which requires an edid read (so maybe > skip the test if a forced probe takes less than 10ms or so). Err, an igt that only

[PATCH] freedreno/a6xx: Add a few registers

Add a few new registers for a6xx gpu. Signed-off-by: Akhil P Oommen --- registers/adreno/a6xx.xml | 2 ++ registers/adreno/a6xx_gmu.xml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/registers/adreno/a6xx.xml b/registers/adreno/a6xx.xml index 15314fb..3b04565 100644 ---

Re: [PATCH v4 00/27] drm: Fix EDID reading on ti-sn65dsi86; solve some chicken-and-egg problems

Hi, On Fri, Apr 16, 2021 at 3:40 PM Douglas Anderson wrote: > > The primary goal of this series is to try to properly fix EDID reading > for eDP panels using the ti-sn65dsi86 bridge. > > Previously we had a patch that added EDID reading but it turned out > not to work at bootup. This caused some

[PATCH] freedreno/a6xx: Add a few registers

Add a few new registers for a6xx gpu. Signed-off-by: Akhil P Oommen --- registers/adreno/a6xx.xml | 2 ++ registers/adreno/a6xx_gmu.xml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/registers/adreno/a6xx.xml b/registers/adreno/a6xx.xml index 15314fb..3b04565 100644 ---

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021, 09:25 Marek Olšák wrote: > Daniel, imagine hardware that can only do what Windows does: future fences > signalled by userspace whenever userspace wants, and no kernel queues like > we have today. > Hmm, that sounds kinda like what we're trying to do for Libre-SOC's gpu

Re: [PATCH] drm: Fix fbcon blank on QEMU graphics drivers

On Fri, 16 Apr 2021 20:30:05 +0200, Daniel Vetter wrote: > > On Fri, Apr 16, 2021 at 2:53 PM Takashi Iwai wrote: > > > > Currently the DRM fbcon helper for console blank, > > drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always > > returns zero, supposing the driver dealing with

Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

On 19/04/2021 16:19, Jason Ekstrand wrote: On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote: On 16/04/2021 17:38, Jason Ekstrand wrote: On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote: Add an entry for the new uAPI needed for DG1. v2(Daniel): - include the overall upstreaming

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Daniel, imagine hardware that can only do what Windows does: future fences signalled by userspace whenever userspace wants, and no kernel queues like we have today. The only reason why current AMD GPUs work is because they have a ring buffer per queue with pointers to userspace command buffers

Re: [PATCH v3 2/5] dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings

On Mon, 19 Apr 2021 09:32:41 +0200, Neil Armstrong wrote: > Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings. > > Signed-off-by: Neil Armstrong > --- > .../devicetree/bindings/display/mediatek/mediatek,cec.yaml | 1 + >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 9:10 AM Daniel Vetter wrote: > > On Tue, Apr 20, 2021 at 1:59 PM Christian König > wrote: > > > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > > the kernel's problem. > > > > Well, the path of inner peace begins with four words. “Not my

Re: [PATCH v3 1/5] dt-bindings: display: mediatek, hdmi: Convert to use graph schema

On Mon, 19 Apr 2021 09:32:40 +0200, Neil Armstrong wrote: > Update the mediatek,dpi binding to use the graph schema. > > Signed-off-by: Neil Armstrong > --- > .../display/mediatek/mediatek,cec.yaml| 51 +++ > .../display/mediatek/mediatek,hdmi-ddc.yaml | 57 >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Sorry for the mega-reply but timezones... On Tue, Apr 20, 2021 at 6:59 AM Christian König wrote: > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > the kernel's problem. > > Well, the path of inner peace begins with four words. “Not my fucking > problem.” 律 >

Re: [PATCH 4/5] drm/i915/stolen: pass the allocation flags

On 20/04/2021 14:18, Matthew Auld wrote: From: CQ Tang Stolen memory is always allocated as physically contiguous pages, mark the object flags as such. v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin ---

Re: [PATCH 1/5] drm/i915: Create stolen memory region from local memory

On 20/04/2021 14:18, Matthew Auld wrote: From: CQ Tang Add "REGION_STOLEN" device info to dg1, create stolen memory region from upper portion of local device memory, starting from DSMBASE. v2: - s/drm_info/drm_dbg; userspace likely doesn't care about stolen. - mem->type is only

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 16:16, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 17:07 schrieb Daniel Stone: > > If the compositor no longer has a guarantee that the buffer will be ready > for composition in a reasonable amount of time (which dma_fence gives us, >

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

It's still early in the morning here and I'm not awake yet so sorry if this comes out in bits and pieces... On Tue, Apr 20, 2021 at 7:43 AM Daniel Stone wrote: > > Hi Marek, > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: >> >> 2. Explicit synchronization for window systems and modesetting

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

On 20/04/2021 17:13, Hans Verkuil wrote: > On 16/04/2021 13:38, Neil Armstrong wrote: >> On 16/04/2021 11:58, Laurent Pinchart wrote: >>> Hi Neil, >>> >>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: This adds DW-HDMI driver a glue option to disable loading of the CEC

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 17:07 schrieb Daniel Stone: On Tue, 20 Apr 2021 at 15:58, Christian König > wrote: Am 20.04.21 um 16:53 schrieb Daniel Stone: On Mon, 19 Apr 2021 at 11:48, Marek Olšák mailto:mar...@gmail.com>> wrote: Deadlock

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

On 16/04/2021 13:38, Neil Armstrong wrote: > On 16/04/2021 11:58, Laurent Pinchart wrote: >> Hi Neil, >> >> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: >>> This adds DW-HDMI driver a glue option to disable loading of the CEC >>> sub-driver. >>> >>> On some SoCs, the CEC

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 16:53 schrieb Daniel Stone: Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák > wrote: Deadlock mitigation to recover from segfaults: - The kernel knows which process is obliged to signal which fence. This information is part of the Present

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, 20 Apr 2021 at 15:58, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 16:53 schrieb Daniel Stone: > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > >> Deadlock mitigation to recover from segfaults: >> - The kernel knows which process is obliged to signal

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 09:25:51, peter.enderb...@sony.com wrote: > On 4/20/21 11:12 AM, Michal Hocko wrote: > > On Tue 20-04-21 09:02:57, peter.enderb...@sony.com wrote: > But that isn't really system memory at all, it's just allocated device > memory. > >>> OK, that was not really clear to me.

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 4:48 PM, Daniel Stone wrote: > On Tue, 20 Apr 2021 at 14:46, > wrote: > > On 4/20/21 3:34 PM, Daniel Stone wrote: > > On Fri, 16 Apr 2021 at 13:34, Peter Enderborg

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > Deadlock mitigation to recover from segfaults: > - The kernel knows which process is obliged to signal which fence. This > information is part of the Present request and supplied by userspace. > - If the producer crashes, the kernel signals

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

On Tue, 20 Apr 2021 at 14:46, wrote: > On 4/20/21 3:34 PM, Daniel Stone wrote: > > On Fri, 16 Apr 2021 at 13:34, Peter Enderborg > wrote: > > This adds a total used dma-buf memory. Details > > can be found in debugfs, however it is not for everyone > >

[PATCH] drm/ttm: fix error handling if no BO can be swapped out

In case that all pre-allocated BOs are busy, just continue to populate BOs since likely half of system memory in total is still free. Signed-off-by: Shiwu Zhang --- drivers/gpu/drm/ttm/ttm_device.c | 4 ++-- drivers/gpu/drm/ttm/ttm_tt.c | 2 ++ 2 files changed, 4 insertions(+), 2

Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge

Hi Frieder, On Tue, Apr 20, 2021 at 01:42:05PM +0200, Frieder Schrempf wrote: > On 23.02.21 13:07, Daniel Vetter wrote: > > On Thu, Feb 18, 2021 at 5:02 PM Andrzej Hajda wrote: > >> W dniu 18.02.2021 o 09:04, Michael Tretter pisze: > >>> On Wed, 10 Feb 2021 10:10:37 +0100, Frieder Schrempf

Re: [PATCH] drm/i915: fix an error code in intel_overlay_do_put_image()

On Wed, Apr 14, 2021 at 09:02:24AM +0300, Dan Carpenter wrote: > This code should propagate the error from intel_overlay_pin_fb() > but currently it returns success. > > Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane") > Signed-off-by: Dan Carpenter Reviewed-by:

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 1:59 PM Christian König wrote: > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > the kernel's problem. > > Well, the path of inner peace begins with four words. “Not my fucking > problem.” > > But I'm not that much concerned about the

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 3:04 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote: >> >> - We live in a post xf86-video-$vendor world, and all these other >> compositors rely on implicit sync. You're not going to be able to get >> rid of them anytime soon.

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 3:34 PM, Daniel Stone wrote: > Hi Peter, > > On Fri, 16 Apr 2021 at 13:34, Peter Enderborg > wrote: > > This adds a total used dma-buf memory. Details > can be found in debugfs, however it is not for everyone > and not always available.

Re: [Intel-gfx] [PULL] topic/intel-gen-to-ver -> drm-intel-next and drm-intel-gt-next

On Tue, Apr 20, 2021 at 12:47:36PM +0300, Joonas Lahtinen wrote: > Quoting Jani Nikula (2021-04-19 12:53:11) > > > > Hi Joonas and Rodrigo - > > > > Here's the gen to ver conversion topic branch to be merged to both > > drm-intel-next and drm-intel-gt-next. > > Pulled. Pulled, thanks. (Sorry

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

Hi Peter, On Fri, 16 Apr 2021 at 13:34, Peter Enderborg wrote: > This adds a total used dma-buf memory. Details > can be found in debugfs, however it is not for everyone > and not always available. dma-buf are indirect allocated by > userspace. So with this value we can monitor and detect >

[PATCH 3/4] drm/mediatek: fine tune the dsi panel's power sequence

Add the drm_panel_prepare_power and drm_panel_unprepare_power control. Turn on panel power(drm_panel_prepare_power) and control before dsi enable. And then dsi enable, send dcs cmd in drm_panel_prepare, last turn on backlight. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dsi.c | 12

[PATCH 1/4] drm/panel: seperate panel power control from panel prepare/unprepare

Some dsi panels require the dsi lanes keeping low before panel power on. So seperate the panel power control and the communication with panel. And put the power control in drm_panel_prepare_power and drm_panel_unprepare_power. Put the communication with panel in drm_panel_prepare and

[PATCH 4/4] drm/mediatek: add dsi module reset driver

Reset dsi HW to default when power on. Prevent the setting differet between bootloader and kernel. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dsi.c | 36 +- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git

[PATCH 2/4] drm/panel: boe-tv101wum-n16 seperate the panel power control

Seperate the panel power control from prepare/unprepare. Signed-off-by: Jitao Shi --- .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 72 +-- 1 file changed, 50 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c

[PATCH 5/5] drm/i915/lmem: Fail driver init if LMEM training failed

From: Matt Roper Boot firmware performs memory training and health assessment during startup. If the memory training fails, the firmware will consider the GPU unusable and will instruct the punit to keep the GT powered down. If this happens, our driver will be unable to communicate with the GT

[PATCH 4/5] drm/i915/stolen: pass the allocation flags

From: CQ Tang Stolen memory is always allocated as physically contiguous pages, mark the object flags as such. v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c |

[PATCH 2/5] drm/i915/stolen: treat stolen local as normal local memory

Underneath it's the same stuff, so things like the PTE_LM bits for the GTT should just keep working as-is. Signed-off-by: Matthew Auld Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH 3/5] drm/i915/stolen: enforce the min_page_size contract

From: CQ Tang Since stolen can now be device local-memory underneath, we should try to enforce any min_page_size restrictions when allocating pages. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 --- 1

[PATCH 1/5] drm/i915: Create stolen memory region from local memory

From: CQ Tang Add "REGION_STOLEN" device info to dg1, create stolen memory region from upper portion of local device memory, starting from DSMBASE. v2: - s/drm_info/drm_dbg; userspace likely doesn't care about stolen. - mem->type is only setup after the region probe, so setting the name

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 09:02:57, peter.enderb...@sony.com wrote: > > >> But that isn't really system memory at all, it's just allocated device > >> memory. > > OK, that was not really clear to me. So this is not really accounted to > > MemTotal? If that is really the case then reporting it into the oom

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote: > - We live in a post xf86-video-$vendor world, and all these other > compositors rely on implicit sync. You're not going to be able to get > rid of them anytime soon. What's worse, all the various EGL/vk buffer > sharing things also

Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

On Mon, Jan 25, 2021 at 7:18 PM Nicolas Boichat wrote: > > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > --- > > Changes in v11: > - binding: power-domain-names not power-domainS-names > > Changes in v10: > - Fix the

Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

On Fri, Feb 5, 2021 at 9:02 PM Nicolas Boichat wrote: > > On Sat, Feb 6, 2021 at 1:55 AM Rob Herring wrote: > > > > On Tue, 26 Jan 2021 09:17:56 +0800, Nicolas Boichat wrote: > > > Define a compatible string for the Mali Bifrost GPU found in > > > Mediatek's MT8183 SoCs. > > > > > >

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi Marek, On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > *2. Explicit synchronization for window systems and modesetting* > > The producer is an application and the consumer is a compositor or a > modesetting driver. > > *2.1. The Present request* > So the 'present request' is an ioctl,

  1   2   >