[PATCH] drm/vkms: add missing platform_device_unregister() in vkms_init()

When vkms_init() get into out_put, the unregister call of vkms_device->platform is missing. So add it before return. Fixes: c27f0cc4d43a "drm/vkms: enable cursor by default" Signed-off-by: Qinglang Miao --- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) di

Re: [PATCH v1 01/12] fbdev: gxfb: use generic power management

On Sat, Aug 08, 2020 at 01:17:46PM +0200, Sam Ravnborg wrote: > Hi Vaibhav > > On Wed, Aug 05, 2020 at 11:37:11PM +0530, Vaibhav Gupta wrote: > > Drivers using legacy power management .suspen()/.resume() callbacks > > have to manage PCI states and device's PM states themselves. They also > > need

[PATCH v2 05/12] fbdev: aty128fb: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

Re: [PATCH] drm/mgag200: fix build on alpha arch

Hi Sam thanks for taken care of this issue. Alpha is a rare architecture these days. How do you build and test for it? Am 07.08.20 um 20:05 schrieb Sam Ravnborg: > When building imgag200 for the alpha architecture it fails like this: > mgag200_drv.c:233:9: error: implicit declaration of function

[PATCH] drm/amd/display: convert to use le16_add_cpu()

Convert cpu_to_le16(le16_to_cpu(E1) + E2) to use le16_add_cpu(). Signed-off-by: Qinglang Miao --- drivers/gpu/drm/amd/display/dc/bios/command_table.c | 4 +--- drivers/gpu/drm/amd/display/dc/bios/command_table2.c | 5 + 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/

[PATCH v2 07/12] fbdev: savagefb: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

[PATCH v2 02/12] fbdev: lxfb: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

[PATCH -next] drm/rockchip: cdn-dp: Mark cdn_dp_core_suspend/resume __maybe_unused

If CONFIG_PM is not set, gcc warns: drivers/gpu/drm/rockchip/cdn-dp-core.c:1124:12: warning: ‘cdn_dp_resume’ defined but not used [-Wunused-function] Mark them __maybe_unused to fix this. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 ++-- 1

[PATCH v2 03/12] fbdev: via-core: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

[PATCH v2 11/12] fbdev: s3fb: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

[PATCH v1 2/2] drm/bridge: add refactored it6505 driver

This adds support for the iTE IT6505. This device can convert DPI signal to DP output. Signed-off-by: Jitao Shi Signed-off-by: Pi-Hsun Shih Signed-off-by: Yilun Lin Signed-off-by: Hermes Wu Signed-off-by: Allen Chen --- drivers/gpu/drm/bridge/Kconfig |7 + drivers/gpu/drm/bridge/Mak

[PATCH 2/5] drm/panel: novatek, nt39016: Add missing CR to error messages

If you pass a string that is not terminated with a carriage return to dev_err(), it will eventually be printed with a carriage return, but not right away, since the kernel will wait for a pr_cont(). Signed-off-by: Paul Cercueil --- drivers/gpu/drm/panel/panel-novatek-nt39016.c | 18 +

Re: [PATCH] drm: assure aux_dev is nonzero before using it

Hi Folks, I know this thread eventually dropped off due to not identifying the underlying issue. It's still occuring on 5.8 and in my case it happened because the udev device nodes for the DP aux devices were not cleaned up whereas the kernel had no association with them. I can reproduc

[PATCH v2 09/12] fbdev: i740fb: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

Re: [PATCH v1 01/12] fbdev: gxfb: use generic power management

