[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

[Intel-gfx] [PATCH 12/12] drm/i915: Implement transcoder LRR for TGL+

From: Ville Syrjälä Implement low refresh rate (LRR) where we change the vblank length by hand as requested, but otherwise keep the timing generator running in non-VRR mode (ie. fixed refresh rate). The panel itself must support VRR for this to work, and only TGL+ has the double buffred

[Intel-gfx] [PATCH 11/12] drm/i915: Assert that VRR is off during vblank evasion if necessary

From: Ville Syrjälä Whenever we change the actual transcoder timings (clock via seamless M/N, full modeset, (or soon) vtotal via LRR) we want the timing generator to be in non-VRR during the commit. Warn if we forgot to turn VRR off prior to vblank evasion. Cc: Manasi Navare Signed-off-by:

[Intel-gfx] [PATCH 10/12] drm/i915: Update VRR parameters in fastset

From: Ville Syrjälä We should be able to change any of the VRR parameters during fastsets as long as we toggle VRR off at the start and then back on at the end. The transcoder will be running in non-VRR mode during the transition. Co-developed-by: Manasi Navare Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH 08/12] drm/i915: Validate that the timings are within the VRR range

From: Ville Syrjälä Let's assume there are some crazy displays where the high end of the VRR range ends up being lower than the refresh rate as determined by the actual timings. In that case when we toggle VRR on/off we would step outside the VRR range when toggling VRR on/off. Let's just make

[Intel-gfx] [PATCH 09/12] drm/i915: Disable VRR during seamless M/N changes

From: Ville Syrjälä Make life less confusing by making sure VRR is disabled whenever we do any drastic changes to the display timings, such as seamless M/N changes. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 6 -- 1 file changed, 4

[Intel-gfx] [PATCH 07/12] drm/i915: Relocate is_in_vrr_range()

From: Ville Syrjälä Move is_in_vrr_range() into intel_vrr.c in anticipation of more users, and rename it accordingly. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_panel.c | 17 - drivers/gpu/drm/i915/display/intel_vrr.c | 9

[Intel-gfx] [PATCH 04/12] drm/i915: Enable VRR later during fastsets

From: Ville Syrjälä In order to reconcile seamless M/N updates with VRR we'll need to defer the fastset VRR enable to happen after the seamless M/N update (which happens during the vblank evade critical section). So just push the VRR enable to be the last thing during the update. This will also

[Intel-gfx] [PATCH 05/12] drm/i915: Adjust seamless_m_n flag behaviour

From: Ville Syrjälä Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the flag will only be set if we need to do the seamless M/N update, and in all other cases the flag is cleared. Also rename the flag to update_m_n to make it more clear it's similar to update_pipe. I

[Intel-gfx] [PATCH 06/12] drm/i915: Optimize out redundant M/N updates

From: Ville Syrjälä Don't perform a seamless M/N update if the values aren't actually changing. This avoids doing extra shenanigans during vblank evasion needlessly. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 4 +++- 1 file changed, 3

[Intel-gfx] [PATCH 03/12] drm/i915: Extract intel_crtc_vblank_evade_scanlines()

From: Ville Syrjälä Pull the vblank evasion scanline calculations into their own helper to declutter intel_pipe_update_start() a bit. Reviewed-by: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.c | 53 +-- 1 file changed, 31

[Intel-gfx] [PATCH 02/12] drm/i915: Change intel_pipe_update_{start, end}() calling convention

From: Ville Syrjälä We'll need to also look at the old crtc state in intel_pipe_update_start() so change the calling convention to just plumb in the full atomic state instead. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.c| 18

[Intel-gfx] [PATCH 01/12] drm/i915: Move psr unlock out from the pipe update critical section

From: Ville Syrjälä Do the PSR unlock after the vblank evade critcal section is fully over, not before. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 00/12] drm/i915: VRR, LRR, and M/N stuff

