[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2)

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2) URL : https://patchwork.freedesktop.org/series/87242/ State : success == Summary == CI Bug Log - changes from CI_DRM_9790_full -> Patchwork_19706_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2)

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2) URL : https://patchwork.freedesktop.org/series/87242/ State : success == Summary == CI Bug Log - changes from CI_DRM_9790 -> Patchwork_19706

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2)

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2) URL : https://patchwork.freedesktop.org/series/87242/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separate

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2)

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers (rev2) URL : https://patchwork.freedesktop.org/series/87242/ State : warning == Summary == $ dim checkpatch origin/drm-tip 428923af2258 drm/dp: Rewrap kdocs for struct drm_dp_aux 2c3cb32ffa61 drm/dp: Fi

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers URL : https://patchwork.freedesktop.org/series/87242/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9790_full -> Patchwork_19705_full ===

Re: [Intel-gfx] [PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux

On 2/19/21 1:52 PM, Lyude Paul wrote: > Since we're about to be adding some more fields and update this > documentation, let's rewrap it to the new column limit of 100 beforehand. > No actual doc or functional changes are made here. > The preferred column limit is still 80. For some (exceptional)

Re: [Intel-gfx] [PATCH 02/30] drm/dp: Fixup kernel docs for struct drm_dp_aux

On 2/19/21 1:52 PM, Lyude Paul wrote: > * Make sure that struct members are referred to using @, otherwise they > won't be formatted as such > * Make sure to refer to other struct types using & so they link back to > each struct's definition > * Make sure to precede constant values with % so th

Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device

On Thu, Feb 18, 2021 at 10:06:08PM -0800, Winkler, Tomas wrote: On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote: >> >> On Tue, 16 Feb 2021, Tomas Winkler wrote: >> > Add the platform driver for i915 on-die spi device, exposed via mfd >> > framework. >> > >> > Cc: Rodrigo Vivi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers URL : https://patchwork.freedesktop.org/series/87242/ State : success == Summary == CI Bug Log - changes from CI_DRM_9790 -> Patchwork_19705 Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers URL : https://patchwork.freedesktop.org/series/87242/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

== Series Details == Series: drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers URL : https://patchwork.freedesktop.org/series/87242/ State : warning == Summary == $ dim checkpatch origin/drm-tip ce207403b6ba drm/dp: Rewrap kdocs for struct drm_dp_aux 59ab34a09514 drm/dp: Fixup ker

[Intel-gfx] [PATCH 30/30] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

And finally, convert all of the code in drm_dp_mst_topology.c over to using drm_err() and drm_dbg*(). Note that this refactor would have been a lot more complicated to have tried writing a coccinelle script for, so this whole thing was done by hand. Signed-off-by: Lyude Paul --- drivers/gpu/drm/

[Intel-gfx] [PATCH 28/30] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()

Now that we've added a back-pointer to drm_device to drm_dp_aux, made drm_dp_aux available to any functions in drm_dp_helper.c which need to print to the kernel log, and ensured all of our logging uses a consistent format, let's do the final step of the conversion and actually move everything over

[Intel-gfx] [PATCH 29/30] drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()

Next step in the conversion, move everything in drm_dp_dual_mode_helper.c over to using drm_err() and drm_dbg_kms(). This was done using the following cocci script: @@ expression list expr; @@ ( - DRM_DEBUG_KMS(expr); + drm_dbg_kms(dev, expr); | - DRM_ERROR(expr); + drm_err(dev,

[Intel-gfx] [PATCH 27/30] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()

Since this is one of the few functions in drm_dp_mst_topology.c that doesn't have any way of getting access to a drm_device, let's pass the drm_dp_mst_topology_mgr down to this function so that it can use drm_dbg_kms(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_mst_topology.c |

[Intel-gfx] [PATCH 26/30] drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()

So that we can start using drm_dbg_*() throughout the DRM DP helpers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +--- drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++- include/drm/drm_dp_dual_mode_helper.h | 4 ++-- 3 files changed, 14

[Intel-gfx] [PATCH 25/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output()

Another function to pass drm_device * down to so we can start using the drm_dbg_*() in the DRM DP helpers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++-- include/drm/drm_dp_dual_mode_helper.h | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff -

[Intel-gfx] [PATCH 24/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()

Another function we need to pass drm_device down to in order to start using drm_dbg_*(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- include/drm/drm_dp_dual_mode_helper.h | 2 +- 3 files changed, 4 inserti

[Intel-gfx] [PATCH 22/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()

Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll need to be able to access the DRM device in the dual mode DP helpers as well. Note however that since drm_dp_dual_mode_detect() can be called with DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down th

[Intel-gfx] [PATCH 23/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output()

Another function that we'll need to pass a drm_device (and not drm_dp_aux) down to so that we can move over to using drm_dbg_*(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +-- include/drm/drm_dp_dual_mode_helpe

[Intel-gfx] [PATCH 20/30] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()

So that we can start using drm_dbg_*() for drm_dp_link_train_channel_eq_delay() and drm_dp_lttpr_link_train_channel_eq_delay(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c| 14 +- .../gp

[Intel-gfx] [PATCH 21/30] drm/dp: Always print aux channel name in logs

Since we're about to convert everything in drm_dp_helper.c over to using drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c while we're at it to ensure that we always print the name of the AUX channel in question. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_help

[Intel-gfx] [PATCH 15/30] drm/dp: Add backpointer to drm_device in drm_dp_aux

This is something that we've wanted for a while now: the ability to actually look up the respective drm_device for a given drm_dp_aux struct. This will also allow us to transition over to using the drm_dbg_*() helpers for debug message printing, as we'll finally have a drm_device to reference for d

[Intel-gfx] [PATCH 17/30] drm/dp: Clarify DP AUX registration time

The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display b

[Intel-gfx] [PATCH 19/30] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()

So that we can start using drm_dbg_*() in drm_dp_link_train_clock_recovery_delay(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c | 3 ++- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2

[Intel-gfx] [PATCH 18/30] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()

Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want to make sure that we can also add ratelimited versions of these macros in order to retain some of the previous debugging output behavior we had. However, as I was preparing to do this I noticed that the current rate limited

[Intel-gfx] [PATCH 16/30] drm/dp: Rewrap drm_dp_aux_register()/drm_dp_aux_init() kdocs

We're about to make a correction to these, so let's rewrap the kernel docs for these while we're at it. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers

[Intel-gfx] [PATCH 13/30] drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe()

Just another drive-by fix I noticed while going through the tree to cleanup DP aux adapter registration - make sure we unregister the DP AUX dev if analogix_dp_probe() fails. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + 1 file changed, 1 insertion(+) d

[Intel-gfx] [PATCH 14/30] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister

Since AUX adapters on nouveau have their respective DRM connectors as parents, we need to make sure that we register then after their connectors. Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_connector.c | 26 ++--- 1 file changed, 18 insertions(+), 8 deletions(-)

[Intel-gfx] [PATCH 12/30] drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach()

Another drive-by fix I found when fixing DP AUX adapter across the kernel tree - make sure we don't leak resources (and by proxy-AUX adapters) on failures in anx6345_bridge_attach() by unrolling on errors. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 11

[Intel-gfx] [PATCH 11/30] drm/bridge/analogix/anx6345: Don't link encoder until after connector registration

Another case of linking an encoder to a connector after the connector's been registered. The proper place to do this is before connector registration, so let's fix that. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 12 ++-- 1 file changed, 6 insertio

[Intel-gfx] [PATCH 08/30] drm/bridge/analogix/anx78xx: Setup encoder before registering connector

Since encoder mappings for connectors are exposed to userspace, we should be attaching the encoder before exposing the connector to userspace. Just a drive-by fix for an issue I noticed while fixing up usages of drm_dp_aux_init()/drm_dp_aux_register() across the tree. Signed-off-by: Lyude Paul --

[Intel-gfx] [PATCH 10/30] drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call

Another driver I found that seems to forget to unregister it's DP AUX device. Let's fix this by adding anx6345_bridge_detach(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/bridge/analog

[Intel-gfx] [PATCH 09/30] drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach()

Just another issue I noticed while correcting usages of drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the steps in anx78xx_bridge_attach() fail, we end up leaking resources. So, let's fix that (and fix leaking a DP AUX adapter in the process) by unrolling on errors. Signed-off

[Intel-gfx] [PATCH 06/30] drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach

Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's move the AUX adapter registration to the first point where we know which DRM device we'll be working with - when the drm_bridge is attached. Likewise, we unregister the AUX adapter on bridge detachment by adding a ti_sn_bridge_

[Intel-gfx] [PATCH 07/30] drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call

Surprisingly, this bridge actually registers it's AUX adapter at the correct time already. Nice job! However, it does forget to actually unregister the AUX adapter, so let's add a bridge function to handle that. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 6

[Intel-gfx] [PATCH 04/30] drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached

Since this is a bridge, we don't start out with a respective DRM device. Likewise this means we don't have a connector, which also means that we should be following drm_dp_aux_register()'s documentation advice and not call drm_dp_aux_register() until we have a matching connector. Instead, call drm_

[Intel-gfx] [PATCH 03/30] drm/tegra: Don't register DP AUX channels before connectors

As pointed out by the documentation for drm_dp_aux_register(), drm_dp_aux_init() should be used in situations where the AUX channel for a display driver can potentially be registered before it's respective DRM driver. This is the case with Tegra, since the DP aux channel exists as a platform device

[Intel-gfx] [PATCH 05/30] drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace

Just adds some missing calls to drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the bridge. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/br

[Intel-gfx] [PATCH 02/30] drm/dp: Fixup kernel docs for struct drm_dp_aux

* Make sure that struct members are referred to using @, otherwise they won't be formatted as such * Make sure to refer to other struct types using & so they link back to each struct's definition * Make sure to precede constant values with % so they're formatted correctly Signed-off-by: Lyud

[Intel-gfx] [PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux

Since we're about to be adding some more fields and update this documentation, let's rewrap it to the new column limit of 100 beforehand. No actual doc or functional changes are made here. Signed-off-by: Lyude Paul --- include/drm/drm_dp_helper.h | 42 - 1 fil

[Intel-gfx] [PATCH 00/30] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

Since it's been asked quite a few times on some of the various DP related patch series I've submitted to use the new DRM printk helpers, and it technically wasn't really trivial to do this before due to the lack of a consistent way to find a drm_device for an AUX channel, this patch series aims to

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Read planes watermarks during initial state readout

== Series Details == Series: drm/i915/display: Read planes watermarks during initial state readout URL : https://patchwork.freedesktop.org/series/87241/ State : success == Summary == CI Bug Log - changes from CI_DRM_9790_full -> Patchwork_19704_full

Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers

On Thu, 2021-02-18 at 17:31 +0200, Ville Syrjälä wrote: > On Thu, Feb 18, 2021 at 10:35:05AM +0200, Jani Nikula wrote: > > On Fri, 12 Feb 2021, Lyude Paul wrote: > > > I think it wouldn't be a bad idea to just address this with a followup > > > series > > > instead and use the old DRM_DEBUG_* macr

Re: [Intel-gfx] [PATCH] drm/i915/display: Read planes watermarks during initial state readout

On Fri, Feb 19, 2021 at 08:16:25PM +, Souza, Jose wrote: > On Fri, 2021-02-19 at 21:46 +0200, Ville Syrjälä wrote: > > On Fri, Feb 19, 2021 at 11:16:23AM -0800, José Roberto de Souza wrote: > > > Without this readout all plane watermarks will be kept at zero in the > > > initial state readount

Re: [Intel-gfx] [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays

On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote: > On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote: > > So one thing that has been on my mind for a while: I'd really like > > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb > > to swiotlb

Re: [Intel-gfx] [PATCH] drm/i915/display: Read planes watermarks during initial state readout

On Fri, 2021-02-19 at 21:46 +0200, Ville Syrjälä wrote: > On Fri, Feb 19, 2021 at 11:16:23AM -0800, José Roberto de Souza wrote: > > Without this readout all plane watermarks will be kept at zero in the > > initial state readount causing two problems. > > > > All active planes will always have the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Read planes watermarks during initial state readout

== Series Details == Series: drm/i915/display: Read planes watermarks during initial state readout URL : https://patchwork.freedesktop.org/series/87241/ State : success == Summary == CI Bug Log - changes from CI_DRM_9790 -> Patchwork_19704

Re: [Intel-gfx] [PATCH] drm/i915/display: Read planes watermarks during initial state readout

On Fri, Feb 19, 2021 at 11:16:23AM -0800, José Roberto de Souza wrote: > Without this readout all plane watermarks will be kept at zero in the > initial state readount causing two problems. > > All active planes will always have their watermarks programmed > again, even if what firmware programmed

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches

On Thu, 2021-02-18 at 20:21 +0200, Ville Syrjälä wrote: > On Thu, Feb 18, 2021 at 05:25:54PM +, Souza, Jose wrote: > > On Thu, 2021-02-18 at 00:14 +0200, Ville Syrjälä wrote: > > > On Wed, Feb 17, 2021 at 05:24:03PM +, Souza, Jose wrote: > > > > On Fri, 2021-02-12 at 23:13 +0200, Ville Syrj

[Intel-gfx] [PATCH] drm/i915/display: Read planes watermarks during initial state readout

Without this readout all plane watermarks will be kept at zero in the initial state readount causing two problems. All active planes will always have their watermarks programmed again, even if what firmware programmed matches with the sanitized state during driver takeover. State mismatch errors

Re: [Intel-gfx] i915 dma faults on Xen

On Wed, Oct 21, 2020 at 9:59 AM Jan Beulich wrote: > > On 21.10.2020 15:36, Jason Andryuk wrote: > > On Wed, Oct 21, 2020 at 8:53 AM Jan Beulich wrote: > >> > >> On 21.10.2020 14:45, Jason Andryuk wrote: > >>> On Wed, Oct 21, 2020 at 5:58 AM Roger Pau Monné > >>> wrote: > Hm, it's hard to

Re: [Intel-gfx] [PATCH v2] drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()

On Fri, Feb 19, 2021 at 04:08:09PM +0100, Daniel Vetter wrote: > On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > drm_vblank_restore() exists because certain power saving states > > can clobber the hardware frame counter. The way it does this is > > b

Re: [Intel-gfx] [PATCH] drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK

On Fri, Feb 19, 2021 at 02:25:39PM +0800, Gary C Wang wrote: > HDMI PHY is not available to use when its HDMI disaply plug-in, and power-off > then power-on as soon as getting a hotplug. In above cases where there's a > HDMI > connector physically connected but it can't be used by GLK with 4K pipe

Re: [Intel-gfx] [PATCH v2] drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()

On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_vblank_restore() exists because certain power saving states > can clobber the hardware frame counter. The way it does this is > by guesstimating how many frames were missed purely based on > the differenc

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK

== Series Details == Series: drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK URL : https://patchwork.freedesktop.org/series/87206/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9788_full -> Patchwork_19703_full ==