> > > -static int gxfb_suspend(struct pci_dev *pdev, pm_message_t state) > > > +static int __maybe_unused gxfb_suspend(struct device *dev) > > > { > > > - struct fb_info *info = pci_get_drvdata(pdev); > > > + struct fb_info *info = dev_get_drvdata(dev); > > I do not see any dev_set_drvdata() so I

[PATCH 3/5] drm/panel: simple: Convert sharp, ls020b1dd01d from timings to videomode

Convert the Sharp LS020B1DD01D panel entry from using a struct display_timing to using a struct drm_display_mode, as display_timing seems to be the old and legacy format. Signed-off-by: Paul Cercueil --- drivers/gpu/drm/panel/panel-simple.c | 28 +++- 1 file changed, 15 i

[PATCH 0/5] drm/panel: A few cleanups and improvements

Hi list, Here's a list of 5 patches that bring some cleanups and improvements. Patches 1-2 clean up the novatek,nt39016 code to remove custom handling of the backlight and to add the missing carriage returns on error messages. Patches 3-5 updates the modes list of the sharp,ls020b1dd01d panel, t

Re: [PATCH v1 01/12] fbdev: gxfb: use generic power management

On Mon, Aug 10, 2020 at 06:54:58PM +0200, Sam Ravnborg wrote: > Hi Vaibhav > On Mon, Aug 10, 2020 at 03:09:48PM +0530, Vaibhav Gupta wrote: > > On Sat, Aug 08, 2020 at 01:17:46PM +0200, Sam Ravnborg wrote: > > > Hi Vaibhav > > > > > > On Wed, Aug 05, 2020 at 11:37:11PM +0530, Vaibhav Gupta wrote:

[PATCH 1/5] drm/panel: novatek, nt39016: Handle backlight the standard way

Instead of manipulating the backlight directly in this driver, register it in the probe using drm_panel_of_backlight() and let the drm_panel framework code handle it. Signed-off-by: Paul Cercueil --- drivers/gpu/drm/panel/panel-novatek-nt39016.c | 16 1 file changed, 4 insertion

[PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property

Document optional vcc-supply property that may be used as VCC source. Signed-off-by: Biju Das --- New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/ --- .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentatio

[PATCH 5/5] drm/panel: simple: Add 50Hz mode for sharp,ls020b1dd01d

Add a perfect 50.00 Hz frame rate mode to the list of available modes for the Sharp LS020B1DD01D panel. Signed-off-by: Paul Cercueil --- drivers/gpu/drm/panel/panel-simple.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/

[PATCH v2 06/12] fbdev: nvidia: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

[PATCH v2 04/12] fbdev: aty: use generic power management

Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to ha

Re: [PATCH] drm: amdgpu: Use the correct size when allocating memory

Le 10/08/2020 à 17:42, Dan Carpenter a écrit : On Sun, Aug 09, 2020 at 10:34:06PM +0200, Christophe JAILLET wrote: When '*sgt' is allocated, we must allocated 'sizeof(**sgt)' bytes instead of 'sizeof(*sg)'. 'sg' (i.e. struct scatterlist) is smaller than 'sgt' (i.e struct sg_table), so this coul

[PATCH v2] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets

add event thread to execute events serially from event queue. Also timeout mode is supported which allow an event be deferred to be executed at later time. Both link and phy compliant tests had been done successfully. Changes in v2: - Fix potential deadlock by removing redundant connect_mutex -

[PATCH] drm/v3d: convert to use module_platform_driver

Get rid of boilerplate code by using module_platform_driver macro for v3d_drm. Signed-off-by: Qinglang Miao --- drivers/gpu/drm/v3d/v3d_drv.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c index 82a7

[PATCH v2 00/12] video: fbdev: use generic power management

Linux Kernel Mentee: Remove Legacy Power Management. The purpose of this patch series is to upgrade power management in video fbdev drivers. This has been done by upgrading .suspend() and .resume() callbacks. The upgrade makes sure that the involvement of PCI Core does not change the order of ope

Re: [linux.git drm/ttm]: NULL pointer dereference upon driver probe

> Well how about completely removing the concept of a global TT from TTM? Yes makes sense to me to try and rip out the global TT from the core and turn it into a driver optional feature is possible. Dave. > > What TTM should do is managing domains and help with the transitions > between those do

[PATCH 2/2] drm/ttm: drop bus.size from bus placement.

From: Dave Airlie This is always calculated the same, and only used in a couple of places. --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 7 --- drivers/gpu/drm/ttm/ttm_bo_util.c | 7 --- include/drm/ttm/ttm_bo_api.h| 2 --

[PATCH 1/2] drm/ttm: init mem->bus in common code.

From: Dave Airlie The drivers all do the same thing here. Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 -- drivers/gpu/drm/drm_gem_vram_helper.c | 6 -- drivers/gpu/drm/nouveau/nouveau_bo.c | 6 -- drivers/gpu/drm/qxl/qxl_ttm.c

Re: [PATCH] drm: amdgpu: Use the correct size when allocating memory

On Mon, Aug 10, 2020 at 08:41:14PM +0200, Marion & Christophe JAILLET wrote: > > Le 10/08/2020 à 17:42, Dan Carpenter a écrit : > > On Sun, Aug 09, 2020 at 10:34:06PM +0200, Christophe JAILLET wrote: > > > When '*sgt' is allocated, we must allocated 'sizeof(**sgt)' bytes instead > > > of 'sizeof(*

Re: [PATCH] drm: amdgpu: Use the correct size when allocating memory

On Tue, Aug 11, 2020 at 10:57:02AM +0300, Dan Carpenter wrote: > On Mon, Aug 10, 2020 at 08:41:14PM +0200, Marion & Christophe JAILLET wrote: > > > > Le 10/08/2020 à 17:42, Dan Carpenter a écrit : > > > On Sun, Aug 09, 2020 at 10:34:06PM +0200, Christophe JAILLET wrote: > > > > When '*sgt' is allo

Re: [PATCH 1/2] drm/ttm: init mem->bus in common code.

(cc'ing Christian, just in case he misses them). 2 small cleanups. On Tue, 11 Aug 2020 at 17:47, Dave Airlie wrote: > > From: Dave Airlie > > The drivers all do the same thing here. > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 -- > drivers/gpu/drm/

Re: [PATCH] drm/mgag200: fix build on alpha arch

Hi Thomas. On Tue, Aug 11, 2020 at 08:59:13AM +0200, Thomas Zimmermann wrote: > Hi Sam > > thanks for taken care of this issue. Alpha is a rare architecture these > days. How do you build and test for it? I am on ubuntu here so I have installed: apt install gcc-alpha-linux-gnu And then alpha is

Re: [PATCH 1/2] drm/ttm: init mem->bus in common code.

I've totally missed those and still don't see any reference in any inbox to the original mail or patch #2 in this series. But this patch at least looks like it makes a lot of sense. BTW: Does anybody know why we separate base and offset here? That distinction seems to be superfluous as well.

Re: [PATCH 1/2] drm/ttm: init mem->bus in common code.

On Tue, 11 Aug 2020 at 18:42, Christian König wrote: > > I've totally missed those and still don't see any reference in any inbox > to the original mail or patch #2 in this series. I forgot to cc you on the original posting, but they should be on dri-devel https://patchwork.freedesktop.org/serie

Re: [PATCH 1/2] drm/ttm: init mem->bus in common code.

Am 11.08.20 um 10:49 schrieb Dave Airlie: On Tue, 11 Aug 2020 at 18:42, Christian König wrote: I've totally missed those and still don't see any reference in any inbox to the original mail or patch #2 in this series. I forgot to cc you on the original posting, but they should be on dri-devel

Re: [PATCH] drm/mgag200: fix build on alpha arch

On Tue, Aug 11, 2020 at 10:12:01AM +0200, Sam Ravnborg wrote: > Hi Thomas. > > On Tue, Aug 11, 2020 at 08:59:13AM +0200, Thomas Zimmermann wrote: > > Hi Sam > > > > thanks for taken care of this issue. Alpha is a rare architecture these > > days. How do you build and test for it? > > I am on ubu

Re: [PATCH] drm: assure aux_dev is nonzero before using it

On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote: > Hi Folks, > I know this thread eventually dropped off due to not identifying > the underlying issue. It's still occuring on 5.8 and in my case it > happened because the udev device nodes for the DP aux devices were not > cl

[PATCH] drm/ttm: revert "make TT creation purely optional v3"

This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b. As it turned out VMWGFX needs a much wider audit to fix this. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 19 --- drivers/gpu/drm/ttm/ttm_bo_util.c | 7 ++- drivers/gpu/drm/ttm/ttm_bo_v

Re: [PATCH v8 2/2] display/drm/bridge: TC358775 DSI/LVDS driver

Hi Sam, On Mon, Aug 10, 2020 at 07:54:40PM +0200, Sam Ravnborg wrote: > Hi Vinay. > > Vinay - thanks for following carefully up on the review feedback. > I know it can be frustrating to wait for feedback. > > On Sun, Aug 09, 2020 at 12:30:22AM +0300, Laurent Pinchart wrote: > > Hi Vinay, > > >

Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property

Hi Biju, Thank you for the patch. On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote: > Document optional vcc-supply property that may be used as VCC source. > > Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart > --- > New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819

Re: [PATCH v2 2/3] drm/bridge: lvds-codec: Add support for regulator

Hi Biju, Thank you for the patch. On Mon, Aug 10, 2020 at 04:22:18PM +0100, Biju Das wrote: > Add the support for enabling optional regulator that may be used as VCC > source. > > Signed-off-by: Biju Das > --- > New Patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/ > --- > drivers/gp

[PATCH] locking/rwsem: remove redundant semicolon of down_write_nest_lock

From: Guchun Chen Otherwise, braces are needed when using it. Signed-off-by: Guchun Chen Reviewed-by: Christian König --- include/linux/rwsem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h index 7e5b2a4eb560..7a5bf5d50489 10

Re: [PATCH 7/7] ARM: dts: r8a7742-iwg21d-q7: Add LCD support

Hi Prabhakar, Thank you for the patch. On Fri, Aug 07, 2020 at 06:49:54PM +0100, Lad Prabhakar wrote: > The iwg21d comes with a 7" capacitive touch screen, therefore > add support for it. > > Signed-off-by: Lad Prabhakar > Reviewed-by: Marian-Cristian Rotariu > > --- > arch/arm/boot/dts/r8a7

[RESEND PATCH v3 2/2] drm: panel: Add tianma nt36672a panel driver

Some Poco F1 phones have an LCD panel from Tianma, model nt36672a, with a resolution of 1080x2246 that operates in DSI video mode. Add the drm panel driver for it. During testing, Benni Steini helped us fix the reset sequence timing (from 10ms to 20ms), to get the bootanimation to work on Androi

[RESEND PATCH v3 0/2] Add support for Tianma nt36672a video mode panel

Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is her

[RESEND PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246 and 6.18 inches size. It is found in some of the Poco F1 phones. Signed-off-by: Sumit Semwal Reviewed-by: Rob Herring --- v2: remove ports node, making port@0 directly under panel@0 node. v3: updated to replace port@0

Re: [PATCH] drm/ttm: revert "make TT creation purely optional v3"

Am 11.08.20 um 11:24 schrieb Christian König: This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b. As it turned out VMWGFX needs a much wider audit to fix this. Signed-off-by: Christian König Dare to give me an rb for this? I already tested on amdgpu and it should be fixing the VMW

Re: [PATCH] drm/ttm: revert "make TT creation purely optional v3"

Am 11.08.20 um 14:52 schrieb Christian König: Am 11.08.20 um 11:24 schrieb Christian König: This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b. As it turned out VMWGFX needs a much wider audit to fix this. Signed-off-by: Christian König Dare to give me an rb for this? I already te

Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes

There are a few cases when the flags can change, for example DCC can be disabled due to a hw limitation in the 3d engine. Modifiers give the misleading impression that they help with that, but they don't. They don't really help with anything. Marek On Mon., Aug. 10, 2020, 08:30 Christian König, <

Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

> On Aug 10, 2020, at 5:49 AM, Daniel Vetter wrote: > > On Sat, Aug 08, 2020 at 05:24:53PM +0200, Daniel Vetter wrote: >> On Sat, Aug 8, 2020 at 1:28 PM Greg KH wrote: >>> >>> On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote: On Sat, Aug 8, 2020 at 12:24 PM Greg KH wrote:

Re: [Intel-gfx] [PATCH v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message

On Thu, Jul 2, 2020 at 10:49 AM Anshuman Gupta wrote: > > On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote: > > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta > > wrote: > > > \snip > > > > +static bool > > > > +drm_dp_sideband_parse_query_stream_enc_status( > > > > +

imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

Hello, we are using the mainline kernel (currently on 4.19.128) successfully on an i.MX6DL-based system, but when we try to upgrade to any more recent kernel (>5.1) the display output stops working (screen is blank, backlight works). The relevant entries from the kernel log seem to be: [8.

Re: [PATCH] vt: defer kfree() of vc_screenbuf in vc_do_resize()

On Wed, Aug 12, 2020 at 12:02:03AM +0900, Tetsuo Handa wrote: > On 2020/08/04 21:58, Greg Kroah-Hartman wrote: > > On Tue, Aug 04, 2020 at 08:15:43PM +0900, Tetsuo Handa wrote: > >> Do you think this approach is acceptable? Or, do we need to modify > >> set_origin() ? > >> > > I think what you hav

Re: imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

On Tue, Aug 11, 2020 at 5:07 PM Stefan Birkholz wrote: > > Hello, > > we are using the mainline kernel (currently on 4.19.128) successfully on an > i.MX6DL-based system, but when we try to upgrade to any more recent kernel > (>5.1) the display output stops working (screen is blank, backlight wor

AW: imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

Hi Daniel, actually git bisection yielded two subsequent commits 5bf7295fe34a525 and 80acbed9f8fca1db3f, both were bad, but I wasn't clear about what changed in the imx-drm subsystem in those commits; bisection stopped then. I noticed there was a transition from using to in that timespan, bu

Re: imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

On Tue, 2020-08-11 at 14:50 +, Stefan Birkholz wrote: > Hello, > > we are using the mainline kernel (currently on 4.19.128) successfully on an > i.MX6DL-based system, but when we try to upgrade to any more recent kernel > (>5.1) the display output stops working (screen is blank, backlight wo

AW: imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

On the working system I get: [3.359749] pwm-backlight backlight: Linked as a consumer to regulator.7 [8.789867] panel-lvds panel: Linked as a consumer to regulator.8 Non-working: [3.362822] pwm-backlight backlight: Linked as a consumer to regulator.7 [3.362907] pwm-backlight backli

Re: [PATCH] drm/msm/a6xx: fix crashdec section name typo

On Sat, Aug 08, 2020 at 10:29:11AM -0700, Rob Clark wrote: > From: Rob Clark > > Backport note: maybe wait some time for the crashdec MR[1] to look for > both the old typo'd name and the corrected name to land in mesa 20.2 > > [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6242 R

Re: [PATCH] drm/ttm: revert "make TT creation purely optional v3"

On 2020-08-11 2:53 p.m., Christian König wrote: > Am 11.08.20 um 14:52 schrieb Christian König: >> Am 11.08.20 um 11:24 schrieb Christian König: >>> This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b. >>> >>> As it turned out VMWGFX needs a much wider audit to fix this. >>> >>> Signed-off

Re: [PATCH] drm/ttm: revert "make TT creation purely optional v3"

Am 11.08.20 um 18:42 schrieb Michel Dänzer: On 2020-08-11 2:53 p.m., Christian König wrote: Am 11.08.20 um 14:52 schrieb Christian König: Am 11.08.20 um 11:24 schrieb Christian König: This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b. As it turned out VMWGFX needs a much wider audi

Re: [Intel-gfx] [PATCH v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message

On Thu, Jul 9, 2020 at 9:09 AM Anshuman Gupta wrote: > > On 2020-07-02 at 20:07:36 +0530, Anshuman Gupta wrote: > > On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote: > > > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta > > > wrote: > > > > > > > > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote

Re: [Intel-gfx] [PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors

On Thu, Jul 9, 2020 at 8:40 AM Anshuman Gupta wrote: > \snip > > > +static int > > > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port > > > *intel_dig_port, > > > + enum transcoder cpu_transcoder, > > > + bool enable) > >

[PATCH v4 2/2] drm: panel: Add tianma nt36672a panel driver

Some Poco F1 phones have an LCD panel from Tianma, model nt36672a, with a resolution of 1080x2246 that operates in DSI video mode. Add the drm panel driver for it. During testing, Benni Steini helped us fix the reset sequence timing (from 10ms to 20ms), to get the bootanimation to work on Androi

[PATCH v4 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246 and 6.18 inches size. It is found in some of the Poco F1 phones. Signed-off-by: Sumit Semwal Reviewed-by: Rob Herring --- v2: remove ports node, making port@0 directly under panel@0 node. v3: updated to replace port@0

[PATCH v4 0/2] Add support for Tianma nt36672a video mode panel

Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is her

Re: [PATCH v8 2/2] display/drm/bridge: TC358775 DSI/LVDS driver

Hi Vinay. > > > > If Laurent or others identify further things to improve we can take > > it in-tree. > > Just one thing, please see below. > > > > > >> + d2l_write(tc->i2c, VTIM1, vtime1); > > > > >> + d2l_write(tc->i2c, HTIM2, htime2); > > > > >> + d2l_write(tc->i2c, VTIM2,

Re: [PATCH] drm/ttm: revert "make TT creation purely optional v3"

On Wed, 12 Aug 2020 at 03:11, Christian König wrote: > > Am 11.08.20 um 18:42 schrieb Michel Dänzer: > > On 2020-08-11 2:53 p.m., Christian König wrote: > >> Am 11.08.20 um 14:52 schrieb Christian König: > >>> Am 11.08.20 um 11:24 schrieb Christian König: > This reverts commit 2ddef17678bc2ea

[PATCH] drm/i915/gt: fix itnull.cocci warnings

From: kernel test robot drivers/gpu/drm/i915/gt/gen6_ppgtt.c:263:6-8: ERROR: iterator variable bound on line 262 cannot be NULL drivers/gpu/drm/i915/gt/gen6_ppgtt.c:322:7-9: ERROR: iterator variable bound on line 321 cannot be NULL Many iterators have the property that the first argument is a

[drm-intel:drm-intel-next-queued 27/28] drivers/gpu/drm/i915/gt/gen6_ppgtt.c:263:6-8: ERROR: iterator variable bound on line 262 cannot be NULL

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 06b108297b5cc24418e91c1103587ac7ca6fd03f commit: 1d567ec619333e54283dcd02780ab9a71ef86e44 [27/28] drm/i915/gt: Switch to object allocations for page directories config: i386-randconfig-c001-20200811 (attached as .config

Re: [PATCH v9 3/5] drm/msm/dp: add support for DP PLL driver

On 2020-08-07 13:28, Randy Dunlap wrote: On 8/7/20 1:24 PM, Stephen Boyd wrote: Quoting Rob Clark (2020-08-07 08:51:48) On Fri, Aug 7, 2020 at 8:27 AM Randy Dunlap wrote: On 8/7/20 12:17 AM, Tanmay Shah wrote: diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index ea3

Re: [RFC PATCH V2 0/2] Add Xilinx DSI TX driver

Hi Venkateshwar On Tue, Aug 11, 2020 at 06:16:15AM +0530, Venkateshwar Rao Gannavarapu wrote: > Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar > and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes > upto 4, RGB color formats, video mode and command modes.

[RFC 02/20] drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()

Noticed this while going through our DP code - we use an open-coded version of drm_dp_read_desc() instead of just using the helper, so change that. This will also let us use quirks in the future if we end up needing them. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nou

[RFC 11/20] drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect()

For whatever reason we currently unset the EDID for DP CEC support when responding to the connector being unplugged, instead of just doing it in nouveau_connector_detect() where we set the CEC EDID. This isn't really needed and could even potentially cause us to forget to unset the EDID if the conn

[RFC 09/20] drm/i915/dp: Extract drm_dp_has_mst()

Just a tiny drive-by cleanup, we can consolidate i915's code for checking for MST support into a helper to be shared across drivers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/display/intel_dp.c | 18 ++ include/drm/drm_dp_mst_helper.h | 22 ++

[RFC 06/20] drm/nouveau/kms: Search for encoders' connectors properly

While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_c

[RFC 08/20] drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling

First some backstory here: Currently, we keep track of whether or not we've enabled MST or not by trying to piggy-back off the MST helpers. This means that in order to check whether MST is enabled or not, we actually need to grab drm_dp_mst_topology_mgr.lock. Back when I originally wrote this, I d

[RFC 03/20] drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c

Since this actually logs accesses, we should probably always be using this imho… Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/dr

[RFC 04/20] drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c

No functional changes. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8db9216d52c69..4030806

[RFC 12/20] drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths

Currently we perform both short IRQ handling for DP, and connector reprobing in the HPD IRQ handler. However since we need to grab connection_mutex in order to reprobe a connector, in theory we could accidentally block ourselves from handling any short IRQs until after a modeset completes if a conn

[RFC 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation

This adds support for querying the maximum clock rate of a downstream port on a DisplayPort connection. Generally, downstream ports refer to active dongles which can have their own pixel clock limits. Note as well, we also start marking the connector as disconnected if we can't read the DPCD, sinc

[RFC 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()

Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8a0f7994e1aeb..ee778ddc95fae 100644 --- a/drivers/gpu/drm/nouveau/nouve

[RFC 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's

[RFC 05/20] drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()

Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before enabling") we've been clearing DP_MST_CTRL before we start enabling MST. Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary and redundant, so let's remove it. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs

[RFC 07/20] drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable()

Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers

[RFC 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps

Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index d701f09aea645..bb85d81c25244 100644 --- a/drivers/gpu/drm/nou

[RFC 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()

Now that we've extracted i915's code for reading both the normal DPCD caps and extended DPCD caps into a shared helper, let's start using this in nouveau to enable us to start checking extended DPCD caps for free. Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++

[RFC 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()

And of course, we'll also need to read the sink count from other drivers as well if we're checking whether or not it's supported. So, let's extract the code for this into another helper. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 20 drivers/gpu/

[RFC 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()

Since DP 1.3, it's been possible for DP receivers to specify an additional set of DPCD capabilities, which can take precedence over the capabilities reported at DP_DPCD_REV. Basically any device supporting DP is going to need to read these in an identical manner, in particular nouveau, so let's go

[RFC 18/20] drm/nouveau/kms: Don't change EDID when it hasn't actually changed

Currently in nouveau_connector_ddc_detect() and nouveau_connector_detect_lvds(), we start the connector probing process by releasing the previous EDID and informing DRM of the change. However, since commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") drm_connector_update_edid_prop

[RFC 15/20] drm/i915/dp: Extract drm_dp_has_sink_count()

Since other drivers are also going to need to be aware of the sink count in order to do proper dongle detection, we might as well steal i915's DP_SINK_COUNT helpers and move them into DRM helpers so that other dirvers can use them as well. Note that this also starts using intel_dp_has_sink_count()

[RFC 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

This is another bit that we never implemented for nouveau: dongle detection. When a "dongle", e.g. an active display adaptor, is hooked up to the system and causes an HPD to be fired, we don't actually know whether or not there's anything plugged into the dongle without checking the sink count. As

[RFC 13/20] drm/i915/dp: Extract drm_dp_downstream_read_info()

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_downstream_read_info(). Note that when we do this, we also do make some functional changes

Re: [PATCH] drm/panel-notatek-nt35510: Fix MTP read init

On Mon, Aug 10, 2020 at 3:04 PM Daniel Vetter wrote: > On Sun, Aug 09, 2020 at 12:43:22AM +0200, Linus Walleij wrote: > > In order to successfully read ID of the MTP panel the > > panel MTP control page must be unlocked. Previously > > this wasn't encountered because in the setup with this > > pan

Re: [RFC PATCH V2 0/2] Add Xilinx DSI TX driver

On Tue, Aug 11, 2020 at 2:46 AM Venkateshwar Rao Gannavarapu wrote: > > Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar > and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes > upto 4, RGB color formats, video mode and command modes. > > DSI-TX driver is im

Re: [RFC PATCH V2 0/2] Add Xilinx DSI TX driver

Hi GVRao, Thank you for the patches. On Tue, Aug 11, 2020 at 06:16:15AM +0530, Venkateshwar Rao Gannavarapu wrote: > Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar > and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes > upto 4, RGB color formats, video m

Re: [PATCH] drm/panel-notatek-nt35510: Fix MTP read init

On Tue, Aug 11, 2020 at 10:24 PM Linus Walleij wrote: > > On Mon, Aug 10, 2020 at 3:04 PM Daniel Vetter wrote: > > On Sun, Aug 09, 2020 at 12:43:22AM +0200, Linus Walleij wrote: > > > In order to successfully read ID of the MTP panel the > > > panel MTP control page must be unlocked. Previously >

[PATCH] drm/msm/dpu: fix unitialized variable error

From: Rob Clark drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error: uninitialized symbol 'request_bandwidth'. Reported-by: kernel test robot Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --

Re: [PATCH] drm/msm/dpu: fix unitialized variable error

On Tue, Aug 11, 2020 at 5:08 PM Rob Clark wrote: > > From: Rob Clark > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error: > uninitialized symbol 'request_bandwidth'. > > Reported-by: kernel test robot Reviewed-by: Sean Paul > Signed-off-by: Rob Clark > --- > drivers/g

  1   2   >