From: Ville Syrjälä Attempt to make VRR, LRR, and M/N updates coexist nicely, allowing fastsets whenever feasible. Lightly smoke tested on my adl. Cc: Manasi Navare Ville Syrjälä (12): drm/i915: Move psr unlock out

[Intel-gfx] [PATCH] 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

[Intel-gfx] [PATCH v2 03/12] drm/i915: Call the DDC bus i2c adapter "ddc"

From: Ville Syrjälä Rename the various names we've used for the DDC bus i2c adapter ("i2c", "adapter", etc.) to just "ddc". This differentiates it from the various other i2c busses we might have (DSI panel stuff, DVO control bus, etc.). v2: Don't add a bogus drm_get_edid() call (Jani)

[Intel-gfx] [PATCH 11/12] drm/i915/hdmi: Remove old i2c symlink

From: Ville Syrjälä Remove the i915 specific i2c-N symlink from HDMI connectors. This was added to sort of mirror the DP connectors that alreayd had their aux ch based i2c adapter sitting beneath them in the sysfs hierarchy. But now that we have the standard "ddc" symlink approach provided by

[Intel-gfx] [PATCH 12/12] drm/i915/sdvo: Constify mapping structs

From: Ville Syrjälä We aren't intending to mutate the SDVO device mapping structs, so make them const. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c

[Intel-gfx] [PATCH 10/12] drm/i915/hdmi: Nuke hdmi->ddc_bus

From: Ville Syrjälä Remove the mostly redundant hdmi->ddc_bus. The only thing that needs it anymore is get_encoder_by_ddc_bus(), but that can be replaced with a slight detour through attached_connector+intel_gmbus_get_adapter(). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 09/12] drm/i915/hdmi: Use connector->ddc everwhere

From: Ville Syrjälä We already populate connector->ddc for HDMI ports, but so far we've not taken full advantage of it. Do that by eliminating a bunch of intel_gmbus_get_adapter() lookups. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-

[Intel-gfx] [PATCH 07/12] drm/i915/dp: Populate connector->ddc

From: Ville Syrjälä Populate connector->ddc, and thus create the "ddc" symlink in sysfs for analog DP SST connectors. Let's also reorder intel_dp_aux_init() vs. drm_connector_init_with_ddc() a bit to make sure the i2c aux ch is at least somewhat populated before we pass it on, though

[Intel-gfx] [PATCH 06/12] drm/i915/dvo: Populate connector->ddc

From: Ville Syrjälä Populate connector->ddc, and thus create the "ddc" symlink in sysfs for DVO connectors. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dvo.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git

[Intel-gfx] [PATCH 08/12] drm/i915/mst: Populate connector->ddc

From: Ville Syrjälä Populate connector->ddc, and thus create the "ddc" symlink in sysfs for DP MST connectors. TODO: test that this actually works References: https://gitlab.freedesktop.org/drm/intel/-/issues/3605 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_mst.c |

[Intel-gfx] [PATCH 05/12] drm/i915/crt: Populate connector->ddc

From: Ville Syrjälä Populate connector->ddc, and thus create the "ddc" symlink in sysfs for analog VGA connectors. As a bonus we can replace a bunch of intel_gmbus_get_adapter() lookups with just the connector->ddc pointer. Sadly one extra lookup still remains due to the g4x DVI-I shenanigans.

[Intel-gfx] [PATCH 04/12] drm/i915/lvds: Populate connector->ddc

From: Ville Syrjälä Populate connector->ddc, and thus create the "ddc" symlink in sysfs for the LVDS port. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_lvds.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git

[Intel-gfx] [PATCH 03/12] drm/i915: Call the DDC bus i2c adapter "ddc"

From: Ville Syrjälä Rename the various names we've used for the DDC bus i2c adapter ("i2c", "adapter", etc.) to just "ddc". This differentiates it from the various other i2c busses we might have (DSI panel stuff, DVO control bus, etc.). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 01/12] drm: Reorder drm_sysfs_connector_remove() vs. drm_debugfs_connector_remove()

