[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Use vblank worker to unpin old legacy cursor fb safely

== Series Details == Series: series starting with [v2,1/2] drm/i915: Use vblank worker to unpin old legacy cursor fb safely URL : https://patchwork.freedesktop.org/series/123230/ State : success == Summary == CI Bug Log - changes from CI_DRM_13589 -> Patchwork_123230v1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915: Use vblank worker to unpin old legacy cursor fb safely

== Series Details == Series: series starting with [v2,1/2] drm/i915: Use vblank worker to unpin old legacy cursor fb safely URL : https://patchwork.freedesktop.org/series/123230/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't

[Intel-gfx] [PATCH v2 2/2] drm/vblank: Warn when silently cancelling vblank works

From: Ville Syrjälä Silently cancelling vblank works is a bit rude, especially if said works do any resource management (eg. free memory). WARN if we ever hit this. TODO: Maybe drm_crtc_vblank_off() should wait for any pending work to reach its target vblank before actually doing anything

[Intel-gfx] [PATCH v2 1/2] drm/i915: Use vblank worker to unpin old legacy cursor fb safely

From: Ville Syrjälä The cursor hardware only does sync updates, and thus the hardware will be scanning out from the old fb until the next start of vblank. So in order to make the legacy cursor fastpath actually safe we should not unpin the old fb until we're sure the hardware has ceased

Re: [Intel-gfx] [PATCH v2 04/22] drm/i915/dp: Update the link bpp limits for DSC mode

On Thu, Aug 24, 2023 at 11:04:59AM +0300, Imre Deak wrote: > In non-DSC mode the link bpp can be set in 2*3 bpp steps in the pipe bpp > range, while in DSC mode it can be set in 1/16 bpp steps to any value > up to the maximum pipe bpp. Update the limits accordingly in both modes > to prepare for a

Re: [Intel-gfx] [PATCH v2 03/22] drm/i915/dp: Skip computing a non-DSC link config if DSC is needed

On Thu, Aug 24, 2023 at 11:04:58AM +0300, Imre Deak wrote: > Computing the non-DSC mode link config is redundant once it's determined > that DSC will be needed, so skip computing it. In a follow-up patch this > simplifies setting the link limits which are dependent on the DSC vs. > non-DSC mode. >

Re: [Intel-gfx] [PATCH v2 01/22] drm/i915/dp: Factor out helpers to compute the link limits

On Thu, Aug 24, 2023 at 11:04:56AM +0300, Imre Deak wrote: > Factor out helpers that DP / DP_MST encoders can use to compute the link > rate/lane count and bpp limits. A follow-up patch will call these to > recalculate the limits if DSC compression is required. > > Signed-off-by: Imre Deak > ---

Re: [Intel-gfx] [PATCH v2 09/22] drm/dp_mst: Fix fractional bpp scaling in drm_dp_calc_pbn_mode()

On Thu, Aug 24, 2023 at 11:05:04AM +0300, Imre Deak wrote: > For fractional bpp values passed to the function in a .4 fixed point > format, the fractional part is currently ignored due to scaling bpp too > early. Fix this by scaling the overhead factor instead and to avoid an > overflow

Re: [Intel-gfx] [PATCH] drm/i915/dsi: let HW maintain HS-TRAIL and CLK_POST

For current VBT design, it does define the parameters ths_exit and tclk_post, which are related to the timing values, TEOT and TCLK-POST respectively. Unfortunately they are not configurable from VBT because both parameters are constants passed by VBT. To fix the timing problems, shall the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/bridge_connector: implement OOB HPD handling (rev4)

== Series Details == Series: drm/bridge_connector: implement OOB HPD handling (rev4) URL : https://patchwork.freedesktop.org/series/120395/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13589 -> Patchwork_120395v4 Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/bridge_connector: implement OOB HPD handling (rev4)

== Series Details == Series: drm/bridge_connector: implement OOB HPD handling (rev4) URL : https://patchwork.freedesktop.org/series/120395/ State : warning == Summary == Error: dim checkpatch failed a42361e2d28c drm: Add HPD state to drm_connector_oob_hotplug_event() af79a05f3d56

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/bridge_connector: implement OOB HPD handling (rev4)

== Series Details == Series: drm/bridge_connector: implement OOB HPD handling (rev4) URL : https://patchwork.freedesktop.org/series/120395/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH v7 3/3] drm/bridge_connector: implement oob_hotplug_event

Implement the oob_hotplug_event() callback. Translate it to the HPD notification sent to the HPD bridge in the chain. Reviewed-by: Janne Grunau Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/drm_bridge_connector.c | 31 +++--- 1 file changed, 28 insertions(+), 3

[Intel-gfx] [PATCH v7 2/3] drm/bridge_connector: stop filtering events in drm_bridge_connector_hpd_cb()

In some cases the bridge drivers would like to receive hotplug events even in the case new status is equal to the old status. In the DP case this is used to deliver "attention" messages to the DP host. Stop filtering the events in the drm_bridge_connector_hpd_cb() and let drivers decide whether

[Intel-gfx] [PATCH v7 1/3] drm: Add HPD state to drm_connector_oob_hotplug_event()

From: Bjorn Andersson In some implementations, such as the Qualcomm platforms, the display driver has no way to query the current HPD state and as such it's impossible to distinguish between disconnect and attention events. Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD

[Intel-gfx] [PATCH v7 0/3] drm/bridge_connector: implement OOB HPD handling

Note, numbering for this series starts from v5, since there were several revisions for this patchset under a different series title ([1]). USB altmodes code would send OOB notifications to the drm_connector specified in the device tree. However as the MSM DP driver uses drm_bridge_connector,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm_dbg: add trailing newlines where missing (rev2)

== Series Details == Series: drm_dbg: add trailing newlines where missing (rev2) URL : https://patchwork.freedesktop.org/series/121583/ State : success == Summary == CI Bug Log - changes from CI_DRM_13589_full -> Patchwork_121583v2_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm_dbg: add trailing newlines where missing (rev2)

== Series Details == Series: drm_dbg: add trailing newlines where missing (rev2) URL : https://patchwork.freedesktop.org/series/121583/ State : success == Summary == CI Bug Log - changes from CI_DRM_13589 -> Patchwork_121583v2 Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm_dbg: add trailing newlines where missing (rev2)

== Series Details == Series: drm_dbg: add trailing newlines where missing (rev2) URL : https://patchwork.freedesktop.org/series/121583/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm_dbg: add trailing newlines where missing (rev2)

== Series Details == Series: drm_dbg: add trailing newlines where missing (rev2) URL : https://patchwork.freedesktop.org/series/121583/ State : warning == Summary == Error: dim checkpatch failed 4c66f4d11632 drm_dbg: add trailing newlines to msgs 7cd8bc083a40 drm_dbg: add trailing newlines to

[Intel-gfx] [PATCH v2 5/6] drm_dbg: add trailing newlines to msgs

By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the remainders, in

[Intel-gfx] [PATCH v2 3/6] drm_dbg: add trailing newlines to msgs

By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the remainders, in

[Intel-gfx] [PATCH v2 2/6] drm_dbg: add trailing newlines to msgs

By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the remainders, in

[Intel-gfx] [PATCH v2 6/6] drm: use correct ccflags-y syntax

Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE, which broke builds with: CONFIG_DRM_USE_DYNAMIC_DEBUG=Y CONFIG_DYNAMIC_DEBUG_CORE=Y, but CONFIG_DYNAMIC_DEBUG=N Also add subdir-ccflags so that all drivers pick up the addition. Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in

[Intel-gfx] [PATCH v2 4/6] drm_dbg: add trailing newlines to msgs

By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the remainders, in

[Intel-gfx] [PATCH v2 0/6] drm_dbg: add trailing newlines where missing

By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this rule/convention: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the

[Intel-gfx] [PATCH v2 1/6] drm_dbg: add trailing newlines to msgs

By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the remainders, in