Re: [PATCH v2 5/6] drm/mediatek: mtk_dpi: Use devm_platform_ioremap_resource()

Re: [PATCH v2 4/6] drm/mediatek: mtk_dpi: Switch to .remove_new() void callback

Re: [PATCH v2 3/6] drm/mediatek: mtk_dpi: Switch to devm_drm_of_get_bridge()

Re: [PATCH v2 1/6] drm/mediatek: mtk_dpi: Simplify with devm_drm_bridge_add()

Re: [PATCH v2 2/6] drm/mediatek: mtk_dpi: Simplify with dev_err_probe()

Re: [PATCH v2 1/6] drm/mediatek: mtk_dpi: Simplify with devm_drm_bridge_add()

Re: [Intel-gfx] [PATCH v2] drm/i915/tv: avoid possible division by zero

On Wed, Jul 26, 2023 at 09:21:50AM +0800, Su Hui wrote: > On 2023/7/25 13:51, Dan Carpenter wrote: > > The reason why the first five attempts had bugs is because we are > > trying to write it in the most complicated way possible, shifting by > > logical not what? > Wonderful! Should I add your

Re: [PATCH v3, 3/3] drm/mediatek: dp: Add the audio divider to mtk_dp_data struct

Re: [PATCH v3, 2/3] drm/mediatek: dp: Add the audio packet flag to mtk_dp_data struct

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

On 7/25/2023 5:40 AM, Colin Ian King wrote: 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

[PATCH] drm: bridge: dw_hdmi: Fix ELD is not updated issue

The ELD (EDID-Like Data) is not updated when the HDMI cable is plugged into different HDMI monitors. This is because the EDID is not updated in the HDMI HPD function. As a result, the ELD data remains unchanged and may not reflect the capabilities of the newly connected HDMI sink device. To

Re: [Intel-gfx] [PATCH v2] drm/i915/tv: avoid possible division by zero

On 2023/7/25 13:51, Dan Carpenter wrote: The reason why the first five attempts had bugs is because we are trying to write it in the most complicated way possible, shifting by logical not what? Wonderful! Should I add your name as signed-of-by? I will send a v3 patch later. Really thanks for

linux-next: manual merge of the amdgpu tree with the drm tree

Hi all, Today's linux-next merge of the amdgpu tree got a conflict in: drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c between commit: 8a206685d36f ("drm/amdgpu: use drm_exec for GEM and CSA handling v2") from the drm tree and commit: 30953c4d000b ("drm/amdgpu: Fix style issues in

[PATCH v2] drm/i915/guc/slpc: Restore efficient freq earlier

This should be done before the soft min/max frequencies are restored. When we disable the "Ignore efficient frequency" flag, GuC does not actually bring the requested freq down to RPn. Specifically, this scenario- - ignore efficient freq set to true - reduce min to RPn (from efficient) - suspend

Re: Unexplainable packet drop starting at v6.4

On Wed, 26 Jul 2023 06:50:52 +0700 Bagas Sanjaya wrote: > This time, the bisection points out to v6.4 networking pull, so: > > #regzbot introduced: 6e98b09da931a0 Ask the reporter to test 9b78d919632b, i.e. the tip of net-next before the merge. It seems quite unlikely that the merge itself is

Re: [drm-misc:for-linux-next 2/2] drivers/gpu/drm/drm_debugfs.c:212:33: sparse: sparse: non size-preserving pointer to integer cast

On 7/24/23 09:27, Boris Brezillon wrote: On Fri, 21 Jul 2023 02:06:16 +0800 kernel test robot wrote: tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next head: c7a472297169156252a50d76965eb36b081186e2 commit: 4f66feeab173bd73e71028b8c2e1dcea07e32dd5 [2/2] drm: debugfs: provide

Re: Fwd: Unexplainable packet drop starting at v6.4

On Tue, Jul 18, 2023 at 07:51:24AM +0700, Bagas Sanjaya wrote: > Hi, > > I notice a regression report on Bugzilla [1]. Quoting from it: > > > Hi, > > > > After I updated to 6.4 through Archlinux kernel update, suddenly I noticed > > random packet losses on my routers like nodes. I have these

Re: [Freedreno] [PATCH v1 2/5] drm/msm/dp: incorporate pm_runtime framework into DP driver

On 26/07/2023 02:26, Kuogee Hsieh wrote: On 7/25/2023 3:33 PM, Dmitry Baryshkov wrote: On 26/07/2023 01:25, Kuogee Hsieh wrote: On 7/10/2023 9:22 AM, Kuogee Hsieh wrote: On 7/8/2023 7:52 PM, Bjorn Andersson wrote: On Fri, Jul 07, 2023 at 04:52:20PM -0700, Kuogee Hsieh wrote:

Re: [Freedreno] [PATCH v1 2/5] drm/msm/dp: incorporate pm_runtime framework into DP driver

