Re: Fwd: [git pull] drm fixes for 6.15-rc1

The pull request you sent on Sun, 6 Apr 2025 07:51:03 +1000: > https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2025-04-05 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/758e4c86a159bdd67a8ef60ea118ddb8b2043714 Thank you! -- Deet-doot-dot, I am a bot. htt

Fwd: [git pull] drm fixes for 6.15-rc1

(resend including Linus this time, autocomplete picked the mailing list) Hi Linus, Weekly fixes, mostly from the end of last week, this week was very quiet, maybe you scared everyone away. I probably should have highlighted Jani's work more closely, but it never occured that anyone would willingi

Fwd: [PATCH v1] drm/i915/guc: Always disable interrupt ahead of synchronize_irq

Just found my previous response click on "reply", not the "reply all", so add Cc list. Regards, Zhanjun Dong Forwarded Message Subject: Re: [PATCH v1] drm/i915/guc: Always disable interrupt ahead of synchronize_irq Date: Mon, 27 Jan 2025 17:17:33 -0500 From: Dong, Zhanjun

Fwd: [PATCH] drm/panel-edp: Add CSW MNB601LS1-3

-- Forwarded message - From: Langyan Ye Date: Fri, Dec 27, 2024 at 6:19 PM Subject: [PATCH] drm/panel-edp: Add CSW MNB601LS1-3 To: , , < quic_jessz...@quicinc.com>, , < mrip...@kernel.org>, , , < sim...@ffwll.ch>, , < linux-ker...@vger.kernel.org> Cc: , Langyan Ye < yelang...@huaqi

Fwd: [PATCH] drm/panel-edp: Add B140UAN04.4 and MNE007QS3-7

-- Forwarded message - From: Langyan Ye Date: Wed, Dec 25, 2024 at 10:01 AM Subject: [PATCH] drm/panel-edp: Add B140UAN04.4 and MNE007QS3-7 To: , , < quic_jessz...@quicinc.com>, , < mrip...@kernel.org>, , , < sim...@ffwll.ch>, , < linux-ker...@vger.kernel.org> Cc: , Langyan Ye < ye

Fwd: [PATCH] drm/amdgpu: Make the submission path memory reclaim safe