From: Ville Syrjälä Use the standard onion peeling approach and call drm_debugfs_connector_remove() and drm_sysfs_connector_remove() in the reverse order in drm_connector_unregister() than what we called their add counterpartse in drm_connector_register(). The error unwiding in

[Intel-gfx] [PATCH 02/12] drm/sysfs: Register "ddc" symlink later

From: Ville Syrjälä Currently drm_sysfs_connector_add() attempts to register the "ddc" symlink (based one connector->ddc) before the driver's .early_register() hook has been called. That is too early for i915 which only fully registers the aux ch and associated i2c bus from said hook (to prevent

[Intel-gfx] [PATCH 00/12] drm/i915: Populate connector->ddc always

From: Ville Syrjälä Populate connector->ddc for all output types that don't already do so, and clean up a bunch of code as a result of having the ddc i2c adapter in easy reach. And this also provides the sysfs "ddc" symlink. There are potentially a few oddball (mostly DVI-I) cases where the

[Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour

From: Ville Syrjälä Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the flag will only be set if we need to do the seamless M/N update, and in all other cases the flag is cleared. Also rename the flag to update_m_n to make it more clear it's similar to update_pipe. I

[Intel-gfx] [PATCH 6/6] drm/i915: Optimize out redundant M/N updates

From: Ville Syrjälä Don't perform a seamless M/N update if the values aren't actually changing. This avoids doing extra shenanigans during vblank evasion needlessly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 4 +++- 1 file changed, 3 insertions(+), 1

[Intel-gfx] [PATCH 0/6] drm/i915: VRR and M/N stuff

From: Ville Syrjälä Some prep work towards reconciling VRR and M/N. I think after these we coukd try VRR fastsets that alter the state of the VRR registers, assuming we toggle VRR off and on around the update. Cc: Manasi Navare Ville Syrjälä (6): drm/i915: Move psr unlock out from the pipe

[Intel-gfx] [PATCH 4/6] drm/i915: Enable VRR later during fastsets

From: Ville Syrjälä In order to reconcile seamless M/N updates with VRR we'll need to defer the fastset VRR enable to happen after the seamless M/N update (which happens during the vblank evade critical section). So just push the VRR enable to be the last thing during the update. This will also

[Intel-gfx] [PATCH 3/6] drm/i915: Extract intel_crtc_vblank_evade_scanlines()

From: Ville Syrjälä Pull the vblank evasion scanline calculations into their own helper to declutter intel_pipe_update_start() a bit. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.c | 53 +-- 1 file changed, 31 insertions(+),

[Intel-gfx] [PATCH 2/6] drm/i915: Change intel_pipe_update_{start, end}() calling convention

From: Ville Syrjälä We'll need to also look at the old crtc state in intel_pipe_update_start() so change the calling convention to just plumb in the full atomic state instead. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.c| 18

[Intel-gfx] [PATCH 1/6] drm/i915: Move psr unlock out from the pipe update critical section

From: Ville Syrjälä Do the PSR unlock after the vblank evade critcal section is fully over, not before. Cc: Manasi Navare Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH v2 3/6] drm/i915/sdvo: Nuke the duplicate sdvo->port

From: Ville Syrjälä We already have encoder->port so get rid of the duplicate sdvo->port. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git

[Intel-gfx] [PATCH v2 2/6] drm/i915/sdvo: Initialize the encoder earlier

From: Ville Syrjälä Call drm_encoder_init() earlier so that we don't have to keep passing the i915/dev_priv around separately. v2: Reorder drm_encoder_cleanup() in the error path (Jani) Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 37

[Intel-gfx] [PATCH v2 6/6] drm/i915/sdvo: Print out the i2c pin and slave address

From: Ville Syrjälä To reduce the guesswork a bit let's print out the SDVO device i2c bus and slave address during init. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 4 1 file changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH v2 5/6] drm/i915/sdvo: Rework DDC bus handling

From: Ville Syrjälä Each SDVO device can have up to three sets of DDC pins. Currently we just register a single i2c_adapter for the entire SDVO device and semi-randomly pick the "correct" set of DDC pins during intel_sdvo_tmds_sink_detect(). This doesn't make any real sense especially if we have

