| Message ID | 1488468572-31971-2-git-send-email-narmstrong@baylibre.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Neil, Thank you for the patch. On Thursday 02 Mar 2017 16:29:31 Neil Armstrong wrote: > Some display pipelines can only provide non-RBG input pixels to the HDMI TX > Controller, this patch takes the pixel format from the plat_data if > provided. > > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > --- > drivers/gpu/drm/bridge/dw-hdmi.c | 59 ++++++++++++++++++------------------- > include/drm/bridge/dw_hdmi.h | 9 ++++++ > 2 files changed, 39 insertions(+), 29 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c > b/drivers/gpu/drm/bridge/dw-hdmi.c index 026a0dc..653ecd7 100644 > --- a/drivers/gpu/drm/bridge/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c > @@ -35,12 +35,6 @@ > > #define HDMI_EDID_LEN 512 > > -#define RGB 0 > -#define YCBCR444 1 > -#define YCBCR422_16BITS 2 > -#define YCBCR422_8BITS 3 > -#define XVYCC444 4 > - > enum hdmi_datamap { > RGB444_8B = 0x01, > RGB444_10B = 0x03, > @@ -94,8 +88,8 @@ struct hdmi_vmode { > }; > > struct hdmi_data_info { > - unsigned int enc_in_format; > - unsigned int enc_out_format; > + enum dw_hdmi_color_enc_format enc_in_format; > + enum dw_hdmi_color_enc_format enc_out_format; > unsigned int enc_color_depth; > unsigned int colorimetry; > unsigned int pix_repet_factor; > @@ -569,7 +563,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) > int color_format = 0; > u8 val; > > - if (hdmi->hdmi_data.enc_in_format == RGB) { > + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB) { > if (hdmi->hdmi_data.enc_color_depth == 8) > color_format = 0x01; > else if (hdmi->hdmi_data.enc_color_depth == 10) > @@ -580,7 +574,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) > color_format = 0x07; > else > return; > - } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) { > + } else if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) { > if (hdmi->hdmi_data.enc_color_depth == 8) > color_format = 0x09; > else if (hdmi->hdmi_data.enc_color_depth == 10) > @@ -591,7 +585,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) > color_format = 0x0F; > else > return; > - } else if (hdmi->hdmi_data.enc_in_format == YCBCR422_8BITS) { > + } else if (hdmi->hdmi_data.enc_in_format == > + DW_HDMI_ENC_FMT_YCBCR422_8BITS) { > if (hdmi->hdmi_data.enc_color_depth == 8) > color_format = 0x16; > else if (hdmi->hdmi_data.enc_color_depth == 10) > @@ -627,20 +622,20 @@ static int is_color_space_conversion(struct dw_hdmi > *hdmi) > > static int is_color_space_decimation(struct dw_hdmi *hdmi) > { > - if (hdmi->hdmi_data.enc_out_format != YCBCR422_8BITS) > + if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS) > return 0; > - if (hdmi->hdmi_data.enc_in_format == RGB || > - hdmi->hdmi_data.enc_in_format == YCBCR444) > + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB || > + hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) > return 1; > return 0; > } > > static int is_color_space_interpolation(struct dw_hdmi *hdmi) > { > - if (hdmi->hdmi_data.enc_in_format != YCBCR422_8BITS) > + if (hdmi->hdmi_data.enc_in_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS) > return 0; > - if (hdmi->hdmi_data.enc_out_format == RGB || > - hdmi->hdmi_data.enc_out_format == YCBCR444) > + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB || > + hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) > return 1; > return 0; > } > @@ -652,13 +647,14 @@ static void dw_hdmi_update_csc_coeffs(struct dw_hdmi > *hdmi) u32 csc_scale = 1; > > if (is_color_space_conversion(hdmi)) { > - if (hdmi->hdmi_data.enc_out_format == RGB) { > + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB) { > if (hdmi->hdmi_data.colorimetry == > HDMI_COLORIMETRY_ITU_601) > csc_coeff = &csc_coeff_rgb_out_eitu601; > else > csc_coeff = &csc_coeff_rgb_out_eitu709; > - } else if (hdmi->hdmi_data.enc_in_format == RGB) { > + } else if (hdmi->hdmi_data.enc_in_format == > + DW_HDMI_ENC_FMT_RGB) { > if (hdmi->hdmi_data.colorimetry == > HDMI_COLORIMETRY_ITU_601) > csc_coeff = &csc_coeff_rgb_in_eitu601; > @@ -730,8 +726,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi) > struct hdmi_data_info *hdmi_data = &hdmi->hdmi_data; > u8 val, vp_conf; > > - if (hdmi_data->enc_out_format == RGB || > - hdmi_data->enc_out_format == YCBCR444) { > + if (hdmi_data->enc_out_format == DW_HDMI_ENC_FMT_RGB || > + hdmi_data->enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) { > if (!hdmi_data->enc_color_depth) { > output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS; > } else if (hdmi_data->enc_color_depth == 8) { > @@ -746,7 +742,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi) > } else { > return; > } > - } else if (hdmi_data->enc_out_format == YCBCR422_8BITS) { > + } else if (hdmi_data->enc_out_format == > + DW_HDMI_ENC_FMT_YCBCR422_8BITS) { > if (!hdmi_data->enc_color_depth || > hdmi_data->enc_color_depth == 8) > remap_size = HDMI_VP_REMAP_YCC422_16bit; > @@ -1138,15 +1135,16 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, > struct drm_display_mode *mode) /* Initialise info frame from DRM mode */ > drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > > - if (hdmi->hdmi_data.enc_out_format == YCBCR444) > + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) > frame.colorspace = HDMI_COLORSPACE_YUV444; > - else if (hdmi->hdmi_data.enc_out_format == YCBCR422_8BITS) > + else if (hdmi->hdmi_data.enc_out_format == > + DW_HDMI_ENC_FMT_YCBCR422_8BITS) > frame.colorspace = HDMI_COLORSPACE_YUV422; > else > frame.colorspace = HDMI_COLORSPACE_RGB; > > /* Set up colorimetry */ > - if (hdmi->hdmi_data.enc_out_format == XVYCC444) { > + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_XVYCC444) { > frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; > if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601) > frame.extended_colorimetry = > @@ -1154,7 +1152,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, > struct drm_display_mode *mode) else /*hdmi->hdmi_data.colorimetry == > HDMI_COLORIMETRY_ITU_709*/ frame.extended_colorimetry = > HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; > - } else if (hdmi->hdmi_data.enc_out_format != RGB) { > + } else if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_RGB) { > frame.colorimetry = hdmi->hdmi_data.colorimetry; > frame.extended_colorimetry = HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; > } else { /* Carries no data */ > @@ -1443,10 +1441,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, > struct drm_display_mode *mode) > hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0; > hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0; > > - /* TODO: Get input format from IPU (via FB driver interface) */ > - hdmi->hdmi_data.enc_in_format = RGB; > + /* Get input format from plat data or fallback to RGB */ > + if (hdmi->plat_data->input_fmt >= 0) > + hdmi->hdmi_data.enc_in_format = hdmi->plat_data->input_fmt; > + else > + hdmi->hdmi_data.enc_in_format = DW_HDMI_ENC_FMT_RGB; > > - hdmi->hdmi_data.enc_out_format = RGB; > + hdmi->hdmi_data.enc_out_format = DW_HDMI_ENC_FMT_RGB; > > hdmi->hdmi_data.enc_color_depth = 8; > hdmi->hdmi_data.pix_repet_factor = 0; > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h > index bcceee8..8c0cc13 100644 > --- a/include/drm/bridge/dw_hdmi.h > +++ b/include/drm/bridge/dw_hdmi.h > @@ -21,6 +21,14 @@ enum { > DW_HDMI_RES_MAX, > }; > > +enum dw_hdmi_color_enc_format { > + DW_HDMI_ENC_FMT_RGB = 0, > + DW_HDMI_ENC_FMT_YCBCR444, > + DW_HDMI_ENC_FMT_YCBCR422_16BITS, > + DW_HDMI_ENC_FMT_YCBCR422_8BITS, > + DW_HDMI_ENC_FMT_XVYCC444, > +}; > + > enum dw_hdmi_phy_type { > DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00, > DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2, > @@ -62,6 +70,7 @@ struct dw_hdmi_plat_data { > struct regmap *regm; > enum drm_mode_status (*mode_valid)(struct drm_connector *connector, > struct drm_display_mode *mode); > + enum dw_hdmi_color_enc_format input_fmt; As reported before, I think we should use a combination of media bus format and color space information instead of a custom enum. Ideally this should also be queried at runtime, but that could be done in a second step. > > /* Vendor PHY support */ > const struct dw_hdmi_phy_ops *phy_ops;
On 03/02/2017 04:45 PM, Laurent Pinchart wrote: > Hi Neil, > > Thank you for the patch. > > On Thursday 02 Mar 2017 16:29:31 Neil Armstrong wrote: >> Some display pipelines can only provide non-RBG input pixels to the HDMI TX >> Controller, this patch takes the pixel format from the plat_data if >> provided. >> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >> --- >> drivers/gpu/drm/bridge/dw-hdmi.c | 59 ++++++++++++++++++------------------- >> include/drm/bridge/dw_hdmi.h | 9 ++++++ >> 2 files changed, 39 insertions(+), 29 deletions(-) >> >> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c >> b/drivers/gpu/drm/bridge/dw-hdmi.c index 026a0dc..653ecd7 100644 >> --- a/drivers/gpu/drm/bridge/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c >> @@ -35,12 +35,6 @@ >> >> #define HDMI_EDID_LEN 512 >> >> -#define RGB 0 >> -#define YCBCR444 1 >> -#define YCBCR422_16BITS 2 >> -#define YCBCR422_8BITS 3 >> -#define XVYCC444 4 >> - >> enum hdmi_datamap { >> RGB444_8B = 0x01, >> RGB444_10B = 0x03, >> @@ -94,8 +88,8 @@ struct hdmi_vmode { >> }; >> >> struct hdmi_data_info { >> - unsigned int enc_in_format; >> - unsigned int enc_out_format; >> + enum dw_hdmi_color_enc_format enc_in_format; >> + enum dw_hdmi_color_enc_format enc_out_format; >> unsigned int enc_color_depth; >> unsigned int colorimetry; >> unsigned int pix_repet_factor; >> @@ -569,7 +563,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) >> int color_format = 0; >> u8 val; >> >> - if (hdmi->hdmi_data.enc_in_format == RGB) { >> + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB) { >> if (hdmi->hdmi_data.enc_color_depth == 8) >> color_format = 0x01; >> else if (hdmi->hdmi_data.enc_color_depth == 10) >> @@ -580,7 +574,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) >> color_format = 0x07; >> else >> return; >> - } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) { >> + } else if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) > { >> if (hdmi->hdmi_data.enc_color_depth == 8) >> color_format = 0x09; >> else if (hdmi->hdmi_data.enc_color_depth == 10) >> @@ -591,7 +585,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) >> color_format = 0x0F; >> else >> return; >> - } else if (hdmi->hdmi_data.enc_in_format == YCBCR422_8BITS) { >> + } else if (hdmi->hdmi_data.enc_in_format == >> + DW_HDMI_ENC_FMT_YCBCR422_8BITS) { >> if (hdmi->hdmi_data.enc_color_depth == 8) >> color_format = 0x16; >> else if (hdmi->hdmi_data.enc_color_depth == 10) >> @@ -627,20 +622,20 @@ static int is_color_space_conversion(struct dw_hdmi >> *hdmi) >> >> static int is_color_space_decimation(struct dw_hdmi *hdmi) >> { >> - if (hdmi->hdmi_data.enc_out_format != YCBCR422_8BITS) >> + if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS) >> return 0; >> - if (hdmi->hdmi_data.enc_in_format == RGB || >> - hdmi->hdmi_data.enc_in_format == YCBCR444) >> + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB || >> + hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) >> return 1; >> return 0; >> } >> >> static int is_color_space_interpolation(struct dw_hdmi *hdmi) >> { >> - if (hdmi->hdmi_data.enc_in_format != YCBCR422_8BITS) >> + if (hdmi->hdmi_data.enc_in_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS) >> return 0; >> - if (hdmi->hdmi_data.enc_out_format == RGB || >> - hdmi->hdmi_data.enc_out_format == YCBCR444) >> + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB || >> + hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) >> return 1; >> return 0; >> } >> @@ -652,13 +647,14 @@ static void dw_hdmi_update_csc_coeffs(struct dw_hdmi >> *hdmi) u32 csc_scale = 1; >> >> if (is_color_space_conversion(hdmi)) { >> - if (hdmi->hdmi_data.enc_out_format == RGB) { >> + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB) { >> if (hdmi->hdmi_data.colorimetry == >> HDMI_COLORIMETRY_ITU_601) >> csc_coeff = &csc_coeff_rgb_out_eitu601; >> else >> csc_coeff = &csc_coeff_rgb_out_eitu709; >> - } else if (hdmi->hdmi_data.enc_in_format == RGB) { >> + } else if (hdmi->hdmi_data.enc_in_format == >> + DW_HDMI_ENC_FMT_RGB) { >> if (hdmi->hdmi_data.colorimetry == >> HDMI_COLORIMETRY_ITU_601) >> csc_coeff = &csc_coeff_rgb_in_eitu601; >> @@ -730,8 +726,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi) >> struct hdmi_data_info *hdmi_data = &hdmi->hdmi_data; >> u8 val, vp_conf; >> >> - if (hdmi_data->enc_out_format == RGB || >> - hdmi_data->enc_out_format == YCBCR444) { >> + if (hdmi_data->enc_out_format == DW_HDMI_ENC_FMT_RGB || >> + hdmi_data->enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) { >> if (!hdmi_data->enc_color_depth) { >> output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS; >> } else if (hdmi_data->enc_color_depth == 8) { >> @@ -746,7 +742,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi) >> } else { >> return; >> } >> - } else if (hdmi_data->enc_out_format == YCBCR422_8BITS) { >> + } else if (hdmi_data->enc_out_format == >> + DW_HDMI_ENC_FMT_YCBCR422_8BITS) { >> if (!hdmi_data->enc_color_depth || >> hdmi_data->enc_color_depth == 8) >> remap_size = HDMI_VP_REMAP_YCC422_16bit; >> @@ -1138,15 +1135,16 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, >> struct drm_display_mode *mode) /* Initialise info frame from DRM mode */ >> drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); >> >> - if (hdmi->hdmi_data.enc_out_format == YCBCR444) >> + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) >> frame.colorspace = HDMI_COLORSPACE_YUV444; >> - else if (hdmi->hdmi_data.enc_out_format == YCBCR422_8BITS) >> + else if (hdmi->hdmi_data.enc_out_format == >> + DW_HDMI_ENC_FMT_YCBCR422_8BITS) >> frame.colorspace = HDMI_COLORSPACE_YUV422; >> else >> frame.colorspace = HDMI_COLORSPACE_RGB; >> >> /* Set up colorimetry */ >> - if (hdmi->hdmi_data.enc_out_format == XVYCC444) { >> + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_XVYCC444) { >> frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; >> if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601) >> frame.extended_colorimetry = >> @@ -1154,7 +1152,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, >> struct drm_display_mode *mode) else /*hdmi->hdmi_data.colorimetry == >> HDMI_COLORIMETRY_ITU_709*/ frame.extended_colorimetry = >> HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; >> - } else if (hdmi->hdmi_data.enc_out_format != RGB) { >> + } else if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_RGB) { >> frame.colorimetry = hdmi->hdmi_data.colorimetry; >> frame.extended_colorimetry = > HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; >> } else { /* Carries no data */ >> @@ -1443,10 +1441,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, >> struct drm_display_mode *mode) >> hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0; >> hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0; >> >> - /* TODO: Get input format from IPU (via FB driver interface) */ >> - hdmi->hdmi_data.enc_in_format = RGB; >> + /* Get input format from plat data or fallback to RGB */ >> + if (hdmi->plat_data->input_fmt >= 0) >> + hdmi->hdmi_data.enc_in_format = hdmi->plat_data->input_fmt; >> + else >> + hdmi->hdmi_data.enc_in_format = DW_HDMI_ENC_FMT_RGB; >> >> - hdmi->hdmi_data.enc_out_format = RGB; >> + hdmi->hdmi_data.enc_out_format = DW_HDMI_ENC_FMT_RGB; >> >> hdmi->hdmi_data.enc_color_depth = 8; >> hdmi->hdmi_data.pix_repet_factor = 0; >> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h >> index bcceee8..8c0cc13 100644 >> --- a/include/drm/bridge/dw_hdmi.h >> +++ b/include/drm/bridge/dw_hdmi.h >> @@ -21,6 +21,14 @@ enum { >> DW_HDMI_RES_MAX, >> }; >> >> +enum dw_hdmi_color_enc_format { >> + DW_HDMI_ENC_FMT_RGB = 0, >> + DW_HDMI_ENC_FMT_YCBCR444, >> + DW_HDMI_ENC_FMT_YCBCR422_16BITS, >> + DW_HDMI_ENC_FMT_YCBCR422_8BITS, >> + DW_HDMI_ENC_FMT_XVYCC444, >> +}; >> + >> enum dw_hdmi_phy_type { >> DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00, >> DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2, >> @@ -62,6 +70,7 @@ struct dw_hdmi_plat_data { >> struct regmap *regm; >> enum drm_mode_status (*mode_valid)(struct drm_connector *connector, >> struct drm_display_mode *mode); >> + enum dw_hdmi_color_enc_format input_fmt; > > As reported before, I think we should use a combination of media bus format > and color space information instead of a custom enum. Ideally this should also > be queried at runtime, but that could be done in a second step. > Sure, but I was struggling about finding an equivalence. How should I replace these ? DW_HDMI_ENC_FMT_RGB DW_HDMI_ENC_FMT_YCBCR444 DW_HDMI_ENC_FMT_YCBCR422_16BITS DW_HDMI_ENC_FMT_YCBCR422_8BITS DW_HDMI_ENC_FMT_XVYCC444 I do not have the strict information about the bus format, what is RGB in 8bit per pixel ? Are the 3 samples transmitted separately ? What should be the RGB colorspace ? Should we use the "Packed" formats, LVDS or a new buf format ? Jose, what are the *exact* bus formats supported ? Same for DW_HDMI_ENC_FMT_YCBCR* stuff, are they packed ? I understand the YCBCR444/XVYCC444 needs a color space information instead. Could we use the following list ? Bus Format | Colorspace | Encoding ------------------------------------------------------------------------------- MEDIA_BUS_FMT_RGB888_1X24 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB MEDIA_BUS_FMT_RGB101010_1X30 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB MEDIA_BUS_FMT_RGB121212_1X36 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB MEDIA_BUS_FMT_VUY8_1X24 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 MEDIA_BUS_FMT_YUV10_1X30 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_XV709 But all of these is complex, and I'm not sure how we should handle SDTV modes here, and without knowing the exact inputs types supported by the IP, this needs to be confirmed. Meanwhile, all this can be fixed later, at least this patch moves the definition out of the C file and uses better names for these custom enums. >> >> /* Vendor PHY support */ >> const struct dw_hdmi_phy_ops *phy_ops; >
Hi Neil, On 03-03-2017 11:31, Neil Armstrong wrote: > > Sure, but I was struggling about finding an equivalence. > > How should I replace these ? > > DW_HDMI_ENC_FMT_RGB > DW_HDMI_ENC_FMT_YCBCR444 > DW_HDMI_ENC_FMT_YCBCR422_16BITS > DW_HDMI_ENC_FMT_YCBCR422_8BITS > DW_HDMI_ENC_FMT_XVYCC444 > > I do not have the strict information about the bus format, what is RGB in 8bit per pixel ? > Are the 3 samples transmitted separately ? > What should be the RGB colorspace ? > Should we use the "Packed" formats, LVDS or a new buf format ? > > Jose, what are the *exact* bus formats supported ? Well, the controller supports everything that is in the HDMI spec (1.4 and 2.0), the implementation is the one that limits the supported formats. There is also a CSC but it does not convert from anything to everything :) I think you can safely add every MBUS code that is compatible with HDMI. Namely: - 24/30/36/48-bit RGB 4:4:4 - 24/30/36/48-bit YCbCr 4:4:4 - 16/20/24-bit YCbCr 4:2:2 - 24/30/36/48-bit YCbCr 4:2:0 And then let the glue drivers decide which they support in input and what they want in output (the output is a little tricky because it will depend in EDID, this should be handled by userspace + drm core and not the drivers so let it fixed to RGB, just in case). > > Same for DW_HDMI_ENC_FMT_YCBCR* stuff, are they packed ? Hmm, this depends on the implementation. The controller always receives 48bits of data per pixel, its the implementation that is responsible to correctly align that data. > > I understand the YCBCR444/XVYCC444 needs a color space information instead. > > Could we use the following list ? > > Bus Format | Colorspace | Encoding > ------------------------------------------------------------------------------- > MEDIA_BUS_FMT_RGB888_1X24 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB > MEDIA_BUS_FMT_RGB101010_1X30 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB > MEDIA_BUS_FMT_RGB121212_1X36 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB > MEDIA_BUS_FMT_VUY8_1X24 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X30 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_XV709 I think the HDMI spec dictates the default colorspace+encoding for each bus format, not sure though, Laurent? Best regards, Jose Miguel Abreu > > But all of these is complex, and I'm not sure how we should handle SDTV modes here, > and without knowing the exact inputs types supported by the IP, this needs to be > confirmed. > > Meanwhile, all this can be fixed later, at least this patch moves the > definition out of the C file and uses better names for these custom enums. >
On 03/03/2017 05:39 PM, Jose Abreu wrote: > Hi Neil, > > > On 03-03-2017 11:31, Neil Armstrong wrote: >> >> Sure, but I was struggling about finding an equivalence. >> >> How should I replace these ? >> >> DW_HDMI_ENC_FMT_RGB >> DW_HDMI_ENC_FMT_YCBCR444 >> DW_HDMI_ENC_FMT_YCBCR422_16BITS >> DW_HDMI_ENC_FMT_YCBCR422_8BITS >> DW_HDMI_ENC_FMT_XVYCC444 >> >> I do not have the strict information about the bus format, what is RGB in 8bit per pixel ? >> Are the 3 samples transmitted separately ? >> What should be the RGB colorspace ? >> Should we use the "Packed" formats, LVDS or a new buf format ? >> >> Jose, what are the *exact* bus formats supported ? > > Well, the controller supports everything that is in the HDMI spec > (1.4 and 2.0), the implementation is the one that limits the > supported formats. There is also a CSC but it does not convert > from anything to everything :) Sure, I was meaning the *input* format the controller receives from the pixel encoder, I'm quite sure the format is strict. > > I think you can safely add every MBUS code that is compatible > with HDMI. Namely: > - 24/30/36/48-bit RGB 4:4:4 > - 24/30/36/48-bit YCbCr 4:4:4 > - 16/20/24-bit YCbCr 4:2:2 > - 24/30/36/48-bit YCbCr 4:2:0 > > And then let the glue drivers decide which they support in input > and what they want in output (the output is a little tricky > because it will depend in EDID, this should be handled by > userspace + drm core and not the drivers so let it fixed to RGB, > just in case). > >> >> Same for DW_HDMI_ENC_FMT_YCBCR* stuff, are they packed ? > > Hmm, this depends on the implementation. The controller always > receives 48bits of data per pixel, its the implementation that is > responsible to correctly align that data. > >> >> I understand the YCBCR444/XVYCC444 needs a color space information instead. >> >> Could we use the following list ? >> >> Bus Format | Colorspace | Encoding >> ------------------------------------------------------------------------------- >> MEDIA_BUS_FMT_RGB888_1X24 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB >> MEDIA_BUS_FMT_RGB101010_1X30 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB >> MEDIA_BUS_FMT_RGB121212_1X36 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB >> MEDIA_BUS_FMT_VUY8_1X24 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X30 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_XV709 > > I think the HDMI spec dictates the default colorspace+encoding > for each bus format, not sure though, Laurent? > > Best regards, > Jose Miguel Abreu > >> >> But all of these is complex, and I'm not sure how we should handle SDTV modes here, >> and without knowing the exact inputs types supported by the IP, this needs to be >> confirmed. >> >> Meanwhile, all this can be fixed later, at least this patch moves the >> definition out of the C file and uses better names for these custom enums. >> >
Hi Neil, On 03-03-2017 16:42, Neil Armstrong wrote: > > Sure, I was meaning the *input* format the controller receives from the > pixel encoder, I'm quite sure the format is strict. > Hmm, not quite following you here. As far as the controller goes it supports the formats I mentioned: - 8/10/12/16 bits RGB 4:4:4 - 8/10/12/16 bits YCbCr 4:4:4 - 8/10/12 bits YCbCr 4:2:2 - 8/10/12/16 bits YCbCr 4:2:0 As for the CSC it supports RGB 4:4:4 to/from YCbCr 4:4:4 or 4:2:2 in every defined color depth. So, everything except 4:2:0 (I had to check documentation, I though that CSC supported less formats). Of course this is all limited by the implementation that HW team decides to choose. Best regards, Jose Miguel Abreu
On 03/03/2017 06:22 PM, Jose Abreu wrote: > Hi Neil, > > > On 03-03-2017 16:42, Neil Armstrong wrote: >> >> Sure, I was meaning the *input* format the controller receives from the >> pixel encoder, I'm quite sure the format is strict. >> > > Hmm, not quite following you here. As far as the controller goes > it supports the formats I mentioned: > - 8/10/12/16 bits RGB 4:4:4 > - 8/10/12/16 bits YCbCr 4:4:4 > - 8/10/12 bits YCbCr 4:2:2 > - 8/10/12/16 bits YCbCr 4:2:0 > > As for the CSC it supports RGB 4:4:4 to/from YCbCr 4:4:4 or 4:2:2 > in every defined color depth. > > So, everything except 4:2:0 (I had to check documentation, I > though that CSC supported less formats). > > Of course this is all limited by the implementation that HW team > decides to choose. > > Best regards, > Jose Miguel Abreu > Hi Jose, Thanks for the clarifications. I will try to add missing V4L formats - 8/10/12/16 bits RGB 4:4:4 MEDIA_BUS_FMT_RGB888_1X24 MEDIA_BUS_FMT_RGB101010_1X30 (to be added) MEDIA_BUS_FMT_RGB121212_1X36 (to be added) MEDIA_BUS_FMT_RGB161616_1X48 (to be added) - 8/10/12/16 bits YCbCr 4:4:4 MEDIA_BUS_FMT_YUV8_1X24 MEDIA_BUS_FMT_YUV10_1X30 MEDIA_BUS_FMT_YUV12_1X36 (to be added) MEDIA_BUS_FMT_YUV16_1X48 (to be added) - 8/10/12 bits YCbCr 4:2:2 MEDIA_BUS_FMT_UYVY8_1X16 MEDIA_BUS_FMT_UYVY10_1X20 MEDIA_BUS_FMT_UYVY12_1X24 - 8/10/12/16 bits YCbCr 4:2:0 Jose, how is supposed to be transmitted 4:2:0 over the controller ? Amlogic uses clock doubling to transmit 4:2:0 in CrYCb format. I assume, the transmission is in YYUYYV format in 2x clock. So the formats should be (aligned on the MEDIA_BUS_FMT_YUYV8_1_5X8) : MEDIA_BUS_FMT_YUYV8_1_1X24 (to be added) MEDIA_BUS_FMT_YUYV10_1_1X30 (to be added) MEDIA_BUS_FMT_YUYV12_1_1X36 (to be added) MEDIA_BUS_FMT_YUYV16_1_1X48 (to be added) to have the following transmissions scheme : uuuuuuuu/yyyyyyyy/yyyyyyyy vvvvvvvv/yyyyyyyy/yyyyyyyy Can you confirm this ? Neil
Hi Neil, On 06-03-2017 10:41, Neil Armstrong wrote: > On 03/03/2017 06:22 PM, Jose Abreu wrote: >> Hi Neil, >> >> >> On 03-03-2017 16:42, Neil Armstrong wrote: >>> Sure, I was meaning the *input* format the controller receives from the >>> pixel encoder, I'm quite sure the format is strict. >>> >> Hmm, not quite following you here. As far as the controller goes >> it supports the formats I mentioned: >> - 8/10/12/16 bits RGB 4:4:4 >> - 8/10/12/16 bits YCbCr 4:4:4 >> - 8/10/12 bits YCbCr 4:2:2 >> - 8/10/12/16 bits YCbCr 4:2:0 >> >> As for the CSC it supports RGB 4:4:4 to/from YCbCr 4:4:4 or 4:2:2 >> in every defined color depth. >> >> So, everything except 4:2:0 (I had to check documentation, I >> though that CSC supported less formats). >> >> Of course this is all limited by the implementation that HW team >> decides to choose. >> >> Best regards, >> Jose Miguel Abreu >> > Hi Jose, > > Thanks for the clarifications. > > I will try to add missing V4L formats > > - 8/10/12/16 bits RGB 4:4:4 > > MEDIA_BUS_FMT_RGB888_1X24 > MEDIA_BUS_FMT_RGB101010_1X30 (to be added) > MEDIA_BUS_FMT_RGB121212_1X36 (to be added) > MEDIA_BUS_FMT_RGB161616_1X48 (to be added) > > - 8/10/12/16 bits YCbCr 4:4:4 > > MEDIA_BUS_FMT_YUV8_1X24 > MEDIA_BUS_FMT_YUV10_1X30 > MEDIA_BUS_FMT_YUV12_1X36 (to be added) > MEDIA_BUS_FMT_YUV16_1X48 (to be added) > > - 8/10/12 bits YCbCr 4:2:2 > > MEDIA_BUS_FMT_UYVY8_1X16 > MEDIA_BUS_FMT_UYVY10_1X20 > MEDIA_BUS_FMT_UYVY12_1X24 > > - 8/10/12/16 bits YCbCr 4:2:0 > > Jose, how is supposed to be transmitted 4:2:0 over the controller ? > > Amlogic uses clock doubling to transmit 4:2:0 in CrYCb format. > > I assume, the transmission is in YYUYYV format in 2x clock. Double rate or half rate? 4:2:0 requires half the bandwidth and the horizontal parameters are cut off by half also. I'm not very familiar with 4:2:0 but according to spec it shall be Cb[l][n] Y[l][n] Y[l][n+1] in one line and then Cr[l][n] Y[l+1][n] Y[l+1][n+1] in another line (where "l" is pixel line number and "n" is pixel number). I've worked with 4:2:0 previously but it was just for a prof of concept (I never got to a point where I could submit anything standard), maybe someone who has worked with this can expand a little bit. Anyone? > > So the formats should be (aligned on the MEDIA_BUS_FMT_YUYV8_1_5X8) : > > MEDIA_BUS_FMT_YUYV8_1_1X24 (to be added) > MEDIA_BUS_FMT_YUYV10_1_1X30 (to be added) > MEDIA_BUS_FMT_YUYV12_1_1X36 (to be added) > MEDIA_BUS_FMT_YUYV16_1_1X48 (to be added) > > to have the following transmissions scheme : > > uuuuuuuu/yyyyyyyy/yyyyyyyy > vvvvvvvv/yyyyyyyy/yyyyyyyy > > Can you confirm this ? Seems fine, chroma in consecutive lines and luma in every line. Best regards, Jose Miguel Abreu > > Neil
On 03/06/2017 01:17 PM, Jose Abreu wrote: > Hi Neil, > > > On 06-03-2017 10:41, Neil Armstrong wrote: >> On 03/03/2017 06:22 PM, Jose Abreu wrote: >>> Hi Neil, >>> >>> >>> On 03-03-2017 16:42, Neil Armstrong wrote: >>>> Sure, I was meaning the *input* format the controller receives from the >>>> pixel encoder, I'm quite sure the format is strict. >>>> >>> Hmm, not quite following you here. As far as the controller goes >>> it supports the formats I mentioned: >>> - 8/10/12/16 bits RGB 4:4:4 >>> - 8/10/12/16 bits YCbCr 4:4:4 >>> - 8/10/12 bits YCbCr 4:2:2 >>> - 8/10/12/16 bits YCbCr 4:2:0 >>> >>> As for the CSC it supports RGB 4:4:4 to/from YCbCr 4:4:4 or 4:2:2 >>> in every defined color depth. >>> >>> So, everything except 4:2:0 (I had to check documentation, I >>> though that CSC supported less formats). >>> >>> Of course this is all limited by the implementation that HW team >>> decides to choose. >>> >>> Best regards, >>> Jose Miguel Abreu >>> >> Hi Jose, >> >> Thanks for the clarifications. >> >> I will try to add missing V4L formats >> >> - 8/10/12/16 bits RGB 4:4:4 >> >> MEDIA_BUS_FMT_RGB888_1X24 >> MEDIA_BUS_FMT_RGB101010_1X30 (to be added) >> MEDIA_BUS_FMT_RGB121212_1X36 (to be added) >> MEDIA_BUS_FMT_RGB161616_1X48 (to be added) >> >> - 8/10/12/16 bits YCbCr 4:4:4 >> >> MEDIA_BUS_FMT_YUV8_1X24 >> MEDIA_BUS_FMT_YUV10_1X30 >> MEDIA_BUS_FMT_YUV12_1X36 (to be added) >> MEDIA_BUS_FMT_YUV16_1X48 (to be added) >> >> - 8/10/12 bits YCbCr 4:2:2 >> >> MEDIA_BUS_FMT_UYVY8_1X16 >> MEDIA_BUS_FMT_UYVY10_1X20 >> MEDIA_BUS_FMT_UYVY12_1X24 >> >> - 8/10/12/16 bits YCbCr 4:2:0 >> >> Jose, how is supposed to be transmitted 4:2:0 over the controller ? >> >> Amlogic uses clock doubling to transmit 4:2:0 in CrYCb format. >> >> I assume, the transmission is in YYUYYV format in 2x clock. > > Double rate or half rate? 4:2:0 requires half the bandwidth and > the horizontal parameters are cut off by half also. I'm not very > familiar with 4:2:0 but according to spec it shall be Cb[l][n] > Y[l][n] Y[l][n+1] in one line and then Cr[l][n] Y[l+1][n] > Y[l+1][n+1] in another line (where "l" is pixel line number and > "n" is pixel number). Exact, sorry I mismatch, Amlogic doubles the clock in the encoder and divides the height by 2 to achieve half bandwidth. > > I've worked with 4:2:0 previously but it was just for a prof of > concept (I never got to a point where I could submit anything > standard), maybe someone who has worked with this can expand a > little bit. Anyone? > >> >> So the formats should be (aligned on the MEDIA_BUS_FMT_YUYV8_1_5X8) : >> >> MEDIA_BUS_FMT_YUYV8_1_1X24 (to be added) >> MEDIA_BUS_FMT_YUYV10_1_1X30 (to be added) >> MEDIA_BUS_FMT_YUYV12_1_1X36 (to be added) >> MEDIA_BUS_FMT_YUYV16_1_1X48 (to be added) >> >> to have the following transmissions scheme : >> >> uuuuuuuu/yyyyyyyy/yyyyyyyy >> vvvvvvvv/yyyyyyyy/yyyyyyyy >> >> Can you confirm this ? > > Seems fine, chroma in consecutive lines and luma in every line. > OK then, thanks, but I mismatched, it should be like the 4:2:2 entries : MEDIA_BUS_FMT_UYVY8_1_1X24 (to be added) MEDIA_BUS_FMT_UYVY10_1_1X30 (to be added) MEDIA_BUS_FMT_UYVY12_1_1X36 (to be added) MEDIA_BUS_FMT_UYVY16_1_1X48 (to be added) > Best regards, > Jose Miguel Abreu > >> >> Neil >
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c index 026a0dc..653ecd7 100644 --- a/drivers/gpu/drm/bridge/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/dw-hdmi.c @@ -35,12 +35,6 @@ #define HDMI_EDID_LEN 512 -#define RGB 0 -#define YCBCR444 1 -#define YCBCR422_16BITS 2 -#define YCBCR422_8BITS 3 -#define XVYCC444 4 - enum hdmi_datamap { RGB444_8B = 0x01, RGB444_10B = 0x03, @@ -94,8 +88,8 @@ struct hdmi_vmode { }; struct hdmi_data_info { - unsigned int enc_in_format; - unsigned int enc_out_format; + enum dw_hdmi_color_enc_format enc_in_format; + enum dw_hdmi_color_enc_format enc_out_format; unsigned int enc_color_depth; unsigned int colorimetry; unsigned int pix_repet_factor; @@ -569,7 +563,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) int color_format = 0; u8 val; - if (hdmi->hdmi_data.enc_in_format == RGB) { + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB) { if (hdmi->hdmi_data.enc_color_depth == 8) color_format = 0x01; else if (hdmi->hdmi_data.enc_color_depth == 10) @@ -580,7 +574,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) color_format = 0x07; else return; - } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) { + } else if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) { if (hdmi->hdmi_data.enc_color_depth == 8) color_format = 0x09; else if (hdmi->hdmi_data.enc_color_depth == 10) @@ -591,7 +585,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi) color_format = 0x0F; else return; - } else if (hdmi->hdmi_data.enc_in_format == YCBCR422_8BITS) { + } else if (hdmi->hdmi_data.enc_in_format == + DW_HDMI_ENC_FMT_YCBCR422_8BITS) { if (hdmi->hdmi_data.enc_color_depth == 8) color_format = 0x16; else if (hdmi->hdmi_data.enc_color_depth == 10) @@ -627,20 +622,20 @@ static int is_color_space_conversion(struct dw_hdmi *hdmi) static int is_color_space_decimation(struct dw_hdmi *hdmi) { - if (hdmi->hdmi_data.enc_out_format != YCBCR422_8BITS) + if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS) return 0; - if (hdmi->hdmi_data.enc_in_format == RGB || - hdmi->hdmi_data.enc_in_format == YCBCR444) + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB || + hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) return 1; return 0; } static int is_color_space_interpolation(struct dw_hdmi *hdmi) { - if (hdmi->hdmi_data.enc_in_format != YCBCR422_8BITS) + if (hdmi->hdmi_data.enc_in_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS) return 0; - if (hdmi->hdmi_data.enc_out_format == RGB || - hdmi->hdmi_data.enc_out_format == YCBCR444) + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB || + hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) return 1; return 0; } @@ -652,13 +647,14 @@ static void dw_hdmi_update_csc_coeffs(struct dw_hdmi *hdmi) u32 csc_scale = 1; if (is_color_space_conversion(hdmi)) { - if (hdmi->hdmi_data.enc_out_format == RGB) { + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB) { if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601) csc_coeff = &csc_coeff_rgb_out_eitu601; else csc_coeff = &csc_coeff_rgb_out_eitu709; - } else if (hdmi->hdmi_data.enc_in_format == RGB) { + } else if (hdmi->hdmi_data.enc_in_format == + DW_HDMI_ENC_FMT_RGB) { if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601) csc_coeff = &csc_coeff_rgb_in_eitu601; @@ -730,8 +726,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi) struct hdmi_data_info *hdmi_data = &hdmi->hdmi_data; u8 val, vp_conf; - if (hdmi_data->enc_out_format == RGB || - hdmi_data->enc_out_format == YCBCR444) { + if (hdmi_data->enc_out_format == DW_HDMI_ENC_FMT_RGB || + hdmi_data->enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) { if (!hdmi_data->enc_color_depth) { output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS; } else if (hdmi_data->enc_color_depth == 8) { @@ -746,7 +742,8 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi) } else { return; } - } else if (hdmi_data->enc_out_format == YCBCR422_8BITS) { + } else if (hdmi_data->enc_out_format == + DW_HDMI_ENC_FMT_YCBCR422_8BITS) { if (!hdmi_data->enc_color_depth || hdmi_data->enc_color_depth == 8) remap_size = HDMI_VP_REMAP_YCC422_16bit; @@ -1138,15 +1135,16 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) /* Initialise info frame from DRM mode */ drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); - if (hdmi->hdmi_data.enc_out_format == YCBCR444) + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444) frame.colorspace = HDMI_COLORSPACE_YUV444; - else if (hdmi->hdmi_data.enc_out_format == YCBCR422_8BITS) + else if (hdmi->hdmi_data.enc_out_format == + DW_HDMI_ENC_FMT_YCBCR422_8BITS) frame.colorspace = HDMI_COLORSPACE_YUV422; else frame.colorspace = HDMI_COLORSPACE_RGB; /* Set up colorimetry */ - if (hdmi->hdmi_data.enc_out_format == XVYCC444) { + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_XVYCC444) { frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601) frame.extended_colorimetry = @@ -1154,7 +1152,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) else /*hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_709*/ frame.extended_colorimetry = HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; - } else if (hdmi->hdmi_data.enc_out_format != RGB) { + } else if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_RGB) { frame.colorimetry = hdmi->hdmi_data.colorimetry; frame.extended_colorimetry = HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; } else { /* Carries no data */ @@ -1443,10 +1441,13 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode *mode) hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0; hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0; - /* TODO: Get input format from IPU (via FB driver interface) */ - hdmi->hdmi_data.enc_in_format = RGB; + /* Get input format from plat data or fallback to RGB */ + if (hdmi->plat_data->input_fmt >= 0) + hdmi->hdmi_data.enc_in_format = hdmi->plat_data->input_fmt; + else + hdmi->hdmi_data.enc_in_format = DW_HDMI_ENC_FMT_RGB; - hdmi->hdmi_data.enc_out_format = RGB; + hdmi->hdmi_data.enc_out_format = DW_HDMI_ENC_FMT_RGB; hdmi->hdmi_data.enc_color_depth = 8; hdmi->hdmi_data.pix_repet_factor = 0; diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h index bcceee8..8c0cc13 100644 --- a/include/drm/bridge/dw_hdmi.h +++ b/include/drm/bridge/dw_hdmi.h @@ -21,6 +21,14 @@ enum { DW_HDMI_RES_MAX, }; +enum dw_hdmi_color_enc_format { + DW_HDMI_ENC_FMT_RGB = 0, + DW_HDMI_ENC_FMT_YCBCR444, + DW_HDMI_ENC_FMT_YCBCR422_16BITS, + DW_HDMI_ENC_FMT_YCBCR422_8BITS, + DW_HDMI_ENC_FMT_XVYCC444, +}; + enum dw_hdmi_phy_type { DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00, DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2, @@ -62,6 +70,7 @@ struct dw_hdmi_plat_data { struct regmap *regm; enum drm_mode_status (*mode_valid)(struct drm_connector *connector, struct drm_display_mode *mode); + enum dw_hdmi_color_enc_format input_fmt; /* Vendor PHY support */ const struct dw_hdmi_phy_ops *phy_ops;
Some display pipelines can only provide non-RBG input pixels to the HDMI TX Controller, this patch takes the pixel format from the plat_data if provided. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> --- drivers/gpu/drm/bridge/dw-hdmi.c | 59 ++++++++++++++++++++-------------------- include/drm/bridge/dw_hdmi.h | 9 ++++++ 2 files changed, 39 insertions(+), 29 deletions(-)