Re: [PATCH 09/10] drm/tidss: IRQ code cleanup

On 01/11/2023 16:52, Laurent Pinchart wrote: Hi Tomi, Thank you for the patch. On Wed, Nov 01, 2023 at 11:17:46AM +0200, Tomi Valkeinen wrote: The IRQ setup code is overly complex. All we really need to do is initialize the related fields in struct tidss_device, and request the IRQ. We can dr

Re: [PATCH 08/10] drm/tidss: Add dispc_is_idle()

On 01/11/2023 16:32, Laurent Pinchart wrote: Hi Tomi, Thank you for the patch. On Wed, Nov 01, 2023 at 11:17:45AM +0200, Tomi Valkeinen wrote: Add a helper function, dispc_is_idle(), which returns whether the DSS is idle (i.e. is any video port enabled). For now we add a call to it in the sus

Re: [PATCH v4 09/32] drm/amd/display: add plane 3D LUT driver-specific properties

Also, Melissa, you cannot do: if (!plane_state->color_mgmt_changed) return 0; in amdgpu_dm_plane_set_color_properties. The allocation for dc_plane_state could be new and zero'ed so it needs to be set every time. (Until AMDGPU has better dedup'ing of stuff there) The r

Re: [PATCH 07/10] drm/tidss: Fix dss reset

On 01/11/2023 16:30, Laurent Pinchart wrote: Hi Tomi, Thank you for the patch. On Wed, Nov 01, 2023 at 11:17:44AM +0200, Tomi Valkeinen wrote: The probe function calls dispc_softreset() before runtime PM is enabled and without enabling any of the DSS clocks. This happens to work by luck, and w

Re: [PATCH v7 6/6] drm/i915/panelreplay: Debugfs support for panel replay

On Wed, 2023-10-11 at 16:39 +0530, Animesh Manna wrote: > Add debugfs support which will print source and sink status > per connector basis. Sorry for late review. Noticed only by now that you have added this patch into you set. Can you please describe in commit message how you see the output of

[PATCH] drm/rect: only print the stack trace in drm_calc_scale() once

The kunit test triggers this stack trace deliberately. The drm_rect_scale_cases[] test cases include a negative src and a negative dst. This ends up spamming the logs and can obscure real warnings. Just print the warning once. Reported-by: Linux Kernel Functional Testing Closes: https://lore.

Re: [PATCH 10/10] drm/tidss: Fix atomic_flush check

On 01/11/2023 16:56, Laurent Pinchart wrote: Hi Tomi, Thank you for the patch. On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote: tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, returns immediately as there's no reason to do any register changes. However, the

Re: [PATCH v8 3/5] drm/sched: Split free_job into own work item

On 2023-10-30 23:24, Matthew Brost wrote: > Rather than call free_job and run_job in same work item have a dedicated > work item for each. This aligns with the design and intended use of work > queues. > > v2: >- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting > timestamp in free_job

Re: [PATCH] drm/i915/display: Only fail fastset on PSR2