[Intel-gfx] [PATCH v2 4/6] drm/i915/sdvo: Get rid of the per-connector i2c symlink

From: Ville Syrjälä We should switch over to the standard "ddc" per-connector symlink instead of rolling our own thing. The i2c specific symlink is also in the way of reworking the SDVO DDC handling (which is a mess atm) so get rid of it. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 1/6] drm/i915/sdvo: Nuke attached_output tracking

From: Ville Syrjälä Instead of operating on the output the user specified (via the connector) the current code tends to operate on whichever outputs it has detected as attached. That is not how the kms uapi is supposed to work. So simply get rid of attached_outputs and instead directly operate

[Intel-gfx] [PATCH v2 0/6] drm/i915/sdvo: DDC rework and fixes

From: Ville Syrjälä I have plans to switch the whole driver over to using drm_connector_init_with_ddc(), and thus populate the sysfs "ddc" consistently. The biggest hurdle is the SDVO DDC handling, so start by cleaning that up. I also found some other issues with the SDVO code so some

[Intel-gfx] [PATCH] dma-buf/dma-resv: Stop leaking on krealloc() failure

From: Ville Syrjälä Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some

[Intel-gfx] [PATCH 13/13] drm/i915/sdvo: Print out the i2c pin and slave address

From: Ville Syrjälä To reduce the guesswork a bit let's print out the SDVO device i2c bus and slave address during init. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c

[Intel-gfx] [PATCH 12/13] drm/i915/sdvo: Rework DDC bus handling

From: Ville Syrjälä Each SDVO device can have up to three sets of DDC pins. Currently we just register a single i2c_adapter for the entire SDVO device and semi-randomly pick the "correct" set of DDC pins during intel_sdvo_tmds_sink_detect(). This doesn't make any real sense especially if we have

[Intel-gfx] [PATCH 11/13] drm/i915/sdvo: Get rid of the per-connector i2c symlink

From: Ville Syrjälä We should switch over to the standard "ddc" per-connector symlink instead of rolling our own thing. The i2c specific symlink is also in the way of reworking the SDVO DDC handling (which is a mess atm) so get rid of it. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 10/13] drm/i915/sdvo: Nuke the duplicate sdvo->port

From: Ville Syrjälä We already have encoder->port so get rid of the duplicate sdvo->port. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git

[Intel-gfx] [PATCH 09/13] drm/i915/sdvo: Initialize the encoder ealier

From: Ville Syrjälä Call drm_encoder_init() earlier so that we don't have to keep passing the i915/dev_priv around separately. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 35 +++ 1 file changed, 17 insertions(+), 18 deletions(-) diff --git

[Intel-gfx] [PATCH 08/13] drm/i915/sdvo: Nuke attached_output tracking

From: Ville Syrjälä Instead of operating on the output the user specified (via the connector) the current code tends to operate on whichever outputs it has detected as attached. That is not how the kms uapi is supposed to work. So simply get rid of attached_outputs and instead directly operate

[Intel-gfx] [PATCH 07/13] drm/i915/sdvo: Fail gracefully if the TV dotclock is out of range

From: Ville Syrjälä Instead of warning and continuing with bogus state when the requested dotclock isn't acceptable just print some debug spew and fail gracefully. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 18 +- 1 file changed, 13

[Intel-gfx] [PATCH 06/13] drm/i915/sdvo: Pick the TV dotclock from adjusted_mode

From: Ville Syrjälä port_clock is what the encoder/dpll code is supposed to calculate, it is not the input clock. Use the dotclock as the target we're trying to achieve instead. TODO: the SDVO TV clocking is a mess atm and needs further work Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 05/13] drm/i915: Fully populate crtc_state->dpll

From: Ville Syrjälä Call *_calc_dpll_params() even in cases where the encoder has computed the DPLL params for us. The SDVO TV output code doesn't populate crtc_state->dpll.dot leading to the dotclock getting calculated as zero, and that leads to all kinds of real problems. The g4x DP code also