Sending it out to the mailing lists once more because AMD mail servers tried to convert it to HTML :( Am 17.12.24 um 01:26 schrieb Matthew Brost: On Fri, Nov 22, 2024 at 02:36:59PM +, Tvrtko Ursulin wrote: [SNIP] Do we have system wide workqueues for that? It seems a bit overkill that amd

Re: Fwd: Kernel 6.6.1 hangs on "loading initial ramdisk"

On Wed, Nov 22, 2023 at 07:06:50AM +0700, Bagas Sanjaya wrote: > Hi, > > I notice a regression report on Bugzilla [1]. Quoting from it: > > > After upgrading from 6.5.9 to 6.6.1 on my Dell Latitude E6420 (Intel > > i5-2520M) with EndeavourOS, the boot process would hang at "loading initial > >

Fwd: [PATCH 3/4] fbdev/vesafb: Replace references to global screen_info by local pointer

cc'ing mailing lists Weitergeleitete Nachricht Betreff: Re: [PATCH 3/4] fbdev/vesafb: Replace references to global screen_info by local pointer Datum: Fri, 01 Dec 2023 09:54:51 +0100 Von: Javier Martinez Canillas An: Thomas Zimmermann Thomas Zimmermann writes: Get the g

Fwd: Kernel 6.6.1 hangs on "loading initial ramdisk"

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > After upgrading from 6.5.9 to 6.6.1 on my Dell Latitude E6420 (Intel > i5-2520M) with EndeavourOS, the boot process would hang at "loading initial > ramdisk". The issue is present on the 6.6.1 release of both Linux and > Linu

Fwd: 01f05940a9a75e11a2be64993c44ad8dd06e6e26 causes Wayland servers to flicker in non-gl virtio QEMU cards

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > It seems that commit 01f05940a9a75e11a2be64993c44ad8dd06e6e26 introduced an > issue impacting wlroots and Weston (possibly others) on QEMU with the virtio > card. happens on QEMU, and it happens in virt-manager when I do NOT e

Re: [Nouveau] Fwd: System (Xeon Nvidia) hangs at boot terminal after kernel 6.4.7

[TLDR: This mail in primarily relevant for Linux kernel regression tracking. See link in footer if these mails annoy you.] On 10.08.23 06:19, Thorsten Leemhuis wrote: > On 10.08.23 05:03, Bagas Sanjaya wrote: >> >> I notice a regression report on Bugzilla [1]. Quoting from it: >> >> [...] >> [1]:

Re: Fwd: Kernel 6.6-rc1 fails to reboot or shutdown Ryzen 5825U

On Thu, Sep 14, 2023 at 02:03:00PM +0700, Bagas Sanjaya wrote: > #regzbot introduced: v6.5..v6.6 > https://bugzilla.kernel.org/show_bug.cgi?id=217905 > #regzbot title: shutdown/reboot hang on Ryzen 5825U (stuck on amdgpu > initialization) > Fixing up commit range: #regzbot introduced: v6.5..v6

Fwd: Kernel 6.6-rc1 fails to reboot or shutdown Ryzen 5825U

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > The Kernel stalls at boot very long with a drm-amdgpu message, but fails to > restart or shutdown with secure boot enabled or not. Magic key works to exit. > Nothing wrong in the Kernel 6.5 cycle. Later, the reporter (Cc'ed)

Re: Fwd: Kernel version 6.1.50 regression: radeonfb deactivate vga console

On 02/09/2023 07:01, Bagas Sanjaya wrote: > #regzbot introduced: 9b539c4d1b921b > https://bugzilla.kernel.org/show_bug.cgi?id=217861 > #regzbot title: using pci aperture helpers deactivates AMD ES1000 VGA > controller > #regzbot inconclusive: now tracked on gitlab.freedesktop.org tracker #regzb

Fwd: Kernel version 6.1.50 regression: radeonfb deactivate vga console

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Since kernel version 6.1.50 the VGA console stopped working on all HP > ProLiant (G6 and G7) servers with [AMD/ATI] ES1000 VGA controller. > > No issue with all kernel version 6.1.X before 6.1.50. > No issue with the kernel 6.

Re: [Nouveau] Fwd: System (Xeon Nvidia) hangs at boot terminal after kernel 6.4.7

6.4.9 built with unconn.c from 6.4.6 builds and boots and runs fine. Thanks everybody.

Re: [Nouveau] Fwd: System (Xeon Nvidia) hangs at boot terminal after kernel 6.4.7

On 10.08.23 05:03, Bagas Sanjaya wrote: > > I notice a regression report on Bugzilla [1]. Quoting from it: > >> Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon >> cpu and Nvidia graphics - see below for system specs. >> >> Kernels 6.4.7 & 6.4.8 also compiled from sourc

Fwd: System (Xeon Nvidia) hangs at boot terminal after kernel 6.4.7

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon > cpu and Nvidia graphics - see below for system specs. > > Kernels 6.4.7 & 6.4.8 also compiled from source with identical configs hang > with a froze

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 ne

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

On 19.07.23 14:30, Bagas Sanjaya wrote: > On 7/19/23 18:49, Thorsten Leemhuis wrote: >> On 18.07.23 02:51, Bagas Sanjaya wrote: >>> I notice a regression report on Bugzilla [1]. Quoting from it: >>> After I updated to 6.4 through Archlinux kernel update, suddenly I noticed random packet

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

On 7/19/23 18:49, Thorsten Leemhuis wrote: > On 18.07.23 02:51, Bagas Sanjaya wrote: >> >> I notice a regression report on Bugzilla [1]. Quoting from it: >> >>> After I updated to 6.4 through Archlinux kernel update, suddenly I noticed >>> random packet losses on my routers like nodes. I have thes

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

On 18.07.23 02:51, Bagas Sanjaya wrote: > > I notice a regression report on Bugzilla [1]. Quoting from it: > >> After I updated to 6.4 through Archlinux kernel update, suddenly I noticed >> random packet losses on my routers like nodes. I have these networking >> relevant config on my nodes >>

Fwd: Unexplainable packet drop starting at v6.4

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 networking > relevant config on my nodes > > 1. Using archlinux > 2. Network co

Fwd: Framebuffer-Display issue. (Intel® Iris® Xe)

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Hello I have been having problems for some time now with displaying any linux > distribution with the new kernal. The only thing that can fix it are older > kernals. > > I can't describe it very well, so I'm attaching some pi

Fwd: [PATCH] drm/nouveau/i2c: do not use assignment in if condition

Assignments in if condition are less readable and error-prone. Fixes also checkpatch warning: ERROR: do not use assignment in if condition Signed-off-by: Ran Sun --- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busnv04.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 =>

Re: Fwd: Does not work backlight on Chromebook XE303C12 with Kernel version 6.3.4

On Fri, May 26, 2023 at 08:46:32PM +0700, Bagas Sanjaya wrote: > Hi, > > I notice a regression report on Bugzilla [1]. Quoting from it: > > > I did check it by flashlight. Even with all available backlights drivers > > compiled as modules it does not work. With Kernel version 5.15.106 > > backl

Fwd: Does not work backlight on Chromebook XE303C12 with Kernel version 6.3.4

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > I did check it by flashlight. Even with all available backlights drivers > compiled as modules it does not work. With Kernel version 5.15.106 backlight > works fine. > Kernels for Chomebook uses dtb files that have some backli

Re: [Nouveau] Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

On Thu, May 25, 2023 at 01:24:42PM +0200, Thorsten Leemhuis wrote: > Bagas, thx again for your efforts, much appreciated. But I guess for drm > drivers that have a line like > > B: https://gitlab.freedesktop.org/drm/[...] > > in MAINTAINERS (which includes all the popular drm drivers) this just >

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

On Thu, May 25, 2023 at 06:37:05PM +0700, Bagas Sanjaya wrote: > Oops, again, I messed up the regzbot entry (reporter field still assigned > to me). Inconclusiving... > > #regzbot inconclusive: Wrong reporter assigned (from: doesn't take effect) > > Please ignore this thread as I will send a new

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

I wouldn't be surprised if 4a16dd9d18a0 is the culprit and that it was always broken like this with drm fbdev. Anyway, the logs don't indicate we are actually doing anything wrong, It's just that the tty handling is a little bonkers as always. On Thu, May 25, 2023 at 1:37 PM Bagas Sanjaya wrote:

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

On 5/25/23 17:55, Bagas Sanjaya wrote: > On 5/25/23 17:52, Bagas Sanjaya wrote: >> Hi, >> >> I notice a regression report on Bugzilla [1]. Quoting from it: >> >>> Original Summary: >>> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers >>> produce vast raster right and bottom b

Re: [Nouveau] Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

On 25.05.23 12:55, Bagas Sanjaya wrote: > On 5/25/23 17:52, Bagas Sanjaya wrote: >> >> I notice a regression report on Bugzilla [1]. Quoting from it: >> [...] >> Anyway, I'm adding it to regzbot: >> >> #regzbot introduced: v6.1.12..v6.2.12 >> #regzbot title: vast raster right and bottom borders on

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

On 5/25/23 17:52, Bagas Sanjaya wrote: > Hi, > > I notice a regression report on Bugzilla [1]. Quoting from it: > >> Original Summary: >> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers >> produce vast raster right and bottom borders on the larger resolution of two >> dis

Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Original Summary: > absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers > produce vast raster right and bottom borders on the larger resolution of two > displays > > To reproduce: > 1-connect two unequal na

Re: Fwd: Kernel 5.11 crashes when it boots, it produces black screen.

On Wed, May 10, 2023 at 03:26:56PM +0700, Bagas Sanjaya wrote: > Anyway, let me add this regression to regzbot: > > #regzbot introduced: v5.10..v5.11 > https://bugzilla.kernel.org/show_bug.cgi?id=212579 > #regzbot title: Booting kernel on AMD Ryzen 5 PRO stucks in loading initrd Resolving... #r

Re: Fwd: Kernel 5.11 crashes when it boots, it produces black screen.

On 5/10/23 16:51, Linux regression tracking (Thorsten Leemhuis) wrote: > Bagas, thx for all your help with regression tracking, much appreciated > (side note, as I'm curious for a while already: what is your motivation? > Just want to help? But whatever, any help is great!). > I did this when I w

Re: Fwd: Kernel 5.11 crashes when it boots, it produces black screen.

Hi! On 10.05.23 10:26, Bagas Sanjaya wrote: > > I noticed a regression report on Bugzilla ([1]). As many developers don't > have a look on it, I decided to forward it by email. See the report > for the full thread. > > Quoting from the report: > >> Azamat S. Kalimoulline 2021-04-06 15:45:08 UT

Fwd: Kernel 5.11 crashes when it boots, it produces black screen.

Hi, I noticed a regression report on Bugzilla ([1]). As many developers don't have a look on it, I decided to forward it by email. See the report for the full thread. Quoting from the report: > Azamat S. Kalimoulline 2021-04-06 15:45:08 UTC > > Same as in https://bugzilla.kernel.org/show_bug.c

Fwd: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

Proof, if any where needed, that I should consume more coffee before dealing with email... Adding cc recipients that were dropped in my message this morning. Forwarded Message Subject: Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected Date: Mon, 13 Feb 2023 09:21:10 +

Re: Fwd: [PATCH 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf

On Sun, Aug 21, 2022 at 04:51:34PM +0300, Oded Gabbay wrote: > > +static void vfio_pci_dma_buf_unmap(struct dma_buf_attachment *attachment, > > + struct sg_table *sgt, > > + enum dma_data_direction dir) > > +{ > > + struct vfi

Fwd: [PATCH 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf

On Wed, Aug 17, 2022 at 7:11 PM Jason Gunthorpe wrote: > > dma-buf has become a way to safely acquire a handle to non-struct page > memory that can still have lifetime controlled by the exporter. Notably > RDMA can now import dma-buf FDs and build them into MRs which allows for > PCI P2P operation

Re: Fwd: [PATCH v2 3/3] drm/msm/dp: remove dp_display_en/disable prototypes and data argument

On 6/24/2022 10:37 AM, Abhinav Kumar wrote: Forwarded Message Subject: [PATCH v2 3/3] drm/msm/dp: remove dp_display_en/disable prototypes and data argument Date: Sat, 18 Jun 2022 02:24:34 +0300 From: Dmitry Baryshkov To: Rob Clark , Sean Paul , Abhinav Kumar CC: Stephe

Re: Fwd: [PATCH v2 2/3] drm/msm/dp: rename second dp_display_enable()'s argument

On 6/24/2022 10:36 AM, Abhinav Kumar wrote: Forwarded Message Subject: [PATCH v2 2/3] drm/msm/dp: rename second dp_display_enable()'s argument Date: Sat, 18 Jun 2022 02:24:33 +0300 From: Dmitry Baryshkov To: Rob Clark , Sean Paul , Abhinav Kumar CC: Stephen Boyd , Davi

Re: Fwd: [Freedreno] [PATCH v2 1/3] drm/msm/dp: remove unused stubs

On 6/24/2022 10:36 AM, Abhinav Kumar wrote: Forwarded Message Subject: [Freedreno] [PATCH v2 1/3] drm/msm/dp: remove unused stubs Date: Sat, 18 Jun 2022 02:24:32 +0300 From: Dmitry Baryshkov To: Rob Clark , Sean Paul , Abhinav Kumar CC: David Airlie , linux-arm-...@vger.

[PATCH] drm: fix device_node_continue.cocci warnings (fwd)

The of_node_put does not seem to be needed. Note that there is none at the preceeding continues. julia -- Forwarded message -- Date: Sat, 11 Jun 2022 06:02:45 +0800 From: kernel test robot To: kbu...@lists.01.org Cc: l...@intel.com, Julia Lawall Subject: [PATCH] drm: fix device

Re: [Intel-gfx] [PATCH] drm/i195: Remove some dead struct fwd decl from i915_drv.h

On Fri, Oct 22, 2021 at 09:39:13AM +0100, Matthew Auld wrote: > On Fri, 22 Oct 2021 at 09:22, Daniel Vetter wrote: > > > > Gone with userptr rewrite by Maarten in ed29c2691188 ("drm/i915: Fix > > userptr so we do not have to worry about obj->mm.lock, v7.") > > > > Signed-off-by: Daniel Vetter > >

Re: [Intel-gfx] [PATCH] drm/i195: Remove some dead struct fwd decl from i915_drv.h

On Fri, 22 Oct 2021 at 09:22, Daniel Vetter wrote: > > Gone with userptr rewrite by Maarten in ed29c2691188 ("drm/i915: Fix > userptr so we do not have to worry about obj->mm.lock, v7.") > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst s/i195/i915/ Reviewed-by: Matthew Auld > --- >

[PATCH] drm/i195: Remove some dead struct fwd decl from i915_drv.h

Gone with userptr rewrite by Maarten in ed29c2691188 ("drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.") Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915

Re: [Intel-gfx] [PATCH] drm/i915: Add ww context to intel_dpt_pin (fwd)

I don't seem to have received any other message about this, but from the URL below, the referenced code seems to be: if (IS_ERR(iomem)) { err = PTR_ERR(vma); continue; } It seems that the argument of PTR_ERR should be iomem,

Fwd: Re: [PATCH v15 2/4] dt-bindings: msm: dsi: add yaml schemas for DSI bindings

On 2021-04-08 20:33, Rob Herring wrote: On Mon, Apr 05, 2021 at 04:36:08PM +0530, Krishna Manikandan wrote: Add YAML schema for the device tree bindings for DSI Signed-off-by: Krishna Manikandan Changes in v1: - Separate dsi controller bindings to a separate patch (Stephen Boyd) - M

Fwd: Call traces triggered by starting X on 5.8.x kernels - Radeon RX580

Hi All, I hope this is useful. Let me know if you would like me to test anything. Cheers, Adam [2.] Full description of the problem/report: X works but, 6 warnings triggered, in; drivers/gpu/drm/drm_modeset_lock.c:185 drivers/gpu/drm/drm_crtc_helper.c:148 drivers/gpu/drm/drm_crtc_helper.c:1

Re: Fwd: [PATCH v14 0/2] Add initial support for slimport anx7625

On Wed, Aug 19, 2020 at 02:57:14PM +0800, Hsin-Yi Wang wrote: > I think you missed this email :) > > -- Forwarded message - > From: Sam Ravnborg > Date: Tue, Aug 11, 2020 at 4:35 AM > Subject: Re: [PATCH v14 0/2] Add initial support for slimport anx7625 > To: Xin Ji > Cc: , Laure

Fwd: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

Hi All, I hope you are responsible for the virtio_gpu. Could you please test the virtio_gpu because it doesn't work anymore with the latest Git kernel (see below). Thanks, Christian Weitergeleitete Nachricht Betreff:[Virtual ppce500] virtio_gpu virtio0: swiotlb buf

Re: Fwd: [PATCH] Staging: drm_gem: Fix a typo in a function comment

Yes, I will do it. On Tue, Mar 17, 2020 at 2:04 PM Daniel Vetter wrote: > On Mon, Mar 16, 2020 at 06:08:30PM -0300, Igor Torrente wrote: > > Ccing dri-devel and linux-kernel. > > git apply-mbox chokes on this, can you pls resubmit? > > Thanks, Daniel > > > > > -- Forwarded message --

Re: Fwd: [PATCH] Staging: drm_gem: Fix a typo in a function comment

On Mon, Mar 16, 2020 at 06:08:30PM -0300, Igor Torrente wrote: > Ccing dri-devel and linux-kernel. git apply-mbox chokes on this, can you pls resubmit? Thanks, Daniel > > -- Forwarded message - > From: Igor Matheus Andrade Torrente > Date: Mon, Mar 16, 2020 at 6:04 PM > Subject

Fwd: [PATCH] Staging: drm_gem: Fix a typo in a function comment

Ccing dri-devel and linux-kernel. -- Forwarded message - From: Igor Matheus Andrade Torrente Date: Mon, Mar 16, 2020 at 6:04 PM Subject: [PATCH] Staging: drm_gem: Fix a typo in a function comment To: , , , , , < sumit.sem...@linaro.org> Cc: Igor Matheus Andrade Torrente , < rodrig

Fwd: [PATCH V2 3/3] mtd: rawnand: brcmnand: Add support for flash-edu for dma transfers

Legacy mips soc platforms that have controller v5.0 and 6.0 use flash-edu block for dma transfers. This change adds support for nand dma transfers using the EDU block. Signed-off-by: Kamal Dasu --- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 296 ++- 1 file changed, 290 insert

Re: Fwd: [PATCH] drm/i915: Fix enable OA report logic

On Wed, 08 Jan 2020, Andy Shevchenko wrote: > I forwarding this to a (sub)set of correct MLs/maintainers. Please, > follow the instructions they give. Thanks, already fixed by commit 9278bbb6e43c ("drm/i915/perf: Reverse a ternary to make sparse happy") in our -next. BR, Jani. > > -- Fo

Fwd: [PATCH] drm/i915: Fix enable OA report logic

I forwarding this to a (sub)set of correct MLs/maintainers. Please, follow the instructions they give. -- Forwarded message - From: Ebrahim Byagowi Date: Mon, Dec 23, 2019 at 12:17 PM Subject: [PATCH] drm/i915: Fix enable OA report logic To: Clang raises drivers/gpu/drm/i91

Re: [PATCH v6 2/2] drm/bridge: Add NWL MIPI DSI host controller support (fwd)

Hello, Color_format is unsigned, so it won't be less than 0 on line 272. julia -- Forwarded message -- Date: Mon, 23 Sep 2019 02:29:34 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: Re: [PATCH v6 2/2] drm/bridge: Add NWL MIPI DSI host controller suppo

RE: [radeon-alex:drm-next-5.2-wip 214/226] drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9: preceding lock on line 1065 (fwd)

: [radeon-alex:drm-next-5.2-wip 214/226] drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9: preceding lock on line 1065 (fwd) Hello, It looks like line 1204 needs a break rather than a return, like in the aborts from the other cases. julia -- Forwarded message

[radeon-alex:drm-next-5.2-wip 214/226] drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9: preceding lock on line 1065 (fwd)

Hello, It looks like line 1204 needs a break rather than a return, like in the aborts from the other cases. julia -- Forwarded message -- Date: Sat, 2 Mar 2019 14:36:31 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [radeon-alex:drm-next-5.2-wip 214/2

Re: Fwd: [PATCH] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

On Wed, 13 Feb 2019, Thierry Reding wrote: > On Wed, Feb 13, 2019 at 11:13:23AM +0100, David Santamaría Rogado wrote: >> Sorry previous one wasn't signed off by. > > And now you've got this comment in the commit message that's going to > confuse people looking at the log. > > It's usually to put t

Fwd: [PATCH] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

Sorry previous one wasn't signed off by. The (void *) casting in the driver_data variable assignment is superfluous. Spotted by Jani Nikula. Signed-off-by: David Santamaría Rogado --- drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +- 1 file changed, 9 insertions(+), 9 dele

Re: Fwd: [PATCH] drm: panel-orientation-quirks: Get rid of superfluous (void *) casting

On Wed, Feb 13, 2019 at 11:13:23AM +0100, David Santamaría Rogado wrote: > Sorry previous one wasn't signed off by. And now you've got this comment in the commit message that's going to confuse people looking at the log. It's usually to put this kind of comment below the --- line... > The (void

Fwd: PSA: Mailman changes, From addresses no longer accurate

Hi all, Unfortunately, freedesktop.org's job of sending mail to a huge number of people whilst pretending to be other people, has just got even harder than it was. fd.o can no longer (at least for the moment) send mail with the From addresses of DMARC/DKIM/SPF-protected sender domains. When we try

Re: Fwd: [PATCH v3] drm/bridge/sii902x: Fix EDID readback

Hello Fabrizio, Many thanks for your patch. It's very helpful. Tested-by: Yannick Fertré Best regards Yannick Fertré > Subject: [PATCH v3] drm/bridge/sii902x: Fix EDID readback > Date: Tue, 6 Nov 2018 11:52:36 + > From: Fabrizio Castro > To: Archit Taneja , Andrzej Hajda > , David Airli

Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)

Am 25.10.18 um 09:50 schrieb Maarten Lankhorst: Op 24-10-18 om 20:57 schreef Julia Lawall: The containing function is called with a spin_lock held, so GFP_KERNEL can't be used. julia -- Forwarded message -- Date: Tue, 23 Oct 2018 17:14:25 +0800 From: kbuild test robot To: kbu.

Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)

will send a fix soon. Thanks, David On 2018年10月25日 15:57, Koenig, Christian wrote: Am 25.10.18 um 09:51 schrieb Maarten Lankhorst: Op 25-10-18 om 08:53 schreef Christian König: Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing): Reviewed-by: Chunming Zhou NAK, GFP_ATOMIC should be avoid

Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)

Am 25.10.18 um 09:51 schrieb Maarten Lankhorst: > Op 25-10-18 om 08:53 schreef Christian König: >> Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing): >>> Reviewed-by: Chunming Zhou >> NAK, GFP_ATOMIC should be avoided. >> >> The correct solution is to move the allocation out of the spinlock or dr

Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)

Op 25-10-18 om 08:53 schreef Christian König: > Am 25.10.18 um 03:28 schrieb Zhou, David(ChunMing): >> Reviewed-by: Chunming Zhou > > NAK, GFP_ATOMIC should be avoided. > > The correct solution is to move the allocation out of the spinlock or drop > the lock and reacquire. Yeah +1. Especially in

Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)