On Wed, Nov 01, 2023 at 06:26:47AM +, Hogander, Jouni wrote: > On Tue, 2023-10-31 at 23:21 +, Paz Zcharya wrote: > > Currently, i915 fails fastset if both the sink and the source support > > any version of PSR and regardless of the configuration setting of the > > driver (i.e., i915.enable_

[BUG] gpu: drm: amd: noretry=0 causes failure in amdgpu_device_ip_resume on vega10

Hi, When migrateing from 5.15 to 6.5.9 i noticed that noretry no longer function on vega10 (Instinct MI25). The device will fail to start: [ 40.080411] amdgpu: fw load failed [ 40.083816] amdgpu: smu firmware loading failed [ 40.088350] amdgpu :83:00.0: amdgpu: amdgpu_device_ip_resume f

Re: [PATCH v8 0/5] DRM scheduler changes for Xe

On 2023-10-30 23:24, Matthew Brost wrote: > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we > have been asked to merge our common DRM scheduler patches first. > > This a continuation of a RFC [3] with all comments addressed, ready for > a full review, and hopefully in st

Re: [PATCH] drm/edid: add a quirk for two 240Hz Samsung monitors

On Wed, 01 Nov 2023, Alex Deucher wrote: > On Wed, Nov 1, 2023 at 5:01 PM Hamza Mahfooz wrote: >> >> Without this fix the 5120x1440@240 timing of these monitors >> leads to screen flickering. >> >> Cc: sta...@vger.kernel.org # 6.1+ >> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442 >>

Re: [PATCH] drm/i915: Remove unused for_each_uabi_class_engine

On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: > On 01/11/2023 10:06, Jani Nikula wrote: >> On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt >>> code") >>> removed some code. >>> >>> Signed-off-by

Re: [accel/ivpu] Help -- Which Intel CPU processor can be used for iVPU driver？

Hi, You need a Meteor Lake based platform. Intel 14th gen desktop CPUs were supposed to be Meteor Lake but they ended up as Raptor Lake. NPU (formerly known as VPU) will be available in 14th gen mobile chips. I will update the Kconfig description. Regards, Jacek On 02.11.2023 07:59, Trigger Hua

mainline build failure due to 7966f319c66d ("drm/amd/display: Introduce DML2")

Hi All, The latest mainline kernel branch fails to build x86_64 allmodconfig with the error: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In function 'dml_prefetch_check': drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6707:1: error: the frame size of 20

[PATCH 1/2] drm/i915: Remove unused for_each_uabi_class_engine

From: Tvrtko Ursulin Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code. Signed-off-by: Tvrtko Ursulin Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i

[PATCH 2/2] drm/i915: Move for_each_engine* out of i915_drv.h

From: Tvrtko Ursulin Iterators operate on struct intel_gt so lets move it to intel_gt.h in order to make i915_drv.h less of a dumping ground for stuff. Signed-off-by: Tvrtko Ursulin Suggested-by: Jani Nikula --- drivers/gpu/drm/i915/gt/intel_engine_pm.h | 1 + drivers/gpu/drm/i915/g

Re: [PATCH v2 0/6] drm/edid: split out drm_eld.[ch], add some SAD helpers

On Tue, 31 Oct 2023, Jani Nikula wrote: > v2 of https://patchwork.freedesktop.org/series/123384/ > > Jani Nikula (6): > drm/edid: split out drm_eld.h from drm_edid.h > drm/eld: replace uint8_t with u8 > drm/edid: include drm_eld.h only where required > drm/edid: use a temp variable for sad

Re: [PATCH] drm/i915: Remove unused for_each_uabi_class_engine

On 02/11/2023 09:24, Jani Nikula wrote: On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: On 01/11/2023 10:06, Jani Nikula wrote: On Wed, 01 Nov 2023, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code

Re: [PATCH 1/7] drm: Do not round to megabytes for greater than 1MiB sizes in fdinfo stats

On 26/10/2023 15:43, Tvrtko Ursulin wrote: On 28/09/2023 13:47, Tvrtko Ursulin wrote: On 27/09/2023 14:48, Steven Price wrote: On 27/09/2023 14:38, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It is better not to lose precision and not revert to 1 MiB size granularity for every size greate

[PATCH] drm/i915: Fix potential spectre vulnerability

Fix smatch warning: drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu() warn: potential spectre issue 'pc->user_engines' [r] (local cap) Signed-off-by: chentao --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dri

Re: [PATCH drm-misc-next v8 09/12] drm/gpuvm: reference count drm_gpuvm structures

Hi Danilo, kernel test robot noticed the following build warnings: [auto build test WARNING on 3c6c7ca4508b6cb1a033ac954c50a1b2c97af883] url: https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-gpuvm-convert-WARN-to-drm_WARN-variants/20231102-073332 base

Re: [PATCH 2/3] drm/scheduler: Fix UAF in drm_sched_fence_get_timeline_name

Am 01.11.23 um 09:13 schrieb Daniel Vetter: On Wed, 1 Nov 2023 at 07:59, Dave Airlie wrote: Well, to make it clear once more: Signaling a dma_fence from the destructor of a reference counted object is very problematic! This will be rejected no matter if you do that in C or in Rust. What we can

Re: [PATCH v2 0/2] fbdev/simplefb: Add missing simple-framebuffer features

Hi, On 11/1/23 18:54, Hans de Goede wrote: > Hi, > > On 11/1/23 18:20, Thierry Reding wrote: >> From: Thierry Reding >> >> Hi, >> >> This contains two patches that bring simplefb up to feature parity with >> simpledrm. The patches add support for the "memory-region" property that >> provides an

[PATCH 0/5] Some drm scheduler internal renames

From: Tvrtko Ursulin I found some of the naming a bit incosistent and unclear so just a small attempt to clarify and tidy some of them. See what people think if my first stab improves things or not. Cc: Luben Tuikov Cc: Matthew Brost Tvrtko Ursulin (5): drm/sched: Rename drm_sched_get_clean

[PATCH 3/5] drm/sched: Rename drm_sched_free_job_queue to be more descriptive

From: Tvrtko Ursulin The current name makes it sound like helper will free a queue, while what it does is it enqueues the free job worker. Rename it to drm_sched_run_free_queue to align with existing drm_sched_run_job_queue. Despite that creating an illusion there are two queues, while in reali

[PATCH 2/5] drm/sched: Move free worker re-queuing out of the if block

From: Tvrtko Ursulin Whether or not there are more jobs to clean up does not depend on the existance of the current job, given both drm_sched_get_finished_job and drm_sched_free_job_queue_if_done take and drop the job list lock. Therefore it is confusing to make it read like there is a dependency

[PATCH 1/5] drm/sched: Rename drm_sched_get_cleanup_job to be more descriptive

From: Tvrtko Ursulin "Get cleanup job" makes it sound like helper is returning a job which will execute some cleanup, or something, while the kerneldoc itself accurately says "fetch the next _finished_ job". So lets rename the helper to be self documenting. Signed-off-by: Tvrtko Ursulin Cc: Lub

[PATCH 4/5] drm/sched: Rename drm_sched_run_job_queue_if_ready and clarify kerneldoc

From: Tvrtko Ursulin "If ready" is not immediately clear what it means - is the scheduler ready or something else? Drop the suffix, clarify kerneldoc, and employ the same naming scheme as in drm_sched_run_free_queue: - drm_sched_run_job_queue - enqueues if there is something to enqueue

[PATCH 5/5] drm/sched: Drop suffix from drm_sched_wakeup_if_can_queue

From: Tvrtko Ursulin Because a) helper is exported to other parts of the scheduler and b) there isn't a plain drm_sched_wakeup to begin with, I think we can drop the suffix and by doing so separate the intimiate knowledge between the scheduler components a bit better. Signed-off-by: Tvrtko Ursul