[Intel-gfx] [PATCH 04/13] drm/i915: Don't warn about zero N/P in *_calc_dpll_params()

From: Ville Syrjälä Allow *_calc_dpll_params() to be called even if the N/P dividers are zero without warning. We'll want to call these to make sure the derived values are fully computed, but not all users (VLV DSI in particular) don't even enable the DPLL and thus the dividers will be left at

[Intel-gfx] [PATCH 03/13] drm/i915/sdvo: s/sdvo_inputs_mask/sdvo_num_inputs/

From: Ville Syrjälä The SDVO inputs are reportes a simple number, not a bitmask. Adjust the code to match reality. Note that we don't actually support dual input SDVO devices, and we just always use the first input. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c

[Intel-gfx] [PATCH 02/13] drm/i915/sdvo: Protect macro args

From: Ville Syrjälä Put parens around macro argument evaluation for safety. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c

[Intel-gfx] [PATCH 01/13] drm/i915/sdvo: Issue SetTargetOutput prior ot GetAttachedDisplays

From: Ville Syrjälä I have at least one SDVO device (some Lenovo DVI-I ADD2 card, based on Conexant CX25904) where GetAttachedDisplays returns success but fails to report any attached displays unless wet precede the command with a SetTargetOutput. Make it so. I wasn't able to spot anything in

[Intel-gfx] [PATCH 00/13] drm/i915/sdvo: DDC rework and fixes

From: Ville Syrjälä I have plans to switch the whole driver over to using drm_connector_init_with_ddc(), and thus populate the sysfs "ddc" consistently. The biggest hurdle is the SDVO DDC handling, so start by cleaning that up. I also found some other issues with the SDVO code so some

[Intel-gfx] [PATCH v3 5/6] drm/i915/bios: Extract intel_bios_encoder_port()

From: Ville Syrjälä We'll have a few places where we need to do the full (incl. ICL+ DSI) DVO port->port conversion, so extract the code for that into a helper. Suggested-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bios.c | 18 ++ 1

[Intel-gfx] [PATCH v3 4/6] drm/i915: Remove AUX CH sanitation

From: Ville Syrjälä Stop with the VBT AUX CH sanitation, and instead just check that the appropriate AUX CH is still available when initializing a DP/TC port. The reason being that we want to start initializing ports in VBT order to deal with VBTs that declare child devices with seemingly

[Intel-gfx] [PATCH v3 3/6] drm/i915: Remove DDC pin sanitation

From: Ville Syrjälä Stop with the VBT DDC pin sanitation, and instead just check that the appropriate DDC pin is still available when initializing a HDMI connector. The reason being that we want to start initializing ports in VBT order to deal with VBTs that declare child devices with seemingly

[Intel-gfx] [PATCH v3 2/6] drm/i915: Only populate aux_ch if really needed

From: Ville Syrjälä Mixing VBT based AUX CH with platform defaults seems like a recipe for conflicts. Let's only populate AUX CH if we absolutely need it, that is only if we are dealing with a DP output or a TC port (which need it due to some power well shenanigans). TODO: double check that

[Intel-gfx] [PATCH v3 6/6] drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child device

From: Ville Syrjälä Try to deal with duplicate child devices for the same DDI port by attempting to initialize them in VBT defined order The first on to succeed for a specific DDI port will be the one we use. We'll also get rid of i915->display.vbt.ports[] here as any conflicts will now be

[Intel-gfx] [PATCH v3 0/6] drm/i915: Init DDI ports in VBT order

From: Ville Syrjälä The remaining parts of the big VBT based DDI port initialization series. The main goal being to get the HDMI port working on many ADL-P machines where the VBT declares both eDP and HDMI for the same DDI port (B). v3: Pimped commit messages Add intel_bios_encoder_port()

[Intel-gfx] [PATCH v3 1/6] drm/i915: Initialize dig_port->aux_ch to NONE to be sure