Op 24-10-18 om 20:57 schreef Julia Lawall: > The containing function is called with a spin_lock held, so GFP_KERNEL > can't be used. > > julia > > -- Forwarded message -- > Date: Tue, 23 Oct 2018 17:14:25 +0800 > From: kbuild test robot > To: kbu...@01.org > Cc: Julia Lawall > Sub

Re: [PATCH] drm: fix call_kern.cocci warnings (fwd)

: [PATCH] drm: fix call_kern.cocci warnings (fwd) The containing function is called with a spin_lock held, so GFP_KERNEL can't be used. julia -- Forwarded message -- Date: Tue, 23 Oct 2018 17:14:25 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [

RE: [PATCH] drm: fix call_kern.cocci warnings (fwd)

o Padovan > ; Maarten Lankhorst > ; Sean Paul ; David > Airlie ; dri-devel@lists.freedesktop.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] drm: fix call_kern.cocci warnings (fwd) > > The containing function is called with a spin_lock held, so GFP_KERNEL can't > be

[PATCH] drm: fix call_kern.cocci warnings (fwd)

The containing function is called with a spin_lock held, so GFP_KERNEL can't be used. julia -- Forwarded message -- Date: Tue, 23 Oct 2018 17:14:25 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [PATCH] drm: fix call_kern.cocci warnings CC: kbuild-...

