| Message ID | 20240222-kms-hdmi-connector-state-v7-0-8f4af575fce2@kernel.org |
|---|---|
| Headers | show |
| Series | drm/connector: Create HDMI Connector infrastructure | expand |
Dne četrtek, 22. februar 2024 ob 19:14:19 CET je Maxime Ripard napisal(a): > We're not doing anything special in atomic_mode_set so we can simply > merge it into atomic_enable. > > Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> > Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Best regards, Jernej > --- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +++++++++++++--------------------- > 1 file changed, 14 insertions(+), 24 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > index 799a26215cc2..bae69d696765 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > @@ -103,33 +103,11 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder, > struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode; > struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder); > struct drm_display_info *display = &hdmi->connector.display_info; > + unsigned int x, y; > u32 val = 0; > > DRM_DEBUG_DRIVER("Enabling the HDMI Output\n"); > > - clk_prepare_enable(hdmi->tmds_clk); > - > - sun4i_hdmi_setup_avi_infoframes(hdmi, mode); > - val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI); > - val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END); > - writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0)); > - > - val = SUN4I_HDMI_VID_CTRL_ENABLE; > - if (display->is_hdmi) > - val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE; > - > - writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG); > -} > - > -static void sun4i_hdmi_mode_set(struct drm_encoder *encoder, > - struct drm_crtc_state *crtc_state, > - struct drm_connector_state *conn_state) > -{ > - const struct drm_display_mode *mode = &crtc_state->mode; > - struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder); > - unsigned int x, y; > - u32 val; > - > clk_set_rate(hdmi->mod_clk, mode->crtc_clock * 1000); > clk_set_rate(hdmi->tmds_clk, mode->crtc_clock * 1000); > > @@ -181,6 +159,19 @@ static void sun4i_hdmi_mode_set(struct drm_encoder *encoder, > val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC; > > writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG); > + > + clk_prepare_enable(hdmi->tmds_clk); > + > + sun4i_hdmi_setup_avi_infoframes(hdmi, mode); > + val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI); > + val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END); > + writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0)); > + > + val = SUN4I_HDMI_VID_CTRL_ENABLE; > + if (display->is_hdmi) > + val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE; > + > + writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG); > } > > static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder, > @@ -206,7 +197,6 @@ static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = { > .atomic_check = sun4i_hdmi_atomic_check, > .atomic_disable = sun4i_hdmi_disable, > .atomic_enable = sun4i_hdmi_enable, > - .atomic_mode_set = sun4i_hdmi_mode_set, > .mode_valid = sun4i_hdmi_mode_valid, > }; > > >
Dne četrtek, 22. februar 2024 ob 19:14:21 CET je Maxime Ripard napisal(a): > atomic_check and mode_valid do not check for the same things which can > lead to surprising result if the userspace commits a mode that didn't go > through mode_valid. Let's merge the two implementations into a function > called by both. > > Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> > Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Best regards, Jernej > --- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 74 +++++++++++++++++++++------------- > 1 file changed, 47 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > index c276d984da6b..b7cf369b1906 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > @@ -62,18 +62,6 @@ static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi *hdmi, > return 0; > } > > -static int sun4i_hdmi_atomic_check(struct drm_encoder *encoder, > - struct drm_crtc_state *crtc_state, > - struct drm_connector_state *conn_state) > -{ > - struct drm_display_mode *mode = &crtc_state->mode; > - > - if (mode->flags & DRM_MODE_FLAG_DBLCLK) > - return -EINVAL; > - > - return 0; > -} > - > static void sun4i_hdmi_disable(struct drm_encoder *encoder, > struct drm_atomic_state *state) > { > @@ -166,31 +154,61 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder, > writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG); > } > > -static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder, > - const struct drm_display_mode *mode) > +static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = { > + .atomic_disable = sun4i_hdmi_disable, > + .atomic_enable = sun4i_hdmi_enable, > +}; > + > +static enum drm_mode_status > +sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector, > + const struct drm_display_mode *mode, > + unsigned long long clock) > { > - struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder); > - unsigned long rate = mode->clock * 1000; > - unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */ > + const struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector); > + unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI spec */ > long rounded_rate; > > + if (mode->flags & DRM_MODE_FLAG_DBLCLK) > + return MODE_BAD; > + > /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */ > - if (rate > 165000000) > + if (clock > 165000000) > return MODE_CLOCK_HIGH; > - rounded_rate = clk_round_rate(hdmi->tmds_clk, rate); > + > + rounded_rate = clk_round_rate(hdmi->tmds_clk, clock); > if (rounded_rate > 0 && > - max_t(unsigned long, rounded_rate, rate) - > - min_t(unsigned long, rounded_rate, rate) < diff) > + max_t(unsigned long, rounded_rate, clock) - > + min_t(unsigned long, rounded_rate, clock) < diff) > return MODE_OK; > + > return MODE_NOCLOCK; > } > > -static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = { > - .atomic_check = sun4i_hdmi_atomic_check, > - .atomic_disable = sun4i_hdmi_disable, > - .atomic_enable = sun4i_hdmi_enable, > - .mode_valid = sun4i_hdmi_mode_valid, > -}; > +static int sun4i_hdmi_connector_atomic_check(struct drm_connector *connector, > + struct drm_atomic_state *state) > +{ > + struct drm_connector_state *conn_state = > + drm_atomic_get_new_connector_state(state, connector); > + struct drm_crtc *crtc = conn_state->crtc; > + struct drm_crtc_state *crtc_state = crtc->state; > + struct drm_display_mode *mode = &crtc_state->adjusted_mode; > + enum drm_mode_status status; > + > + status = sun4i_hdmi_connector_clock_valid(connector, mode, > + mode->clock * 1000); > + if (status != MODE_OK) > + return -EINVAL; > + > + return 0; > +} > + > +static enum drm_mode_status > +sun4i_hdmi_connector_mode_valid(struct drm_connector *connector, > + struct drm_display_mode *mode) > +{ > + return sun4i_hdmi_connector_clock_valid(connector, mode, > + mode->clock * 1000); > +} > > static int sun4i_hdmi_get_modes(struct drm_connector *connector) > { > @@ -236,6 +254,8 @@ static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev) > } > > static const struct drm_connector_helper_funcs sun4i_hdmi_connector_helper_funcs = { > + .atomic_check = sun4i_hdmi_connector_atomic_check, > + .mode_valid = sun4i_hdmi_connector_mode_valid, > .get_modes = sun4i_hdmi_get_modes, > }; > > >
On Thu, 22 Feb 2024 19:14:07 +0100 Maxime Ripard <mripard@kernel.org> wrote: > The i915 driver has a property to force the RGB range of an HDMI output. > The vc4 driver then implemented the same property with the same > semantics. KWin has support for it, and a PR for mutter is also there to > support it. > > Both drivers implementing the same property with the same semantics, > plus the userspace having support for it, is proof enough that it's > pretty much a de-facto standard now and we can provide helpers for it. > > Let's plumb it into the newly created HDMI connector. > > Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> > Signed-off-by: Maxime Ripard <mripard@kernel.org> > --- > Documentation/gpu/kms-properties.csv | 1 - > drivers/gpu/drm/drm_atomic.c | 2 + > drivers/gpu/drm/drm_atomic_state_helper.c | 4 +- > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > drivers/gpu/drm/drm_connector.c | 89 +++++++++++++++++++++++++++++++ > include/drm/drm_connector.h | 36 +++++++++++++ > 6 files changed, 134 insertions(+), 2 deletions(-) ... > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 591d2d500f61..6ffe59d01698 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1212,6 +1212,29 @@ static const u32 dp_colorspaces = > BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) | > BIT(DRM_MODE_COLORIMETRY_BT2020_YCC); > > +static const struct drm_prop_enum_list broadcast_rgb_names[] = { > + { DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic" }, > + { DRM_HDMI_BROADCAST_RGB_FULL, "Full" }, > + { DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235" }, > +}; > + > +/* > + * drm_hdmi_connector_get_broadcast_rgb_name - Return a string for HDMI connector RGB broadcast selection > + * @broadcast_rgb: Broadcast RGB selection to compute name of > + * > + * Returns: the name of the Broadcast RGB selection, or NULL if the type > + * is not valid. > + */ > +const char * > +drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb) > +{ > + if (broadcast_rgb > DRM_HDMI_BROADCAST_RGB_LIMITED) > + return NULL; > + > + return broadcast_rgb_names[broadcast_rgb].name; > +} > +EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name); > + > static const char * const output_format_str[] = { > [HDMI_COLORSPACE_RGB] = "RGB", > [HDMI_COLORSPACE_YUV420] = "YUV 4:2:0", > @@ -1708,6 +1731,39 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); > /** > * DOC: HDMI connector properties > * > + * Broadcast RGB (HDMI specific) > + * Indicates the Quantization Range (Full vs Limited) used. The color > + * processing pipeline will be adjusted to match the value of the > + * property, and the Infoframes will be generated and sent accordingly. > + * > + * This property is only relevant if the HDMI output format is RGB. If > + * it's one of the YCbCr variant, it will be ignored and the output will > + * use a limited quantization range. > + * > + * The CRTC attached to the connector must be configured by user-space to > + * always produce full-range pixels. > + * > + * The value of this property can be one of the following: > + * > + * Automatic: > + * The quantization range is selected automatically based on the > + * mode according to the HDMI specifications (HDMI 1.4b - Section > + * 6.6 - Video Quantization Ranges). > + * > + * Full: > + * Full quantization range is forced. > + * > + * Limited 16:235: > + * Limited quantization range is forced. Unlike the name suggests, > + * this works for any number of bits-per-component. > + * > + * Property values other than Automatic can result in colors being off (if > + * limited is selected but the display expects full), or a black screen > + * (if full is selected but the display expects limited). > + * > + * Drivers can set up this property by calling > + * drm_connector_attach_broadcast_rgb_property(). > + * > * content type (HDMI specific): > * Indicates content type setting to be used in HDMI infoframes to indicate > * content type for the external device, so that it adjusts its display This piece of doc looks good to me, so Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Thanks, pq
Am Donnerstag, 22. Februar 2024, 19:14:17 CET schrieb Maxime Ripard: > The new HDMI connector infrastructure allows to remove some boilerplate, > especially to generate infoframes. Let's switch to it. > > Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> > --- > drivers/gpu/drm/rockchip/inno_hdmi.c | 123 ++++++++++++----------------------- > 1 file changed, 42 insertions(+), 81 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c > index 1d2261643743..d59947679042 100644 > --- a/drivers/gpu/drm/rockchip/inno_hdmi.c > +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c > @@ -67,9 +67,7 @@ struct inno_hdmi { > > struct inno_hdmi_connector_state { > struct drm_connector_state base; > - unsigned int enc_out_format; > unsigned int colorimetry; > - bool rgb_limited_range; > }; > > static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder) > @@ -257,26 +255,29 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi) > inno_hdmi_standby(hdmi); > } > > -static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, > - enum hdmi_infoframe_type type) > +static int inno_hdmi_disable_frame(struct drm_connector *connector, > + enum hdmi_infoframe_type type) > { > - struct drm_connector *connector = &hdmi->connector; > + struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector); > > if (type != HDMI_INFOFRAME_TYPE_AVI) { > drm_err(connector->dev, > "Unsupported infoframe type: %u\n", type); > - return; > + return 0; > } > > hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI); > + > + return 0; > } > > -static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, > - union hdmi_infoframe *frame, enum hdmi_infoframe_type type) > +static int inno_hdmi_upload_frame(struct drm_connector *connector, > + enum hdmi_infoframe_type type, > + const u8 *buffer, size_t len) > { > - struct drm_connector *connector = &hdmi->connector; > + struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector); > u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE]; > - ssize_t rc, i; > + ssize_t i; > > if (type != HDMI_INFOFRAME_TYPE_AVI) { > drm_err(connector->dev, > @@ -284,59 +285,19 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, > return 0; > } > > - inno_hdmi_disable_frame(hdmi, type); > + inno_hdmi_disable_frame(connector, type); > > - rc = hdmi_infoframe_pack(frame, packed_frame, > - sizeof(packed_frame)); > - if (rc < 0) > - return rc; > - > - for (i = 0; i < rc; i++) > + for (i = 0; i < len; i++) > hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i, > packed_frame[i]); > > return 0; > } > > -static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi, > - struct drm_display_mode *mode) > -{ > - struct drm_connector *connector = &hdmi->connector; > - struct drm_connector_state *conn_state = connector->state; > - struct inno_hdmi_connector_state *inno_conn_state = > - to_inno_hdmi_conn_state(conn_state); > - union hdmi_infoframe frame; > - int rc; > - > - rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, > - &hdmi->connector, > - mode); > - if (rc) { > - inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI); > - return rc; > - } > - > - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) > - frame.avi.colorspace = HDMI_COLORSPACE_YUV444; > - else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422) > - frame.avi.colorspace = HDMI_COLORSPACE_YUV422; > - else > - frame.avi.colorspace = HDMI_COLORSPACE_RGB; > - > - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) { > - drm_hdmi_avi_infoframe_quant_range(&frame.avi, > - connector, mode, > - inno_conn_state->rgb_limited_range ? > - HDMI_QUANTIZATION_RANGE_LIMITED : > - HDMI_QUANTIZATION_RANGE_FULL); > - } else { > - frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT; > - frame.avi.ycc_quantization_range = > - HDMI_YCC_QUANTIZATION_RANGE_LIMITED; > - } > - > - return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI); > -} > +static const struct drm_connector_hdmi_funcs inno_hdmi_hdmi_connector_funcs = { > + .clear_infoframe = inno_hdmi_disable_frame, > + .write_infoframe = inno_hdmi_upload_frame, > +}; > > static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi) > { > @@ -361,8 +322,8 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi) > v_VIDEO_INPUT_CSP(0); > hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value); > > - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) { > - if (inno_conn_state->rgb_limited_range) { > + if (conn_state->hdmi.output_format == HDMI_COLORSPACE_RGB) { > + if (!conn_state->hdmi.is_full_range) { > csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT; > auto_csc = AUTO_CSC_DISABLE; > c0_c2_change = C0_C2_CHANGE_DISABLE; > @@ -380,14 +341,14 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi) > } > } else { > if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) { > - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) { > + if (conn_state->hdmi.output_format == HDMI_COLORSPACE_YUV444) { > csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT; > auto_csc = AUTO_CSC_DISABLE; > c0_c2_change = C0_C2_CHANGE_DISABLE; > csc_enable = v_CSC_ENABLE; > } > } else { > - if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) { > + if (conn_state->hdmi.output_format == HDMI_COLORSPACE_YUV444) { > csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT; > auto_csc = AUTO_CSC_DISABLE; > c0_c2_change = C0_C2_CHANGE_DISABLE; > @@ -462,10 +423,12 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi, > } > > static int inno_hdmi_setup(struct inno_hdmi *hdmi, > - struct drm_display_mode *mode) > + struct drm_crtc_state *new_crtc_state, > + struct drm_connector_state *new_conn_state) > { > - struct drm_display_info *display = &hdmi->connector.display_info; > - unsigned long mpixelclock = mode->clock * 1000; > + struct drm_connector *connector = &hdmi->connector; > + struct drm_display_info *display = &connector->display_info; > + struct drm_display_mode *mode = &new_crtc_state->adjusted_mode; > > /* Mute video and audio output */ > hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK, > @@ -479,8 +442,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi, > > inno_hdmi_config_video_csc(hdmi); > > - if (display->is_hdmi) > - inno_hdmi_config_video_avi(hdmi, mode); > + drm_atomic_helper_connector_hdmi_update_infoframes(connector, > + new_conn_state->state); > > /* > * When IP controller have configured to an accurate video > @@ -488,13 +451,13 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi, > * DCLK_LCDC, so we need to init the TMDS rate to mode pixel > * clock rate, and reconfigure the DDC clock. > */ > - inno_hdmi_i2c_init(hdmi, mpixelclock); > + inno_hdmi_i2c_init(hdmi, new_conn_state->hdmi.tmds_char_rate); > > /* Unmute video and audio output */ > hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK, > v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0)); > > - inno_hdmi_power_up(hdmi, mpixelclock); > + inno_hdmi_power_up(hdmi, new_conn_state->hdmi.tmds_char_rate); > > return 0; > } > @@ -546,7 +509,7 @@ static void inno_hdmi_encoder_enable(struct drm_encoder *encoder, > if (WARN_ON(!crtc_state)) > return; > > - inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode); > + inno_hdmi_setup(hdmi, crtc_state, conn_state); > } > > static void inno_hdmi_encoder_disable(struct drm_encoder *encoder, > @@ -563,7 +526,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder, > struct drm_connector_state *conn_state) > { > struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state); > - struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder); > struct drm_display_mode *mode = &crtc_state->adjusted_mode; > u8 vic = drm_match_cea_mode(mode); > struct inno_hdmi_connector_state *inno_conn_state = > @@ -580,12 +542,7 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder, > else > inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709; > > - inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB; > - inno_conn_state->rgb_limited_range = > - drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED; > - > - return inno_hdmi_display_mode_valid(hdmi, > - &crtc_state->adjusted_mode) == MODE_OK ? 0 : -EINVAL; > + return 0; > } > > static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = { > @@ -662,10 +619,9 @@ static void inno_hdmi_connector_reset(struct drm_connector *connector) > return; > > __drm_atomic_helper_connector_reset(connector, &inno_conn_state->base); > + __drm_atomic_helper_connector_hdmi_reset(connector, connector->state); > > inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709; > - inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB; > - inno_conn_state->rgb_limited_range = false; > } > > static struct drm_connector_state * > @@ -698,6 +654,7 @@ static const struct drm_connector_funcs inno_hdmi_connector_funcs = { > }; > > static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = { > + .atomic_check = drm_atomic_helper_connector_hdmi_check, > .get_modes = inno_hdmi_connector_get_modes, > .mode_valid = inno_hdmi_connector_mode_valid, > }; > @@ -725,10 +682,14 @@ static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi) > > drm_connector_helper_add(&hdmi->connector, > &inno_hdmi_connector_helper_funcs); > - drm_connector_init_with_ddc(drm, &hdmi->connector, > - &inno_hdmi_connector_funcs, > - DRM_MODE_CONNECTOR_HDMIA, > - hdmi->ddc); > + drmm_connector_hdmi_init(drm, &hdmi->connector, > + "Rockchip", "Inno HDMI", > + &inno_hdmi_connector_funcs, > + &inno_hdmi_hdmi_connector_funcs, > + DRM_MODE_CONNECTOR_HDMIA, > + hdmi->ddc, > + BIT(HDMI_COLORSPACE_RGB), > + 8); > > drm_connector_attach_encoder(&hdmi->connector, encoder); > > >
Hi Maxime, On Thu, 22 Feb 2024 at 20:14, Maxime Ripard <mripard@kernel.org> wrote: > > Hi, > > Here's a series that creates some extra infrastructure specifically > targeted at HDMI controllers. > > The idea behind this series came from a recent discussion on IRC during > which we discussed infoframes generation of i915 vs everything else. > > Infoframes generation code still requires some decent boilerplate, with > each driver doing some variation of it. > > In parallel, while working on vc4, we ended up converting a lot of i915 > logic (mostly around format / bpc selection, and scrambler setup) to > apply on top of a driver that relies only on helpers. > > While currently sitting in the vc4 driver, none of that logic actually > relies on any driver or hardware-specific behaviour. > > The only missing piece to make it shareable are a bunch of extra > variables stored in a state (current bpc, format, RGB range selection, > etc.). > > The initial implementation was relying on some generic subclass of > drm_connector to address HDMI connectors, with a bunch of helpers that > will take care of all the "HDMI Spec" related code. Scrambler setup is > missing at the moment but can easily be plugged in. > > The feedback was that creating a connector subclass like was done for > writeback would prevent the adoption of those helpers since it couldn't > be used in all situations (like when the connector driver can implement > multiple output) and required more churn to cast between the > drm_connector and its subclass. The decision was thus to provide a set > of helper and to store the required variables in drm_connector and > drm_connector_state. This what has been implemented now. > > Hans Verkuil also expressed interest in implementing a mechanism in v4l2 > to retrieve infoframes from HDMI receiver and implementing a tool to > decode (and eventually check) infoframes. His current work on > edid-decode to enable that based on that series can be found here: > https://git.linuxtv.org/hverkuil/edid-decode.git/log/?h=hverkuil > > And some more context here: > https://lore.kernel.org/dri-devel/50db7366-cd3d-4675-aaad-b857202234de@xs4all.nl/ > > This series thus leverages the infoframe generation code to expose it > through debugfs. [...] > > Let me know what you think, > Maxime The overall idea looks great. I've started checking how I can use that for our msm devices family, which makes use of bridges and drm_bridge_connector. My current idea is to extend the drm_bridge_funcs with the new callback to be called once the drm_connector has been instantiated. This way all the bridges can influence new connector. Another possibility is to follow drm_bridge_connector design closely and let it call into drm_connector_hdmi code if it detects that the last bridge is the HDMI one. WDYT? Some context, older MSM devices have an on-die HDMI encoder, implemented as drm_bridge at drivers/gpu/drm/msm/hdmi. Newer generation of devices has dropped the on-die HDMI implementation in favour of using external DSI-to-HDMI bridges, like Lontium LT9611 or LT9611UXC. I'm looking at enabling new HDMI infrastructure for both cases.
Hi Dmitry, On Sun, Feb 25, 2024 at 04:50:00PM +0200, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 20:14, Maxime Ripard <mripard@kernel.org> wrote: > > Here's a series that creates some extra infrastructure specifically > > targeted at HDMI controllers. > > > > The idea behind this series came from a recent discussion on IRC during > > which we discussed infoframes generation of i915 vs everything else. > > > > Infoframes generation code still requires some decent boilerplate, with > > each driver doing some variation of it. > > > > In parallel, while working on vc4, we ended up converting a lot of i915 > > logic (mostly around format / bpc selection, and scrambler setup) to > > apply on top of a driver that relies only on helpers. > > > > While currently sitting in the vc4 driver, none of that logic actually > > relies on any driver or hardware-specific behaviour. > > > > The only missing piece to make it shareable are a bunch of extra > > variables stored in a state (current bpc, format, RGB range selection, > > etc.). > > > > The initial implementation was relying on some generic subclass of > > drm_connector to address HDMI connectors, with a bunch of helpers that > > will take care of all the "HDMI Spec" related code. Scrambler setup is > > missing at the moment but can easily be plugged in. > > > > The feedback was that creating a connector subclass like was done for > > writeback would prevent the adoption of those helpers since it couldn't > > be used in all situations (like when the connector driver can implement > > multiple output) and required more churn to cast between the > > drm_connector and its subclass. The decision was thus to provide a set > > of helper and to store the required variables in drm_connector and > > drm_connector_state. This what has been implemented now. > > > > Hans Verkuil also expressed interest in implementing a mechanism in v4l2 > > to retrieve infoframes from HDMI receiver and implementing a tool to > > decode (and eventually check) infoframes. His current work on > > edid-decode to enable that based on that series can be found here: > > https://git.linuxtv.org/hverkuil/edid-decode.git/log/?h=hverkuil > > > > And some more context here: > > https://lore.kernel.org/dri-devel/50db7366-cd3d-4675-aaad-b857202234de@xs4all.nl/ > > > > This series thus leverages the infoframe generation code to expose it > > through debugfs. > > [...] > > > > > Let me know what you think, > > Maxime > > The overall idea looks great. I've started checking how I can use that > for our msm devices family, which makes use of bridges and > drm_bridge_connector. Yeah, I had that in mind for a while too. I think it would be valuable, but it's difficult as it is already so I didn't tackle it at first :) The format negociation especially seems to divert quite a lot from what i915 and vc4 have been doing, and that's user facing to some extent. > My current idea is to extend the drm_bridge_funcs with the new > callback to be called once the drm_connector has been instantiated. > This way all the bridges can influence new connector. > Another possibility is to follow drm_bridge_connector design closely > and let it call into drm_connector_hdmi code if it detects that the > last bridge is the HDMI one. > WDYT? I had the latter in mind, but I haven't really tried to reconcile the connector state output_format with the drm_atomic_helper_bridge_propagate_bus_fmt, and plug in the output_bpc count too. We would have to create the max_bpc properties from the HDMI connector, and then propagate that upstream along the bridges I guess (or we can just ignore it for now). So, yeah, I had the latter in mind but it might turn out that the former is actually easier. Both make sense to me at least. Maxime
Hi, Here's a series that creates some extra infrastructure specifically targeted at HDMI controllers. The idea behind this series came from a recent discussion on IRC during which we discussed infoframes generation of i915 vs everything else. Infoframes generation code still requires some decent boilerplate, with each driver doing some variation of it. In parallel, while working on vc4, we ended up converting a lot of i915 logic (mostly around format / bpc selection, and scrambler setup) to apply on top of a driver that relies only on helpers. While currently sitting in the vc4 driver, none of that logic actually relies on any driver or hardware-specific behaviour. The only missing piece to make it shareable are a bunch of extra variables stored in a state (current bpc, format, RGB range selection, etc.). The initial implementation was relying on some generic subclass of drm_connector to address HDMI connectors, with a bunch of helpers that will take care of all the "HDMI Spec" related code. Scrambler setup is missing at the moment but can easily be plugged in. The feedback was that creating a connector subclass like was done for writeback would prevent the adoption of those helpers since it couldn't be used in all situations (like when the connector driver can implement multiple output) and required more churn to cast between the drm_connector and its subclass. The decision was thus to provide a set of helper and to store the required variables in drm_connector and drm_connector_state. This what has been implemented now. Hans Verkuil also expressed interest in implementing a mechanism in v4l2 to retrieve infoframes from HDMI receiver and implementing a tool to decode (and eventually check) infoframes. His current work on edid-decode to enable that based on that series can be found here: https://git.linuxtv.org/hverkuil/edid-decode.git/log/?h=hverkuil And some more context here: https://lore.kernel.org/dri-devel/50db7366-cd3d-4675-aaad-b857202234de@xs4all.nl/ This series thus leverages the infoframe generation code to expose it through debugfs. I also used the occasion to unit-test everything but the infoframe generation, which can come later once I get a proper understanding of what the infoframe are supposed to look like. This required to add some extra kunit helpers and infrastructure to have multiple EDIDs and allow each test to run with a particular set of capabilities. This entire series has been tested on a Pi4, passes all its unittests (125 new tests), and has only been build-tested for sunxi and rockchip. Let me know what you think, Maxime Signed-off-by: Maxime Ripard <mripard@kernel.org> --- Changes in v7: - Rebased on top of current next - Only consider the Broadcast RGB property if the output format is RGB, and use a limited range otherwise - Document the fact that Broadcast RGB only applies if the output format is RGB - Add some test to make sure we always get a limited range if we have a YCbCr output format. - Link to v6: https://lore.kernel.org/r/20240212-kms-hdmi-connector-state-v6-0-f4bcdc979e6f@kernel.org Changes in v6: - Rebased on top of current next - Split the tests into separate patches - Improve the Broadcast RGB documentation - Link to v5: https://lore.kernel.org/r/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org Changes in v5: - Dropped the connector init arg checking patch, and the related kunit tests - Dropped HDMI Vendor infoframes in rockchip inno_hdmi - Fixed the build warnings - Link to v4: https://lore.kernel.org/r/20231128-kms-hdmi-connector-state-v4-0-c7602158306e@kernel.org Changes in v4: - Create unit tests for everything but infoframes - Fix a number of bugs identified by the unit tests - Rename DRM (Dynamic Range and Mastering) infoframe file to HDR_DRM - Drop RFC status - Link to v3: https://lore.kernel.org/r/20231031-kms-hdmi-connector-state-v3-0-328b0fae43a7@kernel.org Changes in v3: - Made sure the series work on the RaspberryPi4 - Handle YUV420 in the char clock rate computation - Use the maximum bpc value the connector allows at reset - Expose the RGB Limited vs Full Range value in the connector state instead of through a helper - Fix Broadcast RGB documentation - Add more debug logging - Small fixes here and there - Link to v2: https://lore.kernel.org/r/20230920-kms-hdmi-connector-state-v2-0-17932daddd7d@kernel.org Changes in v2: - Change from a subclass to a set of helpers for drm_connector and drm_connector state - Don't assume that all drivers support RGB, YUV420 and YUV422 but make them provide a bitfield instead. - Don't assume that all drivers support the Broadcast RGB property but make them call the registration helper. - Document the Broacast RGB property - Convert the inno_hdmi and sun4i_hdmi driver. - Link to v1: https://lore.kernel.org/r/20230814-kms-hdmi-connector-state-v1-0-048054df3654@kernel.org --- Maxime Ripard (36): drm/tests: helpers: Include missing drm_drv header drm/tests: helpers: Add atomic helpers drm/tests: Add helper to create mock plane drm/tests: Add helper to create mock crtc drm/tests: connector: Add tests for drmm_connector_init drm/connector: Introduce an HDMI connector initialization function drm/tests: connector: Add tests for drmm_connector_hdmi_init drm/connector: hdmi: Create an HDMI sub-state drm/connector: hdmi: Add output BPC to the connector state drm/tests: Add output bpc tests drm/connector: hdmi: Add support for output format drm/tests: Add output formats tests drm/connector: hdmi: Add HDMI compute clock helper drm/tests: Add HDMI TDMS character rate tests drm/connector: hdmi: Calculate TMDS character rate drm/tests: Add TDMS character rate connector state tests drm/connector: hdmi: Add custom hook to filter TMDS character rate drm/tests: Add HDMI connector rate filter hook tests drm/connector: hdmi: Compute bpc and format automatically drm/tests: Add HDMI connector bpc and format tests drm/connector: hdmi: Add Broadcast RGB property drm/tests: Add tests for Broadcast RGB property drm/connector: hdmi: Add RGB Quantization Range to the connector state drm/tests: Add RGB Quantization tests drm/connector: hdmi: Add Infoframes generation drm/tests: Add infoframes test drm/connector: hdmi: Create Infoframe DebugFS entries drm/vc4: hdmi: Switch to HDMI connector drm/vc4: tests: Remove vc4_dummy_plane structure drm/vc4: tests: Convert to plane creation helper drm/rockchip: inno_hdmi: Switch to HDMI connector drm/sun4i: hdmi: Convert encoder to atomic drm/sun4i: hdmi: Move mode_set into enable drm/sun4i: hdmi: Switch to container_of_const drm/sun4i: hdmi: Consolidate atomic_check and mode_valid drm/sun4i: hdmi: Switch to HDMI connector Documentation/gpu/kms-properties.csv | 1 - drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c | 11 + drivers/gpu/drm/drm_atomic_state_helper.c | 667 +++++++ drivers/gpu/drm/drm_atomic_uapi.c | 4 + drivers/gpu/drm/drm_connector.c | 268 +++ drivers/gpu/drm/drm_debugfs.c | 110 ++ drivers/gpu/drm/rockchip/inno_hdmi.c | 123 +- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 203 +- drivers/gpu/drm/tests/Makefile | 1 + .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1944 ++++++++++++++++++++ drivers/gpu/drm/tests/drm_connector_test.c | 1227 +++++++++++- drivers/gpu/drm/tests/drm_kunit_edid.h | 482 +++++ drivers/gpu/drm/tests/drm_kunit_helpers.c | 150 ++ drivers/gpu/drm/vc4/tests/vc4_mock.c | 6 +- drivers/gpu/drm/vc4/tests/vc4_mock.h | 9 +- drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 44 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 638 +------ drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 6 +- include/drm/drm_atomic_state_helper.h | 12 + include/drm/drm_connector.h | 257 +++ include/drm/drm_kunit_helpers.h | 23 + 23 files changed, 5414 insertions(+), 817 deletions(-) --- base-commit: e31185ce00a96232308300008db193416ceb9769 change-id: 20230814-kms-hdmi-connector-state-616787e67927 Best regards,