From: Ville Syrjälä Make sure dig_port->aux_ch is trustworthy by initializing it to NONE (-1) at the start. The encoder init will later fill in the actual value, if appropriate. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/g4x_dp.c| 2 ++

[Intel-gfx] [PATCH v2 5/5] drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child device

From: Ville Syrjälä Try to deal with duplicate child devices for the same DDI port by attempting to initialize them in VBT defined order The first on to succeed for a specific DDI port will be the one we use. We'll also get rid of i915->display.vbt.ports[] here as any conflicts will now be

[Intel-gfx] [PATCH v2 4/5] drm/i915: Remove AUX CH sanitation

From: Ville Syrjälä Stop with the VBT AUX CH sanitation, and instead just check that the appropriate AUX CH is still available when initializing a DP/TC port. Note that the old way of sanitizing gave priority to the last port declared in the VBT, but now we sort of do the opposite by favoring

[Intel-gfx] [PATCH v2 2/5] drm/i915: Only populate aux_ch is really needed

From: Ville Syrjälä Mixing VBT based AUX CH with platform defaults seems like a recipe for conflicts. Let's only populate AUX CH if we absolutely need it, that is only if we are dealing with a DP output or a TC port (which need it due to some power well shenanigans). TODO: double check that

[Intel-gfx] [PATCH v2 3/5] drm/i915: Remove DDC pin sanitation

From: Ville Syrjälä Stop with the VBT DDC pin sanitation, and instead just check that the appropriate DDC pin is still available when initializing a HDMI connector. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bios.c | 69 --

[Intel-gfx] [PATCH v2 1/5] drm/i915: Initialize dig_port->aux_ch to NONE to be sure

From: Ville Syrjälä Make sure dig_port->aux_ch is trustworthy by initializing it to NONE (-1) at the start. The encoder init will later fill in the actual value, if appropriate. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/g4x_dp.c| 2 ++

[Intel-gfx] [PATCH v2 0/5] drm/i915: Init DDI ports in VBT order

From: Ville Syrjälä The remaining parts of the big VBT based DDI port initialization series. The main goal being to get the HDMI port working on many ADL-P machines where the VBT declares both eDP and HDMI for the same DDI port (B). Ville Syrjälä (5): drm/i915: Initialize dig_port->aux_ch to

[Intel-gfx] [PATCH v3 7/7] drm/i915: Convert HSW/BDW to use port_mask for DDI probe

From: Ville Syrjälä Make HSW/BDW use port_mask for output probing as well. To achieve that the strap checks are moved into intel_ddi_init() itself. Or should we move them to the runtime port_mask init instead? Maybe not since the hardware is still there, just not connected to anything. v2:

[Intel-gfx] [PATCH v3 6/7] drm/i915: Init DDI outputs based on port_mask on skl+

From: Ville Syrjälä Instead of listing every platform's possible DDI outputs in intel_setup_outputs() just loop over the new port_mask to achieve the same thing. HSW/BDW were left as is since they still look at the straps as well. DSI is still a mess. For now just check for the relevant

[Intel-gfx] [PATCH v3 5/7] drm/i915: Beef up SDVO/HDMI port checks

From: Ville Syrjälä The SDVO code already warns when the port in question doesn't actually support SDVO. Let's make that also bail the encoder registration like the generic assert_port_valid() we added. And add a similar thing for g4x HDMI, mainly because on g4x itsefl port D only supports DP

[Intel-gfx] [PATCH v3 4/7] drm/i915: Assert that the port being initialized is valid

From: Ville Syrjälä Sprinkle some asserts to catch any mishaps in the port_mask vs. output init. For DDI/DP/HDMI/SDVO I decided that we want to bail out for an invalid port since those are the encoder types where we might want consider driving the whole thing from the VBT child device list, and

[Intel-gfx] [PATCH v3 3/7] drm/i915: Assert that device info bitmasks have enough bits