Re: [accel/ivpu] Help -- Which Intel CPU processor can be used for iVPU driver？

Hi Jacek, Thanks for the quick response. Seems I need to wait for a while if I want to buy a Meteor Lake based platform because I got the following message from wiki( *https://en.wikipedia.org/wiki/Meteor_Lake )* *Meteor Lake is Intel's code

Re: [PATCH v8 3/5] drm/sched: Split free_job into own work item

On 31/10/2023 03:24, Matthew Brost wrote: Rather than call free_job and run_job in same work item have a dedicated work item for each. This aligns with the design and intended use of work queues. v2: - Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting timestamp in free_job() work

Re: [PATCH 2/3] drm/scheduler: Fix UAF in drm_sched_fence_get_timeline_name

Am Donnerstag, dem 02.11.2023 um 11:48 +0100 schrieb Christian König: [...] > I was considering to change the dma_fence semantics so that > dma_fence_signal() could only be called from the interrupt contexts of > devices and then put a big fat WARN_ON(!in_interrupt()) in there. > > It's a sledge

Re: [PATCH] drm/i915: Fix potential spectre vulnerability

On 02/11/2023 10:16, chentao wrote: Fix smatch warning: drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu() warn: potential spectre issue 'pc->user_engines' [r] (local cap) Signed-off-by: chentao I don't know if this is actually exploitable given the time deltas between the

Re: [PATCH 2/2] drm/i915: Move for_each_engine* out of i915_drv.h

On Thu, 02 Nov 2023, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Iterators operate on struct intel_gt so lets move it to intel_gt.h in > order to make i915_drv.h less of a dumping ground for stuff. > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Jani Nikula Reviewed-by: Jani Nikula >

Re: [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

On Wed, Nov 01, 2023 at 12:01:31PM +0100, Hans de Goede wrote: > On 11/1/23 11:20, Hans de Goede wrote: ... > Attached is this patch, this should probably be one of > the first patches in the v3 submission. Thanks, noted! > Note that if you go with Ville's suggestion to preparse > the MIPI sequ

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

Hi, Jaak, On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja wrote: > > On 31.10.23 14:17, Huacai Chen wrote: > > Hi, Jaak and Evan, > > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen wrote: > >> > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja wrote: > >>> > >>> On 26.10.23 03:58, Huacai Chen wro

Re: [PATCH 2/3] drm/scheduler: Fix UAF in drm_sched_fence_get_timeline_name

Am 02.11.23 um 12:19 schrieb Lucas Stach: Am Donnerstag, dem 02.11.2023 um 11:48 +0100 schrieb Christian König: [...] I was considering to change the dma_fence semantics so that dma_fence_signal() could only be called from the interrupt contexts of devices and then put a big fat WARN_ON(!in_inte

Re: [RFC PATCH v4 1/7] drm/panel: nv3052c: Document known register names

On Mon, Oct 30, 2023 at 8:24 AM John Watts wrote: > Many of these registers have a known name in the public datasheet. > Document them as comments for reference. > > Signed-off-by: John Watts > Reviewed-by: Jessica Zhang This makes things better so: Reviewed-by: Linus Walleij Yours, Linus Wa

Re: [RFC PATCH v4 4/7] drm/panel: nv3052c: Add Fascontek FS035VG158 LCD display

On Mon, Oct 30, 2023 at 8:24 AM John Watts wrote: > This display is extremely similar to the LTK035C5444T, but still has > some minor variations in panel initialization. > > Signed-off-by: John Watts > Reviewed-by: Jessica Zhang Reviewed-by: Linus Walleij Yours, Linus Walleij

Re: [RFC 02/11] drm: move lru_lock from ttm_device to drm_device

Am 02.11.23 um 05:32 schrieb Oak Zeng: In the coming patches, we will share the lru list b/t ttm bo based memory allocator and hmm/svm based memory allocator. Thus lru_lock (which is used mainly to protect the lru list) is moved from struct ttm_device to struct drm_device, so this lock can be sha

Re: [RFC PATCH v4 2/7] drm/panel: nv3052c: Add SPI device IDs

On Mon, Oct 30, 2023 at 8:24 AM John Watts wrote: > SPI drivers needs their own list of compatible device IDs in order > for automatic module loading to work. Add those for this driver. > > Signed-off-by: John Watts > Reviewed-by: Jessica Zhang Reviewed-by: Linus Walleij Yours, Linus Walleij

[PULL] drm-misc-fixes

Hi, this is the PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2023-11-02: Short summary of fixes pull: syncobj: - Fix waiting for DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE vc4: - Fix UAF in mock helpers The following changes since commit b132ac51d7a50c37683be56c96ff64f8c887930f: acc

[PATCH] drm/panel: starry-2081101qfh032011-53g: Fine tune the panel power sequence

For "starry, 2081101qfh032011-53g" this panel, it is stipulated in the panel spec that MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high. Signed-off-by: xiazhengqiao --- drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dri

[PATCH v6 2/7] drm/client: Export drm_client_dev_unregister()

Export drm_client_dev_unregister() for use by the i915 driver. The driver does not use drm_dev_unregister(), so it has to clean up the in-kernel DRM clients by itself. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_client.c | 13 + 1 file changed, 13 insertions(+) diff --g

[PATCH v6 0/7] drm/i915: Convert fbdev to DRM client

Convert i915's fbdev code to struct drm_client. Replaces the current ad-hoc integration. The conversion includes a number of cleanups. The patchset also enables unloading of driver modules with in-kernel DRM clients; a feature required by i915. As with the other drivers' fbdev emulation, fbdev in

[PATCH v6 3/7] drm/i915: Unregister in-kernel clients

Unregister all in-kernel clients before unloading the i915 driver. For other drivers, drm_dev_unregister() does this automatically. As i915 does not use this helper, it has to perform the call by itself. Note that there are currently no in-kernel clients in i915. The patch prepares the driver for

[PATCH v6 1/7] drm/client: Do not acquire module reference

Do not acquire a reference on the module that provides a client's callback functions in drm_client_init(). The additional reference prevents the user from unloading the callback functions' module and thus creating dangling pointers. This is only necessary if there is no direct dependency between t

[PATCH v6 6/7] drm/i915: Implement fbdev client callbacks

Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform

[PATCH v6 4/7] drm/i915: Move fbdev functions

Move functions within intel_fbdev.c to simplify later updates. Minor style fixes to make checkpatch happy, but no functional changes. v5: * style fixes (checkpatch) Signed-off-by: Thomas Zimmermann Reviewed-by: Jouni Högander --- drivers/gpu/drm/i915/display/intel_fbdev.c | 154 +++

[PATCH v6 7/7] drm/i915: Implement fbdev emulation as in-kernel client

Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to intel_fbdev_setup() after i915 has registered its DRM device. Just like similar code in other drivers, i915 fbdev emulation now acts like a regular DRM client

[PATCH v6 5/7] drm/i915: Initialize fbdev DRM client with callback functions

Initialize i915's fbdev client by giving an instance of struct drm_client_funcs to drm_client_init(). Also clean up with drm_client_release(). Doing this in i915 prevents fbdev helpers from initializing and releasing the client internally (see drm_fb_helper_init()). No functional change yet; the c

Re: [PATCH drm-misc-next v8 12/12] drm/nouveau: use GPUVM common infrastructure

On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote: > GPUVM provides common infrastructure to track external and evicted > GEM > objects as well as locking and validation helpers. > > Especially external and evicted object tracking is a huge improvement > compared to the current brute force

Re: [PATCH drm-misc-next v8 02/12] drm/gpuvm: don't always WARN in drm_gpuvm_check_overflow()

On Thu, 2023-11-02 at 00:30 +0100, Danilo Krummrich wrote: > Don't always WARN in drm_gpuvm_check_overflow() and separate it into > a > drm_gpuvm_check_overflow() and a dedicated > drm_gpuvm_warn_check_overflow() variant. > > This avoids printing warnings due to invalid userspace requests. > > Si

Re: [PATCH drm-misc-next v8 03/12] drm/gpuvm: export drm_gpuvm_range_valid()

On Thu, 2023-11-02 at 00:30 +0100, Danilo Krummrich wrote: > Drivers may use this function to validate userspace requests in > advance, > hence export it. > > Signed-off-by: Danilo Krummrich Reviewed-by: Thomas Hellström > --- >  drivers/gpu/drm/drm_gpuvm.c | 14 +- >  include/drm/dr

Re: [PATCH drm-misc-next v8 09/12] drm/gpuvm: reference count drm_gpuvm structures

On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote: > Implement reference counting for struct drm_gpuvm. > > Signed-off-by: Danilo Krummrich Will port the Xe series over to check that it works properly and get back with review on this one. > --- >  drivers/gpu/drm/drm_gpuvm.c   

Re: [RFC 03/11] drm: introduce drm evictable LRU

Am 02.11.23 um 05:32 schrieb Oak Zeng: drm LRU manager is introuced for resource eviction purpose. It maintains a LRU list per resource type. Shouldn't we first add the possible resource types in a separate patch? It provides functions to add or remove resource to or from the list. It also

Re: [PATCH drm-misc-next v8 10/12] drm/gpuvm: add an abstraction for a VM / BO combination

On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote: > Add an abstraction layer between the drm_gpuva mappings of a > particular > drm_gem_object and this GEM object itself. The abstraction represents > a > combination of a drm_gem_object and drm_gpuvm. The drm_gem_object > holds > a list of

Re: [PATCH] drm/amdgpu: don't put MQDs in VRAM on ARM | ARM64

Am 31.10.23 um 18:54 schrieb Alex Deucher: Issues were reported with commit 1cfb4d612127 ("drm/amdgpu: put MQDs in VRAM") on an ADLINK Ampere Altra Developer Platform (AVA developer platform). Various ARM systems seem to have problems related to PCIe and MMIO access. In this case, I'm not sure

Re: [PATCH] gpu/drm/drm_framebuffer.c: Use Macro instead of actual number.

Hi Am 02.11.23 um 03:29 schrieb Peng Hao: Use Macro DRM_FORMAT_MAX_PLANES instead of 4, to improve modifiability. Signed-off-by: Peng Hao --- drivers/gpu/drm/drm_framebuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gp

[PULL] drm-misc-next-fixes

Hi Daniel, Dave, Just 2 small ssd130x fixes. Cheers, ~Maarten drm-misc-next-fixes-2023-11-02: drm-misc-next-fixes for v6.7-rc1: - dt binding fix for ssd132x - Initialize ssd130x crtc_state to NULL. The following changes since commit b70438004a14f4d0f9890b3297cd66248728546c: drm/amdgpu: mov

[PATCH v1 0/4] Rockchip rk3066_hdmi update

Update the Rockchip rk3066_hdmi driver in a somewhat similar way to what is proposed for the inno_hdmi driver. Johan Jonker (4): drm/rockchip: rk3066_hdmi: Remove useless mode_fixup drm/rockchip: rk3066_hdmi: Switch encoder hooks to atomic drm/rockchip: rk3066_hdmi: Remove useless output for

[PATCH v1 1/4] drm/rockchip: rk3066_hdmi: Remove useless mode_fixup

The mode_fixup implementation doesn't do anything, so we can simply remove it. Signed-off-by: Johan Jonker --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c index

[PATCH v1 2/4] drm/rockchip: rk3066_hdmi: Switch encoder hooks to atomic

The rk3066_hdmi encoder still uses the non atomic variants of enable and disable. Convert to their atomic equivalents. In atomic mode there is no need to save the adjusted mode, so remove the mode_set function. Signed-off-by: Johan Jonker --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 35 +

[PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format

The Rk3066 hdmi output format is hard coded to RGB. Remove all useless code related to colorimetry and enc_out_format. Signed-off-by: Johan Jonker --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +--- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/drivers/gpu/drm/r

[PATCH v1 4/4] drm/rockchip: rk3066_hdmi: Remove unused drm device pointer

The drm_dev field in the rk3066_hdmi struct stores a pointer to the DRM device but is never used anywhere in the driver. Let's remove it. Signed-off-by: Johan Jonker --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rk3066_hd

[PATCH v2 1/3] drm/amdgpu: Don't implicit sync PRT maps.

These are considered map operations rather than unmap, and there is no point of doing implicit synchronization here. Signed-off-by: Tatsuyuki Ishi --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

[PATCH v2 2/3] drm/amdgpu: Add flag to disable implicit sync for GEM operations.

In Vulkan, it is the application's responsibility to perform adequate synchronization before a sparse unmap, replace or BO destroy operation. Until now, the kernel applied the same rule as implicitly-synchronized APIs like OpenGL, which with per-VM BOs made page table updates stall the queue comple

[PATCH v2 0/3] drm/amdgpu: Add flag to disable implicit sync for GEM operations.

In Vulkan, it is the application's responsibility to perform adequate synchronization before a sparse unmap, replace or BO destroy operation. This adds an option to AMDGPU_VA_OPs to disable redundant implicit sync that happens on sparse unmap or replace operations. This has seen a significant impr

Re: [PATCH] gpu/drm/drm_framebuffer.c: Use Macro instead of actual number.

Good idea! > From: "Thomas Zimmermann" > Date: Thu, Nov 2, 2023, 21:27 > Subject: Re: [PATCH] gpu/drm/drm_framebuffer.c: Use Macro instead of actual > number. > To: "Peng Hao", , > , , > Cc: , > Hi > > Am 02.11.23 um 03:29 schrieb Peng Hao: > > Use Macro DRM_FORMAT_MAX_PLANES instead of 4, t

[PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones: this means that in order to request poweroff of cores, we are supposed to write a bitmask of cores that should be powered off! This means that the panfros

Re: [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote: > On 11/1/23 10:32, Andy Shevchenko wrote: > > On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote: > >> On 10/31/23 17:07, Hans de Goede wrote: > >>> On 10/24/23 18:11, Andy Shevchenko wrote: > On Tue, Oct 24, 2023 at 06

[PATCH v2 3/3] drm/amdgpu: Bump amdgpu driver version.

For detection of the new explicit sync functionality without having to try the ioctl. Signed-off-by: Tatsuyuki Ishi --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amd

[PATCH v2 0/6] drm/panfrost: Turn off clocks and regulators in PM

Changes in v2: - Added hard reset GPU recovery - Tightened polling time for soft reset and power on - New execution time measurements after poweroff fix (see [1]) [1]: https://lore.kernel.org/all/20231102141507.73481-1-angelogioacchino.delre...@collabora.com/ At least MediaTek platforms are a

[PATCH v2 5/6] drm/panfrost: Implement ability to turn on/off regulators in suspend

Some platforms/SoCs can power off the GPU entirely by completely cutting off power, greatly enhancing battery time during system suspend: add a new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators during full suspend only on selected platforms. Signed-off-by: AngeloGioacchino Del

[PATCH v2 6/6] drm/panfrost: Set regulators on/off during system sleep on MediaTek SoCs

All of the MediaTek SoCs supported by Panfrost can completely cut power to the GPU during full system sleep without any user-noticeable delay in the resume operation, as shown by measurements taken on multiple MediaTek SoCs. As an example, for MT8195 - a "before" with only runtime PM operations (s

[PATCH v2 2/6] drm/panfrost: Tighten polling for soft reset and power on

In many cases, soft reset takes more than 1 microsecond, but definitely less than 10; moreover in the poweron flow, tilers, shaders and l2 will become ready (each) in less than 10 microseconds as well. Even in the cases (at least on my platforms, rarely) in which those take more than 10 microsecon

Re: [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 11/2/23 15:19, Andy Shevchenko wrote: > On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote: >> On 11/1/23 10:32, Andy Shevchenko wrote: >>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote: On 10/31/23 17:07, Hans de Goede wrote: > On 10/24/23 18:11, Andy Sh

[PATCH v2 1/6] drm/panfrost: Perform hard reset to recover GPU if soft reset fails

Even though soft reset should ideally never fail, during development of some power management features I managed to get some bits wrong: this resulted in GPU soft reset failures, where the GPU was never able to recover, not even after suspend/resume cycles, meaning that the only way to get function

Re: [PATCH 3/3] drm/panel-edp: Choose correct preferred mode

Hi, On Wed, Nov 1, 2023 at 11:31 PM Dmitry Baryshkov wrote: > > On Wed, 1 Nov 2023 at 23:26, Hsin-Yi Wang wrote: > > > > If a non generic edp-panel is under aux-bus, the mode read from edid would > > still be selected as preferred and results in multiple preferred modes, > > which is ambiguous.

[PATCH v2 4/6] drm/panfrost: Set clocks on/off during system sleep on MediaTek SoCs

All of the MediaTek SoCs supported by Panfrost can switch the clocks off and on during system sleep to save some power without any user experience penalty. Measurements taken on multiple MediaTek SoCs show that adding this will not prolong the time that is required to resume the system in any mean

[PATCH v2 3/6] drm/panfrost: Implement ability to turn on/off GPU clocks in suspend

Currently, the GPU is being internally powered off for runtime suspend and turned back on for runtime resume through commands sent to it, but note that the GPU doesn't need to be clocked during the poweroff state, hence it is possible to save some power on selected platforms. Add suspend and resum

Re: [PATCH 07/10] drm/tidss: Fix dss reset

On Wed, Nov 01, 2023 at 11:17:44AM +0200, Tomi Valkeinen wrote: > The probe function calls dispc_softreset() before runtime PM is enabled > and without enabling any of the DSS clocks. This happens to work by > luck, and we need to make sure the DSS HW is active and the fclk is > enabled. Not sure

Fbdev issue after the drm updates 'drm-next-2023-10-31-1'

Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message:  [    0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please c

[PATCH v12 0/4] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support

This path series aims to add support for RZ/G2L DU DRM driver. RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video signal processor (VSPD) and Display unit(DU). The output of LCDC is connected to Display parallel interface and MIPI link video interface. The output from DS

[PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support

The LCD controller is composed of Frame Compression Processor (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU). It has DPI/DSI interfaces and supports a maximum resolution of 1080p along with 2 RPFs to support the blending of two picture layers and raster operations (ROPs). The DU mo

[PATCH v3 11/15] drm/i915/dsi: Extract common soc_gpio_set_value() helper

Extract a common soc_gpio_set_value() helper that may be used by a few SoCs. Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 46 +++- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/

[PATCH v3 13/15] drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO communities

Currently soc_gpio_set_value() supports only a single indexing for GPIO pin. For CHV case, for example, we will need to distinguish community based index from the one that VBT is using. Introduce an additional parameter to soc_gpio_set_value() and its callers. Signed-off-by: Andy Shevchenko ---

[PATCH v3 14/15] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

It's a dirty hack in the driver that pokes GPIO registers behind the driver's back. Moreoever it might be problematic as simultaneous I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl: cherryview: prevent concurrent access to GPIO controllers") for the details. Taking all this into con

[rft, PATCH v3 00/15] drm/i915/dsi: 2nd attempt to get rid of IOSF GPIO

DSI code for VBT has a set of ugly GPIO hacks, one of which is direct talking to GPIO IP behind the actual driver's back. A second attempt to fix that is here. If I understood correctly, my approach should work in the similar way as the current IOSF GPIO. Hans, I believe you have some devices tha

Re: [PATCH 10/10] drm/tidss: Fix atomic_flush check

On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote: > tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, > returns immediately as there's no reason to do any register changes. > > However, the code checks for 'crtc->state->enable', which does not > reflect the actual

[PATCH v3 02/15] drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915

From: Jani Nikula Follow the contemporary conventions. Cc: Andy Shevchenko Cc: Hans de Goede Signed-off-by: Jani Nikula Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/

[PATCH v12 1/4] dt-bindings: display: Document Renesas RZ/G2L DU bindings

The RZ/G2L LCD controller is composed of Frame Compression Processor (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU). The DU module supports the following hardware features − Display Parallel Interface (DPI) and MIPI LINK Video Interface − Display timing master − Generates video timi

[PATCH v3 05/15] drm/i915/dsi: bxt/icl GPIO set value do not need gpio source

From: Jani Nikula Drop the unused parameter. Cc: Andy Shevchenko Cc: Hans de Goede Signed-off-by: Jani Nikula Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/displa

[PATCH v3 03/15] drm/i915/dsi: clarify GPIO exec sequence

From: Jani Nikula With the various sequence versions and pointer increments interleaved, it's a bit hard to decipher what's going on. Add separate paths for different sequence versions. Cc: Andy Shevchenko Cc: Hans de Goede Signed-off-by: Jani Nikula Signed-off-by: Andy Shevchenko --- drive

[PATCH v3 09/15] drm/i915/dsi: Remove GPIO lookup table at the end of intel_dsi_vbt_gpio_init()

From: Hans de Goede To properly deal with GPIOs used in MIPI panel sequences a temporary GPIO lookup will be used. Since there can only be 1 GPIO lookup table for the ":00:02.0" device this will not work if the GPIO lookup table used by intel_dsi_vbt_gpio_init() is still registered. After ge

[PATCH v3 12/15] drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back

It's a dirty hack in the driver that pokes GPIO registers behind the driver's back. Moreoever it might be problematic as simultaneous I/O may hang the system, see the commit 40ecab551232 ("pinctrl: baytrail: Really serialize all register accesses") for the details. Taking all this into consideratio

Re: [rft, PATCH v3 00/15] drm/i915/dsi: 2nd attempt to get rid of IOSF GPIO

On Thu, Nov 02, 2023 at 05:12:13PM +0200, Andy Shevchenko wrote: > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct > talking to GPIO IP behind the actual driver's back. A second attempt > to fix that is here. > > If I understood correctly, my approach should work in the simil

[PATCH v3 07/15] drm/i915/dsi: Get rid of redundant 'else'

In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Reviewed-by: Andi Shyti Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 58 +

[PATCH v3 04/15] drm/i915/dsi: rename platform specific *_exec_gpio() to *_gpio_set_value()

From: Jani Nikula The lowest level functions are about setting GPIO values, not about executing any sequences anymore. Cc: Andy Shevchenko Cc: Hans de Goede Signed-off-by: Jani Nikula Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--

  1   2   >