Re: [PATCH RESEND] drm/mediatek: Add valid modifier check

On Tue, Jul 25, 2023 at 1:59 AM Justin Green wrote: > > Add a check to mtk_drm_mode_fb_create() that rejects any modifier that > is not the AFBC mode supported by MT8195's display overlays. > > Tested by booting ChromeOS and verifying the UI works, and by running > the ChromeOS kms_addfb_basic bin

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

On Tuesday, July 25th, 2023 at 04:55, André Almeida wrote: > It's not clear what we should do about non-robust OpenGL apps after GPU > resets, so I'll try to summarize the topic, show some options and my > proposal to move forward on that. > > Em 27/06/2023 10:23, André Almeida escreveu: > > >

Re: [PATCH] drm/shmem-helper: Reset vma->vm_ops before calling dma_buf_mmap()

On Mon, 24 Jul 2023 13:26:10 +0200 Boris Brezillon wrote: > The dma-buf backend is supposed to provide its own vm_ops, but some > implementation just have nothing special to do and leave vm_ops > untouched, probably expecting this field to be zero initialized (this > is the case with the system_h

Re: [PATCH v14 01/12] drm/shmem-helper: Factor out pages alloc/release from drm_gem_shmem_get/put_pages()

On Sun, 23 Jul 2023 02:47:35 +0300 Dmitry Osipenko wrote: > Factor out pages allocation from drm_gem_shmem_get_pages() into > drm_gem_shmem_acquire_pages() function and similar for the put_pages() > in a preparation for addition of shrinker support to drm-shmem. > > Once shrinker will be added,

Re: [PATCH v2 02/47] mm: shrinker: remove redundant shrinker_rwsem in debugfs operations

> On Jul 24, 2023, at 17:43, Qi Zheng wrote: > > The debugfs_remove_recursive() will wait for debugfs_file_put() to return, > so the shrinker will not be freed when doing debugfs operations (such as > shrinker_debugfs_count_show() and shrinker_debugfs_scan_write()), so there > is no need to ho

Re: [PATCH v2 01/47] mm: vmscan: move shrinker-related code into a separate file

> On Jul 25, 2023, at 11:09, Qi Zheng wrote: > > > > On 2023/7/25 10:35, Muchun Song wrote: >>> On Jul 24, 2023, at 17:43, Qi Zheng wrote: >>> >>> The mm/vmscan.c file is too large, so separate the shrinker-related >>> code from it into a separate file. No functional changes. >>> >>> Sign

[PATCH] drm/radeon: Fix format error

Fix the error(s): ERROR: space required before the open parenthesis '(' Signed-off-by: Yonggang Wu --- drivers/gpu/drm/radeon/r300.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index 9c1a92fa2af6..252

Re: [PATCH v2 01/47] mm: vmscan: move shrinker-related code into a separate file

> On Jul 24, 2023, at 17:43, Qi Zheng wrote: > > The mm/vmscan.c file is too large, so separate the shrinker-related > code from it into a separate file. No functional changes. > > Signed-off-by: Qi Zheng > --- > include/linux/shrinker.h | 3 + > mm/Makefile | 4 +- > mm/shrin

Re: [Nouveau] [PATCH] drm/nouveau/fifo:Fix Nineteen occurrences of the gk104.c error: ERROR: space prohibited before that ':' (ctx:WxW) ERROR: trailing statements should be on next line ERROR: space p

not sure how i got signed up for this and i don’t see a way to unsubscribe. this is flooding my email with things i don’t care about. On Fri, Jul 14, 2023, at 1:14 AM, huzhi...@208suo.com wrote: > Signed-off-by: ZhiHu > --- > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++--

Re: [PATCH] drm/mgag200: Increase bandwidth for G200se A rev1

Thomas, Hello, I'm the user who reported the issue. Definitely happy to help you sort this out if I can, though my response speed will decrease when term restarts in October. > I'd be interested in the exact model and the unique_rev_id > (you said A, rev1 ?) The machine is an Intel SR1625URR

Re: [PATCH v6 11/11] drm/mediatek: dp: Don't register HPD interrupt handler for eDP case

Il 25/07/23 08:37, CK Hu (胡俊光) ha scritto: Hi, Angelo: On Mon, 2023-07-17 at 16:14 +0200, AngeloGioacchino Del Regno wrote: External email : Please do not click links or open attachments until you have verified the sender or the content. The interrupt handler for HPD is useful only i

Re: [PATCH v2 2/4] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI

On 16.12.22 22:07, Lucas Stach wrote: > Add a simple wrapper driver for the DWC HDMI bridge driver that > implements the few bits that are necessary to abstract the i.MX8MP > SoC integration. > > Signed-off-by: Lucas Stach > Reviewed-by: Laurent Pinchart > Tested-by: Marek Vasut I tested this

Re: [PATCH v2 4/4] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

On 16.12.22 22:07, Lucas Stach wrote: > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a > full timing generator and can switch between different video sources. On > the i.MX8MP however the only supported source is the LCDIF. The block > just needs to be powered up and told

Re: [PATCH v14 02/12] drm/shmem-helper: Add pages_pin_count field

On Sun, 23 Jul 2023 02:47:36 +0300 Dmitry Osipenko wrote: > And new pages_pin_count field to struct drm_gem_shmem_object that will > determine whether pages are evictable by memory shrinker. The pages will > be evictable only when pages_pin_count=0. This patch prepares code for > addition of the

[PATCH v7 00/11] MediaTek DisplayPort: support eDP and aux-bus

Changes in v7: - Fixed snippet removal, moved from patch [11/11] to [9/11] where it actually belongs to, as in patch 9/11 I'm moving that snippet to a new function. Changes in v6: - Added some previously missing error checking (patch [01/11]) - Added error checks for devm_drm_bridge_add()

[PATCH v7 02/11] drm/mediatek: dp: Move AUX and panel poweron/off sequence to function

Everytime we run bridge detection and/or EDID read we run a poweron and poweroff sequence for both the AUX and the panel; moreover, this is also done when enabling the bridge in the .atomic_enable() callback. Move this power on/off sequence to a new mtk_dp_aux_panel_poweron() function as to common

[PATCH v7 01/11] drm/mediatek: dp: Add missing error checks in mtk_dp_parse_capabilities

If reading the RX capabilities fails the training pattern will be set wrongly: add error checking for drm_dp_read_dpcd_caps() and return if anything went wrong with it. While at it, also add a less critical error check when writing to clear the ESI0 IRQ vector. Fixes: f70ac097a2cf ("drm/mediatek:

[PATCH v7 04/11] drm/mediatek: dp: Use devm variant of drm_bridge_add()

In preparation for adding support for aux-bus, which will add a code path that may fail after the drm_bridge_add() call, change that to devm_drm_bridge_add() to simplify failure paths later. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai Reviewed-by: CK Hu Reviewed-by: Alexa

[PATCH v7 06/11] drm/mediatek: dp: Enable event interrupt only when bridge attached

It is useless and error-prone to enable the DisplayPort event interrupt before finishing to probe and install the driver, as the DP training cannot happen before the entire pipeline is correctly set up, as the interrupt handler also requires the full hardware to be initialized by mtk_dp_bridge_atta

[PATCH v7 11/11] drm/mediatek: dp: Don't register HPD interrupt handler for eDP case

The interrupt handler for HPD is useful only if a display is actually supposed to be hotpluggable, as that manages the machinery to perform cable (un)plug detection, debouncing and setup for re-training. Since eDP panels are not supposed to be hotpluggable we can avoid using the HPD interrupts alt

[PATCH v7 09/11] drm/mediatek: dp: Add support for embedded DisplayPort aux-bus

For the eDP case we can support using aux-bus on MediaTek DP: this gives us the possibility to declare our panel as generic "panel-edp" which will automatically configure the timings and available modes via the EDID that we read from it. To do this, move the panel parsing at the end of the probe f

[PATCH v7 10/11] drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus

In order to support usecases in which the panel regulator can be switched on and off to save power, and usecases in which the panel regulator is off at boot, add a .wait_hpd_asserted() callback for the AUX bus: this will make sure to wait until the panel is fully ready after power-on before trying

[PATCH v7 05/11] drm/mediatek: dp: Move AUX_P0 setting to mtk_dp_initialize_aux_settings()

Move the register write to MTK_DP_AUX_P0_3690 to set the AUX reply mode to function mtk_dp_initialize_aux_settings(), as this is effectively part of the DPTX AUX setup sequence. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai Reviewed-by: CK Hu Reviewed-by: Alexandre Mergnat

[PATCH v7 07/11] drm/mediatek: dp: Avoid mutex locks if audio is not supported/enabled

If a controller (usually, eDP!) does not support audio, or audio is not enabled because the endpoint has no audio support, it's useless to lock a mutex only to unlock it right after because there's no .plugged_cb(). Check if the audio is supported and enabled before locking the mutex in mtk_dp_upd

[PATCH v7 03/11] drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()

Change logging from drm_{err,info}() to dev_{err,info}() in functions mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be essential to avoid getting NULL pointer kernel panics if any kind of error happens during AUX transfers happening before the bridge is attached. This may potential

[PATCH v7 08/11] drm/mediatek: dp: Move PHY registration to new function

In preparation for adding support for eDP, move the PHY registration code to a new mtk_dp_register_phy() function for better readability. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai Reviewed-by: Alexandre Mergnat --- drivers/gpu

Re: [PATCH v14 10/12] drm/shmem-helper: Refactor locked/unlocked functions

On Sun, 23 Jul 2023 02:47:44 +0300 Dmitry Osipenko wrote: > Add locked/unlocked postfixes to drm-shmem function names to make clear > where reservation lock is taken and where not. Uh, ignore my comment on patch 1 then... > Add more common helpers to drm_gem_shmem_helper.h I'd do the renaming

Re: [PATCH v14 12/12] drm/gem: Add _unlocked postfix to drm_gem_pin/unpin()

On Sun, 23 Jul 2023 02:47:46 +0300 Dmitry Osipenko wrote: > Make clear that drm_gem_pin/unpin() functions take reservation lock by > adding _unlocked postfix to the function names. > > Suggested-by: Boris Brezillon > Signed-off-by: Dmitry Osipenko I'm still a bit confused by the fact we somet

Re: [PATCH v14 10/12] drm/shmem-helper: Refactor locked/unlocked functions

On Tue, 25 Jul 2023 09:47:02 +0200 Boris Brezillon wrote: > On Sun, 23 Jul 2023 02:47:44 +0300 > Dmitry Osipenko wrote: > > > Add locked/unlocked postfixes to drm-shmem function names to make clear > > where reservation lock is taken and where not. > > Uh, ignore my comment on patch 1 then..

[PATCH] dma_buf/sync_file: Enable signaling for fences when querying status

From: Mikko Perttunen dma_fence_get_status is not guaranteed to return valid information on if the fence has been signaled or not if SW signaling has not been enabled for the fence. To ensure valid information is reported, enable SW signaling for fences before getting their status. Signed-off-by

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

On 7/25/23 04:55, André Almeida wrote: > Hi everyone, > > It's not clear what we should do about non-robust OpenGL apps after GPU > resets, so I'll try to summarize the topic, show some options and my proposal > to move forward on that. > > Em 27/06/2023 10:23, André Almeida escreveu: >> +Robus

Re: [PATCH v14 02/12] drm/shmem-helper: Add pages_pin_count field

On Tue, 25 Jul 2023 09:27:09 +0200 Boris Brezillon wrote: > On Sun, 23 Jul 2023 02:47:36 +0300 > Dmitry Osipenko wrote: > > > And new pages_pin_count field to struct drm_gem_shmem_object that will > > determine whether pages are evictable by memory shrinker. The pages will > > be evictable only

Re: [PATCH v5 9/9] drm: selftest: convert drm_mm selftest to KUnit

Hi, On Thu, Apr 27, 2023 at 03:14:39PM +0200, Maxime Ripard wrote: > Hi, > > On Fri, Jul 08, 2022 at 05:30:52PM -0300, Maíra Canal wrote: > > From: Arthur Grillo > > > > Considering the current adoption of the KUnit framework, convert the > > DRM mm selftest to the KUnit API. > > > > Signed-of

Re: [PATCH] drm: support up to 128 drm devices

On Mon, 17 Jul 2023 at 14:54, Simon Ser wrote: > > On Monday, July 17th, 2023 at 15:24, Emil Velikov > wrote: > > > > > For going forward, here is one way we can shave this yak: > > > > - update libdrm to max 64 nodes > > > > - roll libdrm release, nag distributions to update to it // could be

Re: [PATCH v5 9/9] drm: selftest: convert drm_mm selftest to KUnit

On Tue, 25 Jul 2023 at 16:38, Maxime Ripard wrote: > > Hi, > > On Thu, Apr 27, 2023 at 03:14:39PM +0200, Maxime Ripard wrote: > > Hi, > > > > On Fri, Jul 08, 2022 at 05:30:52PM -0300, Maíra Canal wrote: > > > From: Arthur Grillo > > > > > > Considering the current adoption of the KUnit framework,

Re: [PATCH v2 03/47] mm: shrinker: add infrastructure for dynamically allocating shrinker

Hi Muchun, On 2023/7/25 17:02, Muchun Song wrote: On 2023/7/24 17:43, Qi Zheng wrote: Currently, the shrinker instances can be divided into the following three types: a) global shrinker instance statically defined in the kernel, such as     workingset_shadow_shrinker. b) global shrinker ins