From: Ville Syrjälä Sprinkle in some BUILD_BUG_ON()s to make sure some of the bitmasks used in the device info have enough bits. Do we have a better place for this sort of stuff? v2: Relocate to the new place Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH v3 2/7] drm/i915: Introduce device info port_mask

From: Ville Syrjälä Declare the available DVO/SDVO/HDMI/DP/DDI ports in the device info. The other outputs (LVDS/TV/DSI/VGA) are left out since for most of them we don't consider them as "ports". DSI we should probably perhaps include somehow in the device info. Just not sure how. Or we just

[Intel-gfx] [PATCH v3 1/7] drm/i915: Remove bogus DDI-F from hsw/bdw output init

From: Ville Syrjälä HSW/BDW don't have DDI-F so don't go looking for one. Seems to have been accidentally left behind when the skl+ stuff got split out in commit 097d9e902068 ("drm/i915/display: remove strap checks from gen 9"). Reviewed-by: Lucas De Marchi Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH v3 0/7] drm/i915: Init DDI ports based on port_mask

From: Ville Syrjälä Introduce port_mask into the device info and utilize it it initalize DDI ports instead of hand rolling each intel_ddi_init() call per platform+port. This is an intermediate step towards initializing DDI/DP/HDMI/DSI ports purely based on VBT information. v2: rebased due to

[Intel-gfx] [PATCH v2 13/13] drm/i915/psr: Re-enable PSR1 on hsw/bdw

From: Ville Syrjälä All known issues fixed now, so re-enable PSR1 on hsw/bdw. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display_device.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c

[Intel-gfx] [PATCH v2 12/13] drm/i915/psr: Allow PSR with sprite enabled on hsw/bdw

From: Ville Syrjälä Can't see why we'd want the sprite blocking PSR entry. Mask it out. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 4 drivers/gpu/drm/i915/display/intel_psr.c | 4 2 files changed, 8 insertions(+) diff --git

[Intel-gfx] [PATCH v2 11/13] drm/i915/psr: Don't skip both TP1 and TP2/3 on hsw/bdw

From: Ville Syrjälä WA 0479 says: "Do not skip both TP1 and TP2/TP3". Let's just stick the minimum 100us TP2/3 time in there to avoid that. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_psr.c | 9 + 1 file changed, 9 insertions(+) diff --git

[Intel-gfx] [PATCH v2 10/13] drm/i915/psr: Do no mask display register writes on hsw/bdw

