RE: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation
> -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:49 AM > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation > > Add support to enable the DP tunnel BW allocation mode. Follow-up patches will > call the required helpers added here to prepare for a modeset on a link with > DP > tunnels, the last change in the patchset actually enabling BWA. > > With BWA enabled, the driver will expose the full mode list a display > supports, > regardless of any BW limitation on a shared (Thunderbolt) link. Such BW > limits will > be checked against only during a modeset, when the driver has the full > knowledge > of each display's BW requirement. > > If the link BW changes in a way that a connector's modelist may also change, > userspace will get a hotplug notification for all the connectors sharing the > same > link (so it can adjust the mode used for a display). > > The BW limitation can change at any point, asynchronously to modesets on a > given connector, so a modeset can fail even though the atomic check for it > passed. In such scenarios userspace will get a bad link notification and in > response is supposed to retry the modeset. > > v2: > - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state(). > (Ville) > - Fix propagating the error from > intel_dp_tunnel_atomic_compute_stream_bw(). (Ville) > - Move tunnel==NULL checks from driver to DRM core helpers. (Ville) > - Simplify return flow from intel_dp_tunnel_detect(). (Ville) > - s/dp_tunnel_state/inherited_dp_tunnels (Ville) > - Simplify struct intel_dp_tunnel_inherited_state. (Ville) > - Unconstify object pointers (vs. states) where possible. (Ville) > - Init crtc_state while declaring it in check_group_state(). (Ville) > - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC. > (Ville) > - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the > BW allocation from encoder hooks up to intel_atomic_commit_tail() > later in the patchset. > - Disable BW alloc mode during system suspend. > - Allocate the required BW for all tunnels during system resume. > - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded > sequence in a follow-up patch. > - Add function documentation to all exported functions. > - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL. Changes look good to me. Reviewed-by: Uma Shankar > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/Kconfig | 14 + > drivers/gpu/drm/i915/Kconfig.debug| 1 + > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/display/intel_atomic.c | 2 + > drivers/gpu/drm/i915/display/intel_crtc.c | 25 + > drivers/gpu/drm/i915/display/intel_crtc.h | 1 + > .../gpu/drm/i915/display/intel_display_core.h | 1 + > .../drm/i915/display/intel_display_types.h| 9 + > .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 ++ > .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 +++ > 10 files changed, 1004 insertions(+) > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index > 3089029abba48..5932024f8f954 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -155,6 +155,20 @@ config DRM_I915_PXP > protected session and manage the status of the alive software session, > as well as its life cycle. > > +config DRM_I915_DP_TUNNEL > + bool "Enable DP tunnel support" > + depends on DRM_I915 > + depends on USB4 > + select DRM_DISPLAY_DP_TUNNEL > + default y > + help > + Choose this option to detect DP tunnels and enable the Bandwidth > + Allocation mode for such tunnels. This allows using the maximum > + resolution allowed by the link BW on all displays sharing the > + link BW, for instance on a Thunderbolt link. > + > + If in doubt, say "Y". > + > menu "drm/i915 Debugging" > depends on DRM_I915 > depends on EXPERT > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 5b7162076850c..bc18e2d9ea05d 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -28,6 +28,7 @@ config DRM_I915_DEBUG > select STACKDEPOT > select STACKTRACE > select DRM_DP_AUX_CHARDEV > + select DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE if > DRM_I915_DP_TUNNEL > select X86_MSR # used by igt/pm_rpm > select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) > select DRM_DEBUG_MM if DRM=y > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index
RE: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
>
> Detect DP tunnels and enable the BW allocation mode on them. Send a hotplug
> notification to userspace in response to a BW change.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_display_driver.c | 20 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--
> 2 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 4f7ba7eb03d27..87dd07e0d138d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -35,6 +35,7 @@
> #include "intel_dkl_phy.h"
> #include "intel_dmc.h"
> #include "intel_dp.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpll.h"
> #include "intel_dpll_mgr.h"
> #include "intel_fb.h"
> @@ -434,10 +435,8 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
>
> for_each_pipe(i915, pipe) {
> ret = intel_crtc_init(i915, pipe);
> - if (ret) {
> - intel_mode_config_cleanup(i915);
> - return ret;
> - }
> + if (ret)
> + goto err_mode_config;
> }
>
> intel_plane_possible_crtcs_init(i915);
> @@ -457,6 +456,10 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
> intel_vga_disable(i915);
> intel_setup_outputs(i915);
>
> + ret = intel_dp_tunnel_mgr_init(i915);
> + if (ret)
> + goto err_hdcp;
> +
> intel_display_driver_disable_user_access(i915);
>
> drm_modeset_lock_all(dev);
> @@ -475,6 +478,13 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
> ilk_wm_sanitize(i915);
>
> return 0;
> +
> +err_hdcp:
> + intel_hdcp_component_fini(i915);
> +err_mode_config:
> + intel_mode_config_cleanup(i915);
> +
> + return ret;
> }
>
> /* part #3: call after gem init */
> @@ -599,6 +609,8 @@ void intel_display_driver_remove_noirq(struct
> drm_i915_private *i915)
>
> intel_mode_config_cleanup(i915);
>
> + intel_dp_tunnel_mgr_cleanup(i915);
> +
> intel_overlay_cleanup(i915);
>
> intel_gmbus_teardown(i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f7f8bd5742ad4..789b5fa074fd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5726,6 +5726,7 @@ intel_dp_detect(struct drm_connector *connector,
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = _port->base;
> enum drm_connector_status status;
> + int ret;
>
> drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name); @@ -5761,9 +5762,18
> @@ intel_dp_detect(struct drm_connector *connector,
> intel_dp->is_mst);
> }
>
> + intel_dp_tunnel_disconnect(intel_dp);
> +
> goto out;
> }
>
> + ret = intel_dp_tunnel_detect(intel_dp, ctx);
> + if (ret == -EDEADLK)
> + return ret;
> +
> + if (ret == 1)
> + intel_connector->base.epoch_counter++;
> +
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> intel_dp_configure_mst(intel_dp);
> @@ -5794,8 +5804,6 @@ intel_dp_detect(struct drm_connector *connector,
>* with an IRQ_HPD, so force a link status check.
>*/
> if (!intel_dp_is_edp(intel_dp)) {
> - int ret;
> -
> ret = intel_dp_retrain_link(encoder, ctx);
> if (ret)
> return ret;
> @@ -5935,6 +5943,8 @@ void intel_dp_encoder_flush_work(struct
> drm_encoder *encoder)
>
> intel_dp_mst_encoder_cleanup(dig_port);
>
> + intel_dp_tunnel_destroy(intel_dp);
> +
> intel_pps_vdd_off_sync(intel_dp);
>
> /*
> --
> 2.39.2
RE: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
>
> The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
> depends on the GFX driver reading out the sink's DPRX capabilities in
> response to
> a long HPD pulse. Since in i915 this read-out can be blocked by another
> connector's/encoder's hotplug event handling (which is serialized by
> drm_mode_config::connection_mutex), do a dummy DPRX read-out in the
> encoder's HPD pulse handler (which is not blocked by other encoders).
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 35ef17439038a..f7f8bd5742ad4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6162,6 +6162,7 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
> bool long_hpd) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_dp *intel_dp = _port->dp;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
>
> if (dig_port->base.type == INTEL_OUTPUT_EDP &&
> (long_hpd || !intel_pps_have_panel_power_or_vdd(intel_dp))) { @@ -
> 6184,6 +6185,17 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
> bool long_hpd)
> dig_port->base.base.name,
> long_hpd ? "long" : "short");
>
> + /*
> + * TBT DP tunnels require the GFX driver to read out the DPRX caps in
> + * response to long HPD pulses. The DP hotplug handler does that,
> + * however the hotplug handler may be blocked by another
> + * connector's/encoder's hotplug handler. Since the TBT CM may not
> + * complete the DP tunnel BW request for the latter connector/encoder
> + * waiting for this encoder's DPRX read, perform a dummy read here.
> + */
> + if (long_hpd)
> + intel_dp_read_dprx_caps(intel_dp, dpcd);
> +
> if (long_hpd) {
> intel_dp->reset_link_params = true;
> return IRQ_NONE;
> --
> 2.39.2
RE: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
>
> Suspend and resume DP tunnels during system suspend/resume, disabling the BW
> allocation mode during suspend, re-enabling it after resume. This reflects the
> link's BW management component (Thunderbolt CM) disabling BWA during
> suspend. Before any BW requests the driver must read the sink's DPRX
> capabilities (since the BW manager requires this information, so snoops for
> it on
> AUX), so ensure this read takes place.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a3dfcbb710027..35ef17439038a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -36,6 +36,7 @@
> #include
>
> #include
> +#include
> #include #include
> #include @@ -
> 3313,18 +3314,21 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> - if (!crtc_state)
> - return;
> + bool dpcd_updated = false;
>
> /*
>* Don't clobber DPCD if it's been already read out during output
>* setup (eDP) or detect.
>*/
> - if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> + if (crtc_state && intel_dp->dpcd[DP_DPCD_REV] == 0) {
> intel_dp_get_dpcd(intel_dp);
> + dpcd_updated = true;
> + }
>
> - intel_dp_reset_max_link_params(intel_dp);
> + intel_dp_tunnel_resume(intel_dp, crtc_state, dpcd_updated);
> +
> + if (crtc_state)
> + intel_dp_reset_max_link_params(intel_dp);
> }
>
> bool intel_dp_initial_fastset_check(struct intel_encoder *encoder, @@ -5947,6
> +5951,8 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
>
> intel_pps_vdd_off_sync(intel_dp);
> +
> + intel_dp_tunnel_suspend(intel_dp);
> }
>
> void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
> --
> 2.39.2
RE: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
>
> Handle DP tunnel IRQs a sink (or rather a BW management component like the
> Thunderbolt Connection Manager) raises to signal the completion of a BW
> request by the driver, or to signal any state change related to the link BW.
Looks Good to me.
Reviewed-by: Uma Shankar
X`
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
> include/drm/display/drm_dp.h| 1 +
> 2 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5ad7808788745..a3dfcbb710027 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4904,13 +4904,15 @@ static bool intel_dp_mst_link_status(struct intel_dp
> *intel_dp)
> * - %true if pending interrupts were serviced (or no interrupts were
> * pending) w/o detecting an error condition.
> * - %false if an error condition - like AUX failure or a loss of link - is
> - * detected, which needs servicing from the hotplug work.
> + * detected, or another condition - like a DP tunnel BW state change -
> needs
> + * servicing from the hotplug work.
> */
> static bool
> intel_dp_check_mst_status(struct intel_dp *intel_dp) {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> bool link_ok = true;
> + bool reprobe_needed = false;
>
> drm_WARN_ON_ONCE(>drm, intel_dp->active_mst_links < 0);
>
> @@ -4937,6 +4939,13 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>
> intel_dp_mst_hpd_irq(intel_dp, esi, ack);
>
> + if (esi[3] & DP_TUNNELING_IRQ) {
> + if (drm_dp_tunnel_handle_irq(i915-
> >display.dp_tunnel_mgr,
> + _dp->aux))
> + reprobe_needed = true;
> + ack[3] |= DP_TUNNELING_IRQ;
> + }
> +
> if (!memchr_inv(ack, 0, sizeof(ack)))
> break;
>
> @@ -4947,7 +4956,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> drm_dp_mst_hpd_irq_send_new_request(_dp-
> >mst_mgr);
> }
>
> - return link_ok;
> + return link_ok && !reprobe_needed;
> }
>
> static void
> @@ -5304,23 +5313,32 @@ static void
> intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
> drm_dbg_kms(>drm, "Sink specific irq unhandled\n"); }
>
> -static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> +static bool intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool reprobe_needed = false;
> u8 val;
>
> if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
> - return;
> + return false;
>
> if (drm_dp_dpcd_readb(_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
> !val)
> - return;
> + return false;
> +
> + if ((val & DP_TUNNELING_IRQ) &&
> + drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
> + _dp->aux))
> + reprobe_needed = true;
>
> if (drm_dp_dpcd_writeb(_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
> - return;
> + return reprobe_needed;
>
> if (val & HDMI_LINK_STATUS_CHANGED)
> intel_dp_handle_hdmi_link_status_change(intel_dp);
> +
> + return reprobe_needed;
> }
>
> /*
> @@ -5341,6 +5359,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp) {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u8 old_sink_count = intel_dp->sink_count;
> + bool reprobe_needed = false;
> bool ret;
>
> /*
> @@ -5363,7 +5382,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> }
>
> intel_dp_check_device_service_irq(intel_dp);
> - intel_dp_check_link_service_irq(intel_dp);
> + reprobe_needed = intel_dp_check_link_service_irq(intel_dp);
>
> /* Handle CEC interrupts, if any */
> drm_dp_cec_irq(_dp->aux);
> @@ -5390,10 +5409,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>* FIXME get rid of the ad-hoc phy test modeset code
>* and properly incorporate it into the normal modeset.
>*/
> - return false;
> + reprobe_needed = true;
> }
>
> - return true;
> + return !reprobe_needed;
> }
>
> /* XXX this is probably wrong for multiple downstream ports */ diff --git
> a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index
> 8bfd5d007be8d..4891bd916d26a 100644
>
RE: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check BW limit
> -Original Message- > From: dri-devel On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:49 AM > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check > BW limit > > Add the atomic state during a modeset required to enable the DP tunnel BW > allocation mode on links where such a tunnel was detected. This state applies > to > an already enabled output, the state added for a newly enabled output will be > computed and added/cleared to/from the atomic state in a follow-up patch. > > v2: > - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state(). > - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up > patch adding the corresponding state. (Ville) > - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up > patch adding the corresponding state. Looks Good to me. Reviewed-by: Uma Shankar > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++ > drivers/gpu/drm/i915/display/intel_display.c | 12 > drivers/gpu/drm/i915/display/intel_link_bw.c | 5 + > 3 files changed, 23 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > b/drivers/gpu/drm/i915/display/intel_atomic.c > index 96ab37e158995..798cb90361a83 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > @@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc) > if (crtc_state->post_csc_lut) > drm_property_blob_get(crtc_state->post_csc_lut); > > + if (crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_get(crtc_state->dp_tunnel_ref.tunnel, > + _state->dp_tunnel_ref); > + > crtc_state->update_pipe = false; > crtc_state->update_m_n = false; > crtc_state->update_lrr = false; > @@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc, > > __drm_atomic_helper_crtc_destroy_state(_state->uapi); > intel_crtc_free_hw_state(crtc_state); > + if (crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_put(_state->dp_tunnel_ref); > kfree(crtc_state); > } > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index e1a4200f67a7e..16973ebb7865d 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -33,6 +33,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -73,6 +74,7 @@ > #include "intel_dp.h" > #include "intel_dp_link_training.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_dpll.h" > #include "intel_dpll_mgr.h" > #include "intel_dpt.h" > @@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct > intel_atomic_state *state, > saved_state->crc_enabled = slave_crtc_state->crc_enabled; > > intel_crtc_free_hw_state(slave_crtc_state); > + if (slave_crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_put(_crtc_state->dp_tunnel_ref); > memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state)); > kfree(saved_state); > > @@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct > intel_atomic_state *state, > _crtc_state->hw.adjusted_mode); > slave_crtc_state->hw.scaling_filter = master_crtc_state- > >hw.scaling_filter; > > + if (master_crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_get(master_crtc_state- > >dp_tunnel_ref.tunnel, > + _crtc_state->dp_tunnel_ref); > + > copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc); > > slave_crtc_state->uapi.mode_changed = master_crtc_state- > >uapi.mode_changed; > @@ -5365,6 +5373,10 @@ static int intel_modeset_pipe(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc); > + if (ret) > + return ret; > + > ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c > b/drivers/gpu/drm/i915/display/intel_link_bw.c > index 27ea858897c9f..dfd7d5e23f3fa 100644 > --- a/drivers/gpu/drm/i915/display/intel_link_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c > @@ -9,6 +9,7 @@ > #include "intel_crtc.h" > #include "intel_display_types.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_fdi.h" > #include "intel_link_bw.h" > > @@ -163,6 +164,10 @@ static int check_all_link_config(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_check_link(state, limits); > + if (ret) > +
RE: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with
> syncing
> commits
>
> Add a way to get the active pipes through a given DP port by syncing against a
> related pending non-blocking commit. Atm
> intel_dp_get_active_pipes() will only try to sync a given pipe and if that
> would
> block ignore the pipe. A follow-up change enabling the DP tunnel BW allocation
> mode will need to ensure that all active pipes are returned.
>
> This change will use intel_crtc_state::uapi.commit instead of the
> corresponding
> commit in the connector state. This shouldn't make a difference, since the two
> commit objects match for an active pipe.
>
> A follow-up patchset will remove syncing during TC port reset, which should
> reset
> a port/pipe even if syncing against a commit would block.
> Syncing OTOH is not needed there, since the commit used for the reset implies
> a
> sync already. For now add a TODO comment for this.
>
> v2:
> - Add a separate function to try-sync the pipes. (Ville)
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> 4 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 25593f6aae7de..17ed2e62cc66a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> out:
> intel_psr_unlock(new_crtc_state);
> }
> +
> +/**
> + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of
> +pipes
> + * @i915: i915 device object
> + * @pipe_mask: Mask of pipes to sync
> + *
> + * Try to sync a pending non-blocking commit for the provided pipes in
> + * @pipe_mask. The commit won't be synced if this would block.
> + *
> + * Return a mask of the pipes that got synced or didn't need syncing.
> + */
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> +pipe_mask) {
> + struct intel_crtc *crtc;
> + u32 synced = 0;
> +
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> + const struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
> +
> + if (!crtc_state->uapi.commit ||
> + try_wait_for_completion(_state->uapi.commit-
> >hw_done))
> + synced |= BIT(crtc->pipe);
> + }
> +
> + return synced;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> b/drivers/gpu/drm/i915/display/intel_crtc.h
> index 22d7993d1f0ba..71a5b93166da7 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> drm_i915_private *i915, void intel_wait_for_vblank_if_active(struct
> drm_i915_private *i915,
>enum pipe pipe);
> void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> +pipe_mask);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d9e75922ff8f5..d0452d3e534a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> *intel_dp,
> if (!crtc_state->hw.active)
> continue;
>
> - if (conn_state->commit &&
> - !try_wait_for_completion(_state->commit->hw_done))
> - continue;
> -
> *pipe_mask |= BIT(crtc->pipe);
> }
> drm_connector_list_iter_end(_iter);
> @@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder
> *encoder,
> if (ret)
> return ret;
>
> + pipe_mask &= intel_crtc_try_sync_pipes(dev_priv, pipe_mask);
> +
> if (pipe_mask == 0)
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 6b374d481cd9e..14d17903a81f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -7,6 +7,7 @@
> #include "i915_reg.h"
> #include "intel_atomic.h"
> #include "intel_cx0_phy_regs.h"
> +#include "intel_crtc.h"
> #include "intel_ddi.h"
> #include "intel_de.h"
> #include "intel_display.h"
> @@ -1663,6 +1664,12 @@ static
RE: [PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to retry modesets
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH v2 04/21] drm/i915/dp: Add support to notify MST connectors to
> retry modesets
>
> On shared (Thunderbolt) links with DP tunnels, the modeset may need to be
> retried on all connectors on the link due to a link BW limitation arising
> only after
> the atomic check phase. To support this add a helper function queuing a work
> to
> retry the modeset on a given port's connector and at the same time any MST
> connector with streams through the same port. A follow-up change enabling the
> DP tunnel Bandwidth Allocation Mode will take this into use.
>
> v2:
> - Send the uevent only to enabled MST connectors. (Jouni)
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Jouni Högander
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 5 ++-
> drivers/gpu/drm/i915/display/intel_dp.c | 45 ++-
> drivers/gpu/drm/i915/display/intel_dp.h | 6 +++
> .../drm/i915/display/intel_dp_link_training.c | 3 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +
> 5 files changed, 55 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 485c38d71f106..2ee26d19c200b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8085,8 +8085,9 @@ void intel_hpd_poll_fini(struct drm_i915_private
> *i915)
> /* Kill all the work that may have been queued by hpd. */
> drm_connector_list_iter_begin(>drm, _iter);
> for_each_intel_connector_iter(connector, _iter) {
> - if (connector->modeset_retry_work.func)
> - cancel_work_sync(>modeset_retry_work);
> + if (connector->modeset_retry_work.func &&
> + cancel_work_sync(>modeset_retry_work))
> + drm_connector_put(>base);
> if (connector->hdcp.shim) {
> cancel_delayed_work_sync(
> >hdcp.check_work);
> cancel_work_sync(>hdcp.prop_work);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 217196196e50a..88606e336a920 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2842,6 +2842,40 @@ intel_dp_audio_compute_config(struct intel_encoder
> *encoder,
> intel_dp_is_uhbr(pipe_config);
> }
>
> +void intel_dp_queue_modeset_retry_work(struct intel_connector
> +*connector) {
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
> +
> + drm_connector_get(>base);
> + if (!queue_work(i915->unordered_wq,
> >modeset_retry_work))
> + drm_connector_put(>base);
> +}
> +
> +void
> +intel_dp_queue_modeset_retry_for_link(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *crtc_state) {
> + struct intel_connector *connector;
> + struct intel_digital_connector_state *conn_state;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + int i;
> +
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
> + intel_dp_queue_modeset_retry_work(intel_dp-
> >attached_connector);
> +
> + return;
> + }
> +
> + for_each_new_intel_connector_in_state(state, connector, conn_state, i) {
> + if (!conn_state->base.crtc)
> + continue;
> +
> + if (connector->mst_port == intel_dp)
> + intel_dp_queue_modeset_retry_work(connector);
> + }
> +}
> +
> int
> intel_dp_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config, @@ -6441,6
> +6475,14 @@ static void intel_dp_modeset_retry_work_fn(struct work_struct
> *work)
> mutex_unlock(>dev->mode_config.mutex);
> /* Send Hotplug uevent so userspace can reprobe */
> drm_kms_helper_connector_hotplug_event(connector);
> +
> + drm_connector_put(connector);
> +}
> +
> +void intel_dp_init_modeset_retry_work(struct intel_connector
> +*connector) {
> + INIT_WORK(>modeset_retry_work,
> + intel_dp_modeset_retry_work_fn);
> }
>
> bool
> @@ -6457,8 +6499,7 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
> int type;
>
> /* Initialize the work for modeset in case of link train failure */
> - INIT_WORK(_connector->modeset_retry_work,
> - intel_dp_modeset_retry_work_fn);
> + intel_dp_init_modeset_retry_work(intel_connector);
>
> if (drm_WARN(dev, dig_port->max_lanes < 1,
>"Not enough lanes (%d)
RE: [PATCH v2 03/21] drm/i915: Fix display bpp limit computation during system resume
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:48 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 03/21] drm/i915: Fix display bpp limit computation during
> system resume
>
> The system resume display mode restoration should happen with an output
> configuration matching that of the suspend time saved mode. Since the restored
> mode configuration is subject to the bpp fallback logic, starting out with an
> unlimited bpp and reducing the bpp as required by any (MST) link BW limit, the
> resulting bpp will match the one during suspend only if the BW limit checks
> during
> suspend and resume are applied in an identical way. The latter is not
> guaranteed
> at the moment, since the pre-suspend MST topology may not be in place during
> resume (for instance if the MST sink was disconnected while being suspended),
> which makes the MST link BW check accept the unlimited bpp mode
> configuration unconditionally without ensuring that the required BW fits into
> the
> available MST link BW.
>
> To fix the above, initialize the bpp fallback logic with the max link bpp /
> force-FEC
> limits left behind by the suspend time mode save.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 +--
> drivers/gpu/drm/i915/display/intel_link_bw.c | 22
> drivers/gpu/drm/i915/display/intel_link_bw.h | 2 +-
> 3 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 00ac65a140298..485c38d71f106 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6252,12 +6252,11 @@ static int intel_atomic_check_config(struct
> intel_atomic_state *state,
>
> static int intel_atomic_check_config_and_link(struct intel_atomic_state
> *state) {
> - struct drm_i915_private *i915 = to_i915(state->base.dev);
> struct intel_link_bw_limits new_limits;
> struct intel_link_bw_limits old_limits;
> int ret;
>
> - intel_link_bw_init_limits(i915, _limits);
> + intel_link_bw_init_limits(state, _limits);
> old_limits = new_limits;
>
> while (true) {
> diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c
> b/drivers/gpu/drm/i915/display/intel_link_bw.c
> index 9c6d35a405a18..27ea858897c9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_link_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
> @@ -6,6 +6,7 @@
> #include "i915_drv.h"
>
> #include "intel_atomic.h"
> +#include "intel_crtc.h"
> #include "intel_display_types.h"
> #include "intel_dp_mst.h"
> #include "intel_fdi.h"
> @@ -13,19 +14,32 @@
>
> /**
> * intel_link_bw_init_limits - initialize BW limits
> - * @i915: device instance
> + * @state: Atomic state
> * @limits: link BW limits
> *
> * Initialize @limits.
> */
> -void intel_link_bw_init_limits(struct drm_i915_private *i915, struct
> intel_link_bw_limits *limits)
> +void intel_link_bw_init_limits(struct intel_atomic_state *state,
> +struct intel_link_bw_limits *limits)
> {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> enum pipe pipe;
>
> limits->force_fec_pipes = 0;
> limits->bpp_limit_reached_pipes = 0;
> - for_each_pipe(i915, pipe)
> - limits->max_bpp_x16[pipe] = INT_MAX;
> + for_each_pipe(i915, pipe) {
> + const struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state,
> +
> intel_crtc_for_pipe(i915, pipe));
> +
> + if (state->base.duplicated && crtc_state) {
> + limits->max_bpp_x16[pipe] = crtc_state-
> >max_link_bpp_x16;
> + if (crtc_state->fec_enable)
> + limits->force_fec_pipes |= BIT(pipe);
> + } else {
> + limits->max_bpp_x16[pipe] = INT_MAX;
> + }
> + }
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.h
> b/drivers/gpu/drm/i915/display/intel_link_bw.h
> index 2cf57307cc249..6b0ccfff59dab 100644
> --- a/drivers/gpu/drm/i915/display/intel_link_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_link_bw.h
> @@ -22,7 +22,7 @@ struct intel_link_bw_limits {
> int max_bpp_x16[I915_MAX_PIPES];
> };
>
> -void intel_link_bw_init_limits(struct drm_i915_private *i915,
> +void intel_link_bw_init_limits(struct intel_atomic_state *state,
> struct intel_link_bw_limits *limits); int
> intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
>struct intel_link_bw_limits *limits,
> --
> 2.39.2
RE: [PATCH v2 02/21] drm/dp: Add support for DP tunneling
> -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:48 AM > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 02/21] drm/dp: Add support for DP tunneling > > Add support for Display Port tunneling. For now this includes the > support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay > support for later. > > BWA allows using displays that share the same (Thunderbolt) link with > their maximum resolution. Atm, this may not be possible due to the > coarse granularity of partitioning the link BW among the displays on the > link: the BW allocation policy is in a SW/FW/HW component on the link > (on Thunderbolt it's the SW or FW Connection Manager), independent of > the driver. This policy will set the DPRX maximum rate and lane count > DPCD registers the GFX driver will see (0x0, 0x1, 0x02200, > 0x02201) based on the available link BW. > > The granularity of the current BW allocation policy is coarse, based on > the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent > using higher resolutions all together: the display connected first will > get a share of the link BW which corresponds to its full DPRX capability > (regardless of the actual mode it uses). A subsequent display connected > will only get the remaining BW, which could be well below its full > capability. > > BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps > range) and first-come/first-served issues by letting the driver request > the BW for each display on a link which reflects the actual modes the > displays use. > > This patch adds the DRM core helper functions, while a follow-up change > in the patchset takes them into use in the i915 driver. > > v2: > - Fix prepare_to_wait vs. wake-up cond check order in > allocate_tunnel_bw(). (Ville) > - Move tunnel==NULL checks from callers in drivers to here. (Ville) > - Avoid var inits in declaration blocks that can fail or have > side-effects. (Ville) > - Use u8 for driver and group IDs. (Ville) > - Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville) > - Reuse str_yes_no() instead of a local yes_no_chr(). (Ville) > - s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport > the function. (Ville) > - s/clear_tunnel_group_state()/free_group_state() and move kfree() to > this function. (Ville) > - Add separate group_free_bw() helper and describe what the tunnel > estimated BW includes. (Ville) > - Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville) > - Add code comment explaining the purpose of DPCD reg read helpers. > (Ville) > - Add code comment describing the tunnel group name prefix format. > (Ville) > - Report the allocated BW as undetermined until the first allocation > request. > - Skip allocation requests matching the previous request. > - Clear any stale BW request status flags before a new request. > - Add missing error return check of drm_dp_tunnel_atomic_get_group_state() > in drm_dp_tunnel_atomic_set_stream_bw(). > - Add drm_dp_tunnel_get_allocated_bw(). > - > s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_ > bw > - Fix return value description in function doc of drm_dp_tunnel_detect(). > - Add function documentation to all exported functions. > > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/display/Kconfig | 21 + > drivers/gpu/drm/display/Makefile|2 + > drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 +++ > include/drm/display/drm_dp.h| 60 + > include/drm/display/drm_dp_tunnel.h | 248 +++ > 5 files changed, 2260 insertions(+) > create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c > create mode 100644 include/drm/display/drm_dp_tunnel.h > > diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig > index 09712b88a5b83..c0f56888c3280 100644 > --- a/drivers/gpu/drm/display/Kconfig > +++ b/drivers/gpu/drm/display/Kconfig > @@ -17,6 +17,27 @@ config DRM_DISPLAY_DP_HELPER > help > DRM display helpers for DisplayPort. > > +config DRM_DISPLAY_DP_TUNNEL > + bool > + select DRM_DISPLAY_DP_HELPER > + help > + Enable support for DisplayPort tunnels. This allows drivers to use > + DP tunnel features like the Bandwidth Allocation mode to maximize the > + BW utilization for display streams on Thunderbolt links. > + > +config DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE > + bool "Enable debugging the DP tunnel state" > + depends on REF_TRACKER > + depends on DRM_DISPLAY_DP_TUNNEL > + depends on DEBUG_KERNEL > + depends on EXPERT > + help > + Enables debugging the DP tunnel manager's state, including the > + consistency of all managed tunnels' reference counting and the state > of > + streams contained in tunnels. > + > + If in doubt, say "N". >
RE: [RFC PATCH v3 00/23] Color Pipeline API w/ VKMS
> -Original Message- > From: Harry Wentland > Sent: Wednesday, November 8, 2023 10:06 PM > To: dri-devel@lists.freedesktop.org > Cc: wayland-de...@lists.freedesktop.org; Harry Wentland > ; Ville Syrjala ; Pekka > Paalanen ; Simon Ser ; > Melissa Wen ; Jonas Ådahl ; Sebastian > Wick ; Shashank Sharma > ; Alexander Goins ; Joshua > Ashton ; Michel Dänzer ; Aleix Pol > ; Xaver Hugl ; Victoria Brekenfeld > ; Sima ; Shankar, Uma > ; Naseer Ahmed ; > Christopher Braga ; Abhinav Kumar > ; Arthur Grillo ; Hector > Martin ; Liviu Dudau ; Sasha > McIntosh > Subject: [RFC PATCH v3 00/23] Color Pipeline API w/ VKMS > > This is an RFC set for a color pipeline API, along with a sample > implementation in > VKMS. All the key API bits are here. VKMS now supports two named transfer > function colorops and two matrix colorops. We have IGT tests that check all > four > of these colorops with a pixel-by-pixel comparison that checks that these > colorops > do what we expect them to do with a +/- 1 8 bpc code point margin. > > > > This patchset is grouped as follows: > - Patches 1-2: couple general patches/fixes > - Patches 3-5: introduce kunit to VKMS > - Patch 6: description of motivation and details behind the > Color Pipeline API. If you're reading nothing else > but are interested in the topic I highly recommend > you take a look at this. > - Patches 7-23: DRM core and VKMS changes for color pipeline API Hi Harry, One small suggestion, here we are implementing plane color management (pre blending). Can we make the names of functions also to reflect the same. Later support for Pipe level color management (post blending) can be added on top of it using the same UAPI design. As discussed already on the series sent by us, refer below: https://patchwork.freedesktop.org/series/129811/ If you feel ok with the changes, please include support for hw_caps property, changes for adding 1dlut and 3x3 CTM and the fixes called out in the same in your series. This will help in having a unified discussion on the DRM core changes. Thanks & Regards, Uma Shankar > There are plenty of things that I would like to see here but haven't had a > chance > to look at. These will (hopefully) be addressed in future iterations, either > in VKMS > or amdgpu: > - PQ transfer function > - Add custom LUT colorops to VKMS > - Add pre-blending 3DLUT > - How to support HW which can't bypass entire pipeline? > - Add ability to create colorops that don't have BYPASS > - Can we do a LOAD / COMMIT model for LUTs (and other properties)? > - read-only scaling colorop which defines scaling taps and position > - read-only color format colorop to define supported color formats >for a pipeline > - named matrices, for things like converting YUV to RGB > > IGT tests can be found at > https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1 > > IGT patches are also being sent to the igt-dev mailing list. > > If you prefer a gitlab MR for review you can find it at > https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5 > > v3: > - Abandon IOCTLs and discover colorops as clients iterate the pipeline > - Remove need for libdrm > - Add color_pipeline client cap and make mutually exclusive with >COLOR_RANGE and COLOR_ENCODING properties > - add CTM colorop to VKMS > - Use include way for kunit testing static functions (Arthur) > - Make TYPE a range property > - Move enum drm_colorop_type to uapi header > - and a bunch of smaller bits that are highlighted in the relevant commit >description > > v2: > - Rebased on drm-misc-next > - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer > - Incorporate feedback in color_pipeline.rst doc > - Add support for sRGB inverse EOTF > - Add 2nd enumerated TF colorop to VKMS > - Fix LUTs and some issues with applying LUTs in VKMS > > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Simon Ser > Cc: Harry Wentland > Cc: Melissa Wen > Cc: Jonas Ådahl > Cc: Sebastian Wick > Cc: Shashank Sharma > Cc: Alexander Goins > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Aleix Pol > Cc: Xaver Hugl > Cc: Victoria Brekenfeld > Cc: Sima > Cc: Uma Shankar > Cc: Naseer Ahmed > Cc: Christopher Braga > Cc: Abhinav Kumar > Cc: Arthur Grillo > Cc: Hector Martin > Cc: Liviu Dudau > Cc: Sasha McIntosh > > Harry Wentland (23): > drm: Don't treat 0 as -1 in drm_fixp2int_ceil > drm: Add helper for conversion from signed-magnitude > drm/vkms: Create separate Kconfig file for VKMS > drm/vkms: Add kunit tests for VKMS LUT handling > drm
RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> -Original Message- > From: Harry Wentland > Sent: Saturday, February 17, 2024 3:17 AM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: ville.syrj...@linux.intel.com; pekka.paala...@collabora.com; > cont...@emersion.fr; m...@igalia.com; jad...@redhat.com; > sebastian.w...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com; > jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org; > xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch; > quic_nas...@quicinc.com; quic_cbr...@quicinc.com; > quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st; > liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run; Borah, > Chaitanya Kumar > Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms > > > > On 2024-02-13 01:48, Uma Shankar wrote: > > This series intends to add support for Plane Color Management for > > Intel platforms. This is based on the design which has been agreed > > upon by the community. Series implementing the design for generic DRM > > core has been sent out by Harry Wentland and is under review > > below: > > https://patchwork.freedesktop.org/series/123446/ > > > > The base work of above series is squashed under 1 patch and support > > for Intel platform is added on top of it. > > Any reviews on the original core design is expected to be done in > > Harry's series to avoid any forking of the discussion. > > > > We have added some changes/fixes to the Harry's core DRM changes, > > being put up as separate patches on top of squashed patch. These are > > expected to get included in the main series from Harry once agreed upon. > > > > Changes added on core design: > > 1. Below patches implement some fixes on original series > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > > > 2. Implemented a HW capability property to expose segmented luts. > > drm: Add Color lut range attributes > > drm: Add Color ops capability property > > drm: Define helper to create color ops capability property > > drm: Define helper for adding capability property for 1D LUT > > > > This helps in generically defining the hardware lut capabilities, lut > > distribution, precision, segmented or PWL LUTS. > > > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > > drm: Add Enhanced LUT precision structure > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > > > On top of this base work for DRM core plane color pipeline design, > > implementation is done for Intel hardware platforms. Below patches > > include the same: > > > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > > drm/i915/color: Add and attach COLORPIPELINE plane property > > drm/i915/color: Add framework to set colorop > > drm/i915/color: Add callbacks to set plane CTM > > drm/i915/color: Add framework to program PRE/POST CSC LUT > > FIXME: force disable legacy plane color properties for TGL and beyond > > drm/i915/color: Enable Plane Color Pipelines > > drm/i915: Define segmented Lut and add capabilities to colorop > > drm/i915/color: Add plane CTM callback for TGL and beyond > > drm/i915: Add register definitions for Plane Degamma > > drm/i915: Add register definitions for Plane Post CSC > > drm/i915/color: Program Pre-CSC registers > > drm/i915/xelpd: Program Plane Post CSC Registers > > > > Bhanu from Intel will be sending out the igt changes to help test the > > color pipeline implementation based on the current igt changes sent > > out by Harry. > > https://patchwork.freedesktop.org/series/123448/ > > > > Planned Next Steps: > > 1. Work with Harry and community and get DRM core changes for color > > pipeline merged. > > We'll need a userspace to implement support before merging, but we're working > to enabling all color properties gamescope currently uses for the SteamDeck > color > management to the Color Pipeline API, which should help us get there. It's > still a > journey but I think the path is clear. Yeah, thanks Harry for driving it. > I'll send a new version of my patch series next week, including some AMD > implementation (not the entire AMD pipeline yet). Oh ok, Nice. One more input which can be considered:
RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, February 14, 2024 2:34 PM
> To: Shankar, Uma
> Cc: ville.syrj...@linux.intel.com; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
>
> On Wed, 14 Feb 2024 07:28:37 +
> "Shankar, Uma" wrote:
>
> > > -Original Message-
> > > From: dri-devel On Behalf
> > > Of Pekka Paalanen
> > > Sent: Tuesday, February 13, 2024 3:07 PM
> > > To: Shankar, Uma
> > > Cc: intel-...@lists.freedesktop.org;
> > > dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> > > cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> > > jad...@redhat.com; sebastian.w...@redhat.com;
> > > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> > > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> > > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> > > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com;
> > > arthurgri...@riseup.net; mar...@marcan.st; liviu.du...@arm.com;
> > > sashamcint...@google.com; s...@poorly.run
> > > Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add
> > > capabilities to colorop
> > >
> > > On Tue, 13 Feb 2024 12:18:24 +0530
> > > Uma Shankar wrote:
> > >
> > > > This defines the lut segments and create the color pipeline
> > > >
> > > > Signed-off-by: Uma Shankar
> > > > Signed-off-by: Chaitanya Kumar Borah
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_color.c | 109
> > > > +
> > > > 1 file changed, 109 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > > index e223edbe4c13..223cd1ff7291 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> > > ilk_color_funcs = {
> > > > .get_config = ilk_get_config,
> > > > };
> > > >
> > > > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > > > + /* segment 1 */
> > > > + {
> > > > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > > + DRM_MODE_LUT_INTERPOLATE |
> > > > + DRM_MODE_LUT_NON_DECREASING),
> > >
> > > Hi Uma,
> > >
> > > is it a good idea to have these flags per-segment?
> > >
> > > I would find it very strange, unusable really, if REFLECT_NEGATIVE
> > > applied on some but not all segments, for example. Is such
> > > flexibility really necessary in the hardware description?
> >
> > Hi Pekka,
> > Idea to have these flags is to just have some option in case there are
> > some differences across segments. Most cases this should not be the
> > case, just helps to future proof the implementation.
> >
> > Based on how the community feels on the usability of it, we can take a
> > call on the flags and the expected interpretation for the same. We are open
> > for
> suggestions on the same.
> >
> > >
> > > > + .count = 128,
> > > > + .input_bpc = 24, .output_bpc = 16,
> > >
> > > The same question about input_bpc and output_bpc.
> >
> > Same for these as well, userspace can just ignore these if no usage.
> > However, for some clients it may help in Lut computations.
> > The original idea for the structure came from Ville (missed to mention
> > that in cover letter, will get that updated in next version).
> >
> > @ville.syrj...@linux.intel.com Please share your inputs on the usability of
> > these
> attributes.
>
> Userspace will al
RE: [PATCH 09/28] drm: Add Color ops capability property
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:35 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 09/28] drm: Add Color ops capability property
>
> On Tue, Feb 13, 2024 at 12:18:16PM +0530, Uma Shankar wrote:
> > Add capability property which a colorop can expose it's hardware's
> > abilities. It's a blob property that can be filled with respective
> > data structures depending on the colorop. The user space is expected
> > to read this property and program the colorop accordingly.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > include/drm/drm_colorop.h | 13 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9f6a3a1c8020..95f1df73209c 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop
> *colorop,
> > *val = state->curve_1d_type;
> > } else if (property == colorop->data_property) {
> > *val = (state->data) ? state->data->base.id : 0;
> > + } else if (property == colorop->hw_caps_property) {
> > + *val = state->hw_caps ?
> > + state->hw_caps->base.id : 0;
> > } else {
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> > index 5b8c36538491..f417e109c40a 100644
> > --- a/include/drm/drm_colorop.h
> > +++ b/include/drm/drm_colorop.h
> > @@ -59,6 +59,12 @@ struct drm_colorop_state {
> > */
> > enum drm_colorop_curve_1d_type curve_1d_type;
> >
> > + /**
> > +* @hw_caps:
> > +*
> > +*/
> > + struct drm_property_blob *hw_caps;
> > +
>
> Is this supposed to be generic for any colorop or specifically for
> DRM_COLOROP_1D_LUT?
We have intentionally kept it generic so that it can be used for any kind
of hardware color block (1D LUT, 3D LUT etc.). Differentiation can be done
by using the Color op type.
Regards,
Uma Shankar
> > /**
> > * @data:
> > *
> > @@ -167,6 +173,13 @@ struct drm_colorop {
> > */
> > struct drm_property *bypass_property;
> >
> > + /**
> > +* @hwlut_caps_property:
> > +*
> > +* Property to expose hardware lut capbilities.
> > +*/
> > + struct drm_property *hw_caps_property;
> > +
> > /**
> > * @curve_1d_type:
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 08/28] drm: Add Color lut range attributes
> -Original Message-
> From: Sebastian Wick
> Sent: Tuesday, February 13, 2024 5:34 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> cont...@emersion.fr; harry.wentl...@amd.com; m...@igalia.com;
> jad...@redhat.com; shashank.sha...@amd.com; ago...@nvidia.com;
> jos...@froggi.es; mdaen...@redhat.com; aleix...@kde.org;
> xaver.h...@gmail.com; victo...@system76.com; dan...@ffwll.ch;
> quic_nas...@quicinc.com; quic_cbr...@quicinc.com;
> quic_abhin...@quicinc.com; arthurgri...@riseup.net; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; s...@poorly.run
> Subject: Re: [PATCH 08/28] drm: Add Color lut range attributes
>
> On Tue, Feb 13, 2024 at 12:18:15PM +0530, Uma Shankar wrote:
> > This defines a new structure to define color lut ranges, along with
> > related macro definitions and enums. This will help describe segmented
> > lut ranges/PWL LUTs in the hardware.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > include/uapi/drm/drm_mode.h | 58
> > +
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index af67f32e0087..376498715d0e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
> > DRM_MODE_PAGE_FLIP_ASYNC | \
> > DRM_MODE_PAGE_FLIP_TARGET)
> >
>
> All of this uses DRM_MODE_LUT namespace but it seems specifically for the drm
> colorop of type DRM_COLOROP_1D_LUT. Let's be consistent with the naming.
Yeah Sebastian, we will update this and get it aligned.
Thanks for pointing out.
Regards,
Uma Shankar
> > +/**
> > + * DRM_MODE_LUT_INTERPOLATE
> > + *
> > + * linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(0)
> > +
> > +/**
> > + * DRM_MODE_LUT_REUSE_LAST
> > + *
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(1)
> > +
> > +/**
> > + * DRM_MODE_LUT_NON_DECREASING
> > + *
> > + * the curve must be non-decreasing
> > + */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(2)
> > +
> > +/**
> > + * DRM_MODE_LUT_REFLECT_NEGATIVE
> > + *
> > + * the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
> > +
> > +/**
> > + * DRM_MODE_LUT_SINGLE_CHANNEL
> > + *
> > + * the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
> > +
> > +/**
> > + * struct drm_color_lut_range
> > + *
> > + * structure to advertise capability of a color hardware
> > + * block that accepts LUT values. It can represent LUTs with
> > + * varied number of entries and distributions
> > + * (Multi segmented, Logarithmic etc).
> > + */
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > /*
> > * Request a page flip on the specified crtc.
> > *
> > --
> > 2.42.0
> >
RE: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, February 13, 2024 4:32 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com; > m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com; > shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es; > mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com; > victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com; > quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net; > mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com; > s...@poorly.run; Borah, Chaitanya Kumar > Subject: Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms > > On Tue, 13 Feb 2024 12:18:07 +0530 > Uma Shankar wrote: > > > This series intends to add support for Plane Color Management for > > Intel platforms. This is based on the design which has been agreed > > upon by the community. Series implementing the design for generic DRM > > core has been sent out by Harry Wentland and is under review > > below: > > https://patchwork.freedesktop.org/series/123446/ > > > > The base work of above series is squashed under 1 patch and support > > for Intel platform is added on top of it. > > Any reviews on the original core design is expected to be done in > > Harry's series to avoid any forking of the discussion. > > > > We have added some changes/fixes to the Harry's core DRM changes, > > being put up as separate patches on top of squashed patch. These are > > expected to get included in the main series from Harry once agreed upon. > > > > Changes added on core design: > > 1. Below patches implement some fixes on original series > > drm: Add missing function declarations > > drm: handle NULL next colorop in drm_colorop_set_next_property > > drm: Fix error logging in set Color Pipeline > > > > 2. Implemented a HW capability property to expose segmented luts. > > drm: Add Color lut range attributes > > drm: Add Color ops capability property > > drm: Define helper to create color ops capability property > > drm: Define helper for adding capability property for 1D LUT > > > > This helps in generically defining the hardware lut capabilities, lut > > distribution, precision, segmented or PWL LUTS. > > > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > > drm: Add Enhanced LUT precision structure > > drm: Add support for 3x3 CTM > > drm: Add 1D LUT color op > > > > On top of this base work for DRM core plane color pipeline design, > > implementation is done for Intel hardware platforms. Below patches > > include the same: > > > > drm/i915: Add identifiers for intel color blocks > > drm/i915: Add intel_color_op > > drm/i915/color: Add helper to allocate intel colorop > > drm/i915/color: Add helper to create intel colorop > > drm/i915/color: Create a transfer function color pipeline > > drm/i915/color: Add and attach COLORPIPELINE plane property > > drm/i915/color: Add framework to set colorop > > drm/i915/color: Add callbacks to set plane CTM > > drm/i915/color: Add framework to program PRE/POST CSC LUT > > FIXME: force disable legacy plane color properties for TGL and beyond > > drm/i915/color: Enable Plane Color Pipelines > > drm/i915: Define segmented Lut and add capabilities to colorop > > drm/i915/color: Add plane CTM callback for TGL and beyond > > drm/i915: Add register definitions for Plane Degamma > > drm/i915: Add register definitions for Plane Post CSC > > drm/i915/color: Program Pre-CSC registers > > drm/i915/xelpd: Program Plane Post CSC Registers > > > > Bhanu from Intel will be sending out the igt changes to help test the > > color pipeline implementation based on the current igt changes sent > > out by Harry. > > https://patchwork.freedesktop.org/series/123448/ > > > > Planned Next Steps: > > 1. Work with Harry and community and get DRM core changes for color > > pipeline merged. > > 2. Implement pipe color management (post blending) based on the > > current color pipeline design. > > 3. Work with compositor maintainers to get color processing > > implemented using display hardware, thereby avoid any GL or GPU shaders. > > > > Thanks to all the community maintainers and contributors who have > > helped to get this support in upstream Linux. Looking forward to > > collaborate, work together and get this merged. > > > > ... > > > Chaitanya Kumar Bor
RE: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Tuesday, February 13, 2024 3:07 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run
> Subject: Re: [PATCH 17/28] drm/i915: Define segmented Lut and add capabilities
> to colorop
>
> On Tue, 13 Feb 2024 12:18:24 +0530
> Uma Shankar wrote:
>
> > This defines the lut segments and create the color pipeline
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 109
> > +
> > 1 file changed, 109 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index e223edbe4c13..223cd1ff7291 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3811,6 +3811,105 @@ static const struct intel_color_funcs
> ilk_color_funcs = {
> > .get_config = ilk_get_config,
> > };
> >
> > +static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
>
> Hi Uma,
>
> is it a good idea to have these flags per-segment?
>
> I would find it very strange, unusable really, if REFLECT_NEGATIVE applied on
> some but not all segments, for example. Is such flexibility really necessary
> in the
> hardware description?
Hi Pekka,
Idea to have these flags is to just have some option in case there are some
differences
across segments. Most cases this should not be the case, just helps to future
proof
the implementation.
Based on how the community feels on the usability of it, we can take a call on
the flags
and the expected interpretation for the same. We are open for suggestions on
the same.
>
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
>
> The same question about input_bpc and output_bpc.
Same for these as well, userspace can just ignore these if no usage. However,
for some clients
it may help in Lut computations.
The original idea for the structure came from Ville (missed to mention that in
cover letter, will get that
updated in next version).
@ville.syrj...@linux.intel.com Please share your inputs on the usability of
these attributes.
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
>
> What if there is a gap or overlap between the previous segment .end and the
> next
> segment .start? Is it forbidden? Will the kernel common code verify that
> drivers
> don't make mistakes? Or IGT?
This is just to help give some reference to userspace. As of now, driver
trusts the values
coming from userspace if it sends wrong values its on him and driver can't help
much.
However, we surely can have some sanity check like non decreasing luts etc. to
driver.
Ideally LUT values should not overlap, but we can indicate this explicitly with
flag to
hint the userspace (for overlap or otherwise) and also get a check in driver
for the same.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > +
RE: [PATCH 05/28] drm: Add support for 3x3 CTM
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, February 13, 2024 2:45 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; cont...@emersion.fr; harry.wentl...@amd.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; arthurgri...@riseup.net;
> mar...@marcan.st; liviu.du...@arm.com; sashamcint...@google.com;
> s...@poorly.run; Borah, Chaitanya Kumar
> Subject: Re: [PATCH 05/28] drm: Add support for 3x3 CTM
>
> On Tue, 13 Feb 2024 12:18:12 +0530
> Uma Shankar wrote:
>
> > From: Chaitanya Kumar Borah
> >
> > Add support for 3x3 Color Transformation Matrices in Color Pipeline.
> >
> > Signed-off-by: Chaitanya Kumar Borah
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_colorop.c | 2 +-
> > include/uapi/drm/drm_mode.h | 1 +
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index e7bf1fb054af..c54b0d6c133e 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_colorop *colorop,
> > case DRM_COLOROP_CTM_3X4:
> > size = sizeof(struct drm_color_ctm_3x4);
> > break;
> > + case DRM_COLOROP_CTM_3X3:
> > + size = sizeof(struct drm_color_ctm);
> > + break;
> > default:
> > /* should never get here */
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/drm_colorop.c
> > b/drivers/gpu/drm/drm_colorop.c index 462ffec42cdf..6bae6dc8e54b
> > 100644
> > --- a/drivers/gpu/drm/drm_colorop.c
> > +++ b/drivers/gpu/drm/drm_colorop.c
> > @@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
> drm_colorop *colorop,
> >0);
> >
> > /* data */
> > - if (type == DRM_COLOROP_CTM_3X4) {
> > + if (type == DRM_COLOROP_CTM_3X4 || type ==
> DRM_COLOROP_CTM_3X3) {
> > prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLOB,
> >"DATA", 0);
> > if (!prop)
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index f16318f1785f..68696253867e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -868,6 +868,7 @@ struct drm_color_lut {
> >
> > enum drm_colorop_type {
> > DRM_COLOROP_1D_CURVE,
> > + DRM_COLOROP_CTM_3X3,
> > DRM_COLOROP_CTM_3X4,
> > };
> >
>
> Hi,
>
> where are the docs for DRM_COLOROP_CTM_3X3?
Hi Pekka,
Sorry, we missed this in the current version. Will update the same in next
revision.
Regards,
Uma Shankar
>
> Thanks,
> pq
RE: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders
> -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Tuesday, January 23, 2024 3:59 PM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Subject: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI > DP encoders > > A follow-up change will need to resume DP tunnels during system resume, so > call > intel_dp_sync_state() always for DDI encoders, so this function can resume the > tunnels for all DP connectors. Looks good to me. Reviewed-by: Uma Shankar > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index aa6e7da08fbce..1e26e62b82d48 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -4131,7 +4131,7 @@ static void intel_ddi_sync_state(struct intel_encoder > *encoder, > intel_tc_port_sanitize_mode(enc_to_dig_port(encoder), > crtc_state); > > - if (crtc_state && intel_crtc_has_dp_encoder(crtc_state)) > + if (intel_encoder_is_dp(encoder)) > intel_dp_sync_state(encoder, crtc_state); } > > -- > 2.39.2
RE: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder
> enable/disable hooks
>
> Allocate and free the DP tunnel BW required by a stream while
> enabling/disabling
> the stream during a modeset.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c| 28
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index dfe0b07a122d1..1e498e1510adf 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -19,6 +19,7 @@
> #include "intel_dp.h"
> #include "intel_dp_aux.h"
> #include "intel_dp_link_training.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_fifo_underrun.h"
> #include "intel_hdmi.h"
> @@ -729,6 +730,24 @@ static void vlv_enable_dp(struct intel_atomic_state
> *state,
> encoder->audio_enable(encoder, pipe_config, conn_state); }
>
> +static void g4x_dp_pre_pll_enable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state *new_crtc_state,
> + const struct drm_connector_state
> *new_conn_state) {
> + intel_dp_tunnel_atomic_alloc_bw(state, encoder,
> + new_crtc_state, new_conn_state);
> +}
> +
> +static void g4x_dp_post_pll_disable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *old_crtc_state,
> + const struct drm_connector_state
> *old_conn_state) {
> + intel_dp_tunnel_atomic_free_bw(state, encoder,
> +old_crtc_state, old_conn_state); }
> +
> static void g4x_pre_enable_dp(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config, @@ -
> 762,6 +781,8 @@ static void vlv_dp_pre_pll_enable(struct intel_atomic_state
> *state,
> intel_dp_prepare(encoder, pipe_config);
>
> vlv_phy_pre_pll_enable(encoder, pipe_config);
> +
> + g4x_dp_pre_pll_enable(state, encoder, pipe_config, conn_state);
> }
>
> static void chv_pre_enable_dp(struct intel_atomic_state *state, @@ -785,6
> +806,8 @@ static void chv_dp_pre_pll_enable(struct intel_atomic_state *state,
> intel_dp_prepare(encoder, pipe_config);
>
> chv_phy_pre_pll_enable(encoder, pipe_config);
> +
> + g4x_dp_pre_pll_enable(state, encoder, pipe_config, conn_state);
> }
>
> static void chv_dp_post_pll_disable(struct intel_atomic_state *state, @@
> -792,6
> +815,8 @@ static void chv_dp_post_pll_disable(struct intel_atomic_state
> *state,
> const struct intel_crtc_state
> *old_crtc_state,
> const struct drm_connector_state
> *old_conn_state) {
> + g4x_dp_post_pll_disable(state, encoder, old_crtc_state,
> +old_conn_state);
> +
> chv_phy_post_pll_disable(encoder, old_crtc_state); }
>
> @@ -1349,11 +1374,14 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
> intel_encoder->enable = vlv_enable_dp;
> intel_encoder->disable = vlv_disable_dp;
> intel_encoder->post_disable = vlv_post_disable_dp;
> + intel_encoder->post_pll_disable = g4x_dp_post_pll_disable;
> } else {
> + intel_encoder->pre_pll_enable = g4x_dp_pre_pll_enable;
> intel_encoder->pre_enable = g4x_pre_enable_dp;
> intel_encoder->enable = g4x_enable_dp;
> intel_encoder->disable = g4x_disable_dp;
> intel_encoder->post_disable = g4x_post_disable_dp;
> + intel_encoder->post_pll_disable = g4x_dp_post_pll_disable;
> }
> intel_encoder->audio_enable = g4x_dp_audio_enable;
> intel_encoder->audio_disable = g4x_dp_audio_disable; diff --git
> a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 922194b957be2..aa6e7da08fbce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -54,6 +54,7 @@
> #include "intel_dp_aux.h"
> #include "intel_dp_link_training.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_dsi.h"
> #include "intel_fdi.h"
> @@ -3141,6 +3142,9 @@ static void intel_ddi_post_pll_disable(struct
> intel_atomic_state *state,
>
>
RE: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state computation
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state
> computation
>
> Compute the BW required through a DP tunnel on links with such tunnels
> detected and add the corresponding atomic state during a modeset.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 +
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 78dfe8be6031d..6968fdb7ffcdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2880,6 +2880,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
> struct drm_connector_state *conn_state) {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> +to_intel_atomic_state(conn_state->state);
> struct drm_display_mode *adjusted_mode = _config-
> >hw.adjusted_mode;
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> const struct drm_display_mode *fixed_mode; @@ -2980,6 +2981,9 @@
> intel_dp_compute_config(struct intel_encoder *encoder,
> intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
> intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config,
> conn_state);
>
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> + pipe_config);
> +
> return 0;
> }
>
> @@ -6087,6 +6091,15 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> return ret;
> }
>
> + if (!intel_connector_needs_modeset(state, conn))
> + return 0;
> +
> + ret = intel_dp_tunnel_atomic_check_state(state,
> + intel_dp,
> + intel_conn);
> + if (ret)
> + return ret;
> +
> /*
>* We don't enable port sync on BDW due to missing w/as and
>* due to not having adjusted the modeset sequence appropriately.
> @@ -6094,9 +6107,6 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> if (DISPLAY_VER(dev_priv) < 9)
> return 0;
>
> - if (!intel_connector_needs_modeset(state, conn))
> - return 0;
> -
> if (conn->has_tile) {
> ret = intel_modeset_tile_group(state, conn->tile_group->id);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 520393dc8b453..cbfab3173b9ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -42,6 +42,7 @@
> #include "intel_dp.h"
> #include "intel_dp_hdcp.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_hdcp.h"
> #include "intel_hotplug.h"
> @@ -523,6 +524,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> struct drm_connector_state *conn_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_atomic_state *state =
> +to_intel_atomic_state(conn_state->state);
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_dp *intel_dp = _mst->primary->dp;
> const struct intel_connector *connector = @@ -619,6 +621,9 @@ static
> int intel_dp_mst_compute_config(struct intel_encoder *encoder,
>
> intel_psr_compute_config(intel_dp, pipe_config, conn_state);
>
> + intel_dp_tunnel_atomic_compute_stream_bw(state, intel_dp, connector,
> + pipe_config);
> +
> return 0;
> }
>
> @@ -876,6 +881,14 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> if (ret)
> return ret;
>
> + if (intel_connector_needs_modeset(state, connector)) {
> + ret = intel_dp_tunnel_atomic_check_state(state,
> + intel_connector-
> >mst_port,
> + intel_connector);
> + if (ret)
> + return ret;
> + }
> +
> return drm_dp_atomic_release_time_slots(>base,
> _connector->mst_port-
> >mst_mgr,
> intel_connector->port);
> --
> 2.39.2
RE: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in intel_dp_max_link_data_rate()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in
> intel_dp_max_link_data_rate()
>
> Take any link BW limitation into account in intel_dp_max_link_data_rate().
> Such a
> limitation can be due to multiple displays on (Thunderbolt) links with DP
> tunnels
> sharing the link BW.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 323475569ee7f..78dfe8be6031d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -63,6 +63,7 @@
> #include "intel_dp_hdcp.h"
> #include "intel_dp_link_training.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpio_phy.h"
> #include "intel_dpll.h"
> #include "intel_fifo_underrun.h"
> @@ -152,6 +153,22 @@ int intel_dp_link_symbol_clock(int rate)
> return DIV_ROUND_CLOSEST(rate * 10, intel_dp_link_symbol_size(rate));
> }
>
> +static int max_dprx_rate(struct intel_dp *intel_dp) {
> + if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + return drm_dp_tunnel_max_dprx_rate(intel_dp->tunnel);
> +
> + return drm_dp_bw_code_to_link_rate(intel_dp-
> >dpcd[DP_MAX_LINK_RATE]);
> +}
> +
> +static int max_dprx_lane_count(struct intel_dp *intel_dp) {
> + if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + return drm_dp_tunnel_max_dprx_lane_count(intel_dp->tunnel);
> +
> + return drm_dp_max_lane_count(intel_dp->dpcd);
> +}
> +
> static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp) {
> intel_dp->sink_rates[0] = 162000;
> @@ -180,7 +197,7 @@ static void intel_dp_set_dpcd_sink_rates(struct intel_dp
> *intel_dp)
> /*
>* Sink rates for 8b/10b.
>*/
> - max_rate = drm_dp_bw_code_to_link_rate(intel_dp-
> >dpcd[DP_MAX_LINK_RATE]);
> + max_rate = max_dprx_rate(intel_dp);
> max_lttpr_rate = drm_dp_lttpr_max_link_rate(intel_dp-
> >lttpr_common_caps);
> if (max_lttpr_rate)
> max_rate = min(max_rate, max_lttpr_rate); @@ -259,7 +276,7
> @@ static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = _dig_port->base;
>
> - intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp-
> >dpcd);
> + intel_dp->max_sink_lane_count = max_dprx_lane_count(intel_dp);
>
> switch (intel_dp->max_sink_lane_count) {
> case 1:
> @@ -389,14 +406,21 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
> * @max_dprx_rate: Maximum data rate of the DPRX
> * @max_dprx_lanes: Maximum lane count of the DPRX
> *
> - * Calculate the maximum data rate for the provided link parameters.
> + * Calculate the maximum data rate for the provided link parameters
> + taking into
> + * account any BW limitations by a DP tunnel attached to @intel_dp.
> *
> * Returns the maximum data rate in kBps units.
> */
> int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> int max_dprx_rate, int max_dprx_lanes) {
> - return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes);
> + int max_rate = drm_dp_max_dprx_data_rate(max_dprx_rate,
> +max_dprx_lanes);
> +
> + if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
> + max_rate = min(max_rate,
> +drm_dp_tunnel_available_bw(intel_dp->tunnel));
> +
> + return max_rate;
> }
>
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
> --
> 2.39.2
RE: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()
>
> Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX BW used
> by a follow-up patch enabling the DP tunnel BW allocation mode.
> The link BW can be below the DPRX BW due to a BW limitation on a link shared
> by multiple sinks.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
> 3 files changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 23434d0aba188..9cd675c6d0ee8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -383,6 +383,22 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
> 100 * 16 * 8);
> }
>
> +/**
> + * intel_dp_max_link_data_rate: Calculate the maximum rate for the
> +given link params
> + * @intel_dp: Intel DP object
> + * @max_dprx_rate: Maximum data rate of the DPRX
> + * @max_dprx_lanes: Maximum lane count of the DPRX
> + *
> + * Calculate the maximum data rate for the provided link parameters.
> + *
> + * Returns the maximum data rate in kBps units.
> + */
> +int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> + int max_dprx_rate, int max_dprx_lanes) {
> + return drm_dp_max_dprx_data_rate(max_dprx_rate, max_dprx_lanes); }
> +
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp) {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); @@
> -612,7 +628,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
> intel_dp *intel_dp,
> int mode_rate, max_rate;
>
> mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> - max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
> + max_rate = intel_dp_max_link_data_rate(intel_dp, link_rate,
> +lane_count);
> if (mode_rate > max_rate)
> return false;
>
> @@ -1214,7 +1230,8 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> max_lanes = intel_dp_max_lane_count(intel_dp);
>
> - max_rate = drm_dp_max_dprx_data_rate(max_link_clock, max_lanes);
> + max_rate = intel_dp_max_link_data_rate(intel_dp, max_link_clock,
> +max_lanes);
> +
> mode_rate = intel_dp_link_required(target_clock,
>
> intel_dp_mode_min_output_bpp(connector, mode));
>
> @@ -1564,8 +1581,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> for (lane_count = limits->min_lane_count;
>lane_count <= limits->max_lane_count;
>lane_count <<= 1) {
> - link_avail =
> drm_dp_max_dprx_data_rate(link_rate,
> -
> lane_count);
> + link_avail =
> intel_dp_max_link_data_rate(intel_dp,
> +
> link_rate,
> +
> lane_count);
> +
>
> if (mode_rate <= link_avail) {
> pipe_config->lane_count = lane_count;
> @@ -2422,8 +2441,9 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> pipe_config->pipe_bpp,
> BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
> intel_dp_config_required_rate(pipe_config),
> - drm_dp_max_dprx_data_rate(pipe_config->port_clock,
> - pipe_config->lane_count));
> + intel_dp_max_link_data_rate(intel_dp,
> + pipe_config->port_clock,
> + pipe_config->lane_count));
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 49553e43add22..8b0dfbf06afff 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -117,6 +117,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp
> *intel_dp); int intel_dp_link_required(int pixel_clock, int bpp); int
> intel_dp_effective_data_rate(int pixel_clock, int bpp_x16,
>int bw_overhead);
> +int intel_dp_max_link_data_rate(struct intel_dp *intel_dp,
> + int max_dprx_rate, int max_dprx_lanes);
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp); bool
> intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state); diff
> --
> git
RE: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
>
> Factor out a function to read the sink's DPRX capabilities used by a follow-up
> patch enabling the DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 30 +++
> .../drm/i915/display/intel_dp_link_training.h | 1 +
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 7b140cbf8dd31..fb84ca98bb7ab 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -162,6 +162,28 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp,
> const u8 dpcd[DP_RECEI
> return lttpr_count;
> }
>
> +int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8
> +dpcd[DP_RECEIVER_CAP_SIZE]) {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (intel_dp_is_edp(intel_dp))
> + return 0;
> +
> + /*
> + * Detecting LTTPRs must be avoided on platforms with an AUX timeout
> + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> + */
> + if (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))
> + if (drm_dp_dpcd_probe(_dp->aux,
> +
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> + return -EIO;
> +
> + if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
> + return -EIO;
> +
> + return 0;
> +}
> +
> /**
> * intel_dp_init_lttpr_and_dprx_caps - detect LTTPR and DPRX caps, init the
> LTTPR link training mode
> * @intel_dp: Intel DP struct
> @@ -192,12 +214,10 @@ int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp
> *intel_dp)
> if (!intel_dp_is_edp(intel_dp) &&
> (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> + int err = intel_dp_read_dprx_caps(intel_dp, dpcd);
>
> - if (drm_dp_dpcd_probe(_dp->aux,
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> - return -EIO;
> -
> - if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
> - return -EIO;
> + if (err != 0)
> + return err;
>
> lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index 2c8f2775891b0..19836a8a4f904 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -11,6 +11,7 @@
> struct intel_crtc_state;
> struct intel_dp;
>
> +int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8
> +dpcd[DP_RECEIVER_CAP_SIZE]);
> int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp);
>
> void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> --
> 2.39.2
RE: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()
>
> Factor out a function updating the sink's link rate and lane count
> capabilities, used
> by a follow-up patch enabling the DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f40706c5d1aad..23434d0aba188 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3949,6 +3949,13 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> _dp->desc);
> }
>
> +void intel_dp_update_sink_caps(struct intel_dp *intel_dp) {
> + intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
> + intel_dp_set_common_rates(intel_dp);
> +}
> +
> static bool
> intel_dp_get_dpcd(struct intel_dp *intel_dp) { @@ -3965,9 +3972,7 @@
> intel_dp_get_dpcd(struct intel_dp *intel_dp)
> drm_dp_read_desc(_dp->aux, _dp->desc,
>drm_dp_is_branch(intel_dp->dpcd));
>
> - intel_dp_set_sink_rates(intel_dp);
> - intel_dp_set_max_sink_lane_count(intel_dp);
> - intel_dp_set_common_rates(intel_dp);
> + intel_dp_update_sink_caps(intel_dp);
> }
>
> if (intel_dp_has_sink_count(intel_dp)) { diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index a7906d8738c4a..49553e43add22 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -106,6 +106,7 @@ int intel_dp_config_required_rate(const struct
> intel_crtc_state *crtc_state); int intel_dp_rate_select(struct intel_dp
> *intel_dp,
> int rate); int intel_dp_max_common_rate(struct intel_dp *intel_dp); int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
> +void intel_dp_update_sink_caps(struct intel_dp *intel_dp);
>
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> u8 *link_bw, u8 *rate_select);
> --
> 2.39.2
RE: [PATCH 06/19] drm/i915/dp: Export intel_dp_max_common_rate/lane_count()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 06/19] drm/i915/dp: Export
> intel_dp_max_common_rate/lane_count()
>
> Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by a
> follow-up patch enabling the DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a5c60428ffb7..f40706c5d1aad 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -309,7 +309,7 @@ static int intel_dp_common_rate(struct intel_dp
> *intel_dp, int index) }
>
> /* Theoretical max between source and sink */ -static int
> intel_dp_max_common_rate(struct intel_dp *intel_dp)
> +int intel_dp_max_common_rate(struct intel_dp *intel_dp)
> {
> return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates -
> 1); } @@ -326,7 +326,7 @@ static int intel_dp_max_source_lane_count(struct
> intel_digital_port *dig_port) }
>
> /* Theoretical max between source and sink */ -static int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
> +int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> int source_max = intel_dp_max_source_lane_count(dig_port);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 37274e3c2902f..a7906d8738c4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -104,6 +104,8 @@ int intel_dp_max_link_rate(struct intel_dp *intel_dp);
> int
> intel_dp_max_lane_count(struct intel_dp *intel_dp); int
> intel_dp_config_required_rate(const struct intel_crtc_state *crtc_state); int
> intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
> +int intel_dp_max_common_rate(struct intel_dp *intel_dp); int
> +intel_dp_max_common_lane_count(struct intel_dp *intel_dp);
>
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> u8 *link_bw, u8 *rate_select);
> --
> 2.39.2
RE: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()
>
> Factor out intel_dp_config_required_rate() used by a follow-up patch enabling
> the
> DP tunnel BW allocation mode.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> 2 files changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c7b06a9b197cc..0a5c60428ffb7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2338,6 +2338,17 @@ intel_dp_compute_config_limits(struct intel_dp
> *intel_dp,
> limits);
> }
>
> +int intel_dp_config_required_rate(const struct intel_crtc_state
> +*crtc_state) {
> + const struct drm_display_mode *adjusted_mode =
> + _state->hw.adjusted_mode;
> + int bpp = crtc_state->dsc.compression_enable ?
> + to_bpp_int_roundup(crtc_state->dsc.compressed_bpp_x16) :
> + crtc_state->pipe_bpp;
> +
> + return intel_dp_link_required(adjusted_mode->crtc_clock, bpp); }
> +
> static int
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config, @@ -2405,31
> +2416,15 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
> return ret;
> }
>
> - if (pipe_config->dsc.compression_enable) {
> - drm_dbg_kms(>drm,
> - "DP lane count %d clock %d Input bpp %d Compressed
> bpp " BPP_X16_FMT "\n",
> - pipe_config->lane_count, pipe_config->port_clock,
> - pipe_config->pipe_bpp,
> - BPP_X16_ARGS(pipe_config-
> >dsc.compressed_bpp_x16));
> + drm_dbg_kms(>drm,
> + "DP lane count %d clock %d bpp input %d compressed "
> BPP_X16_FMT " link rate required %d available %d\n",
> + pipe_config->lane_count, pipe_config->port_clock,
> + pipe_config->pipe_bpp,
> + BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
> + intel_dp_config_required_rate(pipe_config),
> + drm_dp_max_dprx_data_rate(pipe_config->port_clock,
> + pipe_config->lane_count));
>
> - drm_dbg_kms(>drm,
> - "DP link rate required %i available %i\n",
> - intel_dp_link_required(adjusted_mode->crtc_clock,
> -
> to_bpp_int_roundup(pipe_config->dsc.compressed_bpp_x16)),
> - drm_dp_max_dprx_data_rate(pipe_config-
> >port_clock,
> - pipe_config->lane_count));
> - } else {
> - drm_dbg_kms(>drm, "DP lane count %d clock %d bpp
> %d\n",
> - pipe_config->lane_count, pipe_config->port_clock,
> - pipe_config->pipe_bpp);
> -
> - drm_dbg_kms(>drm,
> - "DP link rate required %i available %i\n",
> - intel_dp_link_required(adjusted_mode->crtc_clock,
> -pipe_config->pipe_bpp),
> - drm_dp_max_dprx_data_rate(pipe_config-
> >port_clock,
> - pipe_config->lane_count));
> - }
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 46f79747f807d..37274e3c2902f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -102,6 +102,7 @@ void intel_dp_mst_suspend(struct drm_i915_private
> *dev_priv); void intel_dp_mst_resume(struct drm_i915_private *dev_priv); int
> intel_dp_max_link_rate(struct intel_dp *intel_dp); int
> intel_dp_max_lane_count(struct intel_dp *intel_dp);
> +int intel_dp_config_required_rate(const struct intel_crtc_state
> +*crtc_state);
> int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
>
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> --
> 2.39.2
RE: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
>
> Instead of intel_dp_max_data_rate() use the equivalent
> drm_dp_max_dprx_data_rate() which was copied from the former one in a
> previous patch.
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 62 +++-
> drivers/gpu/drm/i915/display/intel_dp.h | 1 -
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> 4 files changed, 10 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0caebbb3e2dbb..b9f985a5e705b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2478,7 +2478,7 @@ intel_link_compute_m_n(u16 bits_per_pixel_x16, int
> nlanes,
> u32 link_symbol_clock = intel_dp_link_symbol_clock(link_clock);
> u32 data_m = intel_dp_effective_data_rate(pixel_clock,
> bits_per_pixel_x16,
> bw_overhead);
> - u32 data_n = intel_dp_max_data_rate(link_clock, nlanes);
> + u32 data_n = drm_dp_max_dprx_data_rate(link_clock, nlanes);
>
> /*
>* Windows/BIOS uses fixed M/N values always. Follow suit.
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4e36c2c39888e..c7b06a9b197cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -383,52 +383,6 @@ int intel_dp_effective_data_rate(int pixel_clock, int
> bpp_x16,
> 100 * 16 * 8);
> }
>
> -/*
> - * Given a link rate and lanes, get the data bandwidth.
> - *
> - * Data bandwidth is the actual payload rate, which depends on the data
> - * bandwidth efficiency and the link rate.
> - *
> - * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth
> efficiency
> - * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80 * (1/8) =
> - * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol clock. Just by
> - * coincidence, the port clock in kHz matches the data bandwidth in kBps, and
> - * they equal the link bit rate in Gbps multiplied by 10. (Note that
> this no
> - * longer holds for data bandwidth as soon as FEC or MST is taken into
> account!)
> - *
> - * For 128b/132b channel encoding, the data bandwidth efficiency is 96.71%.
> For
> - * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) = 1208875
> - * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The value
> 100
> - * does not match the symbol clock, the port clock (not even if you think in
> - * terms of a byte clock), nor the data bandwidth. It only matches the link
> bit
> - * rate in units of 1 bps.
> - */
> -int
> -intel_dp_max_data_rate(int max_link_rate, int max_lanes) -{
> - int ch_coding_efficiency =
> -
> drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_
> rate));
> - int max_link_rate_kbps = max_link_rate * 10;
> -
> - /*
> - * UHBR rates always use 128b/132b channel encoding, and have
> - * 97.71% data bandwidth efficiency. Consider max_link_rate the
> - * link bit rate in units of 1 bps.
> - */
> - /*
> - * Lower than UHBR rates always use 8b/10b channel encoding, and have
> - * 80% data bandwidth efficiency for SST non-FEC. However, this turns
> - * out to be a nop by coincidence:
> - *
> - * int max_link_rate_kbps = max_link_rate * 10;
> - * max_link_rate_kbps =
> DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 10);
> - * max_link_rate = max_link_rate_kbps / 8;
> - */
> - return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate_kbps *
> max_lanes,
> - ch_coding_efficiency),
> - 100 * 8);
> -}
> -
> bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp) {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); @@
> -658,7 +612,7 @@ static bool intel_dp_can_link_train_fallback_for_edp(struct
> intel_dp *intel_dp,
> int mode_rate, max_rate;
>
> mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> - max_rate = intel_dp_max_data_rate(link_rate, lane_count);
> + max_rate = drm_dp_max_dprx_data_rate(link_rate, lane_count);
> if (mode_rate > max_rate)
> return false;
>
> @@ -1260,7 +1214,7 @@ intel_dp_mode_valid(struct drm_connector
> *_connector,
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> max_lanes = intel_dp_max_lane_count(intel_dp);
>
> - max_rate =
RE: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Friday, January 26, 2024 6:58 PM
> To: Ville Syrjälä
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()
>
> On Fri, Jan 26, 2024 at 01:36:02PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:32PM +0200, Imre Deak wrote:
> > > Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
> > > follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
> > > supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
> > > clarity. This patchset will also switch calling the new DRM function
> > > in i915 instead of intel_dp_max_data_rate().
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/display/drm_dp_helper.c | 58
> +
> > > include/drm/display/drm_dp_helper.h | 2 +
> > > 2 files changed, 60 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > > b/drivers/gpu/drm/display/drm_dp_helper.c
> > > index b1ca3a1100dab..24911243d4d3a 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > > @@ -4058,3 +4058,61 @@ int drm_dp_bw_channel_coding_efficiency(bool
> is_uhbr)
> > > return 80;
> > > }
> > > EXPORT_SYMBOL(drm_dp_bw_channel_coding_efficiency);
> > > +
> > > +/*
> > > + * Given a link rate and lanes, get the data bandwidth.
> > > + *
> > > + * Data bandwidth is the actual payload rate, which depends on the
> > > +data
> > > + * bandwidth efficiency and the link rate.
> > > + *
> > > + * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth
> > > +efficiency
> > > + * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80
> > > +* (1/8) =
> > > + * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol
> > > +clock. Just by
> > > + * coincidence, the port clock in kHz matches the data bandwidth in
> > > +kBps, and
> > > + * they equal the link bit rate in Gbps multiplied by 10. (Note
> > > +that this no
> > > + * longer holds for data bandwidth as soon as FEC or MST is taken
> > > +into account!)
> > > + *
> > > + * For 128b/132b channel encoding, the data bandwidth efficiency is
> > > +96.71%. For
> > > + * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) =
> > > +1208875
> > > + * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The
> > > +value 100
> > > + * does not match the symbol clock, the port clock (not even if you
> > > +think in
> > > + * terms of a byte clock), nor the data bandwidth. It only matches
> > > +the link bit
> > > + * rate in units of 1 bps.
> > > + *
> > > + * Note that protocol layers above the DPRX link level considered
> > > +here can
> > > + * further limit the maximum data rate. Such layers are the MST
> > > +topology (with
> > > + * limits on the link between the source and first branch device as
> > > +well as on
> > > + * the whole MST path until the DPRX link) and (Thunderbolt) DP
> > > +tunnels -
> > > + * which in turn can encapsulate an MST link with its own limit -
> > > +with each
> > > + * SST or MST encapsulated tunnel sharing the BW of a tunnel group.
> > > + *
> > > + * TODO: Add support for querying the max data rate with the above
> > > +limits as
> > > + * well.
> > > + *
> > > + * Returns the maximum data rate in kBps units.
> > > + */
> > > +int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes) {
> > > + int ch_coding_efficiency =
> > > +
> drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_
> rate));
> > > + int max_link_rate_kbps = max_link_rate * 10;
> >
> > That x10 value seems rather pointless.
>
> I suppose the point was to make the units clearer, but it could be clarified
> instead
> in max_link_rates' documentation, which is missing atm.
>
> > > +
> > > + /*
> > > + * UHBR rates always use 128b/132b channel encoding, and have
> > > + * 97.71% data bandwidth efficiency. Consider max_link_rate the
> > > + * link bit rate in units of 1 bps.
> > > + */
> > > + /*
> > > + * Lower than UHBR rates always use 8b/10b channel encoding, and have
> > > + * 80% data bandwidth efficiency for SST non-FEC. However, this turns
> > > + * out to be a nop by coincidence:
> > > + *
> > > + * int max_link_rate_kbps = max_link_rate * 10;
> > > + * max_link_rate_kbps =
> DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 10);
> > > + * max_link_rate = max_link_rate_kbps / 8;
> > > + */
> >
> > Not sure why we are repeating the nuts and bolts detils in the
> > comments so much? Doesn't drm_dp_bw_channel_coding_efficiency()
> > explain all this already?
>
> I simply copied the function, but yes in this context there is duplication,
> thanks for
> reading through all that. Will consolidate both the above and the bigger
> comment
> before the function with the existing docs here.
Changes look good to me.
RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
> -Original Message-
> From: Pekka Paalanen
> Sent: Thursday, November 9, 2023 5:26 PM
> To: Shankar, Uma
> Cc: Joshua Ashton ; Harry Wentland
> ; dri-devel@lists.freedesktop.org; Sebastian Wick
> ; Sasha McIntosh ;
> Abhinav Kumar ; Shashank Sharma
> ; Xaver Hugl ; Hector
> Martin ; Liviu Dudau ; Alexander
> Goins ; Michel Dänzer ; wayland-
> de...@lists.freedesktop.org; Melissa Wen ; Jonas Ådahl
> ; Arthur Grillo ; Victoria
> Brekenfeld ; Sima ; Aleix Pol
> ; Naseer Ahmed ; Christopher
> Braga ; Ville Syrjala
> Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color
> pipeline is needed
>
> On Thu, 9 Nov 2023 10:17:11 +
> "Shankar, Uma" wrote:
>
> > > -Original Message-
> > > From: Joshua Ashton
> > > Sent: Wednesday, November 8, 2023 7:13 PM
> > > To: Shankar, Uma ; Harry Wentland
> > > ; dri-devel@lists.freedesktop.org
>
> ...
>
> > > Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why
> > > prescriptive color pipeline is needed
> > >
> > >
> > >
> > > On 11/8/23 12:18, Shankar, Uma wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Harry Wentland
> > > >> Sent: Friday, October 20, 2023 2:51 AM
> > > >> To: dri-devel@lists.freedesktop.org
>
> ...
>
> > > >> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why
> > > >> prescriptive color pipeline is needed
>
> ...
>
> > > >> +An example of a drm_colorop object might look like one of these::
> > > >> +
> > > >> +/* 1D enumerated curve */
> > > >> +Color operation 42
> > > >> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3
> > > >> + matrix, 3x4
> > > >> matrix, 3D LUT, etc.} = 1D enumerated curve
> > > >> +├─ "BYPASS": bool {true, false}
> > > >> +├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ
> > > >> + EOTF, PQ
> > > >> inverse EOTF, …}
> > > >
> > > > Having the fixed function enum for some targeted input/output may
> > > > not be scalable for all usecases. There are multiple colorspaces
> > > > and transfer functions possible, so it will not be possible to
> > > > cover all these by any enum definitions. Also, this will depend on
> > > > the capabilities of
> > > respective hardware from various vendors.
> > >
> > > The reason this exists is such that certain HW vendors such as AMD
> > > have transfer functions implemented in HW. It is important to take
> > > advantage of these for both precision and power reasons.
> >
> > Issue we see here is that, it will be too usecase and vendor specific.
> > There will be BT601, BT709, BT2020, SRGB, HDR EOTF and many more. Not
> > to forget we will need linearization and non-linearization enums for each of
> these.
>
> I don't see that as a problem at all. It's not a combinatorial explosion like
> input/output combinations in a single enum would be.
> It's always a curve and its inverse at most.
>
> It's KMS properties, not every driver needs to implement every defined enum
> value but only those values it can and wants to support.
> Userspace also sees the supported list, it does not need trial and error.
>
> This is the only way to actually use hard-wired curves. The alternative would
> be
> for userspace to submit a LUT of some type, and the driver needs to start
> guessing if it matches one of the hard-wired curves the hardware supports,
> which
> is just not feasible.
>
> Hard-wired curves are an addition, not a replacement, to custom curves defined
> by parameters or various different LUT representations.
> Many of these hard-wired curves will emerge as is from common use cases.
Point taken, we can go with this fixed function curve types as long as it
represents a
single mathematical operation, thereby avoiding the combination nightmare.
However, just want to make sure that the same thing can be done with a
programmable
hardware. In the case above, lut tables for the same need to be hardcoded in
driver for
various platforms (depending on its capabilities, precision, number, and
distribution of luts etc).
This is manageable, but driver will get bloated with all kinds of hardcoded lut
tables,
which could have been easily computed by the compositor runtime. Driver cannot
compute
the tables runtime due to the complexity of the floating math involved, so
hardcod
RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
> -Original Message- > From: Harry Wentland > Sent: Wednesday, November 8, 2023 8:08 PM > To: Shankar, Uma ; dri-devel@lists.freedesktop.org > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > ; Pekka Paalanen > ; Simon Ser ; Melissa > Wen ; Jonas Ådahl ; Sebastian Wick > ; Shashank Sharma > ; Alexander Goins ; Joshua > Ashton ; Michel Dänzer ; Aleix Pol > ; Xaver Hugl ; Victoria Brekenfeld > ; Sima ; Naseer Ahmed > ; Christopher Braga ; > Abhinav Kumar ; Arthur Grillo > ; Hector Martin ; Liviu Dudau > ; Sasha McIntosh > Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color > pipeline is needed > > > > On 2023-11-08 07:18, Shankar, Uma wrote: > > > > > >> -Original Message- > >> From: Harry Wentland > >> Sent: Friday, October 20, 2023 2:51 AM > >> To: dri-devel@lists.freedesktop.org > >> Cc: wayland-de...@lists.freedesktop.org; Harry Wentland > >> ; Ville Syrjala > >> ; Pekka Paalanen > >> ; Simon Ser ; > >> Melissa Wen ; Jonas Ådahl ; > >> Sebastian Wick ; Shashank Sharma > >> ; Alexander Goins ; > >> Joshua Ashton ; Michel Dänzer > >> ; Aleix Pol ; Xaver Hugl > >> ; Victoria Brekenfeld ; > >> Sima ; Shankar, Uma ; Naseer > >> Ahmed ; Christopher Braga > >> ; Abhinav Kumar ; > >> Arthur Grillo ; Hector Martin > >> ; Liviu Dudau ; Sasha McIntosh > >> > >> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive > >> color pipeline is needed > >> > >> v2: > >> - Update colorop visualizations to match reality (Sebastian, Alex > >> Hung) > >> - Updated wording (Pekka) > >> - Change BYPASS wording to make it non-mandatory (Sebastian) > >> - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property > >>section (Pekka) > >> - Use PQ EOTF instead of its inverse in Pipeline Programming example > >> (Melissa) > >> - Add "Driver Implementer's Guide" section (Pekka) > >> - Add "Driver Forward/Backward Compatibility" section (Sebastian, > >> Pekka) > >> > >> Signed-off-by: Harry Wentland > >> Cc: Ville Syrjala > >> Cc: Pekka Paalanen > >> Cc: Simon Ser > >> Cc: Harry Wentland > >> Cc: Melissa Wen > >> Cc: Jonas Ådahl > >> Cc: Sebastian Wick > >> Cc: Shashank Sharma > >> Cc: Alexander Goins > >> Cc: Joshua Ashton > >> Cc: Michel Dänzer > >> Cc: Aleix Pol > >> Cc: Xaver Hugl > >> Cc: Victoria Brekenfeld > >> Cc: Sima > >> Cc: Uma Shankar > >> Cc: Naseer Ahmed > >> Cc: Christopher Braga > >> Cc: Abhinav Kumar > >> Cc: Arthur Grillo > >> Cc: Hector Martin > >> Cc: Liviu Dudau > >> Cc: Sasha McIntosh > >> --- > >> Documentation/gpu/rfc/color_pipeline.rst | 347 > >> +++ > >> 1 file changed, 347 insertions(+) > >> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst > >> > >> diff --git a/Documentation/gpu/rfc/color_pipeline.rst > >> b/Documentation/gpu/rfc/color_pipeline.rst > >> new file mode 100644 > >> index ..af5f2ea29116 > >> --- /dev/null > >> +++ b/Documentation/gpu/rfc/color_pipeline.rst > >> @@ -0,0 +1,347 @@ > >> + > >> +Linux Color Pipeline API > >> + > >> + > >> +What problem are we solving? > >> + > >> + > >> +We would like to support pre-, and post-blending complex color > >> +transformations in display controller hardware in order to allow for > >> +HW-supported HDR use-cases, as well as to provide support to > >> +color-managed applications, such as video or image editors. > >> + > >> +It is possible to support an HDR output on HW supporting the > >> +Colorspace and HDR Metadata drm_connector properties, but that > >> +requires the compositor or application to render and compose the > >> +content into one final buffer intended for display. Doing so is costly. > >> + > >> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, > >> +and other operations to support color transformations. These > >> +operations are often implemented in fixed-function HW and therefore > >> +much more power efficient than performing similar operations via
RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
> -Original Message- > From: Joshua Ashton > Sent: Wednesday, November 8, 2023 7:13 PM > To: Shankar, Uma ; Harry Wentland > ; dri-devel@lists.freedesktop.org > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > ; Pekka Paalanen > ; Simon Ser ; Melissa > Wen ; Jonas Ådahl ; Sebastian Wick > ; Shashank Sharma > ; Alexander Goins ; Michel > Dänzer ; Aleix Pol ; Xaver Hugl > ; Victoria Brekenfeld ; Sima > ; Naseer Ahmed ; Christopher > Braga ; Abhinav Kumar > ; Arthur Grillo ; Hector > Martin ; Liviu Dudau ; Sasha > McIntosh > Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color > pipeline is needed > > > > On 11/8/23 12:18, Shankar, Uma wrote: > > > > > >> -Original Message- > >> From: Harry Wentland > >> Sent: Friday, October 20, 2023 2:51 AM > >> To: dri-devel@lists.freedesktop.org > >> Cc: wayland-de...@lists.freedesktop.org; Harry Wentland > >> ; Ville Syrjala > >> ; Pekka Paalanen > >> ; Simon Ser ; > >> Melissa Wen ; Jonas Ådahl ; > >> Sebastian Wick ; Shashank Sharma > >> ; Alexander Goins ; > >> Joshua Ashton ; Michel Dänzer > >> ; Aleix Pol ; Xaver Hugl > >> ; Victoria Brekenfeld ; > >> Sima ; Shankar, Uma ; Naseer > >> Ahmed ; Christopher Braga > >> ; Abhinav Kumar ; > >> Arthur Grillo ; Hector Martin > >> ; Liviu Dudau ; Sasha McIntosh > >> > >> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive > >> color pipeline is needed > >> > >> v2: > >> - Update colorop visualizations to match reality (Sebastian, Alex Hung) > >> - Updated wording (Pekka) > >> - Change BYPASS wording to make it non-mandatory (Sebastian) > >> - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property > >> section (Pekka) > >> - Use PQ EOTF instead of its inverse in Pipeline Programming example > (Melissa) > >> - Add "Driver Implementer's Guide" section (Pekka) > >> - Add "Driver Forward/Backward Compatibility" section (Sebastian, > >> Pekka) > >> > >> Signed-off-by: Harry Wentland > >> Cc: Ville Syrjala > >> Cc: Pekka Paalanen > >> Cc: Simon Ser > >> Cc: Harry Wentland > >> Cc: Melissa Wen > >> Cc: Jonas Ådahl > >> Cc: Sebastian Wick > >> Cc: Shashank Sharma > >> Cc: Alexander Goins > >> Cc: Joshua Ashton > >> Cc: Michel Dänzer > >> Cc: Aleix Pol > >> Cc: Xaver Hugl > >> Cc: Victoria Brekenfeld > >> Cc: Sima > >> Cc: Uma Shankar > >> Cc: Naseer Ahmed > >> Cc: Christopher Braga > >> Cc: Abhinav Kumar > >> Cc: Arthur Grillo > >> Cc: Hector Martin > >> Cc: Liviu Dudau > >> Cc: Sasha McIntosh > >> --- > >> Documentation/gpu/rfc/color_pipeline.rst | 347 +++ > >> 1 file changed, 347 insertions(+) > >> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst > >> > >> diff --git a/Documentation/gpu/rfc/color_pipeline.rst > >> b/Documentation/gpu/rfc/color_pipeline.rst > >> new file mode 100644 > >> index ..af5f2ea29116 > >> --- /dev/null > >> +++ b/Documentation/gpu/rfc/color_pipeline.rst > >> @@ -0,0 +1,347 @@ > >> + > >> +Linux Color Pipeline API > >> + > >> + > >> +What problem are we solving? > >> + > >> + > >> +We would like to support pre-, and post-blending complex color > >> +transformations in display controller hardware in order to allow for > >> +HW-supported HDR use-cases, as well as to provide support to > >> +color-managed applications, such as video or image editors. > >> + > >> +It is possible to support an HDR output on HW supporting the > >> +Colorspace and HDR Metadata drm_connector properties, but that > >> +requires the compositor or application to render and compose the > >> +content into one final buffer intended for display. Doing so is costly. > >> + > >> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, > >> +and other operations to support color transformations. These > >> +operations are often implemented in fixed-function HW and therefore > >> +much more power efficient than performing similar operations via shaders > >> or &g
RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
> -Original Message- > From: Harry Wentland > Sent: Friday, October 20, 2023 2:51 AM > To: dri-devel@lists.freedesktop.org > Cc: wayland-de...@lists.freedesktop.org; Harry Wentland > ; Ville Syrjala ; Pekka > Paalanen ; Simon Ser ; > Melissa Wen ; Jonas Ådahl ; Sebastian > Wick ; Shashank Sharma > ; Alexander Goins ; Joshua > Ashton ; Michel Dänzer ; Aleix Pol > ; Xaver Hugl ; Victoria Brekenfeld > ; Sima ; Shankar, Uma > ; Naseer Ahmed ; > Christopher Braga ; Abhinav Kumar > ; Arthur Grillo ; Hector > Martin ; Liviu Dudau ; Sasha > McIntosh > Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color > pipeline is needed > > v2: > - Update colorop visualizations to match reality (Sebastian, Alex Hung) > - Updated wording (Pekka) > - Change BYPASS wording to make it non-mandatory (Sebastian) > - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property >section (Pekka) > - Use PQ EOTF instead of its inverse in Pipeline Programming example > (Melissa) > - Add "Driver Implementer's Guide" section (Pekka) > - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) > > Signed-off-by: Harry Wentland > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Simon Ser > Cc: Harry Wentland > Cc: Melissa Wen > Cc: Jonas Ådahl > Cc: Sebastian Wick > Cc: Shashank Sharma > Cc: Alexander Goins > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Aleix Pol > Cc: Xaver Hugl > Cc: Victoria Brekenfeld > Cc: Sima > Cc: Uma Shankar > Cc: Naseer Ahmed > Cc: Christopher Braga > Cc: Abhinav Kumar > Cc: Arthur Grillo > Cc: Hector Martin > Cc: Liviu Dudau > Cc: Sasha McIntosh > --- > Documentation/gpu/rfc/color_pipeline.rst | 347 +++ > 1 file changed, 347 insertions(+) > create mode 100644 Documentation/gpu/rfc/color_pipeline.rst > > diff --git a/Documentation/gpu/rfc/color_pipeline.rst > b/Documentation/gpu/rfc/color_pipeline.rst > new file mode 100644 > index ..af5f2ea29116 > --- /dev/null > +++ b/Documentation/gpu/rfc/color_pipeline.rst > @@ -0,0 +1,347 @@ > + > +Linux Color Pipeline API > + > + > +What problem are we solving? > + > + > +We would like to support pre-, and post-blending complex color > +transformations in display controller hardware in order to allow for > +HW-supported HDR use-cases, as well as to provide support to > +color-managed applications, such as video or image editors. > + > +It is possible to support an HDR output on HW supporting the Colorspace > +and HDR Metadata drm_connector properties, but that requires the > +compositor or application to render and compose the content into one > +final buffer intended for display. Doing so is costly. > + > +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and > +other operations to support color transformations. These operations are > +often implemented in fixed-function HW and therefore much more power > +efficient than performing similar operations via shaders or CPU. > + > +We would like to make use of this HW functionality to support complex > +color transformations with no, or minimal CPU or shader load. > + > + > +How are other OSes solving this problem? > + > + > +The most widely supported use-cases regard HDR content, whether video > +or gaming. > + > +Most OSes will specify the source content format (color gamut, encoding > +transfer function, and other metadata, such as max and average light levels) > to a > driver. > +Drivers will then program their fixed-function HW accordingly to map > +from a source content buffer's space to a display's space. > + > +When fixed-function HW is not available the compositor will assemble a > +shader to ask the GPU to perform the transformation from the source > +content format to the display's format. > + > +A compositor's mapping function and a driver's mapping function are > +usually entirely separate concepts. On OSes where a HW vendor has no > +insight into closed-source compositor code such a vendor will tune > +their color management code to visually match the compositor's. On > +other OSes, where both mapping functions are open to an implementer they will > ensure both mappings match. > + > +This results in mapping algorithm lock-in, meaning that no-one alone > +can experiment with or introduce new mapping algorithms and achieve > +consistent results regardless of which implementation path is taken. > + > +Why is Linux different? > +=== > + > +Unlike other
RE: [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS
> -Original Message- > From: Harry Wentland > Sent: Friday, October 20, 2023 2:51 AM > To: dri-devel@lists.freedesktop.org > Cc: wayland-de...@lists.freedesktop.org; Harry Wentland > ; Ville Syrjala ; Pekka > Paalanen ; Simon Ser ; > Melissa Wen ; Jonas Ådahl ; Sebastian > Wick ; Shashank Sharma > ; Alexander Goins ; Joshua > Ashton ; Michel Dänzer ; Aleix Pol > ; Xaver Hugl ; Victoria Brekenfeld > ; Sima ; Shankar, Uma > ; Naseer Ahmed ; > Christopher Braga ; Abhinav Kumar > ; Arthur Grillo ; Hector > Martin ; Liviu Dudau ; Sasha > McIntosh > Subject: [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS > > This is an early RFC set for a color pipeline API, along with a sample > implementation in VKMS. All the key API bits are here. > VKMS now supports two named transfer function colorops and we have an IGT > test that confirms that sRGB EOTF, followed by its inverse gives us expected > results within +/- 1 8 bpc codepoint value. > > This patchset is grouped as follows: > - Patches 1-2: couple general patches/fixes > - Patches 3-5: introduce kunit to VKMS > - Patch 6: description of motivation and details behind the > Color Pipeline API. If you're reading nothing else > but are interested in the topic I highly recommend > you take a look at this. > - Patches 7-15: Add core DRM API bits > - Patches 15-17: VKMS implementation > > There are plenty of things that I would like to see here but haven't had a > chance > to look at. These will (hopefully) be addressed in future iterations: > - Abandon IOCTLs and discover colorops as clients iterate the pipeline > - Add color_pipeline client cap and deprecate existing color encoding and >color range properties. >See https://lists.freedesktop.org/archives/dri-devel/2023- > September/422643.html > - Add CTM colorop to VKMS > - Add custom LUT colorops to VKMS > - Add pre-blending 3DLUT with tetrahedral interpolation to VKMS > - How to support HW which can't bypass entire pipeline? > - Add ability to create colorops that don't have BYPASS > - Can we do a LOAD / COMMIT model for LUTs (and other properties)? > > IGT tests can be found at > https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1 > > IGT patches are also being sent to the igt-dev mailing list. > > libdrm changes to support the new IOCTLs are at > https://gitlab.freedesktop.org/hwentland/drm/-/merge_requests/1 > > If you prefer a gitlab MR for review you can find it at > https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5 > > A slightly different approach for a Color Pipeline API was sent by Uma Shankar > and can be found at https://patchwork.freedesktop.org/series/123024/ > > The main difference is that his approach is not introducing a new DRM core > object > but instead exposes color pipelines via blob properties. > There are pros and cons to both approaches. Thanks Harry and all others who have actively contributed to the design and discussions thus far. Due to other commitments, we couldn't participate in XDC this time and also the delay on our part. Our apologies. We looked at the approach and are aligned to go with property-based design, with some suggestions. Will follow in comments in respective patches. We are also in process of trying this for Intel's hardware to identify if any gaps. Regards, Uma Shankar > v2: > - Rebased on drm-misc-next > - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer > - Incorporate feedback in color_pipeline.rst doc > - Add support for sRGB inverse EOTF > - Add 2nd enumerated TF colorop to VKMS > - Fix LUTs and some issues with applying LUTs in VKMS > > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Simon Ser > Cc: Harry Wentland > Cc: Melissa Wen > Cc: Jonas Ådahl > Cc: Sebastian Wick > Cc: Shashank Sharma > Cc: Alexander Goins > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Aleix Pol > Cc: Xaver Hugl > Cc: Victoria Brekenfeld > Cc: Sima > Cc: Uma Shankar > Cc: Naseer Ahmed > Cc: Christopher Braga > Cc: Abhinav Kumar > Cc: Arthur Grillo > Cc: Hector Martin > Cc: Liviu Dudau > Cc: Sasha McIntosh > > Harry Wentland (17): > drm/atomic: Allow get_value for immutable properties on atomic drivers > drm: Don't treat 0 as -1 in drm_fixp2int_ceil > drm/vkms: Create separate Kconfig file for VKMS > drm/vkms: Add kunit tests for VKMS LUT handling > drm/vkms: Avoid reading beyond LUT array > drm/doc/rfc: Describe why prescriptive color pipeline is needed > drm/colorop: Introduce new drm_colorop mode object > drm/colorop: Add TYPE property > drm/color: Add 1D Curve subt
RE: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline
> -Original Message- > From: Christopher Braga > Sent: Friday, September 8, 2023 1:39 AM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: Borah, Chaitanya Kumar ; wayland- > de...@lists.freedesktop.org > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane > Color Pipeline > > > > On 8/29/2023 12:03 PM, Uma Shankar wrote: > > Add the documentation for the new proposed Plane Color Pipeline. > > > > Co-developed-by: Chaitanya Kumar Borah > > > > Signed-off-by: Chaitanya Kumar Borah > > Signed-off-by: Uma Shankar > > --- > > .../gpu/rfc/plane_color_pipeline.rst | 394 ++ > > 1 file changed, 394 insertions(+) > > create mode 100644 Documentation/gpu/rfc/plane_color_pipeline.rst > > > > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst > > b/Documentation/gpu/rfc/plane_color_pipeline.rst > > new file mode 100644 > > index ..60ce515b6ea7 > > --- /dev/null > > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst > > @@ -0,0 +1,394 @@ > > +=== > > + Plane Color Pipeline: A UAPI proposal > > +=== > > + > > +To build the proposal on, lets take the premise of a color pipeline > > +as shown below. > > + > Hi Uma, > Thanks for posting this. A few comments, with some echoing the sentiments of > other commenters on the patch set. Hi Christopher, Thanks for your inputs on the series and my apologies for a late reply. > > + +---+ > > + |RAM| > > + | +--++-++-+ | > > + | | FB 1 || FB 2 || FB N| | > > + | +--++-++-+ | > > + +---+ > > + | Plane Color Hardware Block | > > + ++ > > + | +---v-+ +---v---+ +---v--+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | | Pre-CSC | | Pre-CSC | | Pre-CSC | | > > + | +---+-+ +---+---+ +---+--+ | > > + | | | || > > + | +---v-+ +---v---+ +---v--+ | > > + | |Plane A | | Plane B | | Plane N | | > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + | +---v-+ +v--+ +v-+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | |Post-CSC | | Post-CSC | | Post-CSC | | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + ++ > > ++--v--v---v---| > > +|| || > > +|| Pipe Blender|| > > ++++ > > +||| > > +|+---v--+ | > > +|| Pipe Pre-CSC| | > > +|| | | > > +|+---+--+ | > > +||Pipe Color | > > +|+---v--+ Hardware| > > +|| Pipe CSC/CTM| | > > +|| | | > > +|+---+--+ | > > +||| > > +|+---v--+ | > > +|| Pipe Post-CSC | | > > +|| | | > > +|+---+--+ | > > +||| > > ++-+ > > + | > > + v > > +Pipe Output > > + > > +Each plane consists of the following color blocks > > + * Pre-CSC : This block can used to linearize the input frame buffer data. > > + The linear data then can be further acted on by the following > > + color hardware blocks in the display hardware pipeline > > + > > + * CSC/CTM: Used to program color transformation matrix, this block is used > > +to perform color space conversions like BT2020 to BT709 or > &g
RE: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, September 5, 2023 5:03 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar > ; dri-devel@lists.freedesktop.org; wayland- > de...@lists.freedesktop.org; Harry Wentland ; > Sebastian Wick ; ville.syrj...@linux.intel.com; > Jonas Adahl > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane > Color Pipeline > > On Mon, 4 Sep 2023 13:44:49 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: dri-devel On Behalf > > > Of Pekka Paalanen > > > Sent: Wednesday, August 30, 2023 5:59 PM > > > To: Shankar, Uma > > > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar > > > ; dri-devel@lists.freedesktop.org; > > > wayland- de...@lists.freedesktop.org > > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed > > > Plane Color Pipeline > > > > > > On Wed, 30 Aug 2023 08:59:36 + > > > "Shankar, Uma" wrote: > > > > > > > > -Original Message- > > > > > From: Harry Wentland > > > > > Sent: Wednesday, August 30, 2023 1:10 AM > > > > > To: Shankar, Uma ; > > > > > intel-...@lists.freedesktop.org; dri- > > > > > de...@lists.freedesktop.org > > > > > Cc: Borah, Chaitanya Kumar ; > > > > > wayland- de...@lists.freedesktop.org > > > > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for > > > > > proposed Plane Color Pipeline > > > > > > > > > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > Add the documentation for the new proposed Plane Color Pipeline. > > > > > > > > > > > > Co-developed-by: Chaitanya Kumar Borah > > > > > > > > > > > > Signed-off-by: Chaitanya Kumar Borah > > > > > > > > > > > > Signed-off-by: Uma Shankar > > > > > > --- > > > > > > .../gpu/rfc/plane_color_pipeline.rst | 394 > > > > > > ++ > > > > > > 1 file changed, 394 insertions(+) > > > > > > create mode 100644 > > > > > > Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > > > > > > > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > new file mode 100644 > > > > > > index ..60ce515b6ea7 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > ... > > > > > > Hi Uma! > > > > Thanks Pekka for the feedback and useful inputs. > > Hi Uma, > > sorry to say, but the overall feeling I get from this proposal is that it is > just the > current color related KMS properties wrapped in a pipeline blob. That is not > the > re-design I believe we are looking for, and the feeling is based on several > details > that are just copied from the current property design. Also the "private" > stuff has > to go. Hi Pekka, Ok, got the concerns in general. We will try to evaluate in deeper detail the property based design and come back if there are some issues or inputs. At Intel we don't need private as of now, but we thought of having an option to enable any custom hardware or vendor. But we can drop the same for now if community doesn't feel the need for it. > All the varying LUT entries, varying LUT precision, 1D/3D LUTs, varying LUT > tap > distribution, and parametrized curves are good development, but right now we > are looking at things one step higher level: the overall color pipeline > design and > how to represent any operation. Most of this series is considering details > below > the current attention level, hence I'm paying attention only to the first few > patches. We will need to precisely describe the hardware in userspace. Number of luts, precision, segments etc.., we can't just pass EOTF's as enum from userspace and let driver put hardcoded values to LUT. This will be nothing but an extension of descriptive behaviour. This will be needed as there are multiple colorspaces possible and even LUTS can be used to perform tone mapping. So, we need userspace to be able to program luts directly. This is something we must expose to userspace. We will check if this can be fitted in
RE: [RFC 00/33] Add Support for Plane Color Pipeline
> -Original Message- > From: Sebastian Wick > Sent: Thursday, August 31, 2023 2:46 AM > To: Shankar, Uma > Cc: Harry Wentland ; intel- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; wayland- > de...@lists.freedesktop.org; Ville Syrjala ; > Pekka > Paalanen ; Simon Ser ; > Melissa Wen ; Jonas Ådahl ; Shashank > Sharma ; Alexander Goins ; > Naseer Ahmed ; Christopher Braga > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > -Original Message- > > > From: Harry Wentland > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > To: Shankar, Uma ; > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > > > ; Pekka Paalanen > > > ; Simon Ser ; > > > Melissa Wen ; Jonas Ådahl ; > > > Sebastian Wick ; Shashank Sharma > > > ; Alexander Goins ; > > > Naseer Ahmed ; Christopher Braga > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > +CC Naseer and Chris, FYI > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > Introduction > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > at pre-blending and post-blending phases in the color pipeline. > > > > The current drm implementation exposes only the post-blending > > > > color hardware blocks. Support for pre-blending hardware is missing. > > > > There are multiple use cases where pre-blending color hardware > > > > will be > > > > useful: > > > > a) Linearization of input buffers encoded in various transfer > > > >functions. > > > > b) Color Space conversion > > > > c) Tone mapping > > > > d) Frame buffer format conversion > > > > e) Non-linearization of buffer(apply transfer function) > > > > f) 3D Luts > > > > > > > > and other miscellaneous color operations. > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > hardware to user-space. This will help userspace/middleware to use > > > > display hardware for color processing and blending instead of > > > > doing it through GPU shaders. > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > similar but you beat me to it. :) > > > > Thanks Harry for the useful feedback and overall collaboration on this so > > far. > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the same. > > > > Broad consensus is there that we need a generic API at drm core to > > > > suffice the use case of various HW vendors. Below are the links > > > > capturing the discussion so far. > > > > > > > > Intel's Plane Color Implementation: > > > > https://patchwork.freedesktop.org/series/90825/ > > > > AMD's Plane Color Implementation: > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > industry stakeholders together and converge on a common uapi > expectations. > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > and other prominent user-space developers and maintainers. > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > the same and the path forward. Consensus was made that drm core > > > > should implement descriptive APIs and not go with prescriptive > > > > APIs. DRM core should just expose the hardware capabilities; > > > > enabling, customizing and programming the same should be done by > > > > the user-space. Driver should just > > > honor the user space r
RE: [RFC 02/33] drm: Add color operation structure
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Wednesday, August 30, 2023 6:30 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> ; dri-devel@lists.freedesktop.org; wayland-
> de...@lists.freedesktop.org
> Subject: Re: [RFC 02/33] drm: Add color operation structure
>
> On Tue, 29 Aug 2023 21:33:51 +0530
> Uma Shankar wrote:
>
> > From: Chaitanya Kumar Borah
> >
> > Each Color Hardware block will be represented uniquely in the color
> > pipeline. Define the structure to represent the same.
> >
> > These color operations will form the building blocks of a color
> > pipeline which best represents the underlying Hardware. Color
> > operations can be re-arranged, substracted or added to create distinct
> > color pipelines to accurately describe the Hardware blocks present in
> > the display engine.
> >
> > Co-developed-by: Uma Shankar
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > include/uapi/drm/drm_mode.h | 72
> > +
> > 1 file changed, 72 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index ea1b639bcb28..882479f41745 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -943,6 +943,78 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/**
> > + * enum color_op_block
> > + *
> > + * Enums to identify hardware color blocks.
> > + *
> > + * @DRM_CB_PRE_CSC: LUT before the CTM unit
> > + * @DRM_CB_CSC: CTM hardware supporting 3x3 matrix
> > + * @DRM_CB_POST_CSC: LUT after the CTM unit
> > + * @DRM_CB_3D_LUT: LUT hardware with coefficients for all
> > + * color components
> > + * @DRM_CB_PRIVATE: Vendor specific hardware unit. Vendor
> > + * can expose a custom hardware by defining a
> > + * color operation block with this name as
> > + * identifier
>
> This naming scheme does not seem to work. It assumes a far too rigid pipeline,
> just like the old KMS property design. What if you have two other operations
> between PRE_CSC and CSC?
>
> What sense do PRE_CSC and POST_CSC make if you don't happen to have a CSC
> operation?
Sure, we can re-look at the naming. However, it will be good to define some
standard
operations common to all vendors and keep the rest as vendor private.
> What if a driver put POST_CSC before PRE_CSC in its pipeline?
>
> What if your CSC is actually a series of three independent operations, and in
> addition you have PRE_CSC and POST_CSC?
We should try to standardized the operations as much as possible and leave rest
as
vendor private. Current proposal allows us to do that.
> 3D_LUT is an operation category, not a name. The same could be said about
> private.
Sure, will fix this.
> Given that all these are also UAPI, do we also need protect old userspace from
> seeing values it does not understand?
For the values userspace doesn't understand, it can ignore the blocks. We
should ensure
that userspace always gets a clean state wrt color hardware state and no
baggage from
another client should be there. With that there is no burden of disabling that
particular
block will be there on an older userspace.
> > + */
> > +enum color_op_block {
> > + DRM_CB_INVAL = -1,
> > +
> > + DRM_CB_PRE_CSC = 0,
> > + DRM_CB_CSC,
> > + DRM_CB_POST_CSC,
> > + DRM_CB_3D_LUT,
> > +
> > + /* Any new generic hardware block can be updated here */
> > +
> > + /*
> > +* PRIVATE is kept at 255 to make it future proof and leave
> > +* scope for any new addition
> > +*/
> > + DRM_CB_PRIVATE = 255,
> > + DRM_CB_MAX = DRM_CB_PRIVATE,
> > +};
> > +
> > +/**
> > + * enum color_op_type
> > + *
> > + * These enums are to identify the mathematical operation that
> > + * a hardware block is capable of.
> > + * @CURVE_1D: It represents a one dimensional lookup table
> > + * @CURVE_3D: Represents lut value for each color component for 3d
> > +lut capable hardware
> > + * @MATRIX: It represents co-efficients for a CSC/CTM matrix hardware
> > + * @FIXED_FUNCTION: To enable and program any custom fixed function
> > +hardware unit */ enum color_op_type {
> > + CURVE_1D,
> > + CURVE_3D,
> > + MATRIX,
> > + FIXED_FUNCTION,
>
> My assumption was that a color_op_type would clearly and uniquely define the
> mathematical model of t
RE: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline
> -Original Message- > From: dri-devel On Behalf Of Pekka > Paalanen > Sent: Wednesday, August 30, 2023 5:59 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar > ; dri-devel@lists.freedesktop.org; wayland- > de...@lists.freedesktop.org > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane > Color Pipeline > > On Wed, 30 Aug 2023 08:59:36 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: Harry Wentland > > > Sent: Wednesday, August 30, 2023 1:10 AM > > > To: Shankar, Uma ; > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > Cc: Borah, Chaitanya Kumar ; > > > wayland- de...@lists.freedesktop.org > > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed > > > Plane Color Pipeline > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > Add the documentation for the new proposed Plane Color Pipeline. > > > > > > > > Co-developed-by: Chaitanya Kumar Borah > > > > > > > > Signed-off-by: Chaitanya Kumar Borah > > > > > > > > Signed-off-by: Uma Shankar > > > > --- > > > > .../gpu/rfc/plane_color_pipeline.rst | 394 ++ > > > > 1 file changed, 394 insertions(+) > > > > create mode 100644 > > > > Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > > > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > new file mode 100644 > > > > index ..60ce515b6ea7 > > > > --- /dev/null > > > > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst > > ... > > Hi Uma! Thanks Pekka for the feedback and useful inputs. > > > > +This color pipeline is then packaged within a blob for the user > > > > +space to retrieve it. Details can be found in the next section > > > > + > > > > > > Not sure I like blobs that contain other blob ids. > > > > It provides flexibility and helps with just one interface to > > userspace. Its easy to handle and manage once we get the hang of it . > > > > We can clearly define the steps of parsing and data structures to be > > used while interpreting and parsing the blobs. > > Don't forget extendability. Possibly every single struct will need some kind > of > versioning, and then it's not simple to parse anymore. Add to that new/old > kernel > vs. old/new userspace, and it seems a bit nightmarish to design. Structure to be used to interpret the blob should be defined as UAPI only and is not expected to change once agreed upon. It should be interpreted like a standard property. So structure to be used, say for 3dLut or 1dlut or CTM operations should be standardized and fixed. No versioning of structure should be done and same rules/restrictions as of UAPI property should be applied. New vs old userspace problem exists even today as you rightly highlighted in mail below, however we are planning to propose that we clean the hardware state once the userspace client switches or same client switches the pipeline. > Also since it's records inside a single blob, it's like a new file > format: every record needs a standard header that allows skipping it > appropriately if userspace does not understand it, or you need a standard > index > telling where everything is. Making all records the same size would waste > space, > and extendability requires variable size. The design currently implements 1 hardware block by a struct drm_color_op data structure. Multiple such blocks make the pipeline. So userspace just needs to get the pipeline and then parse blocks 1 by 1. For blocks which it doesn't understand it can just skip and move to the next one. Each block is differentiated by a unique "name" standardized by an enum which will be part of the UAPI. Thus we will have scope for variable size blob to represent the particular hardware pipeline, userspace can parse and implement whichever blocks it understands. Only rule defined by UAPI is the way the respective block is to be parsed and programmed. > I also would not assume that we can declare a standard set of blocks and that > nothing else will be needed. The existing hardware is too diverse for that > from > what I have understood. I assume that some hardware have blocks unique to > them, and they want to at least expose that functionality through a UAPI that > allows at least generic enumeration of functiona
RE: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline
> -Original Message- > From: Harry Wentland > Sent: Wednesday, August 30, 2023 1:10 AM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: Borah, Chaitanya Kumar ; wayland- > de...@lists.freedesktop.org > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane > Color > Pipeline > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > Add the documentation for the new proposed Plane Color Pipeline. > > > > Co-developed-by: Chaitanya Kumar Borah > > > > Signed-off-by: Chaitanya Kumar Borah > > Signed-off-by: Uma Shankar > > --- > > .../gpu/rfc/plane_color_pipeline.rst | 394 ++ > > 1 file changed, 394 insertions(+) > > create mode 100644 Documentation/gpu/rfc/plane_color_pipeline.rst > > > > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst > > b/Documentation/gpu/rfc/plane_color_pipeline.rst > > new file mode 100644 > > index ..60ce515b6ea7 > > --- /dev/null > > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst > > @@ -0,0 +1,394 @@ > > +=== > > + Plane Color Pipeline: A UAPI proposal > > +=== > > + > > +To build the proposal on, lets take the premise of a color pipeline > > +as shown below. > > + > > + +---+ > > + |RAM| > > + | +--++-++-+ | > > + | | FB 1 || FB 2 || FB N| | > > + | +--++-++-+ | > > + +---+ > > + | Plane Color Hardware Block | > > + ++ > > + | +---v-+ +---v---+ +---v--+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | | Pre-CSC | | Pre-CSC | | Pre-CSC | | > > + | +---+-+ +---+---+ +---+--+ | > > + | | | || > > + | +---v-+ +---v---+ +---v--+ | > > + | |Plane A | | Plane B | | Plane N | | > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + | +---v-+ +v--+ +v-+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | |Post-CSC | | Post-CSC | | Post-CSC | | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + ++ > > ++--v--v---v---| > > +|| || > > +|| Pipe Blender|| > > ++++ > > +||| > > +|+---v--+ | > > +|| Pipe Pre-CSC| | > > +|| | | > > +|+---+--+ | > > +||Pipe Color | > > +|+---v--+ Hardware| > > +|| Pipe CSC/CTM| | > > +|| | | > > +|+---+--+ | > > +||| > > +|+---v--+ | > > +|| Pipe Post-CSC | | > > +|| | | > > +|+---+--+ | > > +||| > > ++-+ > > + | > > + v > > +Pipe Output > > + > > +Each plane consists of the following color blocks > > + * Pre-CSC : This block can used to linearize the input frame buffer data. > > + The linear data then can be further acted on by the following > > + color hardware blocks in the display hardware pipeline > > + > > + * CSC/CTM: Used to program color transformation matrix, this block is used > > +to perform color space conversions like BT2020 to BT709 or > > BT601 > > +etc. This block acts on the linearized data coming from the > > +Pre-CSC HW block. > > + > > + * Post-CSC: This HW block can be used to non-linea
RE: [RFC 00/33] Add Support for Plane Color Pipeline
> -Original Message- > From: Harry Wentland > Sent: Wednesday, August 30, 2023 12:56 AM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala > ; Pekka Paalanen > ; > Simon Ser ; Melissa Wen ; Jonas Ådahl > ; Sebastian Wick ; Shashank > Sharma ; Alexander Goins ; > Naseer Ahmed ; Christopher Braga > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > +CC Naseer and Chris, FYI > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > On 2023-08-29 12:03, Uma Shankar wrote: > > Introduction > > > > > > Modern hardwares have various color processing capabilities both at > > pre-blending and post-blending phases in the color pipeline. > > The current drm implementation exposes only the post-blending color > > hardware blocks. Support for pre-blending hardware is missing. > > There are multiple use cases where pre-blending color hardware will be > > useful: > > a) Linearization of input buffers encoded in various transfer > >functions. > > b) Color Space conversion > > c) Tone mapping > > d) Frame buffer format conversion > > e) Non-linearization of buffer(apply transfer function) > > f) 3D Luts > > > > and other miscellaneous color operations. > > > > Hence, there is a need to expose the color capabilities of the > > hardware to user-space. This will help userspace/middleware to use > > display hardware for color processing and blending instead of doing it > > through GPU shaders. > > > > Thanks, Uma, for sending this. I've been working on something similar but you > beat > me to it. :) Thanks Harry for the useful feedback and overall collaboration on this so far. > > > > Work done so far and relevant references > > > > > > Some implementation is done by Intel and AMD/Igalia to address the same. > > Broad consensus is there that we need a generic API at drm core to > > suffice the use case of various HW vendors. Below are the links > > capturing the discussion so far. > > > > Intel's Plane Color Implementation: > > https://patchwork.freedesktop.org/series/90825/ > > AMD's Plane Color Implementation: > > https://patchwork.freedesktop.org/series/116862/ > > > > > > Hackfest conclusions > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the industry > > stakeholders together and converge on a common uapi expectations. > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia and > > other prominent user-space developers and maintainers. > > > > Discussions happened on the uapi expectations, opens, nature of > > hardware of multiple hardware vendors, challenges in generalizing the > > same and the path forward. Consensus was made that drm core should > > implement descriptive APIs and not go with prescriptive APIs. DRM core > > should just expose the hardware capabilities; enabling, customizing > > and programming the same should be done by the user-space. Driver should > > just > honor the user space request without doing any operations internally. > > > > Thanks to Simon Ser, for nicely documenting the design consensus and > > an UAPI RFC which can be referred to here: > > > > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5 > > > nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1Q > Wn48 > > 8=@emersion.fr/ > > > > > > Design considerations > > = > > > > Following are the important aspects taken into account while designing > > the current RFC > > proposal: > > > > 1. Individual HW blocks can be muxed. (e.g. out of two HW blocks only > > one > can be used) > > 2. Position of the HW block in the pipeline can be programmable > > 3. LUTs can be one dimentional or three dimentional > > 4. Number of LUT entries can vary across platforms > > 5. Precision of LUT entries can vary across platforms > > 6. Distribution of LUT entries may vary. e.g Mutli-segmented, > > Logarithmic, > >Piece-Wise Linear(PWL) etc > > 7. There can be parameterized/non-parameterized fixed function HW > blocks. > >e.g. Just a hardware bit, to convert from one color space to another. > > 8. Custom non-standard HW implementation. > > 9. Leaving scope for some vendor define
RE: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, May 26, 2023 7:18 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> handling
>
> On Thu, May 25, 2023 at 08:55:08PM +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: dri-devel On Behalf
> > > Of Ville Syrjala
> > > Sent: Thursday, April 13, 2023 10:19 PM
> > > To: intel-...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> > > handling
> > >
> > > From: Ville Syrjälä
> > >
> > > The CHV CGM CSC coefficients are in s4.12 two's complement format.
> > > Fix the CTM-
> > > >CGM conversion to handle that correctly instead of pretending that
> > > >the hw
> > > coefficients are also in some sign-magnitude format.
> >
> > Spec is slightly confusing when it says:
> > "CGM CSC : Input pixels to the CGM CSC are 14 bits. (u.14 format).
> > Coefficients are
> 16 bits (s3.12)."
> > Also here:
> > "Programmable parameters :
> > c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15
> > :0], c7[15 :0],
> c8[15 :0] ; // signed matrix coefficients (s3.12)"
>
> Yeah, the spec just uses a weird notation where it doesn't count the msb in
> the bits.
>
> >
> > But the coefficients are 16bits, can you help understand how were you
> > able to crack this
>
> The 16bit coefficient already made me suspect they screwed up the notation.
> Testing specific values on real hardware confirmed that.
Got it, thanks Ville for the clarification.
> >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_color.c | 46
> > > ++
> > > 1 file changed, 29 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index 4fc16cac052d..63141f4ed372 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> > > intel_crtc_state *crtc_state)
> > > icl_update_output_csc(crtc, _state->output_csc); }
> > >
> > > +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> > > +frac_bits) {
> > > + s64 c = CTM_COEFF_ABS(coeff);
> > > +
> > > + /* leave an extra bit for rounding */
> > > + c >>= 32 - frac_bits - 1;
> > > +
> > > + /* round and drop the extra bit */
> > > + c = (c + 1) >> 1;
> > > +
> > > + if (CTM_COEFF_NEGATIVE(coeff))
> > > + c = -c;
> > > +
> > > + c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> > > + (s64)(BIT(int_bits + frac_bits - 1) - 1));
> > > +
> > > + return c & (BIT(int_bits + frac_bits) - 1); }
> > > +
> > > +/*
> > > + * CHV Color Gamut Mapping (CGM) CSC
> > > + * |r| | c0 c1 c2 | |r|
> > > + * |g| = | c3 c4 c5 | x |g|
> > > + * |b| | c6 c7 c8 | |b|
> > > + *
> > > + * Coefficients are two's complement s4.12.
> > > + */
> > > static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state
> > > *crtc_state,
> > > struct intel_csc_matrix *csc) {
> > > const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> > > int i;
> > >
> > > - for (i = 0; i < 9; i++) {
> > > - u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> > > -
> > > - /* Round coefficient. */
> > > - abs_coeff += 1 << (32 - 13);
> > > - /* Clamp to hardware limits. */
> > > - abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> > > -
> > > - csc->coeff[i] = 0;
> > > -
> > > - /* Write coefficients in S3.12 format. */
> > > - if (ctm->matrix[i] & (1ULL << 63))
> > > - csc->coeff[i] |= 1 << 15;
> > > -
> > > - csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> > > - csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> > > - }
> > > + for (i = 0; i < 9; i++)
> > > + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> > > }
> > >
> > > static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > > --
> > > 2.39.2
> >
>
> --
> Ville Syrjälä
> Intel
RE: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> -Original Message-
> From: Shankar, Uma
> Sent: Friday, May 26, 2023 2:25 AM
> To: Ville Syrjala ;
> intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: RE: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> handling
>
>
>
> > -Original Message-
> > From: dri-devel On Behalf Of
> > Ville Syrjala
> > Sent: Thursday, April 13, 2023 10:19 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> > handling
> >
> > From: Ville Syrjälä
> >
> > The CHV CGM CSC coefficients are in s4.12 two's complement format. Fix
> > the CTM-
> > >CGM conversion to handle that correctly instead of pretending that
> > >the hw
> > coefficients are also in some sign-magnitude format.
>
> Spec is slightly confusing when it says:
> "CGM CSC : Input pixels to the CGM CSC are 14 bits. (u.14 format).
> Coefficients are
> 16 bits (s3.12)."
> Also here:
> "Programmable parameters :
> c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15 :0],
> c7[15 :0],
> c8[15 :0] ; // signed matrix coefficients (s3.12)"
>
> But the coefficients are 16bits, can you help understand how were you able to
> crack
> this
I think I got it. Looks good to me.
Reviewed-by: Uma Shankar
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 46
> > ++
> > 1 file changed, 29 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 4fc16cac052d..63141f4ed372 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> > intel_crtc_state *crtc_state)
> > icl_update_output_csc(crtc, _state->output_csc); }
> >
> > +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> > +frac_bits) {
> > + s64 c = CTM_COEFF_ABS(coeff);
> > +
> > + /* leave an extra bit for rounding */
> > + c >>= 32 - frac_bits - 1;
> > +
> > + /* round and drop the extra bit */
> > + c = (c + 1) >> 1;
> > +
> > + if (CTM_COEFF_NEGATIVE(coeff))
> > + c = -c;
> > +
> > + c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> > + (s64)(BIT(int_bits + frac_bits - 1) - 1));
> > +
> > + return c & (BIT(int_bits + frac_bits) - 1); }
> > +
> > +/*
> > + * CHV Color Gamut Mapping (CGM) CSC
> > + * |r| | c0 c1 c2 | |r|
> > + * |g| = | c3 c4 c5 | x |g|
> > + * |b| | c6 c7 c8 | |b|
> > + *
> > + * Coefficients are two's complement s4.12.
> > + */
> > static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state
> > *crtc_state,
> > struct intel_csc_matrix *csc) {
> > const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> > int i;
> >
> > - for (i = 0; i < 9; i++) {
> > - u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> > -
> > - /* Round coefficient. */
> > - abs_coeff += 1 << (32 - 13);
> > - /* Clamp to hardware limits. */
> > - abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> > -
> > - csc->coeff[i] = 0;
> > -
> > - /* Write coefficients in S3.12 format. */
> > - if (ctm->matrix[i] & (1ULL << 63))
> > - csc->coeff[i] |= 1 << 15;
> > -
> > - csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> > - csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> > - }
> > + for (i = 0; i < 9; i++)
> > + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> > }
> >
> > static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > --
> > 2.39.2
RE: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 parts
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3
> parts
>
> From: Ville Syrjälä
>
> Apparently desktop gen3 parts don't support the 10bit gamma mode at all. Stop
> claiming otherwise.
>
> As is the case with pipe A on gen3 mobile parts, the PIPECONF gamma mode bit
> can
> be set but it has no effect on the output.
>
> PNV seems to be the only slight exception, but generally the desktop PNV
> variant
> looks more like a mobile part so this is not entirely surprising.
Couldn't check the relevant spec to re-confirm, trusting your judgment here.
Reviewed-by: Uma Shankar
> Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_pci.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c index
> cddb6e197972..305c05c3f93b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
> .dma_mask_size = 32, \
> I9XX_PIPE_OFFSETS, \
> I9XX_CURSOR_OFFSETS, \
> - I9XX_COLORS, \
> GEN_DEFAULT_PAGE_SIZES, \
> GEN_DEFAULT_REGIONS
>
> static const struct intel_device_info i915g_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_I915G),
> + I845_COLORS,
> .has_coherent_ggtt = false,
> .display.cursor_needs_physical = 1,
> .display.has_overlay = 1,
> @@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {
> static
> const struct intel_device_info i915gm_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_I915GM),
> + I9XX_COLORS,
> .is_mobile = 1,
> .display.cursor_needs_physical = 1,
> .display.has_overlay = 1,
> @@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {
> static
> const struct intel_device_info i945g_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_I945G),
> + I845_COLORS,
> .display.has_hotplug = 1,
> .display.cursor_needs_physical = 1,
> .display.has_overlay = 1,
> @@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {
> static
> const struct intel_device_info i945gm_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_I945GM),
> + I9XX_COLORS,
> .is_mobile = 1,
> .display.has_hotplug = 1,
> .display.cursor_needs_physical = 1,
> @@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {
> static
> const struct intel_device_info g33_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_G33),
> + I845_COLORS,
> .display.has_hotplug = 1,
> .display.has_overlay = 1,
> .dma_mask_size = 36,
> @@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = { static
> const struct intel_device_info pnv_g_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_PINEVIEW),
> + I9XX_COLORS,
> .display.has_hotplug = 1,
> .display.has_overlay = 1,
> .dma_mask_size = 36,
> @@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {
> static
> const struct intel_device_info pnv_m_info = {
> GEN3_FEATURES,
> PLATFORM(INTEL_PINEVIEW),
> + I9XX_COLORS,
> .is_mobile = 1,
> .display.has_hotplug = 1,
> .display.has_overlay = 1,
> --
> 2.39.2
RE: [Intel-gfx] [PATCH v2 5/7] drm/i915: Implement CTM property support for VLV
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 5/7] drm/i915: Implement CTM property support
> for
> VLV
>
> From: Ville Syrjälä
>
> VLV has a so called "wide gamut color correction" unit (WGC).
> What it is is a 3x3 matrix similar to the later CHV CGM CSC, which less
> precisions/range. In fact CHV also has the WGC but using it there doesn't
> reall make
> sense when you have the superior CGM CSC around.
>
> Hook up the necessary stuff to expose the WGC as the CTM crtc property.
>
> One additional crazy idea that came to mind would be to use the WGC as an
> output
> CSC on CHV for YCbCr output. But it would be incompatible with the legacy LUT
> usage. In fact since the WGC lacks post-offsets we'd probably have to use the
> legacy
> LUT to do that final part of the RGB->YCbCr conversion. Sounds doable, but
> perhaps
> not worth the hassle.
Yeah WGC on CHV was just kept for safety against any hw issue, with plan to
drop in future platforms.
Exposing it for VLV is nice.
Changes look good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c| 170 +-
> .../drm/i915/display/intel_crtc_state_dump.c | 6 +-
> drivers/gpu/drm/i915/display/intel_display.c | 8 +
> .../drm/i915/display/intel_display_types.h| 3 +
> drivers/gpu/drm/i915/i915_reg.h | 15 ++
> 5 files changed, 198 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 7a705e7d8776..e36d8c248b84 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -587,6 +587,98 @@ static u16 ctm_to_twos_complement(u64 coeff, int
> int_bits, int frac_bits)
> return c & (BIT(int_bits + frac_bits) - 1); }
>
> +/*
> + * VLV/CHV Wide Gamut Color Correction (WGC) CSC
> + * |r| | c0 c1 c2 | |r|
> + * |g| = | c3 c4 c5 | x |g|
> + * |b| | c6 c7 c8 | |b|
> + *
> + * Coefficients are two's complement s2.10.
> + */
> +static void vlv_wgc_csc_convert_ctm(const struct intel_crtc_state
> *crtc_state,
> + struct intel_csc_matrix *csc)
> +{
> + const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> + int i;
> +
> + for (i = 0; i < 9; i++)
> + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 2, 10); }
> +
> +static void vlv_load_wgc_csc(struct intel_crtc *crtc,
> + const struct intel_csc_matrix *csc) {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + intel_de_write_fw(dev_priv, PIPE_WGC_C01_C00(pipe),
> + csc->coeff[1] << 16 | csc->coeff[0]);
> + intel_de_write_fw(dev_priv, PIPE_WGC_C02(pipe),
> + csc->coeff[2]);
> +
> + intel_de_write_fw(dev_priv, PIPE_WGC_C11_C10(pipe),
> + csc->coeff[4] << 16 | csc->coeff[3]);
> + intel_de_write_fw(dev_priv, PIPE_WGC_C12(pipe),
> + csc->coeff[5]);
> +
> + intel_de_write_fw(dev_priv, PIPE_WGC_C21_C20(pipe),
> + csc->coeff[7] << 16 | csc->coeff[6]);
> + intel_de_write_fw(dev_priv, PIPE_WGC_C22(pipe),
> + csc->coeff[8]);
> +}
> +
> +static void vlv_read_wgc_csc(struct intel_crtc *crtc,
> + struct intel_csc_matrix *csc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + u32 tmp;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C01_C00(pipe));
> + csc->coeff[0] = tmp & 0x;
> + csc->coeff[1] = tmp >> 16;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C02(pipe));
> + csc->coeff[2] = tmp & 0x;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C11_C10(pipe));
> + csc->coeff[3] = tmp & 0x;
> + csc->coeff[4] = tmp >> 16;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C12(pipe));
> + csc->coeff[5] = tmp & 0x;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C21_C20(pipe));
> + csc->coeff[6] = tmp & 0x;
> + csc->coeff[7] = tmp >> 16;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C22(pipe));
> + csc->coeff[8] = tmp & 0x;
> +}
> +
> +static void vlv_read_csc(struct intel_crtc_state *crtc_state) {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> +
> + if (crtc_state->wgc_enable)
> + vlv_read_wgc_csc(crtc, _state->csc); }
> +
> +static void vlv_assign_csc(struct intel_crtc_state *crtc_state) {
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (crtc_state->hw.ctm) {
> + drm_WARN_ON(>drm,
RE: [Intel-gfx] [PATCH v2 4/7] drm/i915: Always enable CGM CSC on CHV
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915: Always enable CGM CSC on CHV
>
> From: Ville Syrjälä
>
> On CHV toggling the CGM CSC on/off while the pipe is running leads to
> underruns.
> Looks like we'd have to do the toggling strictly inside the start_of_vblank-
> frame_start window to avoid this, but that window is less than a scanline so
> there's
> no way we can guarantee hitting it.
>
> As a workaround let's just leave the CGM CSC permanently enabled.
> Fortunately the CGM gamma/degamma units don't seem to suffer from this malady.
>
> I also tried turning off CGM unit clock gating, but that did not help.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 63141f4ed372..7a705e7d8776 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -605,6 +605,16 @@ static void chv_cgm_csc_convert_ctm(const struct
> intel_crtc_state *crtc_state,
> csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> }
>
> +#define CHV_CGM_CSC_COEFF_1_0 (1 << 12)
> +
> +static const struct intel_csc_matrix chv_cgm_csc_matrix_identity = {
> + .coeff = {
> + CHV_CGM_CSC_COEFF_1_0, 0, 0,
> + 0, CHV_CGM_CSC_COEFF_1_0, 0,
> + 0, 0, CHV_CGM_CSC_COEFF_1_0,
> + },
> +};
> +
> static void chv_load_cgm_csc(struct intel_crtc *crtc,
>const struct intel_csc_matrix *csc) { @@ -667,9
> +677,9
> @@ static void chv_assign_csc(struct intel_crtc_state *crtc_state)
>
> chv_cgm_csc_convert_ctm(crtc_state, _state->csc);
> } else {
> - drm_WARN_ON(>drm, (crtc_state->cgm_mode &
> CGM_PIPE_MODE_CSC) != 0);
> + drm_WARN_ON(>drm, (crtc_state->cgm_mode &
> CGM_PIPE_MODE_CSC) ==
> +0);
>
> - intel_csc_clear(_state->csc);
> + crtc_state->csc = chv_cgm_csc_matrix_identity;
> }
> }
>
> @@ -2033,6 +2043,13 @@ static u32 chv_cgm_mode(const struct intel_crtc_state
> *crtc_state)
> !lut_is_legacy(crtc_state->hw.gamma_lut))
> cgm_mode |= CGM_PIPE_MODE_GAMMA;
>
> + /*
> + * Toggling the CGM CSC on/off outside of the tiny window
> + * between start of vblank and frame start causes underruns.
> + * Always enable the CGM CSC as a workaround.
> + */
> + cgm_mode |= CGM_PIPE_MODE_CSC;
> +
> return cgm_mode;
> }
>
> --
> 2.39.2
RE: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> -Original Message-
> From: dri-devel On Behalf Of Ville
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
>
> From: Ville Syrjälä
>
> The CHV CGM CSC coefficients are in s4.12 two's complement format. Fix the
> CTM-
> >CGM conversion to handle that correctly instead of pretending that the hw
> coefficients are also in some sign-magnitude format.
Spec is slightly confusing when it says:
"CGM CSC : Input pixels to the CGM CSC are 14 bits. (u.14 format).
Coefficients are 16 bits (s3.12)."
Also here:
"Programmable parameters :
c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15 :0],
c7[15 :0], c8[15 :0] ; // signed matrix coefficients (s3.12)"
But the coefficients are 16bits, can you help understand how were you able to
crack this
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 46 ++
> 1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 4fc16cac052d..63141f4ed372 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> intel_crtc_state *crtc_state)
> icl_update_output_csc(crtc, _state->output_csc); }
>
> +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> +frac_bits) {
> + s64 c = CTM_COEFF_ABS(coeff);
> +
> + /* leave an extra bit for rounding */
> + c >>= 32 - frac_bits - 1;
> +
> + /* round and drop the extra bit */
> + c = (c + 1) >> 1;
> +
> + if (CTM_COEFF_NEGATIVE(coeff))
> + c = -c;
> +
> + c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> + (s64)(BIT(int_bits + frac_bits - 1) - 1));
> +
> + return c & (BIT(int_bits + frac_bits) - 1); }
> +
> +/*
> + * CHV Color Gamut Mapping (CGM) CSC
> + * |r| | c0 c1 c2 | |r|
> + * |g| = | c3 c4 c5 | x |g|
> + * |b| | c6 c7 c8 | |b|
> + *
> + * Coefficients are two's complement s4.12.
> + */
> static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state
> *crtc_state,
> struct intel_csc_matrix *csc)
> {
> const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> int i;
>
> - for (i = 0; i < 9; i++) {
> - u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> -
> - /* Round coefficient. */
> - abs_coeff += 1 << (32 - 13);
> - /* Clamp to hardware limits. */
> - abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> -
> - csc->coeff[i] = 0;
> -
> - /* Write coefficients in S3.12 format. */
> - if (ctm->matrix[i] & (1ULL << 63))
> - csc->coeff[i] |= 1 << 15;
> -
> - csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> - csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> - }
> + for (i = 0; i < 9; i++)
> + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> }
>
> static void chv_load_cgm_csc(struct intel_crtc *crtc,
> --
> 2.39.2
RE: [Intel-gfx] [PATCH v2 2/7] drm/i915: Expose crtc CTM property on ilk/snb
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, April 13, 2023 10:19 PM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 2/7] drm/i915: Expose crtc CTM property on > ilk/snb > > From: Ville Syrjälä > > The ilk/snb code is internally fully capable of handling the CTM property, so > expose > it. > > Note that we still choose not to expose DEGAMMA_LUT though. > The hardware is capable if degamma or gamma, but not both similtanously due to Nit: Typo in "simultaneously" Looks Good to me. Reviewed-by: Uma Shankar > lack of the split gamma mode. Exposing both LUTs might encourage userspace to > try > enabling both at the same time. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_color.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c > b/drivers/gpu/drm/i915/display/intel_color.c > index 07f1afe1d406..4fc16cac052d 100644 > --- a/drivers/gpu/drm/i915/display/intel_color.c > +++ b/drivers/gpu/drm/i915/display/intel_color.c > @@ -3473,7 +3473,7 @@ void intel_color_crtc_init(struct intel_crtc *crtc) > > gamma_lut_size = INTEL_INFO(i915)->display.color.gamma_lut_size; > degamma_lut_size = INTEL_INFO(i915)->display.color.degamma_lut_size; > - has_ctm = degamma_lut_size != 0; > + has_ctm = DISPLAY_VER(i915) >= 5 && !IS_VALLEYVIEW(i915); > > /* >* "DPALETTE_A: NOTE: The 8-bit (non-10-bit) mode is the > -- > 2.39.2
RE: [PATCH 0/7] Enable YCbCr420 format for VDSC
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: Tuesday, March 28, 2023 6:58 PM
> > To: Kandpal, Suraj
> > Cc: Jani Nikula ;
> > dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> > Nautiyal, Ankit K ; Shankar, Uma
> > ; Maarten Lankhorst
> >
> > Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
> >
> > On Tue, 28 Mar 2023 at 16:20, Kandpal, Suraj
> > wrote:
> > > > -Original Message-
> > > > From: dri-devel On
> > > > Behalf Of Jani Nikula
> > > > Sent: Wednesday, March 8, 2023 5:00 PM
> > > > To: Kandpal, Suraj ; dri-
> > > > de...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> > > > Cc: Dmitry Baryshkov ; Nautiyal,
> > > > Ankit K ; Shankar, Uma
> > > > ; Kandpal, Suraj
> > > > Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
> > > >
> > > > On Wed, 22 Feb 2023, Suraj Kandpal wrote:
> > > > > This patch series aims to enable the YCbCr420 format for DSC.
> > > > > Changes are mostly compute params related for hdmi,dp and dsi
> > > > > along with the addition of new rc_tables for native_420 and
> > > > > corresponding changes to macros used to fetch them.
> > > > > There have been discussions prior to this series in which some
> > > > > patches have gotten rb and can be found in the below link
> > > > > https://patchwork.freedesktop.org/series/113729
> > > >
> > > > I think it would be useful to get [1] from Dmitry merged to
> > > > drm-misc-next first, have that in drm-next, and again backmerged
> > > > to drm-intel-next before this. At least patches 1-5.
> > > >
> > > > There's not much point in all drivers duplicating the parameters,
> > > > and we need to move towards common code. Dmitry has been helpful
> > > > in contributing this to us.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > >
> > >
> > > Hi Jani,
> > > Maarten has acked the patch series to be merged through drm-intel
> > > and in the meantime I will work with Dmitry to pull the common code
> > > to avoid duplication
> >
> > Thank you! If necessary feel free to ping me on IRC ('lumag').
>
> Thanks guys, will help merge the change.
Pushed the changes to drm-intel-next. Thanks for the patches and reviews.
Regards,
Uma Shankar
>
> > >
> > > Regards,
> > > Suraj Kandpal
> > >
> > > > [1] https://patchwork.freedesktop.org/series/114473/
> > > >
> > > > >
> > > > > Ankit Nautiyal (2):
> > > > > drm/dp_helper: Add helper to check DSC support with given o/p format
> > > > > drm/i915/dp: Check if DSC supports the given output_format
> > > > >
> > > > > Suraj Kandpal (4):
> > > > > drm/i915: Adding the new registers for DSC
> > > > > drm/i915: Enable YCbCr420 for VDSC
> > > > > drm/i915/display: Fill in native_420 field
> > > > > drm/i915/vdsc: Check slice design requirement
> > > > >
> > > > > Swati Sharma (1):
> > > > > drm/i915/dsc: Add debugfs entry to validate DSC output formats
> > > > >
> > > > > drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> > > > > .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> > > > > .../drm/i915/display/intel_crtc_state_dump.h | 2 +
> > > > > .../drm/i915/display/intel_display_debugfs.c | 78
> > > > > .../drm/i915/display/intel_display_types.h| 1 +
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 39 +++-
> > > > > .../gpu/drm/i915/display/intel_qp_tables.c| 187
> > > > > --
> > > > > .../gpu/drm/i915/display/intel_qp_tables.h| 4 +-
> > > > > drivers/gpu/drm/i915/display/intel_vdsc.c | 108 +-
> > > > > drivers/gpu/drm/i915/i915_reg.h | 28 +++
> > > > > include/drm/display/drm_dp_helper.h | 13 ++
> > > > > 11 files changed, 442 insertions(+), 24 deletions(-)
> > > >
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
> >
> >
> >
> > --
> > With best wishes
> > Dmitry
RE: [PATCH 0/7] Enable YCbCr420 format for VDSC
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Tuesday, March 28, 2023 6:58 PM
> To: Kandpal, Suraj
> Cc: Jani Nikula ;
> dri-devel@lists.freedesktop.org;
> intel-...@lists.freedesktop.org; Nautiyal, Ankit K
> ;
> Shankar, Uma ; Maarten Lankhorst
>
> Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
>
> On Tue, 28 Mar 2023 at 16:20, Kandpal, Suraj wrote:
> > > -Original Message-
> > > From: dri-devel On Behalf
> > > Of Jani Nikula
> > > Sent: Wednesday, March 8, 2023 5:00 PM
> > > To: Kandpal, Suraj ; dri-
> > > de...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> > > Cc: Dmitry Baryshkov ; Nautiyal, Ankit
> > > K ; Shankar, Uma
> > > ; Kandpal, Suraj
> > > Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
> > >
> > > On Wed, 22 Feb 2023, Suraj Kandpal wrote:
> > > > This patch series aims to enable the YCbCr420 format for DSC.
> > > > Changes are mostly compute params related for hdmi,dp and dsi
> > > > along with the addition of new rc_tables for native_420 and
> > > > corresponding changes to macros used to fetch them.
> > > > There have been discussions prior to this series in which some
> > > > patches have gotten rb and can be found in the below link
> > > > https://patchwork.freedesktop.org/series/113729
> > >
> > > I think it would be useful to get [1] from Dmitry merged to
> > > drm-misc-next first, have that in drm-next, and again backmerged to
> > > drm-intel-next before this. At least patches 1-5.
> > >
> > > There's not much point in all drivers duplicating the parameters,
> > > and we need to move towards common code. Dmitry has been helpful in
> > > contributing this to us.
> > >
> > > BR,
> > > Jani.
> > >
> > >
> >
> > Hi Jani,
> > Maarten has acked the patch series to be merged through drm-intel and
> > in the meantime I will work with Dmitry to pull the common code to
> > avoid duplication
>
> Thank you! If necessary feel free to ping me on IRC ('lumag').
Thanks guys, will help merge the change.
Regards,
Uma Shankar
> >
> > Regards,
> > Suraj Kandpal
> >
> > > [1] https://patchwork.freedesktop.org/series/114473/
> > >
> > > >
> > > > Ankit Nautiyal (2):
> > > > drm/dp_helper: Add helper to check DSC support with given o/p format
> > > > drm/i915/dp: Check if DSC supports the given output_format
> > > >
> > > > Suraj Kandpal (4):
> > > > drm/i915: Adding the new registers for DSC
> > > > drm/i915: Enable YCbCr420 for VDSC
> > > > drm/i915/display: Fill in native_420 field
> > > > drm/i915/vdsc: Check slice design requirement
> > > >
> > > > Swati Sharma (1):
> > > > drm/i915/dsc: Add debugfs entry to validate DSC output formats
> > > >
> > > > drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> > > > .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> > > > .../drm/i915/display/intel_crtc_state_dump.h | 2 +
> > > > .../drm/i915/display/intel_display_debugfs.c | 78
> > > > .../drm/i915/display/intel_display_types.h| 1 +
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 39 +++-
> > > > .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
> > > > .../gpu/drm/i915/display/intel_qp_tables.h| 4 +-
> > > > drivers/gpu/drm/i915/display/intel_vdsc.c | 108 +-
> > > > drivers/gpu/drm/i915/i915_reg.h | 28 +++
> > > > include/drm/display/drm_dp_helper.h | 13 ++
> > > > 11 files changed, 442 insertions(+), 24 deletions(-)
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
>
>
>
> --
> With best wishes
> Dmitry
RE: [Intel-gfx] [PATCH 3/7] drm/i915: Adding the new registers for DSC
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, March 8, 2023 4:57 PM
> To: Shankar, Uma ; Kandpal, Suraj
> ; dri-devel@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 3/7] drm/i915: Adding the new registers for
> DSC
>
> On Wed, 08 Mar 2023, "Shankar, Uma" wrote:
> >> -Original Message-
> >> From: Kandpal, Suraj
> >> Sent: Wednesday, February 22, 2023 11:02 AM
> >> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> >> Cc: Shankar, Uma ; Nautiyal, Ankit K
> >> ; Kandpal, Suraj
> >> ; Kulkarni, Vandita
> >>
> >> Subject: [PATCH 3/7] drm/i915: Adding the new registers for DSC
> >
> > Nit: drm/i915/dsc would be better.
> >
> > Looks Good to me.
> > Reviewed-by: Uma Shankar
>
> Except since c3f059483671 ("drm/i915/display: split out DSC and DSS
> registers") the DSC registers need to go to display/intel_vdsc_regs.h.
Oh ok, thanks Jani for spotting it.
Regards,
Uma Shankar
> BR,
> Jani.
>
> >
> >> Adding new DSC register which are introducted MTL onwards
> >>
> >> Signed-off-by: Suraj Kandpal
> >> Reviewed-by: Vandita Kulkarni
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 28
> >> 1 file changed, 28 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h index 596efc940ee7..9e25e21d37e4
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -7715,6 +7715,8 @@ enum skl_power_gate {
> >> #define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe)
> _MMIO_PIPE((pipe) -
> >> PIPE_B, \
> >>
> >> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
> >>
> >> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
> >> +#define DSC_NATIVE_422_ENABLEBIT(23)
> >> +#define DSC_NATIVE_420_ENABLEBIT(22)
> >> #define DSC_ALT_ICH_SEL (1 << 20)
> >> #define DSC_VBR_ENABLE (1 << 19)
> >> #define DSC_422_ENABLE (1 << 18)
> >> @@ -7959,6 +7961,32 @@ enum skl_power_gate {
> >> #define DSC_SLICE_PER_LINE(slice_per_line)
> >> ((slice_per_line) << 16)
> >> #define DSC_SLICE_CHUNK_SIZE(slice_chunk_size)
> >> ((slice_chunk_size)
> >> << 0)
> >>
> >> +/* MTL Display Stream Compression registers */
> >> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB 0x782B4
> >> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB 0x783B4
> >> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC 0x784B4
> >> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC 0x785B4
> >> +#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)
> >>_MMIO_PIPE((pipe) - PIPE_B, \
> >> +
> >> _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
> >> +
> >> _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
> >> +#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)
> >>_MMIO_PIPE((pipe) - PIPE_B, \
> >> +
> >> _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
> >> +
> >> _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
> >> +#define DSC_SL_BPG_OFFSET(offset) ((offset) << 27)
> >> +
> >> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB 0x782B8
> >> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB 0x783B8
> >> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC 0x784B8
> >> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC 0x785B8
> >> +#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)
> >>_MMIO_PIPE((pipe) - PIPE_B, \
> >> +
> >> _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
> >> +
> >> _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
> >> +#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)
> >>_MMIO_PIPE((pipe) - PIPE_B, \
> >> +
> >> _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
> >> +
> >> _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
> >> +#define DSC_NSL_BPG_OFFSET(offset)((offset) << 16)
> >> +#define DSC_SL_OFFSET_ADJ(offset) ((offset) << 0)
> >> +
> >> /* Icelake Rate Control Buffer Threshold Registers */
> >> #define DSCA_RC_BUF_THRESH_0 _MMIO(0x6B230)
> >> #define DSCA_RC_BUF_THRESH_0_UDW _MMIO(0x6B230 + 4)
> >> --
> >> 2.25.1
> >
>
> --
> Jani Nikula, Intel Open Source Graphics Center
RE: [PATCH 6/7] drm/i915/vdsc: Check slice design requirement
> -Original Message-
> From: Kandpal, Suraj
> Sent: Wednesday, February 22, 2023 11:02 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj
> Subject: [PATCH 6/7] drm/i915/vdsc: Check slice design requirement
>
> Add function to check if slice design requirements are being met as defined
> in Bspec:
> 49259 in the section Slice Design Requirement
>
> --v7
> -remove full bspec link [Jani]
> -rename intel_dsc_check_slice_design_req to intel_dsc_slice_dimensions_valid
> [Jani]
>
> --v8
> -fix condition to check if slice width and height are of two -fix minimum
> pixel in slice
> condition
>
> --v10
> -condition should be < rather then >= [Uma]
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Uma Shankar
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 32997c9773aa..a9585f493318 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -447,6 +447,29 @@ calculate_rc_params(struct rc_parameters *rc,
> }
> }
>
> +static int intel_dsc_slice_dimensions_valid(struct intel_crtc_state
> *pipe_config,
> + struct drm_dsc_config *vdsc_cfg) {
> + if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_RGB ||
> + pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
> + if (vdsc_cfg->slice_height > 4095)
> + return -EINVAL;
> + if (vdsc_cfg->slice_height * vdsc_cfg->slice_width < 15000)
> + return -EINVAL;
> + } else if (pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420) {
> + if (vdsc_cfg->slice_width % 2)
> + return -EINVAL;
> + if (vdsc_cfg->slice_height % 2)
> + return -EINVAL;
> + if (vdsc_cfg->slice_height > 4094)
> + return -EINVAL;
> + if (vdsc_cfg->slice_height * vdsc_cfg->slice_width < 3)
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> int intel_dsc_compute_params(struct intel_crtc_state *pipe_config) {
> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> @@ -455,11 +478,20 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
> u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
> const struct rc_parameters *rc_params;
> struct rc_parameters *rc = NULL;
> + int err;
> u8 i = 0;
>
> vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
>pipe_config->dsc.slice_count);
> +
> + err = intel_dsc_slice_dimensions_valid(pipe_config, vdsc_cfg);
> +
> + if (err) {
> + drm_dbg_kms(_priv->drm, "Slice dimension requirements not
> met\n");
> + return err;
> + }
> +
> /*
>* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
> is 0
>* else 1
> --
> 2.25.1
RE: [PATCH v2 5/7] drm/i915/display: Fill in native_420 field
> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, March 3, 2023 11:05 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj ; Jani
> Nikula
>
> Subject: [PATCH v2 5/7] drm/i915/display: Fill in native_420 field
I asked to add "display" but please change to "/drm/i915/dsc" as that is more
relevant.
Use that for whole series.
Change Looks Good to me.
Reviewed-by: Uma Shankar
> Now that we have laid the groundwork for YUV420 Enablement we fill up
> native_420
> field in vdsc_cfg and add appropriate checks wherever required.
>
> ---v2
> -adding native_422 field as 0 [Vandita]
> -filling in second_line_bpg_offset, second_line_offset_adj and nsl_bpg_offset
> in
> vds_cfg when native_420 is true
>
> ---v3
> -adding display version check to solve igt issue
>
> --v7
> -remove is_pipe_dsc check as its always true for D14 [Jani]
>
> --v10
> -keep sink capability check [Jani]
> -move from !(x == y || w == z) to x !=y && w != z [Jani]
>
> --v11
> -avoid native_420 computation if not gen14 [Uma]
>
> --v12
> -fix state mismatch issue of compressed_bpp
>
> Cc: Uma Shankar
> Cc: Jani Nikula
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
> drivers/gpu/drm/i915/display/intel_vdsc.c | 98 ---
> 3 files changed, 100 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index b5316715bb3b..fb7efab8e9e6 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1539,8 +1539,6 @@ static int gen11_dsi_dsc_compute_config(struct
> intel_encoder *encoder,
> if (crtc_state->dsc.slice_count > 1)
> crtc_state->dsc.dsc_split = true;
>
> - vdsc_cfg->convert_rgb = true;
> -
> /* FIXME: initialize from VBT */
> vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2649e8b8ef57..86b9348b74bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1467,9 +1467,10 @@ static int intel_dp_dsc_compute_params(struct
> intel_encoder *encoder,
> vdsc_cfg->dsc_version_minor =
> min(intel_dp_source_dsc_version_minor(intel_dp),
> intel_dp_sink_dsc_version_minor(intel_dp));
> -
> - vdsc_cfg->convert_rgb = intel_dp-
> >dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
> - DP_DSC_RGB;
> + if (vdsc_cfg->convert_rgb)
> + vdsc_cfg->convert_rgb =
> + intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP -
> DP_DSC_SUPPORT] &
> + DP_DSC_RGB;
>
> line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
> if (!line_buf_depth) {
> @@ -1587,6 +1588,15 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> pipe_config-
> >bigjoiner_pipes,
> pipe_bpp,
> timeslots);
> + /*
> + * According to DSC 1.2a Section 4.1.1 Table 4.1 the
> maximum
> + * supported PPS value can be 63.9375 and with the
> further
> + * mention that bpp should be programmed double the
> target bpp
> + * restricting our target bpp to be 31.9375 at max
> + */
> + if (pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420)
> + dsc_max_output_bpp = min_t(u16,
> dsc_max_output_bpp, 31 << 4);
> +
> if (!dsc_max_output_bpp) {
> drm_dbg_kms(_priv->drm,
> "Compressed BPP not supported\n");
> diff
> --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index ed16f63d6355..44243fc81b46 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -460,14 +460,50 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
> vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> vdsc_cfg->slice
RE: [PATCH 4/7] drm/i915: Enable YCbCr420 for VDSC
> -Original Message-
> From: Kandpal, Suraj
> Sent: Wednesday, February 22, 2023 11:02 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj ;
> Kulkarni,
> Vandita
> Subject: [PATCH 4/7] drm/i915: Enable YCbCr420 for VDSC
drm/i915/dsc is better
Looks Good to me.
Reviewed-by: Uma Shankar
> Implementation of VDSC for YCbCr420.
> Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c (Derived
> from C-
> Model, which is given along with DSC1.2a Spec from Vesa)
> intel_lookup_range_min/max_qp functons need to take into account the output
> format. Based on that appropriate qp table need to be chosen.
> Other rc_parameters need to be set where currently values for 444 format is
> hardcoded in calculate_rc_parameters( ).
> vdsc_cfg struct needs to be filled with output format information, where
> these are
> hardcoded for 444 format.
> Bspec: 49259
> Signed-off-by: Suraj Kandpal
> Reviewed-by: Vandita Kulkarni
> ---
> .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
> .../gpu/drm/i915/display/intel_qp_tables.h| 4 +-
> drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-
> 3 files changed, 180 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c
> b/drivers/gpu/drm/i915/display/intel_qp_tables.c
> index 6f8e4ec5c0fb..6e86c0971d24 100644
> --- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
> +++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
> @@ -17,6 +17,15 @@
> /* from BPP 6 to 36 in steps of 0.5 */
> #define RC_RANGE_QP444_12BPC_MAX_NUM_BPP 61
>
> +/* from BPP 6 to 24 in steps of 0.5 */
> +#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP 17
> +
> +/* from BPP 6 to 30 in steps of 0.5 */
> +#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP 23
> +
> +/* from BPP 6 to 36 in steps of 0.5 */
> +#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP 29
> +
> /*
> * These qp tables are as per the C model
> * and it has the rows pointing to bpps which increment @@ -283,26 +292,182
> @@
> static const u8
> rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_12BPC
> 11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5,
> 5, 4 } };
>
> -#define PARAM_TABLE(_minmax, _bpc, _row, _col) do { \
> - if (bpc == (_bpc)) \
> - return rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
> +static const u8
> rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MA
> X_NUM_BPP] = {
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
> + { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
> + { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
> + { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
> + { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
> + { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
> + { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
> + { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
> + { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
> + { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
> + { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 } };
> +
> +static const u8
> rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MA
> X_NUM_BPP] = {
> + { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
> + { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
> + { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
> + { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
> + { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
> + { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
> + { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
> + { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
> + { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
> + { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
> + { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
> + { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
> + { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
> + { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
> + { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 } };
> +
> +static const u8
> rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_10BPC_
> MAX_NUM_BPP] = {
&g
RE: [PATCH 3/7] drm/i915: Adding the new registers for DSC
> -Original Message-
> From: Kandpal, Suraj
> Sent: Wednesday, February 22, 2023 11:02 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj ;
> Kulkarni,
> Vandita
> Subject: [PATCH 3/7] drm/i915: Adding the new registers for DSC
Nit: drm/i915/dsc would be better.
Looks Good to me.
Reviewed-by: Uma Shankar
> Adding new DSC register which are introducted MTL onwards
>
> Signed-off-by: Suraj Kandpal
> Reviewed-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 596efc940ee7..9e25e21d37e4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7715,6 +7715,8 @@ enum skl_power_gate {
> #define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe) _MMIO_PIPE((pipe) -
> PIPE_B, \
>
> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
>
> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
> +#define DSC_NATIVE_422_ENABLE BIT(23)
> +#define DSC_NATIVE_420_ENABLE BIT(22)
> #define DSC_ALT_ICH_SEL (1 << 20)
> #define DSC_VBR_ENABLE (1 << 19)
> #define DSC_422_ENABLE (1 << 18)
> @@ -7959,6 +7961,32 @@ enum skl_power_gate {
> #define DSC_SLICE_PER_LINE(slice_per_line) ((slice_per_line) << 16)
> #define DSC_SLICE_CHUNK_SIZE(slice_chunk_size)
> ((slice_chunk_size)
> << 0)
>
> +/* MTL Display Stream Compression registers */
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB0x782B4
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB0x783B4
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC0x784B4
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC0x785B4
> +#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)
> _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
> +#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)
> _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
> +#define DSC_SL_BPG_OFFSET(offset)((offset) << 27)
> +
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB0x782B8
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB0x783B8
> +#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC0x784B8
> +#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC0x785B8
> +#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)
> _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
> +
> _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
> +#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)
> _MMIO_PIPE((pipe) - PIPE_B, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
> +
> _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
> +#define DSC_NSL_BPG_OFFSET(offset) ((offset) << 16)
> +#define DSC_SL_OFFSET_ADJ(offset)((offset) << 0)
> +
> /* Icelake Rate Control Buffer Threshold Registers */
> #define DSCA_RC_BUF_THRESH_0 _MMIO(0x6B230)
> #define DSCA_RC_BUF_THRESH_0_UDW _MMIO(0x6B230 + 4)
> --
> 2.25.1
RE: [PATCH 2/7] drm/i915/dp: Check if DSC supports the given output_format
> -Original Message-
> From: Kandpal, Suraj
> Sent: Wednesday, February 22, 2023 11:02 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
>
> Subject: [PATCH 2/7] drm/i915/dp: Check if DSC supports the given
> output_format
>
> From: Ankit Nautiyal
>
> Go with DSC only if the given output_format is supported.
>
> v2: Use drm helper to get DSC format support for sink.
>
> v3: remove drm_dp_dsc_compute_bpp.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Uma Shankar
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 +
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index fe98c7dec193..f2fb3ec2dd99 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1491,6 +1491,31 @@ static int intel_dp_dsc_compute_params(struct
> intel_encoder *encoder,
> return drm_dsc_compute_rc_parameters(vdsc_cfg);
> }
>
> +static bool intel_dp_dsc_supports_format(struct intel_dp *intel_dp,
> + enum intel_output_format output_format)
> {
> + u8 sink_dsc_format;
> +
> + switch (output_format) {
> + case INTEL_OUTPUT_FORMAT_RGB:
> + sink_dsc_format = DP_DSC_RGB;
> + break;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + sink_dsc_format = DP_DSC_YCbCr444;
> + break;
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + if (min(intel_dp_source_dsc_version_minor(intel_dp),
> + intel_dp_sink_dsc_version_minor(intel_dp)) < 2)
> + return false;
> + sink_dsc_format = DP_DSC_YCbCr420_Native;
> + break;
> + default:
> + return false;
> + }
> +
> + return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +sink_dsc_format); }
> +
> int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state, @@ -
> 1511,6 +1536,9 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> return -EINVAL;
>
> + if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> + return -EINVAL;
> +
> if (compute_pipe_bpp)
> pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state-
> >max_requested_bpc);
> else
> --
> 2.25.1
RE: [PATCH 1/7] drm/dp_helper: Add helper to check DSC support with given o/p format
> -Original Message-
> From: Kandpal, Suraj
> Sent: Wednesday, February 22, 2023 11:02 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
>
> Subject: [PATCH 1/7] drm/dp_helper: Add helper to check DSC support with given
> o/p format
>
> From: Ankit Nautiyal
>
> Add helper to check if the DP sink supports DSC with the given o/p format.
>
> v2: Add documentation for the helper. (Uma Shankar)
>
> Signed-off-by: Ankit Nautiyal
> ---
> include/drm/display/drm_dp_helper.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index ab55453f2d2c..41da8eb4801e 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -194,6 +194,19 @@ drm_dp_dsc_sink_max_slice_width(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> DP_DSC_SLICE_WIDTH_MULTIPLIER;
> }
>
> +/*
Use /** instead of /*
With that fixed, this is
Reviewed-by: Uma Shankar
> + * drm_dp_dsc_sink_supports_format() - check if sink supports DSC with
> +given output format
> + * @dsc_dpcd : DSC-capability DPCDs of the sink
> + * @output_format: output_format which is to be checked
> + *
> + * Returns true if the sink supports DSC with the given output_format, false
> otherwise.
> + */
> +static inline bool
> +drm_dp_dsc_sink_supports_format(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE], u8 output_format) {
> + return dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT]
> &
> +output_format; }
> +
> /* Forward Error Correction Support on DP 1.4 */ static inline bool
> drm_dp_sink_supports_fec(const u8 fec_capable)
> --
> 2.25.1
RE: DRM/KMS PWL API Thoughts and Questions
> -Original Message- > From: Harry Wentland > Sent: Saturday, June 11, 2022 1:59 AM > To: Pekka Paalanen ; sebast...@sebastianwick.net; > Shankar, Uma > Cc: Vitaly Prosyak ; Sharma, Shashank > ; Lakha, Bhawanpreet > ; Deucher, Alexander > ; Alex Hung ; dri-devel de...@lists.freedesktop.org>; amd-gfx list ; > intel- > g...@lists.freedesktop.org; Modem, Bhanuprakash > > Subject: DRM/KMS PWL API Thoughts and Questions > > (I'm sending this as an email as lowest common denominator but feel an issue > on the > color-and-hdr repo would be a better interface for productive discussion. > Please pop > over to https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/10 if you > agree. > Hopefully we can drive the discussion there but if there is a strong > preference for > email that works as well. :) ) > > I've wanted to start a thread to discuss the use of PWL APIs that were > introduced by > Uma a year ago and for which Bhanuprakash provided IGT tests. I have come to > like > the API but as we're getting closer to a real-world use of it I have a few > questions > and comments. As with a lot of complex APIs the devil is in the details. Some > of > those details are currently underspecified, or underdocumented and it's > important > that we all interpret the API the same way. Thanks Harry for starting this thread. Adding Ville to the discussion as well as the original design is his brain child. We can discuss on the issue you created if all others agree. > **The API** > > The original patches posted by Uma: > https://patchwork.freedesktop.org/series/90822/ > https://patchwork.freedesktop.org/series/90826/ > > The IGT tests for PWL API: > https://patchwork.freedesktop.org/series/96895/ > > I've rebased the kernel patches on a slightly more recent kernel, along with > an AMD > implementation: > https://gitlab.freedesktop.org/hwentland/linux/-/tree/color-and-hdr > > I've also rebased them on an IGT tree, but that's not too up-to-date: > https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/color-and-hdr > > > **Why do I like the API?** > > In order to allow HW composition of HDR planes in linear space we need the > ability > to program at least a per-CRTC regamma (inv_EOTF) to go from linear to wire > format post-blending. Since userspace might want to apply corrections on top > of a > simple transfer function (such as PQ, BT.709, etc.) it would like a way to > set a custom > LUT. > > The existing CRTC gamma LUT defines equally spaced entries. As Pekka shows in > [1] > equally-spaced LUTs have unacceptable error for regamma/inv_EOTF. Hence we > need finer granularity of our entries near zero while coarse granularity > works fine > toward the brighter values. > > [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/9 > > HW (at least AMD and Intel HW) implements this ability as segmented piece-wise > linear LUTs. These define segments of equally spaced entries. These segments > are > constrained by the HW implementation. I like how the PWL API allows different > drivers to specify the constraints imposed by different HW while allowing > userspace > a generic way of parsing the PWL. This also avoids complex calculations in > the kernel > driver, which might be required for other APIs one could envision. If anyone > likes I > can elaborate on some ideas for an alternate API, though all of them will > require > non-trivial transformations by the kernel driver in order to program them to > HW. > I feel the current design fits best to most of the implementations, even legacy API/hardware can be defined using the proposed UAPI's. Its good that we are in agreement and we can surely iron out the UAPI and document the expectations. > **Nitpicks** > > The API defines everything inside the segments, including flags and values > that apply > to the entire PWL, such as DRM_MODE_LUT_GAMMA, > DRM_MODE_LUT_REFLECT_NEGATIVE, input_bpc, and output_bpc. If these don't > stay constant for segments it might complicate the interpretation of > segments. I > suggest we consider these as effectively applying to the entire PWL. We could > encode them in an overall drm_color_lut struct that includes an array of > drm_color_lut_range but that's probably not necessary, hence why I called > this out > as a nitpick. I would just like us to be aware of this ambiguity and document > that > these values applies to the entire PWL. It can be done, no concerns as such. > > **How to read the PWL** > > Let me first give a summary for how this LUT is used in userspace. If you're > familiar > with this please review and comment if I got th
RE: [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, February 15, 2022 11:22 AM
> To: intel-gfx ; dri-devel de...@lists.freedesktop.org>
> Cc: Ville Syrjälä ; Shankar, Uma
> ; Hogander, Jouni ; C,
> Ramalingam
> Subject: [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
>
> From: Jouni Högander
>
> Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E port.
> Correct
> offset is 0x64C14.
>
> Fix this by handling PHY_E port seprately.
>
> Signed-off-by: Matt Roper
> Signed-off-by: Jouni Högander
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 6 --
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index c60575cb5368..f08061c748b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -32,7 +32,7 @@ void intel_snps_phy_wait_for_calibration(struct
> drm_i915_private *i915)
> if (!intel_phy_is_snps(i915, phy))
> continue;
>
> - if (intel_de_wait_for_clear(i915, ICL_PHY_MISC(phy),
> + if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
> DG2_PHY_DP_TX_ACK_MASK, 25))
> drm_err(>drm, "SNPS PHY %c failed to calibrate
> after
> 25ms.\n",
> phy);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4d12abb2d7ff..354c25f483cb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9559,8 +9559,10 @@ enum skl_power_gate {
>
> #define _ICL_PHY_MISC_A 0x64C00
> #define _ICL_PHY_MISC_B 0x64C04
> -#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
> - _ICL_PHY_MISC_B)
> +#define _DG2_PHY_MISC_TC10x64C14 /* TC1="PHY E" but offset as if "PHY F"
> */
> +#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A,
> _ICL_PHY_MISC_B)
Nit: Align it as was defined earlier to honor line limit.
Looks Good to me.
Reviewed-by: Uma Shankar
> +#define DG2_PHY_MISC(port) ((port) == PHY_E ? _MMIO(_DG2_PHY_MISC_TC1) :
> \
> + ICL_PHY_MISC(port))
> #define ICL_PHY_MISC_MUX_DDID (1 << 28)
> #define ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
> #define DG2_PHY_DP_TX_ACK_MASK REG_GENMASK(23, 20)
> --
> 2.20.1
RE: [PATCH 2/3] drm/i915/dg2: Drop 38.4 MHz MPLLB tables
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, February 15, 2022 11:22 AM
> To: intel-gfx ; dri-devel de...@lists.freedesktop.org>
> Cc: Ville Syrjälä ; Shankar, Uma
> ; Roper, Matthew D ;
> Srivatsa, Anusha ; Souza, Jose
> ; C, Ramalingam
> Subject: [PATCH 2/3] drm/i915/dg2: Drop 38.4 MHz MPLLB tables
>
> From: Matt Roper
>
> Our early understanding of DG2 was incorrect; since the 5th display isn't
> actually a
> Type-C output, 38.4 MHz input clocks are never used on this platform and we
> can
> drop the corresponding MPLLB tables.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Anusha Srivatsa
> Cc: José Roberto de Souza
> Signed-off-by: Matt Roper
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 208 +-
> 1 file changed, 1 insertion(+), 207 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index 8573a458811a..c60575cb5368 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -250,197 +250,6 @@ static const struct intel_mpllb_state * const
> dg2_dp_100_tables[] = {
> NULL,
> };
>
> -/*
> - * Basic DP link rates with 38.4 MHz reference clock.
> - */
> -
> -static const struct intel_mpllb_state dg2_dp_rbr_38_4 = {
> - .clock = 162000,
> - .ref_control =
> - REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
> - .mpllb_cp =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
> - .mpllb_div =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 2),
> - .mpllb_div2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 304),
> - .mpllb_fracn1 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
> - .mpllb_fracn2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 49152),
> -};
> -
> -static const struct intel_mpllb_state dg2_dp_hbr1_38_4 = {
> - .clock = 27,
> - .ref_control =
> - REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
> - .mpllb_cp =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
> - .mpllb_div =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
> - .mpllb_div2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
> - .mpllb_fracn1 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
> - .mpllb_fracn2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
> -};
> -
> -static const struct intel_mpllb_state dg2_dp_hbr2_38_4 = {
> - .clock = 54,
> - .ref_control =
> - REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
> - .mpllb_cp =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
> - .mpllb_div =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
> - .mpllb_div2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
> - .m
RE: [PATCH 1/3] drm/i915/dg2: Enable 5th display
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, February 15, 2022 11:22 AM
> To: intel-gfx ; dri-devel de...@lists.freedesktop.org>
> Cc: Ville Syrjälä ; Shankar, Uma
> ; Roper, Matthew D ;
> Dhanavanthri, Swathi ; De Marchi, Lucas
> ; Souza, Jose ; C, Ramalingam
>
> Subject: [PATCH 1/3] drm/i915/dg2: Enable 5th display
>
> From: Matt Roper
>
> DG2 supports a 5th display output which the hardware refers to as "TC1,"
> even though it isn't a Type-C output. This behaves similarly to the TC1 on
> past
> platforms with just a couple minor differences:
>
> * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on
>ICP/TGP/ADP.
> * DG2 doesn't need the hpd inversion setting that we had to use on DG1
>
> Cc: Swathi Dhanavanthri
> Cc: Lucas De Marchi
> Cc: José Roberto de Souza
> Signed-off-by: Matt Roper
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_gmbus.c | 16 ++--
> drivers/gpu/drm/i915/i915_irq.c| 5 -
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index 6ce8c10fe975..2fad03250661 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -98,11 +98,21 @@ static const struct gmbus_pin gmbus_pins_dg1[] = {
> [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
> };
>
> +static const struct gmbus_pin gmbus_pins_dg2[] = {
> + [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> + [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> + [GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
> + [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
> + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ }, };
> +
> /* pin is expected to be valid */
> static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private
> *dev_priv,
>unsigned int pin)
> {
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
> + return _pins_dg2[pin];
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> return _pins_dg1[pin];
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> return _pins_icp[pin];
> @@ -123,7 +133,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
> *dev_priv, {
> unsigned int size;
>
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
> + size = ARRAY_SIZE(gmbus_pins_dg2);
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> size = ARRAY_SIZE(gmbus_pins_dg1);
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> size = ARRAY_SIZE(gmbus_pins_icp);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index
> fdd568ba4a16..4d81063b128c 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -179,6 +179,7 @@ static const u32 hpd_sde_dg1[HPD_NUM_PINS] = {
> [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
> [HPD_PORT_C] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_C),
> [HPD_PORT_D] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_D),
> + [HPD_PORT_TC1] = SDE_TC_HOTPLUG_DG2(HPD_PORT_TC1),
Not sure if this applies to DG1, the 5th TC1 port is only for DG2. Should we
not have a separate
DG2 struct. Can you please clarify to help understand.
Regards,
Uma Shankar
> };
>
> static void intel_hpd_init_pins(struct drm_i915_private *dev_priv) @@ -4424,7
> +4425,9 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> if (I915_HAS_HOTPLUG(dev_priv))
> dev_priv->hotplug_funcs = _hpd_funcs;
> } else {
> - if (HAS_PCH_DG1(dev_priv))
> + if (HAS_PCH_DG2(dev_priv))
> + dev_priv->hotplug_funcs = _hpd_funcs;
> + else if (HAS_PCH_DG1(dev_priv))
> dev_priv->hotplug_funcs = _hpd_funcs;
> else if (DISPLAY_VER(dev_priv) >= 11)
> dev_priv->hotplug_funcs = _hpd_funcs; diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index
> 4ea1713e6b60..4d12abb2d7ff 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6182,6 +6182,7 @@
> /* south display engine interrupt: ICP/TGP */
> #define SDE_GMBUS_ICP(1 << 23)
> #define SDE_TC_HOTPLUG_ICP(hpd_pin) REG_BIT(24 +
> _HPD_PIN_TC(hpd_pin))
> +#define SDE_TC_HOTPLUG_DG2(hpd_pin) REG_BIT(25 +
> _HPD_PIN_TC(hpd_pin)) /* sigh */
> #define SDE_DDI_HOTPLUG_ICP(hpd_pin) REG_BIT(16 +
> _HPD_PIN_DDI(hpd_pin))
> #define SDE_DDI_HOTPLUG_MASK_ICP (SDE_DDI_HOTPLUG_ICP(HPD_PORT_D) | \
>SDE_DDI_HOTPLUG_ICP(HPD_PORT_C) | \
> --
> 2.20.1
RE: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: dri-devel On Behalf Of Harry > Wentland > Sent: Wednesday, February 2, 2022 9:42 PM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features > > > > On 2021-09-06 17:38, Uma Shankar wrote: > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > We've had a number of discussions on naming for these properties but I don't > think > we've arrived at a consensus. It has come up repeatedly, though, that > gamma/degamma might be misleading terms. > > I've opened a ticket on gitlab to help track this item and would like it if > we could > discuss the merits of different naming schemes over > there: > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7 > > Uma, I tried to tag you but don't see you on gitlab.freedesktop.org. Thanks Harry for creating the issue. I have replied there and we can discuss and finalize the UAPI. Regards, Uma Shankar > Harry > > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > > > Userspace can take smart blending decisions and utilize these hardware > > supported plane color features to get accurate color profile. The same > > can help in consistent color quality from source to panel taking > > advantage of advanced color features in hardware. > > > > These patches add the property interfaces and enable helper functions. > > This series adds Intel's XE_LPD hw specific plane gamma feature. We > > can build up and add other platform/hardware specific implementation > > on top of this series. > > > > Credits: Special mention and credits to Ville Syrja
RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> -Original Message- > From: Harry Wentland > Sent: Tuesday, November 23, 2021 8:35 PM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: ville.syrj...@linux.intel.com; ppaala...@gmail.com; brian.star...@arm.com; > sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline > > > > On 2021-09-06 17:38, Uma Shankar wrote: > > This is a RFC proposal for plane color hardware blocks. > > It exposes the property interface to userspace and calls out the > > details or interfaces created and the intended purpose. > > > > Credits: Ville Syrjälä > > Signed-off-by: Uma Shankar > > --- > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 > > +++ > > 1 file changed, 167 insertions(+) > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst > > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst > > b/Documentation/gpu/rfc/drm_color_pipeline.rst > > new file mode 100644 > > index ..0d1ca858783b > > --- /dev/null > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst > > @@ -0,0 +1,167 @@ > > +== > > +Display Color Pipeline: Proposed DRM Properties > > +== > > + > > +This is how a typical display color hardware pipeline looks like: > > + +---+ > > + |RAM| > > + | +--++-++-+ | > > + | | FB 1 || FB 2 || FB N| | > > + | +--++-++-+ | > > + +---+ > > + | Plane Color Hardware Block | > > + ++ > > + | +---v-+ +---v---+ +---v--+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | | DeGamma | | Degamma | | Degamma | | > > + | +---+-+ +---+---+ +---+--+ | > > + | | | || > > + | +---v-+ +---v---+ +---v--+ | > > + | |Plane A | | Plane B | | Plane N | | > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + | +---v-+ +v--+ +v-+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | | Gamma | | Gamma | | Gamma| | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + ++ > > ++--v--v---v---| > > +|| || > > +|| Pipe Blender|| > > ++++ > > +||| > > +|+---v--+ | > > +|| Pipe DeGamma| | > > +|| | | > > +|+---+--+ | > > +||Pipe Color | > > +|+---v--+ Hardware| > > +|| Pipe CSC/CTM| | > > +|| | | > > +|+---+--+ | > > +||| > > +|+---v--+ | > > +|| Pipe Gamma | | > > +|| | | > > +|+---+--+ | > > +||| > > ++-+ > > + | > > + v > > + Pipe Output > > + > > This diagram defines what happens before and after the blending space but did > where does scaling fit into it? Scaling can look different when performed in > linear or > non-linear space so I think it is important to define where in the pipeline > it sits. > > In my view scaling would happen between plane degamma and plane CSC. Yeah we can add scaling as well to make it clear. Scaling ideally should happen after Degamma. In intel's case it is after the CSC. Regards, Uma Shankar > Harry > > > +Proposal is to have below properties for a plane: > > + > > +* Plan
RE: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> -Original Message-
> From: Harry Wentland
> Sent: Friday, November 12, 2021 2:41 AM
> To: Shankar, Uma ; Ville Syrjälä
>
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ppaala...@gmail.com; brian.star...@arm.com; sebast...@sebastianwick.net;
> shashank.sha...@amd.com
> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct
> for
> HDR planes
>
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Ville Syrjälä
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland
> >> Cc: Shankar, Uma ;
> >> intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org;
> >> ppaala...@gmail.com; brian.star...@arm.com;
> >> sebast...@sebastianwick.net; shashank.sha...@amd.com
> >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
> >> struct for HDR planes
> >>
> >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >>>
> >>>
> >>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>>> planes have different capabilities, implemented respective
> >>>> structure for the HDR planes.
> >>>>
> >>>> Signed-off-by: Uma Shankar
> >>>> ---
> >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> >>>> ++
> >>>> 1 file changed, 52 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> index afcb4bf3826c..6403bd74324b 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
> >>>> intel_crtc_state
> >> *crtc_state)
> >>>> }
> >>>> }
> >>>>
> >>>> + /* FIXME input bpc? */
> >>>> +__maybe_unused
> >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>>> +/* segment 1 */
> >>>> +{
> >>>> +.flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> +.count = 128,
> >>>> +.input_bpc = 24, .output_bpc = 16,
> >>>> +.start = 0, .end = (1 << 24) - 1,
> >>>> +.min = 0, .max = (1 << 24) - 1,
> >>>> +},
> >>>> +/* segment 2 */
> >>>> +{
> >>>> +.flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> +.count = 1,
> >>>> +.input_bpc = 24, .output_bpc = 16,
> >>>> +.start = (1 << 24) - 1, .end = 1 << 24,
> >>>> +.min = 0, .max = (1 << 27) - 1,
> >>>> +},
> >>>> +/* Segment 3 */
> >>>> +{
> >>>> +.flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> +.count = 1,
> >>>> +.input_bpc = 24, .output_bpc = 16,
> >>>> +.start = 1 << 24, .end = 3 << 24,
> >>>> +.min = 0, .max = (1 << 27) - 1,
> >>>> +},
> >>>> +/* Segment 4 */
> >>>> +{
> >>>> +.flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>
RE: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, November 11, 2021 10:13 PM
> To: Harry Wentland
> Cc: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org; ppaala...@gmail.com; brian.star...@arm.com;
> sebast...@sebastianwick.net; shashank.sha...@amd.com
> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct
> for
> HDR planes
>
> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >
> >
> > On 2021-09-06 17:38, Uma Shankar wrote:
> > > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > > planes have different capabilities, implemented respective structure
> > > for the HDR planes.
> > >
> > > Signed-off-by: Uma Shankar
> > > ---
> > > drivers/gpu/drm/i915/display/intel_color.c | 52
> > > ++
> > > 1 file changed, 52 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index afcb4bf3826c..6403bd74324b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)
> > > }
> > > }
> > >
> > > + /* FIXME input bpc? */
> > > +__maybe_unused
> > > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > > + /* segment 1 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 128,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 0, .end = (1 << 24) - 1,
> > > + .min = 0, .max = (1 << 24) - 1,
> > > + },
> > > + /* segment 2 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = (1 << 24) - 1, .end = 1 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > + /* Segment 3 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 1 << 24, .end = 3 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > + /* Segment 4 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 3 << 24, .end = 7 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > +};
> >
> > If I understand this right, userspace would need this definition in
> > order to populate the degamma blob. Should this sit in a UAPI header?
Hi Harry, Pekka and Ville,
Sorry for being a bit late on the replies, got side tracked with various issues.
I am back on this. Apologies for delay.
> My original idea (not sure it's fully realized in this series) is to have a
> new
> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> value points to a kernel provided blob that contains one of these LUT
> descriptors.
> Userspace can then query them dynamically and pick the best one for its
> current use
> case.
We have this as part of the series Ville. Patch 3 of this series creates a
DEGAMMA_MODE
property just for this. With that userspace can just query the blob_id's and
will get the
various degamma mode possible and the respective segment
RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, October 13, 2021 12:56 PM > To: Shankar, Uma > Cc: Simon Ser ; daniel.vet...@ffwll.ch; intel- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com; > sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline > > On Tue, 12 Oct 2021 19:11:29 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: Pekka Paalanen > > > Sent: Tuesday, October 12, 2021 5:30 PM > > > To: Simon Ser > > > Cc: Shankar, Uma ; > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org; > > > harry.wentl...@amd.com; ville.syrj...@linux.intel.com; > > > brian.star...@arm.com; sebast...@sebastianwick.net; > > > shashank.sha...@amd.com > > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware > > > Pipeline > > > > > > On Tue, 12 Oct 2021 10:35:37 + > > > Simon Ser wrote: > > > > > > > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen > > > wrote: > > > > > > > > > is there a practise of landing proposal documents in the kernel? > > > > > How does that work, will a kernel tree carry the patch files? > > > > > Or should this document be worded like documentation for an > > > > > accepted feature, and then the patches either land or don't? > > > > > > > > Once everyone agrees, the RFC can land. I don't think a kernel > > > > tree is necessary. See: > > > > > > > > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html > > > > > > Does this mean the RFC doc patch will land, but the code patches > > > will remain in the review cycles waiting for userspace proving vehicles? > > > Rather than e.g. committed as files that people would need to apply > > > themselves? Or how does one find the code patches corresponding to RFC > > > docs? > > > > As I understand, this section was added to finalize the design and > > debate on the UAPI, structures, headers and design etc. Once a general > > agreement is in place with all the stakeholders, we can have ack on > > design and approach and get it merged. This hence serves as an approved > reference for the UAPI, accepted and agreed by community at large. > > > > Once the code lands, all the documentation will be added to the right > > driver sections and helpers, like it's been done currently. > > I'm just wondering: someone browses a kernel tree, and discovers this RFC doc > in > there. They want to see or test the latest (WIP) kernel implementation of it. > How will > they find the code / patches? Maybe we could include the WIP links here to help with getting the pieces, this may include the driver patches and also the userspace efforts as well. Regards, Uma Shankar > > Thanks, > pq
RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, October 13, 2021 2:01 PM > To: Shankar, Uma > Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > brian.star...@arm.com; sebast...@sebastianwick.net; > shashank.sha...@amd.com > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline > > On Tue, 12 Oct 2021 20:58:27 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: Pekka Paalanen > > > Sent: Tuesday, October 12, 2021 4:01 PM > > > To: Shankar, Uma > > > Cc: intel-...@lists.freedesktop.org; > > > dri-devel@lists.freedesktop.org; harry.wentl...@amd.com; > > > ville.syrj...@linux.intel.com; brian.star...@arm.com; > > > sebast...@sebastianwick.net; shashank.sha...@amd.com > > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware > > > Pipeline > > > > > > On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar > > > wrote: > > > > > > > This is a RFC proposal for plane color hardware blocks. > > > > It exposes the property interface to userspace and calls out the > > > > details or interfaces created and the intended purpose. > > > > > > > > Credits: Ville Syrjälä > > > > Signed-off-by: Uma Shankar > > > > --- > > > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 > > > > +++ > > > > 1 file changed, 167 insertions(+) create mode 100644 > > > > Documentation/gpu/rfc/drm_color_pipeline.rst > > > > > > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst > > > > b/Documentation/gpu/rfc/drm_color_pipeline.rst > > > > new file mode 100644 > > > > index ..0d1ca858783b > > > > --- /dev/null > > > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst > > > > @@ -0,0 +1,167 @@ > > > > +== > > > > +Display Color Pipeline: Proposed DRM Properties > > ... > > > > > +Proposal is to have below properties for a plane: > > > > + > > > > +* Plane Degamma or Pre-Curve: > > > > + * This will be used to linearize the input framebuffer data. > > > > + * It will apply the reverse of the color transfer function. > > > > + * It can be a degamma curve or OETF for HDR. > > > > > > As you want to produce light-linear values, you use EOTF or inverse OETF. > > > > > > The term OETF has a built-in assumption that that happens in a camera: > > > it takes in light and produces and electrical signal. Lately I > > > have personally started talking about non-linear encoding of color > > > values, since EOTF is often associated with displays if nothing > > > else is said (taking > in an electrical signal and producing light). > > > > > > So this would be decoding the color values into light-linear color > > > values. That is what an EOTF does, yes, but I feel there is a > > > nuanced difference. A piece of equipment implements an EOTF by > > > turning an electrical signal into light, hence EOTF often refers > > > to specific equipment. You could talk about content EOTF to denote > > > content value encoding, as opposed to output or display EOTF, but > > > that might be confusing if you look at e.g. the diagrams in > > > BT.2100: is it the EOTF > or is it the inverse OETF? Is the (inverse?) OOTF included? > > > > > > So I try to side-step those questions by talking about encoding. > > > > The idea here is that frame buffer presented to display plane engine > > will be non- > linear. > > So output of a media decode should result in content with EOTF applied. > > Hi, > > sure, but the question is: which EOTF. There can be many different > things called "EOTF" in a single pipeline, and then it's up to the > document writer to make the difference between them. Comparing two > documents with different conventions causes a lot of confusion in my > personal experience, so it is good to define the concepts more carefully. Hi Pekka, I think you have given some nice inputs to really deep dive and document here. Will update this with the right expectations wrt what transfer functions to be used at various stages in the operation pipeline. > > So output of a media decode should result in content with EOTF applied. > >
RE: [RFC v2 03/22] drm: Add Plane Degamma Mode property
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, October 12, 2021 5:20 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com;
> sebast...@sebastianwick.net; shashank.sha...@amd.com
> Subject: Re: [RFC v2 03/22] drm: Add Plane Degamma Mode property
>
> On Tue, 7 Sep 2021 03:08:45 +0530
> Uma Shankar wrote:
>
> > Add Plane Degamma Mode as an enum property. Create a helper function
> > for all plane color management features.
> >
> > This is an enum property with values as blob_id's and exposes the
> > various gamma modes supported and the lut ranges. Getting the blob id
> > in userspace, user can get the mode supported and also the range of
> > gamma mode supported with number of lut coefficients. It can then set
> > one of the modes using this enum property.
> >
> > Lut values will be sent through separate GAMMA_LUT blob property.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > Documentation/gpu/drm-kms.rst | 90 ++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > drivers/gpu/drm/drm_color_mgmt.c | 93 ++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 23 ++
> > 7 files changed, 212 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst
> > b/Documentation/gpu/drm-kms.rst index 1ef7951ded5e..f4658417bf20
> > 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -545,9 +545,99 @@ Damage Tracking Properties Color Management
> > Properties
> > ---
> >
> > +Below is how a typical hardware pipeline for color will look like:
> > +
> > +.. kernel-render:: DOT
> > + :alt: Display Color Pipeline
> > + :caption: Display Color Pipeline Overview
> > +
> > + digraph "KMS" {
> > + node [shape=box]
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > + label="Display Color Hardware Blocks"
> > +
> > + node [bgcolor=grey style=filled]
> > + "Plane Degamma A" -> "Plane CSC/CTM A"
> > + "Plane CSC/CTM A" -> "Plane Gamma A"
> > + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> > height=0.75];
> > + "Plane Gamma A" -> "Pipe Blender"
> > + "Pipe Blender" -> "Pipe DeGamma"
> > + "Pipe DeGamma" -> "Pipe CSC/CTM"
> > + "Pipe CSC/CTM" -> "Pipe Gamma"
> > + "Pipe Gamma" -> "Pipe Output"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma B" -> "Plane CSC/CTM B"
> > + "Plane CSC/CTM B" -> "Plane Gamma B"
> > + "Plane Gamma B" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma C" -> "Plane CSC/CTM C"
> > + "Plane CSC/CTM C" -> "Plane Gamma C"
> > + "Plane Gamma C" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_fb {
> > + style=dashed
> > + label="RAM"
> > +
> > + node [shape=box width=1.7 height=0.2]
> > +
> > + "FB 1" -> "Plane Degamma A"
> > + "FB 2" -> "Plane Degamma B"
> > + "FB 3" -> "Plane Degamma C"
> > + }
> > + }
> > +
> > +In real world usecases,
> > +
> > +1. Plane Degamma can be used to linearize a non linear gamma encoded
> > +framebuffer. This is needed to do any linear math like color space
> > +conversion. For ex, linearize frames encoded in SRGB or by HDR curve.
>
> Hi,
>
> Maybe better to avoid the term "gamma" as the curves are not always a pure
> power
>
RE: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, October 12, 2021 5:25 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com; > sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features > > On Tue, 7 Sep 2021 03:08:42 +0530 > Uma Shankar wrote: > > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > > > Userspace can take smart blending decisions and utilize these hardware > > supported plane color features to get accurate color profile. The same > > can help in consistent color quality from source to panel taking > > advantage of advanced color features in hardware. > > > > These patches add the property interfaces and enable helper functions. > > This series adds Intel's XE_LPD hw specific plane gamma feature. We > > can build up and add other platform/hardware specific implementation > > on top of this series. > > > > Credits: Special mention and credits to Ville Syrjala for coming up > > with a design for this feature and inputs. This series is based on his > > original design and idea. > > > > Note: Userspace support for this new UAPI will be done on Chrome in > > alignment with weston and general opensource community. > > Discussion ongoing with Harry Wentland, Pekka and community on color > > pipeline and UAPI design. Harry's RFC below: > > https://patchwork.freedesktop.org/series/89506/ > > We need to converge on a common UAPI interface which caters to all the > > modern color hardware pipelines. > > >
RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, October 12, 2021 4:01 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > harry.wentl...@amd.com; ville.syrj...@linux.intel.com; > brian.star...@arm.com; sebast...@sebastianwick.net; > shashank.sha...@amd.com > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline > > On Tue, 7 Sep 2021 03:08:43 +0530 > Uma Shankar wrote: > > > This is a RFC proposal for plane color hardware blocks. > > It exposes the property interface to userspace and calls out the > > details or interfaces created and the intended purpose. > > > > Credits: Ville Syrjälä > > Signed-off-by: Uma Shankar > > --- > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 > > +++ > > 1 file changed, 167 insertions(+) > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst > > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst > > b/Documentation/gpu/rfc/drm_color_pipeline.rst > > new file mode 100644 > > index ..0d1ca858783b > > --- /dev/null > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst > > @@ -0,0 +1,167 @@ > > +== > > +Display Color Pipeline: Proposed DRM Properties > > Hi, > is there a practise of landing proposal documents in the kernel? How > does that work, will a kernel tree carry the patch files? > Or should this document be worded like documentation for an accepted > feature, and then the patches either land or don't? > A thread is forked for this query, we will conclude there. > > +== > > + > > +This is how a typical display color hardware pipeline looks like: > > Typical, or should we say that this is the abstract color pipeline that KMS > assumes? > > Then drivers map this to pieces of hardware the best they can and > reject or do not expose the parts they cannot. Yeah sure Pekka, I will reword this to be clear. > > + +---+ > > + |RAM| > > + | +--++-++-+ | > > + | | FB 1 || FB 2 || FB N| | > > + | +--++-++-+ | > > + +---+ > > + | Plane Color Hardware Block | > > + ++ > > + | +---v-+ +---v---+ +---v--+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | | DeGamma | | Degamma | | Degamma | | > > + | +---+-+ +---+---+ +---+--+ | > > + | | | || > > + | +---v-+ +---v---+ +---v--+ | > > + | |Plane A | | Plane B | | Plane N | | > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + | +---v-+ +v--+ +v-+ | > > + | | Plane A | | Plane B | | Plane N | | > > + | | Gamma | | Gamma | | Gamma| | > > + | +---+-+ ++--+ ++-+ | > > + | | | | | > > + ++ > > ++--v--v---v---| > > +|| || > > +|| Pipe Blender|| > > ++++ > > +||| > > +|+---v--+ | > > +|| Pipe DeGamma| | > > +|| | | > > +|+---+--+ | > > +||Pipe Color | > > +|+---v--+ Hardware| > > +|| Pipe CSC/CTM| | > > +|| | | > > +|+---+--+ | > > +||| > > +|+---v--+ | > > +|| Pipe Gamma | | > > +|| | | > > +|+---+--+ | > > +||| > > ++-+ > > + | > > + v > > + Pipe Output &
RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, October 12, 2021 5:30 PM > To: Simon Ser > Cc: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org; harry.wentl...@amd.com; > ville.syrj...@linux.intel.com; brian.star...@arm.com; > sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline > > On Tue, 12 Oct 2021 10:35:37 + > Simon Ser wrote: > > > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen > wrote: > > > > > is there a practise of landing proposal documents in the kernel? How > > > does that work, will a kernel tree carry the patch files? > > > Or should this document be worded like documentation for an accepted > > > feature, and then the patches either land or don't? > > > > Once everyone agrees, the RFC can land. I don't think a kernel tree is > > necessary. See: > > > > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html > > Does this mean the RFC doc patch will land, but the code patches will remain > in the > review cycles waiting for userspace proving vehicles? > Rather than e.g. committed as files that people would need to apply > themselves? Or > how does one find the code patches corresponding to RFC docs? As I understand, this section was added to finalize the design and debate on the UAPI, structures, headers and design etc. Once a general agreement is in place with all the stakeholders, we can have ack on design and approach and get it merged. This hence serves as an approved reference for the UAPI, accepted and agreed by community at large. Once the code lands, all the documentation will be added to the right driver sections and helpers, like it's been done currently. @daniel.vet...@ffwll.ch Hope this is the right understanding. Thanks & Regards, Uma Shankar > > Thanks, > pq
RE: [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO
> -Original Message-
> From: Nikula, Jani
> Sent: Monday, September 13, 2021 3:00 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com
> Subject: RE: [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor
> block
> for MSO
>
> On Mon, 13 Sep 2021, "Shankar, Uma" wrote:
> >> -Original Message-
> >> From: dri-devel On Behalf
> >> Of Jani Nikula
> >> Sent: Tuesday, August 31, 2021 7:48 PM
> >> To: intel-...@lists.freedesktop.org
> >> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> >> Nikula, Jani
> >> Subject: [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA
> >> vendor block for MSO
> >>
> >> The VESA Organization Vendor-Specific Data Block, defined in VESA
> >> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
> >> stream count and segment pixel overlap.
> >>
> >> DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
> >> describing how DisplayID sections may be embedded in EDID extension
> >> blocks. DisplayID v2.0 does not have such a section, perhaps implying
> >> that DisplayID v2.0 data should not be included in EDID extensions,
> >> but rather in a "pure" DisplayID structure at its own DDC address pair
> >> A4h/A5h, as
> described in VESA E-DDC Standard v1.3 chapter 3.
> >>
> >> However, in practice, displays out in the field have embedded
> >> DisplayID
> >> v2.0 data blocks in EDID extensions, including, in particular, some
> >> eDP MSO displays, where a pure DisplayID structure is not available at all.
> >>
> >> Parse the MSO data from the DisplayID data block. Do it as part of
> >> drm_add_display_info(), extending it to parse also DisplayID data to
> >> avoid requiring extra calls to update the information.
> >>
> >> v2: Check for VESA OUI (Ville)
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 72
> >> +
> >> include/drm/drm_connector.h | 12 +++
> >> include/drm/drm_displayid.h | 13
> >> +++
> >> 3 files changed, 97 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 92974b1478bc..c45c225267ca 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -28,6 +28,7 @@
> >> * DEALINGS IN THE SOFTWARE.
> >> */
> >>
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -5145,6 +5146,71 @@ void drm_get_monitor_range(struct
> >> drm_connector *connector,
> >> info->monitor_range.max_vfreq); }
> >>
> >> +static void drm_parse_vesa_mso_data(struct drm_connector *connector,
> >> + const struct displayid_block *block) {
> >> + struct displayid_vesa_vendor_specific_block *vesa =
> >> + (struct displayid_vesa_vendor_specific_block *)block;
> >> + struct drm_display_info *info = >display_info;
> >> +
> >> + if (block->num_bytes < 3) {
> >> + drm_dbg_kms(connector->dev, "Unexpected vendor block size
> >> %u\n",
> >> + block->num_bytes);
> >> + return;
> >> + }
> >> +
> >> + if (oui(vesa->oui[0], vesa->oui[1], vesa->oui[2]) != VESA_IEEE_OUI)
> >> + return;
> >> +
> >> + if (sizeof(*vesa) != sizeof(*block) + block->num_bytes) {
> >> + drm_dbg_kms(connector->dev, "Unexpected VESA vendor block
> >> size\n");
> >> + return;
> >> + }
> >> +
> >> + switch (FIELD_GET(DISPLAYID_VESA_MSO_MODE, vesa->mso)) {
> >> + default:
> >> + drm_dbg_kms(connector->dev, "Reserved MSO mode value\n");
> >> + fallthrough;
> >> + case 0:
> >> + info->mso_stream_count = 0;
> >> + break;
> >> + case 1:
> >> + info->mso_stream_count = 2; /* 2 or 4 links */
> >> + break;
> >> + case 2:
> >> + info->mso_stream_count = 4; /* 4 links */
> >> + break;
> >> + }
> >> +
> >> + if (!info->mso_stream_count) {
> >> +
RE: [Intel-gfx] [PATCH v2 6/6] drm/i915/edp: use MSO pixel overlap from DisplayID data
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Tuesday, August 31, 2021 7:48 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula,
> Jani
>
> Subject: [Intel-gfx] [PATCH v2 6/6] drm/i915/edp: use MSO pixel overlap from
> DisplayID data
>
> Now that we have MSO pixel overlap in display info, use it.
>
Looks ok to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index df402f63b741..baf21f9aa40e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2420,6 +2420,8 @@ static void intel_edp_mso_mode_fixup(struct
> intel_connector *connector, static void intel_edp_mso_init(struct intel_dp
> *intel_dp) {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct drm_display_info *info = >base.display_info;
> u8 mso;
>
> if (intel_dp->edp_dpcd[0] < DP_EDP_14) @@ -2438,8 +2440,9 @@ static
> void intel_edp_mso_init(struct intel_dp *intel_dp)
> }
>
> if (mso) {
> - drm_dbg_kms(>drm, "Sink MSO %ux%u configuration\n",
> - mso, drm_dp_max_lane_count(intel_dp->dpcd) / mso);
> + drm_dbg_kms(>drm, "Sink MSO %ux%u configuration, pixel
> overlap %u\n",
> + mso, drm_dp_max_lane_count(intel_dp->dpcd) / mso,
> + info->mso_pixel_overlap);
> if (!HAS_MSO(i915)) {
> drm_err(>drm, "No source MSO support,
> disabling\n");
> mso = 0;
> @@ -2447,7 +2450,7 @@ static void intel_edp_mso_init(struct intel_dp
> *intel_dp)
> }
>
> intel_dp->mso_link_count = mso;
> - intel_dp->mso_pixel_overlap = 0; /* FIXME: read from DisplayID v2.0 */
> + intel_dp->mso_pixel_overlap = mso ? info->mso_pixel_overlap : 0;
> }
>
> static bool
> --
> 2.30.2
RE: [Intel-gfx] [PATCH v2 5/6] drm/i915/edp: postpone MSO init until after EDID read
> -Original Message- > From: Intel-gfx On Behalf Of Jani > Nikula > Sent: Tuesday, August 31, 2021 7:48 PM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula, > Jani > > Subject: [Intel-gfx] [PATCH v2 5/6] drm/i915/edp: postpone MSO init until > after EDID > read > > MSO will require segment pixel overlap information from the EDID. Postpone MSO > init until after we've read and cached the EDID. > Looks ok to me. Reviewed-by: Uma Shankar > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_dp.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 64e8151d13a4..df402f63b741 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -2536,8 +2536,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp) >*/ > intel_edp_init_source_oui(intel_dp, true); > > - intel_edp_mso_init(intel_dp); > - > return true; > } > > @@ -4804,6 +4802,9 @@ static bool intel_edp_init_connector(struct intel_dp > *intel_dp, > if (fixed_mode) > downclock_mode = intel_drrs_init(intel_connector, fixed_mode); > > + /* MSO requires information from the EDID */ > + intel_edp_mso_init(intel_dp); > + > /* multiply the mode clock and horizontal timings for MSO */ > intel_edp_mso_mode_fixup(intel_connector, fixed_mode); > intel_edp_mso_mode_fixup(intel_connector, downclock_mode); > -- > 2.30.2
RE: [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO
> -Original Message-
> From: dri-devel On Behalf Of Jani
> Nikula
> Sent: Tuesday, August 31, 2021 7:48 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula,
> Jani
>
> Subject: [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor block
> for
> MSO
>
> The VESA Organization Vendor-Specific Data Block, defined in VESA DisplayID
> Standard v2.0, specifies the eDP Multi-SST Operation (MSO) stream count and
> segment pixel overlap.
>
> DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension, describing how
> DisplayID sections may be embedded in EDID extension blocks. DisplayID v2.0
> does
> not have such a section, perhaps implying that DisplayID v2.0 data should not
> be
> included in EDID extensions, but rather in a "pure" DisplayID structure at
> its own DDC
> address pair A4h/A5h, as described in VESA E-DDC Standard v1.3 chapter 3.
>
> However, in practice, displays out in the field have embedded DisplayID
> v2.0 data blocks in EDID extensions, including, in particular, some eDP MSO
> displays,
> where a pure DisplayID structure is not available at all.
>
> Parse the MSO data from the DisplayID data block. Do it as part of
> drm_add_display_info(), extending it to parse also DisplayID data to avoid
> requiring
> extra calls to update the information.
>
> v2: Check for VESA OUI (Ville)
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 72 +
> include/drm/drm_connector.h | 12 +++ include/drm/drm_displayid.h | 13
> +++
> 3 files changed, 97 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 92974b1478bc..c45c225267ca 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -28,6 +28,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -5145,6 +5146,71 @@ void drm_get_monitor_range(struct drm_connector
> *connector,
> info->monitor_range.max_vfreq); }
>
> +static void drm_parse_vesa_mso_data(struct drm_connector *connector,
> + const struct displayid_block *block) {
> + struct displayid_vesa_vendor_specific_block *vesa =
> + (struct displayid_vesa_vendor_specific_block *)block;
> + struct drm_display_info *info = >display_info;
> +
> + if (block->num_bytes < 3) {
> + drm_dbg_kms(connector->dev, "Unexpected vendor block size
> %u\n",
> + block->num_bytes);
> + return;
> + }
> +
> + if (oui(vesa->oui[0], vesa->oui[1], vesa->oui[2]) != VESA_IEEE_OUI)
> + return;
> +
> + if (sizeof(*vesa) != sizeof(*block) + block->num_bytes) {
> + drm_dbg_kms(connector->dev, "Unexpected VESA vendor block
> size\n");
> + return;
> + }
> +
> + switch (FIELD_GET(DISPLAYID_VESA_MSO_MODE, vesa->mso)) {
> + default:
> + drm_dbg_kms(connector->dev, "Reserved MSO mode value\n");
> + fallthrough;
> + case 0:
> + info->mso_stream_count = 0;
> + break;
> + case 1:
> + info->mso_stream_count = 2; /* 2 or 4 links */
> + break;
> + case 2:
> + info->mso_stream_count = 4; /* 4 links */
> + break;
> + }
> +
> + if (!info->mso_stream_count) {
> + info->mso_pixel_overlap = 0;
> + return;
> + }
> +
> + info->mso_pixel_overlap = FIELD_GET(DISPLAYID_VESA_MSO_OVERLAP,
> vesa->mso);
> + if (info->mso_pixel_overlap > 8) {
> + drm_dbg_kms(connector->dev, "Reserved MSO pixel overlap value
> %u\n",
> + info->mso_pixel_overlap);
> + info->mso_pixel_overlap = 8;
Going beyond 8 is not right from a vendor perspective as it goes into reserved
region.
Should we not just set to 0 or how we decide that we fixed overlap at 8. It
seems an
undefined operation and it may vary from sink to sink.
Regards,
Uma Shankar
> + }
> +
> + drm_dbg_kms(connector->dev, "MSO stream count %u, pixel overlap %u\n",
> + info->mso_stream_count, info->mso_pixel_overlap); }
> +
> +static void drm_update_mso(struct drm_connector *connector, const
> +struct edid *edid) {
> + const struct displayid_block *block;
> + struct displayid_iter iter;
> +
> + displayid_iter_edid_begin(edid, );
> + displayid_iter_for_each(block, ) {
> + if (block->tag == DATA_BLOCK_2_VENDOR_SPECIFIC)
> + drm_parse_vesa_mso_data(connector, block);
> + }
> + displayid_iter_end();
> +}
> +
> /* A connector has no EDID information, so we've got no EDID to compute
> quirks
> from. Reset
> * all of the values which would have been set from EDID
> */
> @@ -5168,6 +5234,9 @@ drm_reset_display_info(struct drm_connector
> *connector)
>
> info->non_desktop = 0;
RE: [PATCH v2 3/6] drm/edid: abstract OUI conversion to 24-bit int
> -Original Message-
> From: dri-devel On Behalf Of Jani
> Nikula
> Sent: Tuesday, August 31, 2021 7:48 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula,
> Jani
>
> Subject: [PATCH v2 3/6] drm/edid: abstract OUI conversion to 24-bit int
>
> Replace the open coded OUI conversion from three bytes to a 24-bit int, as
> we'll be
> adding one more user shortly. No functional changes.
>
> Side note: CTA-861 format has the OUI bytes in reverse order.
Looks ok to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 6325877c5fd6..92974b1478bc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -49,6 +49,11 @@
> (((edid)->version > (maj)) || \
>((edid)->version == (maj) && (edid)->revision > (min)))
>
> +static int oui(u8 first, u8 second, u8 third) {
> + return (first << 16) | (second << 8) | third; }
> +
> #define EDID_EST_TIMINGS 16
> #define EDID_STD_TIMINGS 8
> #define EDID_DETAILED_TIMINGS 4
> @@ -4113,32 +4118,24 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
>
> static bool cea_db_is_hdmi_vsdb(const u8 *db) {
> - int hdmi_id;
> -
> if (cea_db_tag(db) != VENDOR_BLOCK)
> return false;
>
> if (cea_db_payload_len(db) < 5)
> return false;
>
> - hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
> -
> - return hdmi_id == HDMI_IEEE_OUI;
> + return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
> }
>
> static bool cea_db_is_hdmi_forum_vsdb(const u8 *db) {
> - unsigned int oui;
> -
> if (cea_db_tag(db) != VENDOR_BLOCK)
> return false;
>
> if (cea_db_payload_len(db) < 7)
> return false;
>
> - oui = db[3] << 16 | db[2] << 8 | db[1];
> -
> - return oui == HDMI_FORUM_IEEE_OUI;
> + return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
> }
>
> static bool cea_db_is_vcdb(const u8 *db)
> --
> 2.30.2
RE: [Intel-gfx] [PATCH v2 2/6] drm/displayid: add DisplayID v2.0 data blocks and primary use cases
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Tuesday, August 31, 2021 7:48 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula,
> Jani
>
> Subject: [Intel-gfx] [PATCH v2 2/6] drm/displayid: add DisplayID v2.0 data
> blocks and
> primary use cases
>
> DisplayID v2.0 changes the data block identifiers and product types (now
> called
> primary use cases).
Looks ok to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_displayid.h | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h index
> 0ed9445b5482..79771091771a 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -26,6 +26,10 @@
>
> struct edid;
>
> +/* DisplayID Structure versions */
> +#define DISPLAY_ID_STRUCTURE_VER_12 0x12
> +#define DISPLAY_ID_STRUCTURE_VER_20 0x20
> +
> /* DisplayID Structure v1r2 Data Blocks */
> #define DATA_BLOCK_PRODUCT_ID0x00
> #define DATA_BLOCK_DISPLAY_PARAMETERS0x01
> @@ -48,6 +52,20 @@ struct edid;
> #define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
> #define DATA_BLOCK_CTA 0x81
>
> +/* DisplayID Structure v2r0 Data Blocks */
> +#define DATA_BLOCK_2_PRODUCT_ID 0x20
> +#define DATA_BLOCK_2_DISPLAY_PARAMETERS 0x21
> +#define DATA_BLOCK_2_TYPE_7_DETAILED_TIMING 0x22
> +#define DATA_BLOCK_2_TYPE_8_ENUMERATED_TIMING0x23
> +#define DATA_BLOCK_2_TYPE_9_FORMULA_TIMING 0x24
> +#define DATA_BLOCK_2_DYNAMIC_VIDEO_TIMING0x25
> +#define DATA_BLOCK_2_DISPLAY_INTERFACE_FEATURES 0x26
> +#define DATA_BLOCK_2_STEREO_DISPLAY_INTERFACE0x27
> +#define DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY 0x28
> +#define DATA_BLOCK_2_CONTAINER_ID0x29
> +#define DATA_BLOCK_2_VENDOR_SPECIFIC 0x7e
> +#define DATA_BLOCK_2_CTA_DISPLAY_ID 0x81
> +
> /* DisplayID Structure v1r2 Product Type */
> #define PRODUCT_TYPE_EXTENSION 0
> #define PRODUCT_TYPE_TEST1
> @@ -57,6 +75,17 @@ struct edid;
> #define PRODUCT_TYPE_REPEATER5
> #define PRODUCT_TYPE_DIRECT_DRIVE6
>
> +/* DisplayID Structure v2r0 Display Product Primary Use Case (~Product Type)
> */
> +#define PRIMARY_USE_EXTENSION0
> +#define PRIMARY_USE_TEST 1
> +#define PRIMARY_USE_GENERIC 2
> +#define PRIMARY_USE_TV 3
> +#define PRIMARY_USE_DESKTOP_PRODUCTIVITY 4
> +#define PRIMARY_USE_DESKTOP_GAMING 5
> +#define PRIMARY_USE_PRESENTATION 6
> +#define PRIMARY_USE_HEAD_MOUNTED_VR 7
> +#define PRIMARY_USE_HEAD_MOUNTED_AR 8
> +
> struct displayid_header {
> u8 rev;
> u8 bytes;
> --
> 2.30.2
RE: [PATCH v2 1/6] drm/displayid: re-align data block macros
> -Original Message-
> From: dri-devel On Behalf Of Jani
> Nikula
> Sent: Tuesday, August 31, 2021 7:48 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula,
> Jani
>
> Subject: [PATCH v2 1/6] drm/displayid: re-align data block macros
>
> Make the values easier to read. Also add DisplayID Structure version and
> revision
> information (this is different from the spec version).
Looks ok to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_displayid.h | 57 +++--
> 1 file changed, 29 insertions(+), 28 deletions(-)
>
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h index
> ec64d141f578..0ed9445b5482 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -26,35 +26,36 @@
>
> struct edid;
>
> -#define DATA_BLOCK_PRODUCT_ID 0x00
> -#define DATA_BLOCK_DISPLAY_PARAMETERS 0x01 -#define
> DATA_BLOCK_COLOR_CHARACTERISTICS 0x02 -#define
> DATA_BLOCK_TYPE_1_DETAILED_TIMING 0x03 -#define
> DATA_BLOCK_TYPE_2_DETAILED_TIMING 0x04 -#define
> DATA_BLOCK_TYPE_3_SHORT_TIMING 0x05 -#define
> DATA_BLOCK_TYPE_4_DMT_TIMING 0x06 -#define DATA_BLOCK_VESA_TIMING
> 0x07 -#define DATA_BLOCK_CEA_TIMING 0x08 -#define
> DATA_BLOCK_VIDEO_TIMING_RANGE 0x09 -#define
> DATA_BLOCK_PRODUCT_SERIAL_NUMBER 0x0a -#define
> DATA_BLOCK_GP_ASCII_STRING 0x0b -#define
> DATA_BLOCK_DISPLAY_DEVICE_DATA 0x0c -#define
> DATA_BLOCK_INTERFACE_POWER_SEQUENCING 0x0d -#define
> DATA_BLOCK_TRANSFER_CHARACTERISTICS 0x0e -#define
> DATA_BLOCK_DISPLAY_INTERFACE 0x0f -#define
> DATA_BLOCK_STEREO_DISPLAY_INTERFACE 0x10 -#define
> DATA_BLOCK_TILED_DISPLAY 0x12 -#define DATA_BLOCK_CTA 0x81
> +/* DisplayID Structure v1r2 Data Blocks */
> +#define DATA_BLOCK_PRODUCT_ID0x00
> +#define DATA_BLOCK_DISPLAY_PARAMETERS0x01
> +#define DATA_BLOCK_COLOR_CHARACTERISTICS 0x02
> +#define DATA_BLOCK_TYPE_1_DETAILED_TIMING0x03
> +#define DATA_BLOCK_TYPE_2_DETAILED_TIMING0x04
> +#define DATA_BLOCK_TYPE_3_SHORT_TIMING 0x05
> +#define DATA_BLOCK_TYPE_4_DMT_TIMING 0x06
> +#define DATA_BLOCK_VESA_TIMING 0x07
> +#define DATA_BLOCK_CEA_TIMING0x08
> +#define DATA_BLOCK_VIDEO_TIMING_RANGE0x09
> +#define DATA_BLOCK_PRODUCT_SERIAL_NUMBER 0x0a
> +#define DATA_BLOCK_GP_ASCII_STRING 0x0b
> +#define DATA_BLOCK_DISPLAY_DEVICE_DATA 0x0c
> +#define DATA_BLOCK_INTERFACE_POWER_SEQUENCING0x0d
> +#define DATA_BLOCK_TRANSFER_CHARACTERISTICS 0x0e
> +#define DATA_BLOCK_DISPLAY_INTERFACE 0x0f
> +#define DATA_BLOCK_STEREO_DISPLAY_INTERFACE 0x10
> +#define DATA_BLOCK_TILED_DISPLAY 0x12
> +#define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
> +#define DATA_BLOCK_CTA 0x81
>
> -#define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
> -
> -#define PRODUCT_TYPE_EXTENSION 0
> -#define PRODUCT_TYPE_TEST 1
> -#define PRODUCT_TYPE_PANEL 2
> -#define PRODUCT_TYPE_MONITOR 3
> -#define PRODUCT_TYPE_TV 4
> -#define PRODUCT_TYPE_REPEATER 5
> -#define PRODUCT_TYPE_DIRECT_DRIVE 6
> +/* DisplayID Structure v1r2 Product Type */
> +#define PRODUCT_TYPE_EXTENSION 0
> +#define PRODUCT_TYPE_TEST1
> +#define PRODUCT_TYPE_PANEL 2
> +#define PRODUCT_TYPE_MONITOR 3
> +#define PRODUCT_TYPE_TV 4
> +#define PRODUCT_TYPE_REPEATER5
> +#define PRODUCT_TYPE_DIRECT_DRIVE6
>
> struct displayid_header {
> u8 rev;
> --
> 2.30.2
RE: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
> -Original Message- > From: sebast...@sebastianwick.net > Sent: Monday, August 16, 2021 7:07 PM > To: Harry Wentland > Cc: Brian Starkey ; Sharma, Shashank > ; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; ppaala...@gmail.com; mca...@google.com; > jsha...@google.com; deepak.sha...@amd.com; shiris...@amd.com; > vitaly.pros...@amd.com; aric@amd.com; bhawanpreet.la...@amd.com; > krunoslav.ko...@amd.com; hersenxs...@amd.com; > nicholas.kazlaus...@amd.com; laurentiu.pa...@oss.nxp.com; > ville.syrj...@linux.intel.com; n...@arm.com; Shankar, Uma > > Subject: Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC > > On 2021-08-16 14:40, Harry Wentland wrote: > > On 2021-08-16 7:10 a.m., Brian Starkey wrote: > >> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote: > >>> Hello Brian, > >>> (+Uma in cc) > >>> Thanks Shashank for cc'ing me. Apologies for being late here. Now seems all stakeholders are back so we can resume the UAPI discussion on color. > >>> Thanks for your comments, Let me try to fill-in for Harry to keep > >>> the design discussion going. Please find my comments inline. > >>> > > > > Thanks, Shashank. I'm back at work now. Had to cut my trip short due > > to rising Covid cases and concern for my kids. > > > >>> On 8/2/2021 10:00 PM, Brian Starkey wrote: > >>>> > >> > >> -- snip -- > >> > >>>> > >>>> Android doesn't blend in linear space, so any API shouldn't be > >>>> built around an assumption of linear blending. > >>>> > > > > This seems incorrect but I guess ultimately the OS is in control of > > this. If we want to allow blending in non-linear space with the new > > API we would either need to describe the blending space or the > > pre/post-blending gamma/de-gamma. > > > > Any idea if this blending behavior in Android might get changed in the > > future? > > There is lots of software which blends in sRGB space and designers adjusted > to the > incorrect blending in a way that the result looks right. > Blending in linear space would result in incorrectly looking images. > I feel we should just leave it to userspace to decide rather than forcing linear or non Linear blending in driver. > >>> > >>> If I am not wrong, we still need linear buffers for accurate Gamut > >>> transformation (SRGB -> BT2020 or other way around) isn't it ? > >> > >> Yeah, you need to transform the buffer to linear for color gamut > >> conversions, but then back to non-linear (probably sRGB or gamma 2.2) > >> for actual blending. > >> > >> This is why I'd like to have the per-plane "OETF/GAMMA" separate from > >> tone-mapping, so that the composition transfer function is > >> independent. > >> > >>> > >> > >> ... > >> > >>>>> + > >>>>> +Tonemapping in this case could be a simple nits value or `EDR`_ > >>>>> +to > >>>>> describe > >>>>> +how to scale the :ref:`SDR luminance`. > >>>>> + > >>>>> +Tonemapping could also include the ability to use a 3D LUT which > >>>>> might be > >>>>> +accompanied by a 1D shaper LUT. The shaper LUT is required in > >>>>> order to > >>>>> +ensure a 3D LUT with limited entries (e.g. 9x9x9, or 17x17x17) > >>>>> operates > >>>>> +in perceptual (non-linear) space, so as to evenly spread the > >>>>> limited > >>>>> +entries evenly across the perceived space. > >>>> > >>>> Some terminology care may be needed here - up until this point, I > >>>> think you've been talking about "tonemapping" being luminance > >>>> adjustment, whereas I'd expect 3D LUTs to be used for gamut > >>>> adjustment. > >>>> > >>> > >>> IMO, what harry wants to say here is that, which HW block gets > >>> picked and how tone mapping is achieved can be a very driver/HW > >>> specific thing, where one driver can use a 1D/Fixed function block, > >>> whereas another one can choose more complex HW like a 3D LUT for the > >>> same. > >>> > >>> DRM layer needs to define only the property to hook the API with > >>> core driver, and the driver can decide which HW to pick and > >>> confi
RE: [PATCH 04/21] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> -Original Message-
> From: dri-devel On Behalf Of Harry
> Wentland
> Sent: Monday, June 28, 2021 8:45 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash
> Subject: Re: [PATCH 04/21] drm/i915/xelpd: Define Degamma Lut range struct for
> HDR planes
>
> On 2021-06-01 6:52 a.m., Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective structure
> > for the HDR planes.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 52
> > ++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index dab892d2251b..c735d06a6b54 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -2093,6 +2093,58 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)
> > }
> > }
> >
> > + /* FIXME input bpc? */
> > +__maybe_unused
> > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
>
> Why are these using DRM_MODE_LUT_GAMMA and not
> DRM_MODE_LUT_DEGAMMA when the lut_type for this LUT is
> LUT_TYPE_DEGAMMA?
Thanks Harry for the comments.
Yeah this is an oversight, will fix this.
>
>
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
>
> Why do we need more than 16 bpc for LUT? FP16 is enough to represent HDR in
> linear space. Wouldn't 16 bpc be enough?
Pipe sometimes works internally on higher precision (just to take care of
rounding etc.), later the
extra data gets dropped at the end of the pipe. So from source side you are
right, 16bpc is enough
but the lut precision can go higher.
>
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
>
> How can max be 1 << 27 if input_bpc is 24?
This is to take care of > 1.0 section. 1.0 to 3.0 and 3.0 to 7.0.
So we have 3.24 format for Lut to take care of this.
Also, I have an action to update the series with UAPI doc and new naming for
the property.
My apologies for being late on that one. Will update and send that out soon.
Thanks & Regards,
Uma Shankar
>
> Harry
>
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 1 << 24, .end = 3 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 4 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 3 << 24, .end = 7 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > +};
> > +
> > void intel_color_init(struct intel_crtc *crtc)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
RE: [PATCH 0/9] Enhance pipe color support for multi segmented luts
> -Original Message- > From: dri-devel On Behalf Of Pekka > Paalanen > Sent: Monday, June 7, 2021 1:00 PM > To: Harry Wentland > Cc: intel-...@lists.freedesktop.org; Shankar, Uma ; > Sebastian Wick ; dri-devel@lists.freedesktop.org; > Modem, Bhanuprakash > Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts > > On Fri, 4 Jun 2021 14:51:25 -0400 > Harry Wentland wrote: > > > On 2021-06-01 6:41 a.m., Uma Shankar wrote: > > > Modern hardwares have multi segmented lut approach to prioritize the > > > darker regions of the spectrum. This series introduces a new UAPI to > > > define the lut ranges supported by the respective hardware. > > > > > > This also enables Pipe Color Management Support for Intel's XE_LPD hw. > > > Enable Support for Pipe Degamma with the increased lut samples > > > supported by hardware. This also adds support for newly introduced > > > Logarithmic Gamma for XE_LPD. Also added the gamma readout support. > > > > > > The Logarithmic gamma implementation on XE_LPD is non linear and > > > adds 25 segments with non linear lut samples in each segment. The > > > expectation is userspace will create the luts as per this > > > distribution and pass the final samples to driver to be programmed in > > > hardware. > > > > > > > Is this design targetting Intel XE_LPD HW in particular or is it > > intended to be generic? > > > > If this is intended to be generic I think it would benefit from a lot > > more documentation. At this point it's difficult for me to see how to > > adapt this to AMD HW. It would take me a while to be comfortable to > > make a call on whether we can use it or not. And what about other vendors? > > > > I think we need to be cautious in directly exposing HW functionality > > through UAPI. The CM parts of AMD HW seem to be changing in some way > > each generation and it looks like the same is true for Intel. The > > trouble we have with adapting the old gamma/degamma properties to > > modern HW is some indication to me that this approach is somewhat > > problematic. > > > > It would be useful to understand and document the specific use-cases > > we want to provide to userspace implementers with this functionality. > > Do we want to support modern transfer functions such as PQ or HLG? If > > so, it might be beneficial to have an API to explicitly specify that, > > and then use LUT tables in drivers that are optimized for the implementing > > HW. > > Hi Harry, > > from my very limited understanding so far, enum might be fine for PQ, but HLG > is not > just one transfer function, although it may often be confused as one. PQ and > HLG > are fundamentally different designs to HDR broadcasting I believe. It would be > unfortunate to make a mistake here, engraving it into UAPI. Yes Pekka, putting this in UAPI may limit us. > > Or is the use case tone mapping? If so, would a parametric definition > > of tone mapping be easier to manage? > > A very good question at least I have no idea about. Responded on earlier mail in thread. For non linear lut (gamma block), usecase is primarily tone mapping but there are implementations where non linear blending is seeked (AFAIR Android does that), so it leaves room for those usecases as well. Regards, Uma Shankar > > Thanks, > pq > > > > +-+--+ > > > | x | 2 pow x segment|No of Entries > > > | | 0 | 1 | > > > | 0 | 1 | 1 | > > > | 1 | 2 | 2 | > > > | 2 | 4 | 2 | > > > | 3 | 8 | 2 | > > > | 4 | 16 | 2 | > > > | 5 | 32 | 4 | > > > | 6 | 64 | 4 | > > > | 7 | 128| 4 | > > > | 8 | 256| 8 | > > > | 9 | 512| 8 | > > > | 10 | 1024 | 8 | > > > | 11 | 2048 | 16 | > > > | 12 | 4096 | 16 | > > > | 13 | 8192 | 16 | > > > | 14 | 16384 | 32 | > > > | 15 | 32768 | 32 | > > > | 16 | 65536 | 64 | > > > | 17 | 131072 | 64 | > > > | 18 | 262144 | 64 | > > > | 19 | 524288 | 32 | > > > | 20 | 1048576| 32 | > > >
RE: [PATCH 0/9] Enhance pipe color support for multi segmented luts
> -Original Message- > From: Harry Wentland > Sent: Saturday, June 5, 2021 12:21 AM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: Modem, Bhanuprakash ; Cyr, Aric > > Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts > > On 2021-06-01 6:41 a.m., Uma Shankar wrote: > > Modern hardwares have multi segmented lut approach to prioritize the > > darker regions of the spectrum. This series introduces a new UAPI to > > define the lut ranges supported by the respective hardware. > > > > This also enables Pipe Color Management Support for Intel's XE_LPD hw. > > Enable Support for Pipe Degamma with the increased lut samples > > supported by hardware. This also adds support for newly introduced > > Logarithmic Gamma for XE_LPD. Also added the gamma readout support. > > > > The Logarithmic gamma implementation on XE_LPD is non linear and adds > > 25 segments with non linear lut samples in each segment. The > > expectation is userspace will create the luts as per this distribution > > and pass the final samples to driver to be programmed in hardware. > > > > Is this design targetting Intel XE_LPD HW in particular or is it intended to > be generic? > > If this is intended to be generic I think it would benefit from a lot more > documentation. At this point it's difficult for me to see how to adapt this > to AMD > HW. It would take me a while to be comfortable to make a call on whether we > can > use it or not. And what about other vendors? This is expected to be generic for all vendors. XE_LPD is just a reference implementation. It's basically an extension of what we have for crtc color but designing the UAPI to have it more scalable for future hardware. The legacy hardware implementation which we have in crtc properties can easily fit in this new UAPI and this can help represent hardware better with more precision and scalability. Credits to Ville as to this is his idea of how we can represent hardware generically and advertise to userspace. Sure, I will add more documentation to make this clearer. > I think we need to be cautious in directly exposing HW functionality through > UAPI. > The CM parts of AMD HW seem to be changing in some way each generation and it > looks like the same is true for Intel. The trouble we have with adapting the > old > gamma/degamma properties to modern HW is some indication to me that this > approach is somewhat problematic. > The advantage of having flexibility in userspace is that we give access of hardware to userspace.It can then control things based on various usecases and not limited by just a subset of operations what we define (in the lack of such an implementation). > It would be useful to understand and document the specific use-cases we want > to > provide to userspace implementers with this functionality. Do we want to > support > modern transfer functions such as PQ or HLG? If so, it might be beneficial to > have an > API to explicitly specify that, and then use LUT tables in drivers that are > optimized for > the implementing HW. Or is the use case tone mapping? If so, would a > parametric > definition of tone mapping be easier to manage? > Yes right, ideally this is what intend to achieve here. We cant have fixed tables for operations like Tone mapping as it will depend on mastering luminance values which can vary along with other attributes of metadata. Eventually this operation would be done by the gamma block (non linear luts), the values for which would be calculated and send by userspace. Thus making all this very generic. Also we can't do any color math in driver as it has lot of floating operations. So here the trade-off is between having a UAPI where userspace controls hw, computes and sends values vs having just a fixed function operations with hard coded lut tables in driver. Maybe we can have both the options in order to give flexibility to hardware vendors. We can document the usage of the UAPI we create which can help things co-exist. Userspace can query the supported properties and implement based on the properties exposed by the respective vendor driver implementation. My personal preference would be to go with generic option (expose hardware to userspace) which will make life easier for userspace developers. This will help use hardware for any color operation not just limited to linearization, CSC conversions and tone mapping. Also this is already done for crtc, so it just need to be extended to planes. > > +-+--+ > > | x | 2 pow x segment|No of Entries > > | | 0 | 1 | > > | 0 | 1 | 1 | > > | 1
RE: [PATCH 02/21] drm: Add Plane Degamma Mode property
> -Original Message-
> From: Harry Wentland
> Sent: Friday, June 4, 2021 11:54 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash ; Cyr, Aric
>
> Subject: Re: [PATCH 02/21] drm: Add Plane Degamma Mode property
>
> On 2021-06-01 6:51 a.m., Uma Shankar wrote:
> > Add Plane Degamma Mode as an enum property. Create a helper function
> > for all plane color management features.
> >
> > This is an enum property with values as blob_id's and exposes the
> > various gamma modes supported and the lut ranges. Getting the blob id
> > in userspace, user can get the mode supported and also the range of
> > gamma mode supported with number of lut coefficients. It can then set
> > one of the modes using this enum property.
> >
> > Lut values will be sent through separate GAMMA_LUT blob property.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > Documentation/gpu/drm-kms.rst | 90 ++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > drivers/gpu/drm/drm_color_mgmt.c | 93 ++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 23 ++
> > 7 files changed, 212 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst
> > b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..752be545e7d7
> > 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -514,9 +514,99 @@ Damage Tracking Properties Color Management
> > Properties
> > ---
> >
> > +Below is how a typical hardware pipeline for color will look like:
> > +
> > +.. kernel-render:: DOT
> > + :alt: Display Color Pipeline
> > + :caption: Display Color Pipeline Overview
> > +
> > + digraph "KMS" {
> > + node [shape=box]
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > + label="Display Color Hardware Blocks"
> > +
> > + node [bgcolor=grey style=filled]
> > + "Plane Degamma A" -> "Plane CSC/CTM A"
> > + "Plane CSC/CTM A" -> "Plane Gamma A"
> > + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> > height=0.75];
> > + "Plane Gamma A" -> "Pipe Blender"
> > + "Pipe Blender" -> "Pipe DeGamma"
> > + "Pipe DeGamma" -> "Pipe CSC/CTM"
> > + "Pipe CSC/CTM" -> "Pipe Gamma"
> > + "Pipe Gamma" -> "Pipe Output"
> > + }
> > +
>
> It might be worthwhile to also highlight the YCbCr coefficient matrix in the
> pipeline,
> between the FB and Plane degamma, i.e.
> YCbCr coefficients > plane degamma > csc > ...
>
> One problem with this view is that not all HW will support all (or any) of
> these CM
> blocks on all planes. For example, on AMD HW cursors are very different from
> other
> planes and don't really have full CM support.
>
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma B" -> "Plane CSC/CTM B"
> > + "Plane CSC/CTM B" -> "Plane Gamma B"
> > + "Plane Gamma B" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma C" -> "Plane CSC/CTM C"
> > + "Plane CSC/CTM C" -> "Plane Gamma C"
> > + "Plane Gamma C" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_fb {
> > + style=dashed
> > + label="RAM"
> > +
> > + node [shape=box width=1.7 height=0.2]
> > +
> > + "FB 1" -> "Plane Degamma A"
> > + "FB 2" -> "Plane Degamma B"
> > + "FB 3" -> "Plane Degamma C"
> > + }
> > + }
> > +
> > +In real world usecases,
> > +
> > +1. Plane Degamma can be used to linearize
RE: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes
> -Original Message-
> From: Harry Wentland
> Sent: Friday, June 4, 2021 8:53 PM
> To: Shankar, Uma ; Pekka Paalanen
>
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
> attributes
>
> On 2021-06-02 4:26 p.m., Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Pekka Paalanen
> >> Sent: Wednesday, June 2, 2021 3:04 PM
> >> To: Shankar, Uma
> >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >> Modem, Bhanuprakash
> >> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut
> >> range attributes
> >>
> >> On Tue, 1 Jun 2021 16:21:58 +0530
> >> Uma Shankar wrote:
> >>
> >>> Existing LUT precision structure is having only 16 bit precision.
> >>> This is not enough for upcoming enhanced hardwares and advance
> >>> usecases like HDR processing. Hence added a new structure with 32
> >>> bit precision values.
> >>>
> >>> This also defines a new structure to define color lut ranges, along
> >>> with related macro definitions and enums. This will help describe
> >>> multi segmented lut ranges in the hardware.
> >>>
> >>> Signed-off-by: Uma Shankar
> >>> ---
> >>> include/uapi/drm/drm_mode.h | 58
> >>> +
> >>> 1 file changed, 58 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h
> >>> b/include/uapi/drm/drm_mode.h index 9b6722d45f36..d0ce48d2e732
> >>> 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -819,6 +819,64 @@ struct hdr_output_metadata {
> >>> };
> >>> };
> >>>
> >>> +/*
> >>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and
> means
> >> the LUT
> >>> + * can be used for either purpose, but not simultaneously. To
> >>> + expose
> >>> + * modes that support gamma and degamma simultaneously the gamma
> >>> + mode
> >>> + * must declare distinct DRM_MODE_LUT_GAMMA and
> >> DRM_MODE_LUT_DEGAMMA
> >>> + * ranges.
> >>> + */
> >>> +/* LUT is for gamma (after CTM) */
> >>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>> +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
> >>> +BIT(1)
> >>> +/* linearly interpolate between the points */ #define
> >>> +DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>> +/*
> >>> + * the last value of the previous range is the
> >>> + * first value of the current range.
> >>> + */
> >>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>> +/* the curve must be non-decreasing */ #define
> >>> +DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>> +/* the curve is reflected across origin for negative inputs */
> >>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>> +/* the same curve (red) is used for blue and green channels as well
> >>> +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>> +
> >>> +struct drm_color_lut_range {
> >>> + /* DRM_MODE_LUT_* */
> >>> + __u32 flags;
> >>> + /* number of points on the curve */
> >>> + __u16 count;
> >>> + /* input/output bits per component */
> >>> + __u8 input_bpc, output_bpc;
> >>> + /* input start/end values */
> >>> + __s32 start, end;
> >>> + /* output min/max values */
> >>> + __s32 min, max;
> >>> +};
> >>> +
> >>> +enum lut_type {
> >>
> >> Unprefixed type name in UAPI headers is probably not a good idea.
> >
> > Ok, will rename these.
> >
> >>> + LUT_TYPE_DEGAMMA = 0,
> >>> + LUT_TYPE_GAMMA = 1,
> >>> +};
> >>
> >> All the above stuff seems to be the same in your other patch series'
> >> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series
> >> replacing the series "[PATCH 0/9] Enhance pipe color support for
> >> multi segmented luts" or what does this mean?
> >
> > The concept and idea is similar and the range definition is also
> > common. But this series focuses on plane color management while the other
> > one
> is for
RE: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, June 2, 2021 3:04 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
> attributes
>
> On Tue, 1 Jun 2021 16:21:58 +0530
> Uma Shankar wrote:
>
> > Existing LUT precision structure is having only 16 bit precision. This
> > is not enough for upcoming enhanced hardwares and advance usecases
> > like HDR processing. Hence added a new structure with 32 bit precision
> > values.
> >
> > This also defines a new structure to define color lut ranges, along
> > with related macro definitions and enums. This will help describe
> > multi segmented lut ranges in the hardware.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > include/uapi/drm/drm_mode.h | 58
> > +
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 9b6722d45f36..d0ce48d2e732 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -819,6 +819,64 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
> the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and
> DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
> > +BIT(1)
> > +/* linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */ #define
> > +DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > +enum lut_type {
>
> Unprefixed type name in UAPI headers is probably not a good idea.
Ok, will rename these.
> > + LUT_TYPE_DEGAMMA = 0,
> > + LUT_TYPE_GAMMA = 1,
> > +};
>
> All the above stuff seems to be the same in your other patch series'
> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series replacing the
> series "[PATCH 0/9] Enhance pipe color support for multi segmented luts" or
> what
> does this mean?
The concept and idea is similar and the range definition is also common. But
this series
focuses on plane color management while the other one is for pipe/crtc color
features.
Hence separated and floated them as unique series for review.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > +
> > +/*
> > + * Creating 64 bit palette entries for better data
> > + * precision. This will be required for HDR and
> > + * similar color processing usecases.
> > + */
> > +struct drm_color_lut_ext {
> > + /*
> > +* Data is U32.32 fixed point format.
> > +*/
> > + __u64 red;
> > + __u64 green;
> > + __u64 blue;
> > + __u64 reserved;
> > +};
> > +
> > #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
> > DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
> > DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
RE: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 2:59 PM > To: Shankar, Uma > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem, > Bhanuprakash ; Harry Wentland > > Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features > > On Tue, 1 Jun 2021 16:21:57 +0530 > Uma Shankar wrote: > > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > Hi, > > this is an excellent picture. I have long been wanting schematics like that > in the DRM > UAPI documentation. Another note on that: > https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html > > But the schematic for DRM UAPI documentation needs to be written in terms of > the > abstract KMS pipeline with property names spelled out, like in what Ville > sketched in > that email. Sure Pekka, I can add that. > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > This is very much welcome! > > There is also the thread: > https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html > > Everything mentioned will interact with each other by changing what the > abstract > KMS pixel pipeline does. I think you and Harry should probably look at each > others' > suggestions and see how to fit them all into a single abstract KMS pipeline. > > People are adding new pieces into KMS left and right, and I fear we lose > sight of how > everything will actually work together when all KMS properties are supposed > to be > generic and potentially present simultaneously. This is why I would very much > like to > have that *whole* abstract KMS pipeline documented with *everything*. > Otherwise > it is coming really hard fast to figure out how generic userspace should use > all t
RE: [PATCH 1/9] drm: Add gamma mode property
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, June 2, 2021 2:40 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 1/9] drm: Add gamma mode property
>
> On Tue, 1 Jun 2021 16:11:27 +0530
> Uma Shankar wrote:
>
> > Add a gamma mode property to enable various kind of gamma modes
> > supported by platforms like: Interpolated, Split, Multi Segmented,
> > Logarithmic etc. Userspace can get this property and should be able to
> > get the platform capabilities wrt various gamma modes possible and the
> > possible ranges.
> >
> > It can select one of the modes exposed as blob_id as an enum and set
> > the respective mode.
> >
> > It can then create the LUT and send it to driver using already
> > available GAMMA_LUT property as blob.
> >
> > Note: This is based on design by Ville and is being carried forward
> > based on his original idea.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 5 +++
> > drivers/gpu/drm/drm_color_mgmt.c | 75 +++
> > include/drm/drm_color_mgmt.h | 8
> > include/drm/drm_crtc.h| 14 ++
> > include/uapi/drm/drm_mode.h | 43 ++
> > 5 files changed, 145 insertions(+)
> >
>
> ...
>
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 13eeba2a750a..b1eead03ebe8 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -262,6 +262,13 @@ struct drm_crtc_state {
> > */
> > struct drm_property_blob *mode_blob;
> >
> > + /**
> > +* @gamma_mode: This is a blob_id and exposes the platform capabilities
> > +* wrt to various gamma modes and the respective lut ranges. This also
> > +* helps user select a gamma mode amongst the supported ones.
> > +*/
> > + u32 gamma_mode;
> > +
> > /**
> > * @degamma_lut:
> > *
> > @@ -1096,6 +1103,13 @@ struct drm_crtc {
> > */
> > struct drm_property *scaling_filter_property;
> >
> > + /**
> > +* @gamma_mode_property: Optional CRTC property to enumerate and
> > +* select the mode of the crtc gamma/degmama LUTs. This also exposes
> > +* the lut ranges of the various supported gamma modes to userspace.
> > +*/
> > + struct drm_property *gamma_mode_property;
> > +
> > /**
> > * @state:
> > *
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 9b6722d45f36..d7758d351936 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -819,6 +819,49 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
> the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and
> DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
> > +BIT(1)
> > +/* linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */ #define
> > +DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > +enum lut_type {
> > + LUT_TYPE_DEGAMMA = 0,
> > + LUT_TYPE_GAMMA = 1,
> > +};
> > +
> > #define DRM_MODE_PAGE_FLIP_EVENT 0
RE: [PATCH 5/9] drm: Add Client Cap for advance gamma mode
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, June 2, 2021 2:33 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 5/9] drm: Add Client Cap for advance gamma mode
>
> On Tue, 1 Jun 2021 16:11:31 +0530
> Uma Shankar wrote:
>
> > Introduced a client cap for advance cap mode capability. Userspace
>
> Typo: "cap mode" should be "gamma mode"?
Yeah, will fix this.
> > should set this to get to be able to use the new gamma_mode property.
> >
> > If this is not set, driver will work in legacy mode.
> >
> > Note: This is suggested by Ville and based on his idea, the new gamma
> > mode handling is designed.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_ioctl.c | 5 +
> > include/drm/drm_atomic.h | 1 +
> > include/drm/drm_crtc.h| 8
> > include/drm/drm_file.h| 8
> > include/uapi/drm/drm.h| 8
> > 6 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a5470a0ebbe6..7ee35bc14455 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -1036,6 +1036,8 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> > break;
> > }
> >
> > + crtc_state->advance_gamma_mode_active =
> > + state->advance_gamma_mode_active;
> > ret = drm_atomic_crtc_set_property(crtc,
> > crtc_state, prop, prop_value);
> > break;
> > @@ -1372,6 +1374,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > drm_modeset_acquire_init(,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > state->acquire_ctx =
> > state->allow_modeset = !!(arg->flags &
> > DRM_MODE_ATOMIC_ALLOW_MODESET);
> > + state->advance_gamma_mode_active =
> > +file_priv->advance_gamma_mode_active;
> >
> > retry:
> > copied_objs = 0;
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 53d314103a37..d51f72213882 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -361,6 +361,11 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> > return -EINVAL;
> > file_priv->writeback_connectors = req->value;
> > break;
> > + case DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES:
> > + if (req->value > 1)
> > + return -EINVAL;
> > + file_priv->advance_gamma_mode_active = req->value;
> > + break;
> > default:
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index
> > ac5a28eff2c8..5a398a249c80 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -379,6 +379,7 @@ struct drm_atomic_state {
> > * states.
> > */
> > bool duplicated : 1;
> > + bool advance_gamma_mode_active : 1;
>
> "advance" is a verb. Did you mean "advanced"?
Right, will rename it.
>
> > struct __drm_planes_state *planes;
> > struct __drm_crtcs_state *crtcs;
> > int num_connector;
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 5a594f134a81..f4339fbad086 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -170,6 +170,11 @@ struct drm_crtc_state {
> > */
> > bool color_mgmt_changed : 1;
> >
> > + /**
> > +* This is to indicate advance gamma mode support
> > +*/
> > + bool advance_gamma_mode_active : 1;
>
> Same here.
>
> > +
> > /**
> > * @no_vblank:
> > *
> > @@ -1036,6 +1041,9 @@ struct drm_crtc {
> > */
> > bool enabled;
> >
> > + /** To handle advance gamma mode support */
> > + bool advance_gamma_mode_active : 1;
>
> Same here.
>
> > +
> > /**
> > * @mode:
> > *
> > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h index
> > b81b3bfb08c8..4af3e1a2a158 100644
> > --- a/include/drm/drm_file.h
> > ++
RE: [PATCH v3 3/3] drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available
> -Original Message- > From: Nautiyal, Ankit K > Sent: Tuesday, March 9, 2021 10:09 AM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Shankar, > Uma > ; airl...@linux.ie; jani.nik...@linux.intel.com > Subject: [PATCH v3 3/3] drm/i915/display: Configure HDMI2.1 Pcon for FRL only > if > Src-Ctl mode is available > > Currently we see only the MAX FRL BW from PCON before going for FRL. > Also add the check if source control mode is supported by the PCON, before > starting > configuring PCON for FRL training. > > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 2e90359ce21f..8e401d3fd29d 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -2638,7 +2638,8 @@ void intel_dp_check_frl_training(struct intel_dp > *intel_dp) > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); > > /* Always go for FRL training if supported */ > - if (!intel_dp_is_hdmi_2_1_sink(intel_dp) || > + if (!(intel_dp->dpcd[2] & DP_PCON_SOURCE_CTL_MODE) || Would be good to add spec reference as well here. With that added, this is Reviewed-by: Uma Shankar > + !intel_dp_is_hdmi_2_1_sink(intel_dp) || > intel_dp->frl.is_trained) > return; > > -- > 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH v3 1/9] drm/dp: add MSO related DPCD registers
> -Original Message- > From: Intel-gfx On Behalf Of Jani > Nikula > Sent: Thursday, February 11, 2021 8:22 PM > To: intel-...@lists.freedesktop.org > Cc: Nikula, Jani ; Varide, Nischal > ; dri-devel@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v3 1/9] drm/dp: add MSO related DPCD registers > > Add DPCD register definitions for eDP 1.4 Multi-SST Operation. Looks Good to me. Reviewed-by: Uma Shankar > Cc: Nischal Varide > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index > edffd1dcca3e..632ad7faa006 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -1016,6 +1016,11 @@ struct drm_device; > #define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ > #define DP_EDP_REGIONAL_BACKLIGHT_0 0x741/* eDP 1.4 */ > > +#define DP_EDP_MSO_LINK_CAPABILITIES0x7a4/* eDP 1.4 */ > +# define DP_EDP_MSO_NUMBER_OF_LINKS_MASK(7 << 0) > +# define DP_EDP_MSO_NUMBER_OF_LINKS_SHIFT 0 > +# define DP_EDP_MSO_INDEPENDENT_LINK_BIT(1 << 3) > + > /* Sideband MSG Buffers */ > #define DP_SIDEBAND_MSG_DOWN_REQ_BASE0x1000 /* 1.2 MST */ > #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ > -- > 2.20.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 15/15] drm/i915/display: Let PCON convert from RGB to YCbCr if it can
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Friday, December 18, 2020 4:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v7 15/15] drm/i915/display: Let PCON convert from RGB to
> YCbCr if it can
>
> If PCON has capability to convert RGB->YCbCr colorspace and also to 444->420
> downsampling then for any YUV420 only mode, we can let the PCON do all the
> conversion. If the PCON supports
> RGB->YCbCr conversion for all BT2020, BT709, BT601, choose
> the one that is selected by userspace via connector colorspace property,
> otherwise default to BT601.
>
> v2: As suggested by Uma Shankar, considered case for colorspace
> BT709 and BT2020, and default to BT601. Also appended dir 'display' in commit
> message.
>
> v3: Fixed typo in condition for printing one of the error msg.
>
> v4: As suggested by Uma Shankar:
> -Fixed bug in determining the colorspace for RGB->YCbCr conversion.
> -Fixed minor formatting issues
> Also updated the commit message as per latest changes.
Changes look good, please work on color fixup as a separate series.
Reviewed-by: Uma Shankar
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 72 +++
> drivers/gpu/drm/i915/display/intel_dp.h | 3 +-
> 4 files changed, 65 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index fbc07a93504b..17eaa56c5a99 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> if (!is_mst)
> intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
>
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
> /*
>* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
> @@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> intel_ddi_init_dp_buf_reg(encoder, crtc_state);
> if (!is_mst)
> intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
> - intel_dp_configure_protocol_converter(intel_dp);
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
> intel_dp_sink_set_fec_ready(intel_dp, crtc_state); diff --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 4c01c7c23dfd..2009ae9e9678 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1460,6 +1460,7 @@ struct intel_dp {
> int pcon_max_frl_bw;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> + bool rgb_to_ycbcr;
> } dfp;
>
> /* Display stream compression testing */ diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index fdc028b7db07..d7e01482c808 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector
> *connector,
> !drm_mode_is_420_only(info, mode))
> return INTEL_OUTPUT_FORMAT_RGB;
>
> + if (intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> if (intel_dp->dfp.ycbcr_444_to_420)
> return INTEL_OUTPUT_FORMAT_YCBCR444;
> else
> @@ -4319,7 +4323,8 @@ static void intel_dp_enable_port(struct intel_dp
> *intel_dp,
> intel_de_posting_read(dev_priv, intel_dp->output_reg); }
>
> -void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
> +void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
> +const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 tmp;
> @@ -4348,12 +4353,42 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp)
> enableddisabled(intel_dp->d
RE: [PATCH v7 11/15] drm/i915: Add support for enabling link status and recovery
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Friday, December 18, 2020 4:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v7 11/15] drm/i915: Add support for enabling link status and
> recovery
>
> From: Swati Sharma
>
> In this patch enables support for detecting link failures between PCON and
> HDMI
> sink in i915 driver. HDMI link loss indication to upstream DP source is
> indicated
> via IRQ_HPD. This is followed by reading of HDMI link configuration status
> (HDMI_TX_LINK_ACTIVE_STATUS).
> If the PCON → HDMI 2.1 link status is off; reinitiate frl link training to
> recover.
> Also, report HDMI FRL link error count range for each individual FRL active
> lane is
> indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
>
> v2: Checked for dpcd read and write failures and added debug message.
> (Uma Shankar)
>
> v3: Rearranged code to re-start FRL link training or fall back to TMDS mode.
>
> v4: Resused function to check frl which inturn restarts FRL and fallback to
> TMDS
> mode.
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Ankit Nautiyal
> Reviewed-by: Uma Shankar (v2)
Change looks fine, you can keep RB.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 53 +++--
> 1 file changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1e0ff39bb927..66f35e7c9903 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6013,6 +6013,28 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return link_ok;
> }
>
> +static void
> +intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp) {
> + bool is_active;
> + u8 buf = 0;
> +
> + is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
> + if (intel_dp->frl.is_trained && !is_active) {
> + if (drm_dp_dpcd_readb(_dp->aux,
> DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
> + return;
> +
> + buf &= ~DP_PCON_ENABLE_HDMI_LINK;
> + if (drm_dp_dpcd_writeb(_dp->aux,
> DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
> + return;
> +
> + drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
> +_dp->attached_connector->base);
> +
> + /* Restart FRL training or fall back to TMDS mode */
> + intel_dp_check_frl_training(intel_dp);
> + }
> +}
> +
> static bool
> intel_dp_needs_link_retrain(struct intel_dp *intel_dp) { @@ -6378,7 +6400,7
> @@ intel_dp_hotplug(struct intel_encoder *encoder,
> return state;
> }
>
> -static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
> +static void intel_dp_check_device_service_irq(struct intel_dp
> +*intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 val;
> @@ -6402,6 +6424,30 @@ static void intel_dp_check_service_irq(struct intel_dp
> *intel_dp)
> drm_dbg_kms(>drm, "Sink specific irq unhandled\n"); }
>
> +static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 val;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
> + return;
> +
> + if (drm_dp_dpcd_readb(_dp->aux,
> + DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
> !val) {
> + drm_dbg_kms(>drm, "Error in reading link service irq
> vector\n");
> + return;
> + }
> +
> + if (drm_dp_dpcd_writeb(_dp->aux,
> +DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
> + drm_dbg_kms(>drm, "Error in writing link service irq
> vector\n");
> + return;
> + }
> +
> + if (val & HDMI_LINK_STATUS_CHANGED)
> + intel_dp_handle_hdmi_link_status_change(intel_dp);
> +}
> +
> /*
> * According to DP spec
> * 5.1.2:
> @@ -6441,7 +6487,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> return false;
> }
>
> - intel_dp_check_service_irq(intel_dp);
> + intel_dp_check_device_service_irq(intel_dp);
> + intel_dp_check_link_service_irq(intel_dp);
>
> /* Handle CEC interrupts, if any */
> drm_dp_cec_irq(_dp->aux);
> @@ -6871,7 +6918,7 @@ intel_dp_detect(struct drm_connector *connector,
> to_intel_connector(connector)->detect_edid)
> status = connector_status_connected;
>
> - intel_dp_check_service_irq(intel_dp);
> + intel_dp_check_device_service_irq(intel_dp);
>
> out:
> if (status != connector_status_connected && !intel_dp->is_mst)
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 04/15] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Friday, December 18, 2020 4:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v7 04/15] drm/dp_helper: Add Helpers for FRL Link Training
> support for DP-HDMI2.1 PCON
>
> This patch adds support for configuring a PCON device, connected as a DP
> branched device to enable FRL Link training with a HDMI2.1 + sink.
>
> v2: Fixed typos and addressed other review comments from Uma Shankar.
> -changed the commit message for better clarity (Uma Shankar) -removed
> unnecessary argument supplied to a drm helper function.
> -fixed return value for max frl read from pcon.
>
> v3: Removed DPCD 0x3035 for MAX Sink FRL b/w as per new version of spec.
>
> Signed-off-by: Ankit Nautiyal
> Reviewed-by: Uma Shankar (v2)
Changes look good, you can keep the RB.
> drivers/gpu/drm/drm_dp_helper.c | 263
> include/drm/drm_dp_helper.h | 70 +
> 2 files changed, 333 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 5bd0934004e3..f501e3890921 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2596,3 +2596,266 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> device *dev, #undef DP_SDP_LOG } EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> +
> +/**
> + * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns maximum frl bandwidth supported by PCON in GBPS,
> + * returns 0 if not supported.
> + */
> +int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + int bw;
> + u8 buf;
> +
> + buf = port_cap[2];
> + bw = buf & DP_PCON_MAX_FRL_BW;
> +
> + switch (bw) {
> + case DP_PCON_MAX_9GBPS:
> + return 9;
> + case DP_PCON_MAX_18GBPS:
> + return 18;
> + case DP_PCON_MAX_24GBPS:
> + return 24;
> + case DP_PCON_MAX_32GBPS:
> + return 32;
> + case DP_PCON_MAX_40GBPS:
> + return 40;
> + case DP_PCON_MAX_48GBPS:
> + return 48;
> + case DP_PCON_MAX_0GBPS:
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
> +
> +/**
> + * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 if success, else returns negative error code.
> + */
> +int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool
> +enable_frl_ready_hpd) {
> + int ret;
> + u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
> + DP_PCON_ENABLE_LINK_FRL_MODE;
> +
> + if (enable_frl_ready_hpd)
> + buf |= DP_PCON_ENABLE_HPD_READY;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
> +
> +/**
> + * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns true if success, else returns false.
> + */
> +bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux) {
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
> + if (ret < 0)
> + return false;
> +
> + if (buf & DP_PCON_FRL_READY)
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
> +
> +/**
> + * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
> + * @aux: DisplayPort AUX channel
> + * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI
> +sink
> + * @concurrent_mode: true if concurrent mode or operation is required,
> + * false otherwise.
> + *
> + * Returns 0 if success, else returns negative error code.
> + */
> +
> +int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
> + bool concurrent_mode)
> +{
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
> + if (ret < 0)
> + return ret;
> +
> + if (concurrent_mode)
> + buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
> + else
> + buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
> +
&
RE: [PATCH v6 15/15] drm/i915/display: Let PCON convert from RGB to YUV if it can
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Wednesday, December 16, 2020 5:01 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v6 15/15] drm/i915/display: Let PCON convert from RGB to YUV
> if it can
>
> If PCON has capability to convert RGB->YUV colorspace and also to 444->420
> downsampling then for any YUV420 only mode, we can let the PCON do all the
> conversion.
>
> v2: As suggested by Uma Shankar, considered case for colorspace
> BT709 and BT2020, and default to BT609. Also appended dir 'display' in commit
> message.
>
> v3: Fixed typo in condition for printing one of the error msg.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 68 +++
> drivers/gpu/drm/i915/display/intel_dp.h | 3 +-
> 4 files changed, 58 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index fbc07a93504b..17eaa56c5a99 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> if (!is_mst)
> intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
>
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
> /*
>* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
> @@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> intel_ddi_init_dp_buf_reg(encoder, crtc_state);
> if (!is_mst)
> intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
> - intel_dp_configure_protocol_converter(intel_dp);
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
> intel_dp_sink_set_fec_ready(intel_dp, crtc_state); diff --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 4c01c7c23dfd..2009ae9e9678 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1460,6 +1460,7 @@ struct intel_dp {
> int pcon_max_frl_bw;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> + bool rgb_to_ycbcr;
> } dfp;
>
> /* Display stream compression testing */ diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index abc9b772d1c8..366b2e4e7f4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector
> *connector,
> !drm_mode_is_420_only(info, mode))
> return INTEL_OUTPUT_FORMAT_RGB;
>
> + if (intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> if (intel_dp->dfp.ycbcr_444_to_420)
> return INTEL_OUTPUT_FORMAT_YCBCR444;
> else
> @@ -4311,7 +4315,8 @@ static void intel_dp_enable_port(struct intel_dp
> *intel_dp,
> intel_de_posting_read(dev_priv, intel_dp->output_reg); }
>
> -void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
> +void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
> +const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 tmp;
> @@ -4338,14 +4343,34 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp)
> drm_dbg_kms(>drm,
> "Failed to set protocol converter YCbCr 4:2:0
> conversion mode to %s\n",
> enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
> -
> - tmp = 0;
> -
> - if (drm_dp_dpcd_writeb(_dp->aux,
> -DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
> + if (intel_dp->dfp.rgb_to_ycbcr) {
> + bool bt2020, bt709;
> +
> + bt2020 =
> drm_dp_downstream_rgb_to_ycb
RE: [PATCH v5 07/15] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Wednesday, December 16, 2020 11:01 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v5 07/15] drm/dp_helper: Add helpers to configure PCONs RGB-
> YCbCr Conversion
>
> DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion of
> colorspace from RGB to YCbCr.
> https://groups.vesa.org/wg/DP/document/previewpdf/15651
>
> This patch adds the relavant registers and helper functions to get the
> capability
> and set the color conversion bits for rgb->ycbcr conversion through PCON.
>
> v2: As suggested in review comments:
> -Fixed bug in the check condition in a drm_helper as reported by Dan
> Carpenter
> and Kernel test robot. (Dan Carepenter) -Modified the color-conversion cap
> helper function, to accomodate
> BT709 and BT2020 colorspace. (Uma Shankar) -Added spec details for the new
> cap for color conversion. (Uma Shankar)
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 61 +
> include/drm/drm_dp_helper.h | 19 +-
> 2 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 689fd0d5f6c5..9abd65c694ab 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -949,6 +949,38 @@ bool
> drm_dp_downstream_444_to_420_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE] }
> EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
>
> +/**
> + * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream
> facing port
> + * RGB->YCbCr conversion
> capability
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: downstream facing port capabilities
> + * @colorspc: Colorspace for which conversion cap is sought
> + *
> + * Returns: whether the downstream facing port can convert RGB->YCbCr
> +for a given
> + * colorspace.
> + */
> +bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4],
> +u8 color_spc)
> +{
> + if (!drm_dp_is_branch(dpcd))
> + return false;
> +
> + if (dpcd[DP_DPCD_REV] < 0x13)
> + return false;
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_HDMI:
> + if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> + return false;
> +
> + return port_cap[3] & color_spc;
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
> +
> /**
> * drm_dp_downstream_mode() - return a mode for downstream facing port
> * @dev: DRM device
> @@ -3101,3 +3133,32 @@ int drm_dp_pcon_pps_override_param(struct
> drm_dp_aux *aux, u8 pps_param[6])
> return 0;
> }
> EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
> +
> +/*
> + * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert
> +RGB to Ycbcr
> + * @aux: displayPort AUX channel
> + * @color_spc: Color-space/s for which conversion is to be enabled, 0 for
> disable.
> + *
> + * Returns 0 on success, else returns negative error code.
> + */
> +int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8
> +color_spc) {
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2,
> );
> + if (ret < 0)
> + return ret;
> +
> + if (color_spc & DP_CONVERSION_RGB_YCBCR_MASK)
> + buf |= (color_spc & DP_CONVERSION_RGB_YCBCR_MASK);
> + else
> + buf &= ~DP_CONVERSION_RGB_YCBCR_MASK;
> +
> + ret = drm_dp_dpcd_writeb(aux,
> DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
> baad87fe6b0a..e096ee98842b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -432,6 +432,17 @@ struct drm_device;
> # define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
> # define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
>
> +/*
RE: [PATCH v4 16/16] drm/i915: Enable PCON configuration for Color Conversion for TGL
> -Original Message- > From: Nautiyal, Ankit K > Sent: Tuesday, December 8, 2020 1:22 PM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ; > airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com; > Kulkarni, Vandita ; Sharma, Swati2 > > Subject: [PATCH v4 16/16] drm/i915: Enable PCON configuration for Color > Conversion for TGL Append display here. > > This patch enables PCON configuration for color space conversion for > TGL+ platfrom. This will help in supporting 8k@60 YUV420 modes common > in HDMI 8k panels, through a capable PCON. > Also allow 8k@60 YUV420 modes, only if PCON claims to support the color space > conversion. > > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 1 + > drivers/gpu/drm/i915/display/intel_dp.c | 5 + > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index 721a47bbc009..ed6b8ea85408 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct > intel_atomic_state *state, > if (!is_mst) > intel_dp_set_power(intel_dp, DP_SET_POWER_D0); > > + intel_dp_configure_protocol_converter(intel_dp); Both the changes seems to be unrelated, it would be good to put configuration of protocol convertor in earlier patches and just pruning logic here. Also the description of patch needs to change to clearly call this out. > intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); > /* >* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index b3f1190d8150..86289c925612 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -720,6 +720,11 @@ intel_dp_mode_valid_downstream(struct > intel_connector *connector, > const struct drm_display_info *info = >base.display_info; > int tmds_clock; > > + /* Allow 8k YUV420 modes, only if PCON supports RGB->YUV conversion > */ > + if (mode->hdisplay == 7680 && drm_mode_is_420_only(info, mode) && > + !intel_dp->dfp.rgb_to_ycbcr) I think this will be a platform limitation, as there may be platforms which can do that on the SOC side as well. So would be good to limit to those platforms where pcon conversion is the only option in order to support this configuration, instead of doing it for all platforms. > + return MODE_NO_420; > + > /* >* If PCON and HDMI2.1 sink both support FRL MODE, check FRL >* bandwidth constraints. > -- > 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 15/16] drm/i915: Let PCON convert from RGB to YUV if it can
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Tuesday, December 8, 2020 1:22 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v4 15/16] drm/i915: Let PCON convert from RGB to YUV if it can
Make it drm/i915/display:
> If PCON has capability to convert RGB->YUV colorspace and also to 444->420
> downsampling then for any YUV420 only mode, we can let the PCON do all the
> conversion.
>
> Signed-off-by: Ankit Nautiyal
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 37 +--
> 2 files changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b41de41759a0..4150108bdc6d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1460,6 +1460,7 @@ struct intel_dp {
> int pcon_max_frl_bw, sink_max_frl_bw;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> + bool rgb_to_ycbcr;
> } dfp;
>
> /* Display stream compression testing */ diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 30c76ba63232..b3f1190d8150 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector
> *connector,
> !drm_mode_is_420_only(info, mode))
> return INTEL_OUTPUT_FORMAT_RGB;
>
> + if (intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> if (intel_dp->dfp.ycbcr_444_to_420)
> return INTEL_OUTPUT_FORMAT_YCBCR444;
> else
> @@ -4365,13 +4369,12 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp)
> "Failed to set protocol converter YCbCr 4:2:0
> conversion mode to %s\n",
> enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
>
> - tmp = 0;
> -
> - if (drm_dp_dpcd_writeb(_dp->aux,
> -DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
> + tmp = intel_dp->dfp.rgb_to_ycbcr ?
> + DP_CONVERSION_BT601_RGB_YCBCR_ENABLE : 0;
There are other combinations also possible like BT709 and BT2020. Handle those
as well here.
If no colorspace data is provided we can make BT601 as default, but if user
chooses a colorspace
and pcon supports it, then we should go for that option. We can get that info
from connector
colorspace properties.
> + if (drm_dp_pcon_convert_rgb_to_ycbcr(_dp->aux, tmp) <= 0)
> drm_dbg_kms(>drm,
> - "Failed to set protocol converter YCbCr 4:2:2
> conversion mode to %s\n",
> - enableddisabled(false));
> + "Failed to set protocol converter RGB->YCbCr
> conversion mode to %s\n",
> + enableddisabled(intel_dp->dfp.rgb_to_ycbcr));
> }
>
> static void intel_enable_dp(struct intel_atomic_state *state, @@ -6897,7
> +6900,7 @@ intel_dp_update_420(struct intel_dp *intel_dp) {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_connector *connector = intel_dp->attached_connector;
> - bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420;
> + bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420, rgb_to_ycbcr;
>
> /* No YCbCr output support on gmch platforms */
> if (HAS_GMCH(i915))
> @@ -6919,14 +6922,23 @@ intel_dp_update_420(struct intel_dp *intel_dp)
> dp_to_dig_port(intel_dp)->lspcon.active ||
> drm_dp_downstream_444_to_420_conversion(intel_dp->dpcd,
> intel_dp-
> >downstream_ports);
> + rgb_to_ycbcr = drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp-
> >dpcd,
> + intel_dp-
> >downstream_ports);
>
> if (INTEL_GEN(i915) >= 11) {
> + /* Let PCON convert from RGB->YCbCr if possible */
> + if (is_branch && rgb_to_ycbcr && ycbcr_444_to_420) {
> + intel_dp->dfp.rgb_to_ycbcr = true;
> + intel_dp->dfp.ycbcr_444_to_420 = true;
>
RE: [PATCH v4 14/16] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Tuesday, December 8, 2020 1:22 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v4 14/16] drm/i915/display: Configure PCON for DSC1.1 to
> DSC1.2 encoding
>
> When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink via DP
> HDMI2.1 PCON, the PCON can be configured to decode the
> DSC1.1 compressed stream and encode to DSC1.2. It then sends the
> DSC1.2 compressed stream to the HDMI2.1 sink.
>
> This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based on the
> PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder capabilities.
>
> v2: Addressed review comments from Uma Shankar:
> -fixed the error in packing pps parameter values -added check for pcon in the
> pcon related function -appended display in commit message
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 117 ++-
> drivers/gpu/drm/i915/display/intel_dp.h | 2 +
> 3 files changed, 118 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3ff8b18f1997..721a47bbc009 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3653,6 +3653,7 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
>
> intel_dp_check_frl_training(intel_dp, crtc_state);
> + intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
>
> /*
>* 7.i Follow DisplayPort specification training sequence (see notes for
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4dd272a34ee8..30c76ba63232 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4039,9 +4039,21 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
> *intel_dp) {
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> struct drm_connector *connector = _connector->base;
> + int max_frl_rate;
> + int max_lanes, rate_per_lane;
> + int max_dsc_lanes, dsc_rate_per_lane;
>
> - return (connector->display_info.hdmi.max_frl_rate_per_lane *
> - connector->display_info.hdmi.max_lanes);
> + max_lanes = connector->display_info.hdmi.max_lanes;
> + rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
> + max_frl_rate = max_lanes * rate_per_lane;
> +
> + if (connector->display_info.hdmi.dsc_cap.v_1p2) {
> + max_dsc_lanes = connector-
> >display_info.hdmi.dsc_cap.max_lanes;
> + dsc_rate_per_lane = connector-
> >display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
> + max_frl_rate = min(max_frl_rate, max_dsc_lanes *
> dsc_rate_per_lane);
> + }
> +
> + return max_frl_rate;
> }
>
> static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp) @@ -
> 4171,6 +4183,105 @@ void intel_dp_check_frl_training(struct intel_dp
> *intel_dp,
> }
> }
>
> +static int
> +intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state
> +*crtc_state) {
> +
> + int vactive = crtc_state->hw.adjusted_mode.vdisplay;
> +
> + return intel_hdmi_dsc_get_slice_height(vactive);
> +}
> +
> +static int
> +intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state) {
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = _connector->base;
> + int hdmi_throughput = connector-
> >display_info.hdmi.dsc_cap.clk_per_slice;
> + int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
> + int pcon_max_slices = drm_dp_pcon_dsc_max_slices(intel_dp-
> >pcon_dsc_dpcd);
> + int pcon_max_slice_width =
> +drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
> +
> +
> + return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
> + pcon_max_slice_width,
> + hdmi_max_slices, hdmi_throughput);
> }
> +
> +static int
> +intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
> + const
RE: [PATCH v4 13/16] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Tuesday, December 8, 2020 1:22 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v4 13/16] drm/i915: Add helper functions for calculating DSC
> parameters for HDMI2.1
>
> The DP-HDMI2.1 PCON spec provides way for a source to set PPS
> parameters: slice height, slice width and bits_per_pixel, based on the HDMI2.1
> sink capabilities. The DSC encoder of the PCON will respect these parameters,
> while preparing the 128 byte PPS.
>
> This patch adds helper functions to calculate these PPS paremeters as per the
> HDMI2.1 specification.
>
> v2: Addressed review comments given by Uma Shankar:
> -added documentation for functions
> -fixed typos and errors
Looks good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 233 ++
> drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
> 2 files changed, 240 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index e10fdb369daa..41eb1c175a0e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3428,3 +3428,236 @@ void intel_hdmi_init(struct drm_i915_private
> *dev_priv,
> dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
> intel_hdmi_init_connector(dig_port, intel_connector); }
> +
> +/*
> + * intel_hdmi_dsc_get_slice_height - get the dsc slice_height
> + * @vactive: Vactive of a display mode
> + *
> + * @return: appropriate dsc slice height for a given mode.
> + */
> +int intel_hdmi_dsc_get_slice_height(int vactive) {
> + int slice_height;
> +
> + /*
> + * Slice Height determination : HDMI2.1 Section 7.7.5.2
> + * Select smallest slice height >=96, that results in a valid PPS and
> + * requires minimum padding lines required for final slice.
> + *
> + * Assumption : Vactive is even.
> + */
> + for (slice_height = 96; slice_height <= vactive; slice_height += 2)
> + if (vactive % slice_height == 0)
> + return slice_height;
> +
> + return 0;
> +}
> +
> +/*
> + * intel_hdmi_dsc_get_num_slices - get no. of dsc slices based on dsc
> +encoder
> + * and dsc decoder capabilites
> + *
> + * @crtc_state: intel crtc_state
> + * @src_max_slices: maximum slices supported by the DSC encoder
> + * @src_max_slice_width: maximum slice width supported by DSC encoder
> + * @hdmi_max_slices: maximum slices supported by sink DSC decoder
> + * @hdmi_throughput: maximum clock per slice (MHz) supported by HDMI
> +sink
> + *
> + * @return: num of dsc slices that can be supported by the dsc encoder
> + * and decoder.
> + */
> +int
> +intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
> + int src_max_slices, int src_max_slice_width,
> + int hdmi_max_slices, int hdmi_throughput) {
> +/* Pixel rates in KPixels/sec */
> +#define HDMI_DSC_PEAK_PIXEL_RATE 272
> +/*
> + * Rates at which the source and sink are required to process pixels in
> +each
> + * slice, can be two levels: either atleast 34KHz or atleast 4KHz.
> + */
> +#define HDMI_DSC_MAX_ENC_THROUGHPUT_034
> +#define HDMI_DSC_MAX_ENC_THROUGHPUT_140
> +
> +/* Spec limits the slice width to 2720 pixels */
> +#define MAX_HDMI_SLICE_WIDTH 2720
> + int kslice_adjust;
> + int adjusted_clk_khz;
> + int min_slices;
> + int target_slices;
> + int max_throughput; /* max clock freq. in khz per slice */
> + int max_slice_width;
> + int slice_width;
> + int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
> +
> + if (!hdmi_throughput)
> + return 0;
> +
> + /*
> + * Slice Width determination : HDMI2.1 Section 7.7.5.1
> + * kslice_adjust factor for 4:2:0, and 4:2:2 formats is 0.5, where as
> + * for 4:4:4 is 1.0. Multiplying these factors by 10 and later
> + * dividing adjusted clock value by 10.
> + */
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
> + crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> + kslice_adjust = 10;
> + else
> + kslice_adjust = 5;
> +
> + /*
> + * As per spec, the rate at which the source and the sink
RE: [PATCH v4 07/16] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Tuesday, December 8, 2020 1:22 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v4 07/16] drm/dp_helper: Add helpers to configure PCONs RGB-
> YCbCr Conversion
>
> DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion of
> colorspace from RGB to YCbCr.
> https://groups.vesa.org/wg/DP/document/previewpdf/15651
>
> This patch adds the relavant registers and helper functions to get the
> capability
> and set the color conversion bits for rgb->ycbcr conversion through PCON.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 59 +
> include/drm/drm_dp_helper.h | 10 +-
> 2 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index d0626f57f99c..344662d5c295 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -949,6 +949,35 @@ bool
> drm_dp_downstream_444_to_420_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE] }
> EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
>
> +/**
> + * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream
> facing port
> + * RGB->YCbCr conversion
> capability
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: downstream facing port capabilities
> + *
> + * Returns: whether the downstream facing port can convert RGB->YCbCr
> +*/ bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
> +dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + if (!drm_dp_is_branch(dpcd))
> + return false;
> +
> + if (dpcd[DP_DPCD_REV] < 0x13)
> + return false;
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_HDMI:
> + if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> + return false;
> +
> + return port_cap[3] & DP_DS_HDMI_BT601_RGB_YCBCR_CONV;
I guess there are other conversions also possible, like BT709 and 2020. Update
those
as well here.
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
> +
> /**
> * drm_dp_downstream_mode() - return a mode for downstream facing port
> * @dev: DRM device
> @@ -3140,3 +3169,33 @@ int drm_dp_pcon_pps_override_param(struct
> drm_dp_aux *aux, u8 pps_param[6])
> return 0;
> }
> EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
> +
> +/*
> + * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert
> +RGB to Ycbcr
> + * @aux: displayPort AUX channel
> + * @color_spc: Color space conversion type
> + *
> + * Returns 0 on success, else returns negative error code.
> + */
> +int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8
> +color_spc) {
> + int ret;
> + u8 buf;
> +
> + if (color_spc != DP_CONVERSION_BT601_RGB_YCBCR_ENABLE ||
> + color_spc != DP_CONVERSION_BT709_RGB_YCBCR_ENABLE ||
> + color_spc != DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE)
> + return -EINVAL;
Yeah this is wrong, fix it.
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2,
> );
> + if (ret < 0)
> + return ret;
> +
> + buf |= color_spc;
> + ret = drm_dp_dpcd_writeb(aux,
> DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
> 347b4e1a55b4..1b3d54ed7a78 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -431,6 +431,9 @@ struct drm_device;
> # define DP_DS_HDMI_YCBCR420_PASS_THROUGH (1 << 2)
> # define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
> # define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
> +# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
> +# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
> +# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV (1 << 7)
I think it would be good to mention the location in spec (section or table),
will make it easier to understand/review by directly going to relevant sections
in spec.
>
> #define DP_M