Re: [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk

On Tue, Jul 25, 2023 at 11:22:52AM +0530, Nautiyal, Ankit K wrote: > > On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote: > > On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote: > > > Currently we assume 2 Pixels Per Clock (PPC) while computing > > > plane cdclk and min_cdlck. In cases

Re: [PATCH 05/19] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp

On Mon, Jul 24, 2023 at 05:49:11PM +0530, Nautiyal, Ankit K wrote: > Hi Stan, > > Thanks for the reviews ans suggestions. Please my response inline: > > > On 7/20/2023 2:59 PM, Lisovskiy, Stanislav wrote: > > On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit Nautiyal wrote: > > > In Bigjoiner chec

[PATCH] dt-bindings: display: msm: sm6125-mdss: drop unneeded status from examples

Example DTS should not have 'status' property. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml | 6 -- 1 file changed, 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml b/Documentation/devicet

Re: [PATCH RESEND] drm/mediatek: Add valid modifier check

On Mon, 24 Jul 2023 at 18:58, Justin Green wrote: > + if (cmd->modifier[0] && > This is not DRM_FORMAT_MOD_INVALID. Please either explicitly compare against INVALID if that's what you meant, or against LINEAR if that's what you meant, or both. Cheers, Daniel

[PATCH] drm/i915: Replace i915->gt0 with to_gt(i915)

Quite surprised to see that around i915 there are still i915->gt0 references. Replace them with the to_gt() helper. Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- drivers/gpu/drm/i915/gt/intel_region

RE: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

[AMD Official Use Only - General] > -Original Message- > From: Limonciello, Mario > Sent: Monday, July 24, 2023 9:41 PM > To: Andrew Lunn ; Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch

[PATCH 6.4 043/227] dma-buf/dma-resv: Stop leaking on krealloc() failure

From: Ville Syrjälä commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream. Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fenc

[PATCH 6.1 026/183] dma-buf/dma-resv: Stop leaking on krealloc() failure

From: Ville Syrjälä commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream. Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fenc

Re: [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

On 25/07/2023 00:38, Sripada, Radhakrishna wrote: Hi Tvrtko, The changes makes sense and based on the description looks good. I am bit skeptical about the exec buffer failure reported by ci hence, withholding the r-b for now. If you believe the CI failure is unrelated please feel free to add m

Re: [PATCH 05/19] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp

On 7/25/2023 3:43 PM, Lisovskiy, Stanislav wrote: On Mon, Jul 24, 2023 at 05:49:11PM +0530, Nautiyal, Ankit K wrote: Hi Stan, Thanks for the reviews ans suggestions. Please my response inline: On 7/20/2023 2:59 PM, Lisovskiy, Stanislav wrote: On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit

Re: [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk

On 7/25/2023 3:40 PM, Lisovskiy, Stanislav wrote: On Tue, Jul 25, 2023 at 11:22:52AM +0530, Nautiyal, Ankit K wrote: On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote: On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote: Currently we assume 2 Pixels Per Clock (PPC) while computing

Re: [PATCH 3/9] drm/verisilicon: Add basic drm driver

On 2023/7/25 11:12, Keith Zhao wrote: > > > On 2023/6/7 16:53, Lucas Stach wrote: >> Hi Keith, >> >> Am Freitag, dem 02.06.2023 um 15:40 +0800 schrieb Keith Zhao: >>> Add a basic platform driver of the DRM driver for JH7110 SoC. >>> >>> Signed-off-by: Keith Zhao >>> --- >>> MAINTAINERS

Re: [PATCH v2] drm/bridge: Add debugfs print for bridge chains

Hi Tomi, Thank you for the patch. On Fri, Jul 21, 2023 at 06:01:39PM +0300, Tomi Valkeinen wrote: > DRM bridges are not visible to the userspace and it may not be > immediately clear if the chain is somehow constructed incorrectly. I > have had two separate instances of a bridge driver failing to

[PATCH][next] accel/qaic: remove redundant assignment to pointer pexec

Pointer pexec is being assigned a value however it is never read. The assignment is redundant and can be removed. Signed-off-by: Colin Ian King --- drivers/accel/qaic/qaic_data.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/accel/qaic/qaic_data.c b/drivers/accel/qaic/qaic_data.c in

Re: [PATCH] dt-bindings: display: msm: sm6125-mdss: drop unneeded status from examples

On 2023-07-25 12:16:10, Krzysztof Kozlowski wrote: > Example DTS should not have 'status' property. > > Signed-off-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml | 6 -- This is not needed: it has already been corrected in v3 and v4 of the respect

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

On 24/07/2023 21:16, Andi Shyti wrote: Hi Tvrtko, On Mon, Jul 24, 2023 at 01:56:33PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available") added a code path which does not map via GGTT, but was still setting the ggtt

Re: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages)

On Mon, Jul 24, 2023 at 08:32:45PM +, Kasireddy, Vivek wrote: > Hi Jason, > > > > > On Mon, Jul 24, 2023 at 07:54:38AM +, Kasireddy, Vivek wrote: > > > > > > I'm not at all familiar with the udmabuf use case but that sounds > > > > brittle and effectively makes this notifier udmabuf spec

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

Hi Tvrtko, > > > Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is > > > available") > > > added a code path which does not map via GGTT, but was still setting the > > > ggtt write bit, and so triggering the GGTT flushing. > > > > > > Fix it by not setting that bit unless the GGT

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Move abs_diff() to math.h

Hi Andy, On Mon, Jul 24, 2023 at 11:25:11AM +0300, Andy Shevchenko wrote: > abs_diff() belongs to math.h. Move it there. > This will allow others to use it. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Jiri Slaby # tty/serial Reviewed-by: Andi Shyti Thanks, Andi

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

Hi Michel, Em 25/07/2023 05:03, Michel Dänzer escreveu: On 7/25/23 04:55, André Almeida wrote: Hi everyone, It's not clear what we should do about non-robust OpenGL apps after GPU resets, so I'll try to summarize the topic, show some options and my proposal to move forward on that. Em 27/06

dri-devel@lists.freedesktop.org

Hi Uwe, On Fri, Jul 21, 2023 at 11:21:33PM +0200, Uwe Kleine-König wrote: > to_i915 is defined as > > container_of(dev, struct drm_i915_private, drm); > > So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify > accordingly. > > Signed-off-by: Uwe Kleine-König that's c

[PATCH] drm/amd/display: Fix missing unlock in dm_handle_mst_sideband_msg_ready_event()

Add missing mutex_unlock() in error path in dm_handle_mst_sideband_msg_ready_event(). Fixes: 4f6d9e38c4d2 ("drm/amd/display: Add polling method to handle MST reply packet") Signed-off-by: Yang Yingliang --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 + 1 file changed, 1 ins

Re: [Intel-gfx] [PATCH] drm/i915: Use the i915_vma_flush_writes helper

Hi Tvrtko, > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > @@ -68,10 +68,8 @@ flush_write_domain(struct drm_i915_gem_object *obj, > unsigned int flush_domains) > switch (obj->write_domain) { > case I915_GEM_DOMAIN_GTT: >

[PATCH v2] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

From: Tvrtko Ursulin Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available") added a code path which does not map via GGTT, but was still setting the ggtt write bit, and so triggering the GGTT flushing. Fix it by not setting that bit unless the GGTT mapping path was used, a

Re: [Intel-gfx] [PATCH] drm/i915: Replace i915->gt0 with to_gt(i915)

On 25.07.2023 12:33, Andi Shyti wrote: Quite surprised to see that around i915 there are still i915->gt0 references. Replace them with the to_gt() helper. Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c |

Re: [PATCH] Revert "fbcon: Use kzalloc() in fbcon_prepare_logo()"

On 2023/07/25 2:03, Geert Uytterhoeven wrote: > The syzbot report turned out to be a false possitive, caused by a KMSAN > problem. Indeed, after allocating the buffer, it is fully initialized > using scr_memsetw(). Hence there is no point in allocating zeroed > memory, while this does incur some

Re: [PATCH 12/17] cgroup/drm: Introduce weight based drm cgroup control

On 21/07/2023 23:17, Tejun Heo wrote: On Wed, Jul 12, 2023 at 12:46:00PM +0100, Tvrtko Ursulin wrote: +DRM scheduling soft limits +~~ Please don't say soft limits for this. It means something different for memcg, so it gets really confusing. Call it "weight based CPU

dri-devel@lists.freedesktop.org

Hi Uwe, On Fri, Jul 21, 2023 at 11:21:33PM +0200, Uwe Kleine-König wrote: > to_i915 is defined as > > container_of(dev, struct drm_i915_private, drm); > > So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify > accordingly. > > Signed-off-by: Uwe Kleine-König pushed t

Re: [Intel-gfx] [PATCH] drm/i915/huc: silence injected failure in the load via GSC path

Hi Daniele, On Thu, Jul 20, 2023 at 04:05:05PM -0700, Daniele Ceraolo Spurio wrote: > If we can't load the HuC due to an injected failure, we don't want > to throw and error and trip CI. Using the gt_probe_error macro for > logging ensure that the error is only printed if it wasn't explicitly > in

Re: [PATCH 15/17] cgroup/drm: Expose GPU utilisation

On 21/07/2023 23:20, Tejun Heo wrote: On Fri, Jul 21, 2023 at 12:19:32PM -1000, Tejun Heo wrote: On Wed, Jul 12, 2023 at 12:46:03PM +0100, Tvrtko Ursulin wrote: + drm.active_us + GPU time used by the group recursively including all child groups. Maybe instead add drm.stat and have "u

Re: [PATCH v5 2/2 RESEND] drm: panel: Add novatek nt35596s panel driver

Hi Linus, Le 23/07/2023 à 18:45, Linus Walleij a écrit : Hi Arnaud & Molly, overall the driver looks very good! On Wed, Jul 19, 2023 at 5:20 PM Arnaud Ferraris wrote: From: Molly Sophia Novatek NT35596s is a generic DSI IC that drives command and video mode panels. Add the driver for it.

Re: [PATCH 6/6] drm/format-helper: Add KUnit tests for drm_fb_memcpy()

Hi Arthur, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.5-rc3 next-20230725

Re: Consider switching to WQ_UNBOUND messages (was: Re: [PATCH v2 6/7] workqueue: Report work funcs that trigger automatic CPU_INTENSIVE mechanism)

Hi Tejun, On Wed, Jul 19, 2023 at 12:01 AM Tejun Heo wrote: > On Tue, Jul 18, 2023 at 11:54:58AM +0200, Geert Uytterhoeven wrote: > > I gave it a try on a system with an 800 MHz Cortex A9, only to discover > > it makes no difference, as that machine has 1600 BogoMIPS: > > Oops. > > > workqueue: b

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

On Tue, Jul 25, 2023 at 4:03 AM Michel Dänzer wrote: > > On 7/25/23 04:55, André Almeida wrote: > > Hi everyone, > > > > It's not clear what we should do about non-robust OpenGL apps after GPU > > resets, so I'll try to summarize the topic, show some options and my > > proposal to move forward o

RE: [PATCH v7 3/3] fault-inject: Include linux/types.h by default.

> -Original Message- > From: Ghimiray, Himal Prasad > Sent: 25 July 2023 20:40 > To: intel...@lists.freedesktop.org > Cc: Ghimiray, Himal Prasad ; De Marchi, > Lucas ; Vivi, Rodrigo ; > Nilawar, Badal > Subject: [PATCH v7 3/3] fault-inject: Include linux/types.h by default. > > Functi

Re: [PATCH] drm/radeon: ERROR: "foo * bar" should be "foo *bar"

I applied the same patch from Ran yesterday. Thanks! Alex On Tue, Jul 25, 2023 at 9:23 AM wrote: > > Fix the error(s): > ERROR: "foo * bar" should be "foo *bar" > > Signed-off-by: Yonggang Wu > --- > drivers/gpu/drm/radeon/atom.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >

Re: [PATCH] drm/radeon: Fix format error

Applied. Thanks! On Tue, Jul 25, 2023 at 3:19 AM wrote: > > Fix the error(s): > > ERROR: space required before the open parenthesis '(' > > Signed-off-by: Yonggang Wu > --- > drivers/gpu/drm/radeon/r300.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/

Re: [PATCH drm-misc-next v8 03/12] drm/nouveau: new VM_BIND uapi interfaces

On Mon, Jul 24, 2023 at 9:04 PM Danilo Krummrich wrote: > > > On 7/22/23 00:58, Faith Ekstrand wrote: > > > > On Wed, Jul 19, 2023 at 7:15 PM Danilo Krummrich > > wrote: > > > > This commit provides the interfaces for the new UAPI motivated by the > > Vulkan API.

[PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

If CONFIG_FB_CORE=y but CONFIG_FB=n, the frame buffer bootup logos can no longer be enabled. Fix this by making CONFIG_LOGO depend on CONFIG_FB_CORE instead of CONFIG_FB, as there is no good reason for the logo code to depend on the presence of real frame buffer device drivers. Fixes: 55bffc8170b

Re: [PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

Geert Uytterhoeven writes: Hello Geert, Thanks a lot for your patch! > If CONFIG_FB_CORE=y but CONFIG_FB=n, the frame buffer bootup logos can > no longer be enabled. Fix this by making CONFIG_LOGO depend on > CONFIG_FB_CORE instead of CONFIG_FB, as there is no good reason for the > logo code t

Re: [PATCH drm-misc-next v8 11/12] drm/nouveau: implement new VM_BIND uAPI

On Mon, Jul 24, 2023 at 9:04 PM Danilo Krummrich wrote: > On 7/22/23 17:12, Faith Ekstrand wrote: > > On Wed, Jul 19, 2023 at 7:15 PM Danilo Krummrich > > wrote: > > > > This commit provides the implementation for the new uapi motivated > > by the > > Vulkan A

Re: [PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

Hi Javier, On Tue, Jul 25, 2023 at 6:07 PM Javier Martinez Canillas wrote: > Geert Uytterhoeven writes: > > If CONFIG_FB_CORE=y but CONFIG_FB=n, the frame buffer bootup logos can > > no longer be enabled. Fix this by making CONFIG_LOGO depend on > > CONFIG_FB_CORE instead of CONFIG_FB, as there

Re: [Intel-gfx] [PATCH] drm/i915: Replace i915->gt0 with to_gt(i915)

Hi, On Tue, Jul 25, 2023 at 03:41:31PM +0200, Andrzej Hajda wrote: > On 25.07.2023 12:33, Andi Shyti wrote: > > Quite surprised to see that around i915 there are still i915->gt0 > > references. Replace them with the to_gt() helper. > > > > Signed-off-by: Andi Shyti > > --- > > drivers/gpu/drm/

Re: [PATCH drm-misc-next v8 11/12] drm/nouveau: implement new VM_BIND uAPI

On 7/25/23 18:16, Faith Ekstrand wrote: On Mon, Jul 24, 2023 at 9:04 PM Danilo Krummrich > wrote: On 7/22/23 17:12, Faith Ekstrand wrote: > On Wed, Jul 19, 2023 at 7:15 PM Danilo Krummrich mailto:d...@redhat.com> >

Re: [PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

Geert Uytterhoeven writes: > Hi Javier, > > On Tue, Jul 25, 2023 at 6:07 PM Javier Martinez Canillas > wrote: >> Geert Uytterhoeven writes: >> > If CONFIG_FB_CORE=y but CONFIG_FB=n, the frame buffer bootup logos can >> > no longer be enabled. Fix this by making CONFIG_LOGO depend on >> > CONFI

Re: Non-robust apps and resets (was Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations)

On 7/25/23 17:05, Marek Olšák wrote: > On Tue, Jul 25, 2023 at 4:03 AM Michel Dänzer > wrote: >> On 7/25/23 04:55, André Almeida wrote: >>> Hi everyone, >>> >>> It's not clear what we should do about non-robust OpenGL apps after GPU >>> resets, so I'll try to summarize the topic, show some option

Re: [PATCH v6 1/3] drm/panel: Fix IS_ERR() vs NULL check in nt35950_probe()

On Tue, Jul 25, 2023 at 09:39:55AM +0800, Gaosheng Cui wrote: > The mipi_dsi_device_register_full() returns an ERR_PTR() on failure, > we should use IS_ERR() to check the return value. > > By the way, use dev_err_probe instead of dev_err to print the error code. > > Fixes: 623a3531e9cf ("drm/pane

Re: [PATCH v3 1/1] drm/i915: Move abs_diff() to math.h

On Mon, Jul 24, 2023 at 11:25:11AM +0300, Andy Shevchenko wrote: > abs_diff() belongs to math.h. Move it there. > This will allow others to use it. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Jiri Slaby # tty/serial Acked-by: Greg Kroah-Hartman

[linux-next:master] BUILD REGRESSION 1e25dd7772483f477f79986d956028e9f47f990a

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 1e25dd7772483f477f79986d956028e9f47f990a Add linux-next specific files for 20230725 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202306260401.qzlyqpv2-...@intel.com https

Re: [PATCH] drm/amd/display: Fix missing unlock in dm_handle_mst_sideband_msg_ready_event()

Already applied the fix for this from Dan. Thanks! Alex On Tue, Jul 25, 2023 at 9:21 AM Yang Yingliang wrote: > > Add missing mutex_unlock() in error path in > dm_handle_mst_sideband_msg_ready_event(). > > Fixes: 4f6d9e38c4d2 ("drm/amd/display: Add polling method to handle MST reply > packet")

[PATCH] drm/gma500: remove duplicate macro definitions

Remove identical duplicate block of macro definitions in drivers/gpu/drm/gma500/psb_drv.h. Signed-off-by: Jorge Maidana --- drivers/gpu/drm/gma500/psb_drv.h | 8 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h index f7f709

Re: [PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

Hi Javier, > >> > menuconfig LOGO > >> > bool "Bootup logo" > >> > - depends on FB || SGI_NEWPORT_CONSOLE > >> > + depends on FB_CORE || SGI_NEWPORT_CONSOLE > >> > help > >> > Enable and select frame buffer bootup logos. > >> > >> Should then move this option to driver

Re: [PATCH v5 2/2 RESEND] drm: panel: Add novatek nt35596s panel driver

On Tue, Jul 25, 2023 at 4:16 PM Arnaud Ferraris wrote: > Their magic number sequences are quite different, however all the other > bits (power/reset sequences and timings) fit in, which isn't the case of > the other novatek panel drivers. Moreover, they have similar (although > not identical) res

Re: [PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

Hi Am 25.07.23 um 18:50 schrieb Javier Martinez Canillas: Geert Uytterhoeven writes: Hi Javier, On Tue, Jul 25, 2023 at 6:07 PM Javier Martinez Canillas wrote: Geert Uytterhoeven writes: If CONFIG_FB_CORE=y but CONFIG_FB=n, the frame buffer bootup logos can no longer be enabled. Fix thi

Re: [PATCH v2 -next] drm/fb-helper: Remove unused inline function drm_fb_helper_defio_init()

Hi Am 25.07.23 um 04:13 schrieb YueHaibing: Since commit 8e86dee02253 ("drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs") this inline helper not used anymore. Fixes: 8e86dee02253 ("drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs") Signed-off-by: YueHaibing R

Re: [PATCH] drm/shmem-helper: Reset vma->vm_ops before calling dma_buf_mmap()

Hi Am 24.07.23 um 13:26 schrieb Boris Brezillon: The dma-buf backend is supposed to provide its own vm_ops, but some implementation just have nothing special to do and leave vm_ops untouched, probably expecting this field to be zero initialized (this is the case with the system_heap implementati

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

> > >> @@ -1395,6 +1395,8 @@ int ieee80211_register_hw(struct > > ieee80211_hw *hw) > > >>debugfs_hw_add(local); > > >>rate_control_add_debugfs(local); > > >> > > >> + ieee80211_check_wbrf_support(local); > > >> + > > >>rtnl_lock(); > > >>wiphy_lock(hw->wiphy); > > >> > > > > > >>

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

On 7/25/2023 13:57, Andrew Lunn wrote: @@ -1395,6 +1395,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw) debugfs_hw_add(local); rate_control_add_debugfs(local); + ieee80211_check_wbrf_support(local); + rtnl_lock(); wiphy_lock(hw->wiphy); +void ieee80211_check_wbrf_s

Re: [PATCH v4] drm/ssd130x: Allocate buffers in the plane's .atomic_check callback

Hi Javier, Thanks for your patch! On Fri, Jul 21, 2023 at 9:10 AM Javier Martinez Canillas wrote: > Geert reports that the following NULL pointer dereference happens for him > after commit 49d7d581ceaf ("drm/ssd130x: Don't allocate buffers on each > plane update"): > > [drm] Initialized ssd1

Re: [PATCH] drm/mgag200: Increase bandwidth for G200se A rev1

Hi Roger, thanks for all the information. Am 24.07.23 um 22:57 schrieb Roger Sewell: Thomas, Hello, I'm the user who reported the issue. Definitely happy to help you sort this out if I can, though my response speed will decrease when term restarts in October. I'd be interested in the exact m

Re: drm/ast: Do not enable PCI resources multiple times

Hi Am 25.07.23 um 03:12 schrieb suijingfeng: Hi, On 2023/7/25 02:34, Thomas Zimmermann wrote: Hi Am 18.07.23 um 07:40 schrieb suijingfeng: Hi, Actually,  I'm only a little bit worry about the ast_pm_thaw() code path. |- ast_pm_thaw() |-- ast_drm_thaw() |--- ast_post_gpu() I'm not

Re: [PATCH] video: logo: LOGO should depend on FB_CORE i.s.o. FB

Thomas Zimmermann writes: > Hi > [...] >> >> Yes. I meant to move drivers/video/logo/ to drivers/fbdev/core/logo and to >> source its Kconfig from drivers/fbdev/core/Kconfig, since it now depends >> on FB_CORE. > > No, please rather leave it where it is. There's no code dependencies to > the

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

> This comes back to the point that was mentioned by Johannes - you need to > have deep design understanding of the hardware to know whether or not you > will have producers that a consumer need to react to. Yes, this is the policy is keep referring to. I would expect that there is something somew

[PATCH v3 00/10] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together

The big motivation for this patch series is mostly described in the patch ("drm/panel: Add a way for other devices to follow panel state"), but to quickly summarize here: for touchscreens that are connected to a panel we need the ability to power sequence the two device together. This is not a ne

  1   2   >