On 7/25/2023 3:33 PM, Dmitry Baryshkov wrote: On 26/07/2023 01:25, Kuogee Hsieh wrote: On 7/10/2023 9:22 AM, Kuogee Hsieh wrote: On 7/8/2023 7:52 PM, Bjorn Andersson wrote: On Fri, Jul 07, 2023 at 04:52:20PM -0700, Kuogee Hsieh wrote: Incorporating pm runtime framework into DP driver so

[PATCH] drm/panel: Add prepare_prev_first flag to Visionox VTDR6130

Due to a recent introduction of the pre_enable_prev_first bridge flag [1], the panel driver will be probed before the DSI is enabled, causing the DCS commands to fail to send. Ensure that DSI is enabled before panel probe by setting the prepare_prev_first flag for the panel. [1] commit

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

On Tue, Jul 25, 2023 at 10:44:09PM +, Kasireddy, Vivek wrote: > > If you still need the memory mapped then you re-call hmm_range_fault > > and re-obtain it. hmm_range_fault will resolve all the races and you > > get new pages. > IIUC, for my udmabuf use-case, it looks like calling

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

On 7/25/23 18:43, Danilo Krummrich wrote: On 7/25/23 18:16, Faith Ekstrand wrote: Thanks for the detailed write-up! That would definitely explain it. If I remember, I'll try to do a single-threaded run or two. If your theory is correct, there should be no real perf difference when running

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

Hi Jason, > > > > > > > > I'm not at all familiar with the udmabuf use case but that sounds > > > > > brittle and effectively makes this notifier udmabuf specific right? > > > > Oh, Qemu uses the udmabuf driver to provide Host Graphics > components > > > > (such as Spice, Gstreamer, UI, etc)

Re: [Freedreno] [PATCH v1 2/5] drm/msm/dp: incorporate pm_runtime framework into DP driver

On 26/07/2023 01:25, Kuogee Hsieh wrote: On 7/10/2023 9:22 AM, Kuogee Hsieh wrote: On 7/8/2023 7:52 PM, Bjorn Andersson wrote: On Fri, Jul 07, 2023 at 04:52:20PM -0700, Kuogee Hsieh wrote: Incorporating pm runtime framework into DP driver so that power and clock resource handling can be

Re: [Freedreno] [PATCH v1 2/5] drm/msm/dp: incorporate pm_runtime framework into DP driver

On 7/10/2023 9:22 AM, Kuogee Hsieh wrote: On 7/8/2023 7:52 PM, Bjorn Andersson wrote: On Fri, Jul 07, 2023 at 04:52:20PM -0700, Kuogee Hsieh wrote: Incorporating pm runtime framework into DP driver so that power and clock resource handling can be centralized allowing easier control of these

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

Hi Hugh, > > On Mon, 24 Jul 2023, 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 specific

[PATCH wq/for-6.5-fixes] workqueue: Drop the special locking rule for worker->flags and worker_pool->flags

>From aa6fde93f3a49e42c0fe0490d7f3711bac0d162e Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Mon, 17 Jul 2023 12:50:02 -1000 Subject: [PATCH] workqueue: Scale up wq_cpu_intensive_thresh_us if BogoMIPS is below 4000 wq_cpu_intensive_thresh_us is used to detect CPU-hogging per-cpu work items.

Re: [PATCH 4/6] PCI/VGA: Move the new_state assignment out the loop

On Mon, Jul 24, 2023 at 09:02:14PM +0800, suijingfeng wrote: > PING, please ! Don't worry, these are not forgotten. Your other series seems more important, so that's what I've been paying attention to. > On 2023/7/11 21:43, Sui Jingfeng wrote: > > From: Sui Jingfeng > > > > In the

Re: [PATCH 2/6] PCI/VGA: Deal with PCI VGA compatible devices only

On Sat, Jul 22, 2023 at 04:11:07PM +0800, suijingfeng wrote: > ... > In the future, we may want to expand VGAARB to deal all PCI display class > devices, with another patch. > > if (pdev->class >> 16 == PCI_BASE_CLASS_DISPLAY) > > // accept > > else > >   // return immediately. >

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

Hello, On Tue, Jul 25, 2023 at 03:08:40PM +0100, Tvrtko Ursulin wrote: > > Also, shouldn't this be keyed by the drm device? > > It could have that too, or it could come later. Fun with GPUs that it not > only could be keyed by the device, but also by the type of the GPU engine. > (Which are a)

Re: [PATCH v3 0/9] PCI/VGA: Improve the default VGA device selection

On Mon, Jul 24, 2023 at 08:47:48PM +0800, suijingfeng wrote: > On 2023/7/20 03:32, Bjorn Helgaas wrote: > > "drm/loongson: Add an implement for ..." also solves a problem, but it > > lacks a commit log, so I don't know what the problem is. > > I have already telling you one yeas ago. The patch

Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection

On Mon, Jul 24, 2023 at 08:16:18PM +0800, suijingfeng wrote: > On 2023/7/20 03:32, Bjorn Helgaas wrote: > > > 2) It does not take the PCI Bar may get relocated into consideration. > > > 3) It is not effective for the PCI device without a dedicated VRAM Bar. > > > 4) It is device-agnostic, thus it

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

Geert Uytterhoeven writes: Hello Geert, > Hi Javier, > > Thanks for your patch! > Thanks a lot for your feedabck. > On Fri, Jul 21, 2023 at 9:10 AM Javier Martinez Canillas > wrote: >> Geert reports that the following NULL pointer dereference happens for him [...] > >> Since the primary

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

On 7/25/23 15:09, Andrew Lunn wrote: 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

Re: [PATCH v2 08/10] HID: i2c-hid: Support being a panel follower

Hi, On Mon, Jul 17, 2023 at 11:15 AM Doug Anderson wrote: > > Benjamin, > > On Mon, Jun 26, 2023 at 3:49 PM Doug Anderson wrote: > > > > Benjamin, > > > > On Thu, Jun 8, 2023 at 8:37 AM Benjamin Tissoires > > wrote: > > > > > > > +static const struct drm_panel_follower_funcs > > > >

[PATCH v3 10/10] arm64: dts: qcom: sc7180: Link trogdor touchscreens to the panels

Let's provide the proper link from the touchscreen to the panel on trogdor devices where the touchscreen support it. This allows the OS to power sequence the touchscreen more properly. For the most part, this is just expected to marginally improve power consumption while the screen is off.

[PATCH v3 09/10] HID: i2c-hid: Do panel follower work on the system_wq

Turning on an i2c-hid device can be a slow process. This is why i2c-hid devices use PROBE_PREFER_ASYNCHRONOUS. Unfortunately, when we're a panel follower the i2c-hid power up sequence now blocks the power on of the panel. Let's fix that by scheduling the work on the system_wq. Signed-off-by:

[PATCH v3 04/10] of: property: fw_devlink: Add a devlink for panel followers

Inform fw_devlink of the fact that a panel follower (like a touchscreen) is effectively a consumer of the panel from the purposes of fw_devlink. NOTE: this patch isn't required for correctness but instead optimizes probe order / helps avoid deferrals. Acked-by: Rob Herring Signed-off-by:

[PATCH v3 08/10] HID: i2c-hid: Support being a panel follower

As talked about in the patch ("drm/panel: Add a way for other devices to follow panel state"), we really want to keep the power states of a touchscreen and the panel it's attached to in sync with each other. In that spirit, add support to i2c-hid to be a panel follower. This will let the i2c-hid

[PATCH v3 05/10] HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS()

The SYSTEM_SLEEP_PM_OPS() allows us to get rid of '#ifdef CONFIG_PM_SLEEP', as talked about in commit 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate old ones"). This change is expected to have no functional effect. Signed-off-by: Douglas Anderson --- (no changes since v1)

[PATCH v3 07/10] HID: i2c-hid: Make suspend and resume into helper functions

In a future patch we'd like to be able to call the current i2c-hid suspend and resume functions from times other than system suspend. Move the functions higher up in the file and have them take a "struct i2c_hid" to make this simpler. We'll then add tiny wrappers of the functions for use with

[PATCH v3 06/10] HID: i2c-hid: Rearrange probe() to power things up later

In a future patch, we want to change i2c-hid not to necessarily power up the touchscreen during probe. In preparation for that, rearrange the probe function so that we put as much stuff _before_ powering up the device as possible. This change is expected to have no functional effect.

[PATCH v3 03/10] drm/panel: Add a way for other devices to follow panel state

These days, it's fairly common to see panels that have touchscreens attached to them. The panel and the touchscreen can somewhat be thought of as totally separate devices and, historically, this is how Linux has treated them. However, treating them as separate isn't necessarily the best way to

[PATCH v3 02/10] drm/panel: Check for already prepared/enabled in drm_panel

In a whole pile of panel drivers, we have code to make the prepare/unprepare/enable/disable callbacks behave as no-ops if they've already been called. It's silly to have this code duplicated everywhere. Add it to the core instead so that we can eventually delete it from all the drivers. Note: to

[PATCH v3 01/10] dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens

As talked about in the patch ("drm/panel: Add a way for other devices to follow panel state"), touchscreens that are connected to panels are generally expected to be power sequenced together with the panel they're attached to. Today, nothing provides information allowing you to find out that a

[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

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

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: 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] 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

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

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

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] 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

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

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

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)

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

[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

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 >

[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 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

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

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

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 >> >

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: [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 > > --- > >

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

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

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

[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:

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.

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

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 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. > >

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

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:

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: [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 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

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 >

Re: [Intel-gfx] [PATCH] drm/i915: Simplify expression _i915(dev)->drm

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

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

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: [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

[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,

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] 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

Re: [Intel-gfx] [PATCH] drm/i915: Simplify expression _i915(dev)->drm

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

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

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: [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

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

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: [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

[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

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

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 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 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,

  1   2   >