Re: Fwd: [PATCH v5 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328

Hi, Heiko: Reviewed-by: zhengyang The rk3328 uses a dw-hdmi controller with an external hdmi phy from Innosilicon which uses the generic phy framework for access. Add the necessary data and the compatible for the rk3328 to the rockchip dw-hdmi driver. Signed-off-by: Heiko Stuebner Tested-by

Re: Fwd: [PATCH v5 4/6] drm/rockchip: dw_hdmi: allow including external phys

Hi, Heiko: Reviewed-by: zhengyang Some variants of the dw-hdmi on Rockchip socs use a separate phy block accessed via the generic phy framework, so allow them to be included if such a phy reference is found. Signed-off-by: Heiko Stuebner Tested-by: Robin Murphy ---  drivers/gpu/drm/rockchip

Re: Fwd: [PATCH v5 5/6] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object

Hi, Heiko: Reviewed-by: zhengyang When using special phy handling operations we'll often need access to the rockchip_hdmi struct. As the chip-data that occupies the phy_data pointer initially gets assigned to the rockchip_hdmi struct, we can now re-use this phy_data pointer to hold the refer

Re: Fwd: [PATCH v5 2/6] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching

Hi, Heiko: Hi, Heiko: Hi, Heiko: Reviewed-by: zhengyang So far we always encountered socs with 2 output crtcs needing the driver to tell the hdmi block which output to connect to. But there also exist socs with only one crtc like the rk3228, rk3328 and rk3368. So adapt the register field t

Re: [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() (fwd)

oh, good catch! will fix and respin in just a little bit On Wed, 2018-09-19 at 22:38 +0200, Julia Lawall wrote: > Hello, > > I don't think you can update the loop index variable in > list_for_each_entry, because the mcro uses th index variable to get to the > next element. Perhaps list_for_each_

Re: [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() (fwd)

Hello, I don't think you can update the loop index variable in list_for_each_entry, because the mcro uses th index variable to get to the next element. Perhaps list_for_each_entry_safe would be more suitable? julia -- Forwarded message -- Date: Thu, 20 Sep 2018 04:30:13 +0800 Fr

Fwd: vc4 in v4.19-rc2

Another boot gave me a little bit different result https://pastebin.com/FAwuVQf9 Please, see if you can help. Forwarded Message Subject:vc4 in v4.19-rc2 Date: Thu, 6 Sep 2018 11:01:01 +0300 From: Sergey Suloev To: e...@anholt.net CC: dri-devel@lists.freede

[radeon-alex:drm-next-4.19 52/60] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:352:1-14: code aligned with following code on line 354 (fwd)

It seems that line 352 should have one more tab at the beginning of the line. julia -- Forwarded message -- Date: Fri, 10 Aug 2018 21:01:50 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [radeon-alex:drm-next-4.19 52/60] drivers/gpu/drm/amd/amdgpu/

[PATCH] drm/nouveau/debugfs: fix pm_runtime.cocci warnings (fwd)

From: kbuild test robot pm_runtime_get_sync returns < 0 as error. Unecessary IS_ERR_VALUE at line 164 Generated by: scripts/coccinelle/api/pm_runtime.cocci Fixes: eaeb9010bb4b ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking") CC: Karol Herbst Signed-off-by: kbuild test robot S

Re: [resend PATCH v4 2/5] clk: mediatek: mt2701-mmsys: switch to platform device probing (fwd)

On 18/07/18 16:54, Julia Lawall wrote: > Please check on whether the kfree is still needed. No it is not needed, thanks for noting. Matthias > > julia > > -- Forwarded message -- > Date: Wed, 18 Jul 2018 22:03:48 +0800 > From: kbuild test robot > To: kbu...@01.org > Cc: Julia

Re: [resend PATCH v4 3/5] clk: mediatek: mt8173: switch mmsys to platform device probing (fwd)

On 18/07/18 16:53, Julia Lawall wrote: > Hello, > > Please check on whether the kfree in the remove function is still needed. > Also the platform_driver structure has two probe fields. Fair enough, kfree(private) is not needed, because it is allocated with devm_kzalloc. I'll fix both errors. T

Re: [resend PATCH v4 3/5] clk: mediatek: mt8173: switch mmsys to platform device probing (fwd)

Hello, Please check on whether the kfree in the remove function is still needed. Also the platform_driver structure has two probe fields. julia -- Forwarded message -- Date: Wed, 18 Jul 2018 22:31:13 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: Re:

Re: [resend PATCH v4 2/5] clk: mediatek: mt2701-mmsys: switch to platform device probing (fwd)

Please check on whether the kfree is still needed. julia -- Forwarded message -- Date: Wed, 18 Jul 2018 22:03:48 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: Re: [resend PATCH v4 2/5] clk: mediatek: mt2701-mmsys: switch to platform device probing

Fwd: [radeon-alex:drm-next-4.19-wip 126/132] drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:150:1-3: WARNING: possible condition with no effect (if == else)

Please check on lines 150-153. Both branches appear to be the same. thanks, julia Courriel original Objet: [radeon-alex:drm-next-4.19-wip 126/132] drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:150:1-3: WARNING: possible condition with no effect (if == else) Date: 04.07.2018 15:10 D

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 11/06/18 14:20, Hans Verkuil wrote: > Hi Ville, > > I finally found some time to dig deeper into when a CEC device should be > registered. > > Since it's been a long while since we discussed this let me just recap the > situation > and then propose three solutions: > CEC is implemented for D

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

Hi Ville, I finally found some time to dig deeper into when a CEC device should be registered. Since it's been a long while since we discussed this let me just recap the situation and then propose three solutions: CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers. Whe

Re: [radeon-alex:drm-next-4.18-wip 44/78] drivers/gpu/drm/amd/amdgpu/soc15.c:680:3-24: duplicated argument to & or | (fwd)

Huang, Ray Subject: [radeon-alex:drm-next-4.18-wip 44/78] drivers/gpu/drm/amd/amdgpu/soc15.c:680:3-24: duplicated argument to & or | (fwd) Lines 680 and 682 contain the same constant. julia -- Forwarded message -- Date: Sat, 19 May 2018 04:22:09 +0800 From: kbuild test robot

[radeon-alex:drm-next-4.18-wip 44/78] drivers/gpu/drm/amd/amdgpu/soc15.c:680:3-24: duplicated argument to & or | (fwd)

Lines 680 and 682 contain the same constant. julia -- Forwarded message -- Date: Sat, 19 May 2018 04:22:09 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [radeon-alex:drm-next-4.18-wip 44/78] drivers/gpu/drm/amd/amdgpu/soc15.c:680:3-24: duplicated

Re: Fwd: DRM MIPI DSI device and I2C device?

> 2018-04-05 13:39 GMT+02:00 Laurent Pinchart < laurent.pinch...@ideasonboard.com>: > Hi Andrzej, > > On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: >> On 05.04.2018 12:28, Laurent Pinchart wrote: >>> On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: > Hi, >

Re: Fwd: DRM MIPI DSI device and I2C device?

On 05.04.2018 13:51, Carsten Behling wrote: > > > > 2018-04-05 13:39 GMT+02:00 Laurent Pinchart > >: > > Hi Andrzej, > > > > On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: > >> On 05.04.2018 12:28, Laurent Pinchart wrote: > >>> On Wednesday,

Re: Fwd: DRM MIPI DSI device and I2C device?

Hi Andrzej, On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: > On 05.04.2018 12:28, Laurent Pinchart wrote: > > On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: > >>> Hi, > >>> > >>> I would like to write a DRM bridge driver that is an I2C device and a > >>> DRM MIPI DS

Re: Fwd: DRM MIPI DSI device and I2C device?

On 05.04.2018 12:28, Laurent Pinchart wrote: > Hi Carsten, > > On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: >>> Hi, >>> >>> I would like to write a DRM bridge driver that is an I2C device and a DRM >>> MIPI DSI device. >>> >>> It looks like that both - 'i2c-core.c: of_i2c_registe

Re: Fwd: DRM MIPI DSI device and I2C device?

Hi Carsten, On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: > > Hi, > > > > I would like to write a DRM bridge driver that is an I2C device and a DRM > > MIPI DSI device. > > > > It looks like that both - 'i2c-core.c: of_i2c_register_devices' and > > 'drm_mipi_dsi.c: mipi_dsi_hos

Fwd: DRM MIPI DSI device and I2C device?

> Hi, > > I would like to write a DRM bridge driver that is an I2C device and a DRM MIPI DSI device. > > It looks like that both - 'i2c-core.c: of_i2c_register_devices' and 'drm_mipi_dsi.c: mipi_dsi_host_register' are registering their devices by iterating over devicetree child nodes with for_each

[drm-intel:drm-intel-next-queued 13/14] drivers/gpu/drm/i915/intel_guc.c:230:12-17: WARNING: Unsigned expression compared with zero: level < 0 (fwd)

Level is unsigned, so not less than 0 (line 230). julia -- Forwarded message -- Date: Tue, 20 Mar 2018 16:39:16 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [drm-intel:drm-intel-next-queued 13/14] drivers/gpu/drm/i915/intel_guc.c:230:12-17: WARNI

  1   2   3   >