From: Ville Syrjälä hsw/bdw lack the pipe register vs. display register distinction in their PSR masking capabilities. So to keep our CURSURFLIVE tricks working we need to just unmask all display register writes on these platforms. The downside being that any display regitster (eg. even SWF

[Intel-gfx] [PATCH v2 09/13] drm/i915/psr: Implement WaPsrDPRSUnmaskVBlankInSRD:hsw

From: Ville Syrjälä Bspec asks us to unmask "vblank to registers" in the DPRS unit. Note that I was unable to observe any change in hardware behviour due to this bit on HSW. But let's do this anyway in case it matters in some cases, and the corresponding bit on BDW is abolutely critical as

[Intel-gfx] [PATCH v2 08/13] drm/i915/psr: Implement WaPsrDPAMaskVBlankInSRD:hsw

From: Ville Syrjälä Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware generate the extra vblank between link training and first frame being transmitted. This is the same thing that's controlled by TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering it's effectively

[Intel-gfx] [PATCH v2 07/13] drm/i915/psr: Restore PSR interrupt handler for HSW

From: Ville Syrjälä Add the PSR interrupt handling code back for HSW. Looks like the removal was never completed anyway since the irq setup code was lest untouched. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display_irq.c | 14 ++ 1 file changed, 14

[Intel-gfx] [PATCH v2 06/13] drm/i915/psr: HSW/BDW have no PSR2

From: Ville Syrjälä Deal with HSW/BDW in transcoder_has_psr2(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_psr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c

[Intel-gfx] [PATCH v2 05/13] drm/i915/psr: Bring back HSW/BDW PSR AUX CH registers/setup

From: Ville Syrjälä Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all of it was even removed (BDW AUX data registers were left behind). Update the code to use REG_BIT() & co. while at it. v2: Define the SRD_AUX_CTL bits in terms of DP_AUX_CTL bits (Jouni) Add a comment

[Intel-gfx] [PATCH v2 04/13] drm/i915/psr: Reintroduce HSW PSR1 registers

From: Ville Syrjälä Add back hsw'w special SRD/PSR1 registers. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_psr.c | 20 +++ drivers/gpu/drm/i915/display/intel_psr_regs.h | 4 2 files changed, 20 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH v2 03/13] drm/i915/psr: Wrap PSR1 register with functions

From: Ville Syrjälä In preparation for re-introducing HSW's different PSR1 register offeets let's just wrap all the registers into functions. Avoids having to make the register macros more complex. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_psr.c | 99

[Intel-gfx] [PATCH v2 02/13] drm/i915/psr: Fix BDW PSR AUX CH data register offsets

From: Ville Syrjälä The multiplication got replaced by an addition in some cleanup. This means we never write the correct data to some of the BDW PSR data registers and thus we fail to actually wake up the panel from PSR. Fixes: 4ab4fa103217 ("drm/i915/psr: Make PSR registers relative to

[Intel-gfx] [PATCH v2 00/13] drm/i915/psr: Restore HSW/BDW PSR1

From: Ville Syrjälä Fix all the obvious issues affecting HSW/BDW PSR1 and restore it back to life. The PC8+ vs. init_clock_gating() problem also affects some non-PSR workarounds as well. v2: Rebase (due to irq code movement mostly) Deal with review comments wrt. the AUX setup Ville

[Intel-gfx] [PATCH v2 01/13] drm/i915: Re-init clock gating on coming out of PC8+

From: Ville Syrjälä PC8+ clobbers a bunch of displays registers which need to be restored by hand or else we lost a bunch of workarounds. The important ones for us are at least CHICKEN_PAR2* and CHICKEN_PIPESL*. Curiously at least some CHICKEN_PAR1* registers are preserved by the

[Intel-gfx] [PATCH v2 13/13] drm/i915/dsi: Remove weird has_pch_encoder asserts

From: Ville Syrjälä No idea why the DSI code is feeling the need to assert that has_pch_encoder must not be set. PCH encoders aren't even a thing on any platform that has DSI. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/icl_dsi.c | 2 --

[Intel-gfx] [PATCH v2 11/13] drm/i915/dsi: Move panel reset+power off to be the last thing

From: Ville Syrjälä Follow what Windows does and do the DSI panel reset+power off after everything else. v2: s/intel_dsi_msleep/msleep/ Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/icl_dsi.c | 14 -- 1 file changed, 8 insertions(+), 6

[Intel-gfx] [PATCH v2 12/13] drm/i915/dsi: Grab the crtc from the customary place

From: Ville Syrjälä The encoder hooks already get passed the crtc state so just grab the crtc from there instead of from the connector state. This is generally what everyone else does, so no reason for icl_dsi.c to be different. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH v2 10/13] drm/i915/dsi: Respect power_off_delay on icl+

From: Ville Syrjälä icl+ DSI isn't respecting the panel power_off_delay. Remedy that. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/icl_dsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c

[Intel-gfx] [PATCH v2 09/13] drm/i915/dsi: Do DSC/scaler disable earlier on icl+

From: Ville Syrjälä Do the scaler disable in the spot where bspec has specfied it for TGL+. And also move the DSC disable to match what intel_ddi.c does. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++ 1 file changed, 3

[Intel-gfx] [PATCH v2 08/13] drm/i915/dsi: Move most things from .disable() into .post_disable() on icl+

From: Ville Syrjälä encoder->disable() is supposed to happen before the pipe/transcoder gets disabled. The icl+ DSI code screwed that up and put most things (including the transcoder disable itself) into encoder->disable(). Follow the common rules and hoist most things into the

<    3   4   5   6   7   8   9   10   11   12   >