public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: dri-devel@lists.freedesktop.org,
	laurent.pinchart+renesas@ideasonboard.com,
	Jose.Abreu@synopsys.com, kieran.bingham@ideasonboard.com,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data
Date: Tue, 17 Jan 2017 16:48:41 +0200	[thread overview]
Message-ID: <5448085.cpOE2LFyiJ@avalon> (raw)
In-Reply-To: <1484656294-6140-5-git-send-email-narmstrong@baylibre.com>

Hi Neil,

Thank you for the patch.

On Tuesday 17 Jan 2017 13:31:34 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 | 7 +++++--
>  include/drm/bridge/dw_hdmi.h     | 9 +++++++++
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 8a6a183..fa4147c 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1420,8 +1420,11 @@ 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 = RGB;

This should ideally be queried dynamically. I believe we need to extend the 
DRM bridge API for this purpose. I might be willing to accept a pdata-based 
solution in the meantime though.

>  	hdmi->hdmi_data.enc_out_format = RGB;
> 
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index d6a0ab3..4f426c3 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_INPUT_FMT_RGB = 0,
> +	DW_HDMI_INPUT_FMT_YCBCR444,
> +	DW_HDMI_INPUT_FMT_YCBCR422_16BITS,
> +	DW_HDMI_INPUT_FMT_YCBCR422_8BITS,
> +	DW_HDMI_INPUT_FMT_XVYCC444,
> +};

How about giving the enum a name and dropping the

#define RGB                     0
#define YCBCR444                1
#define YCBCR422_16BITS         2
#define YCBCR422_8BITS          3
#define XVYCC444                4

macros from the driver ? Even better, how about using a media bus format code 
from include/uapi/linux/media-bus-format.h ? We would need an additional 
colorspace field to express the difference between the YCBCR and XVYCC 
formats, as both of them are YUV 4:4:4 and map to the same bus format.

>  enum dw_hdmi_phy_type {
>  	DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
>  	DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
> @@ -68,6 +76,7 @@ struct dw_hdmi_plat_data {
>  				 const struct dw_hdmi_plat_data *data);
>  	bool (*hdmi_read_hpd)(struct dw_hdmi *hdmi,
>  			      const struct dw_hdmi_plat_data *data);
> +	int input_fmt;
>  };
> 
>  int dw_hdmi_probe(struct platform_device *pdev,

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2017-01-17 14:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17 12:31 [RFC/RFT PATCH 0/4] drm/bridge: dw-hdmi: Add support for Custom PHYs Neil Armstrong
2017-01-17 12:31 ` [RFC/RFT PATCH 1/4] drm/bridge: dw-hdmi: Switch to regmap for register access Neil Armstrong
2017-01-17 14:39   ` Laurent Pinchart
2017-01-20 15:12     ` Neil Armstrong
2017-01-17 12:31 ` [RFC/RFT PATCH 2/4] drm/bridge: dw-hdmi: Add support for custom PHY handling Neil Armstrong
2017-01-17 14:54   ` Laurent Pinchart
2017-01-18 10:40   ` Jose Abreu
2017-01-18 11:20     ` Neil Armstrong
2017-01-19 14:20       ` Jose Abreu
2017-01-17 12:31 ` [RFC/RFT PATCH 3/4] drm/bridge: dw-hdmi: Enable CSC even for DVI Neil Armstrong
2017-01-17 14:40   ` Laurent Pinchart
2017-01-18 10:22   ` Jose Abreu
2017-01-18 11:15     ` Neil Armstrong
2017-01-17 12:31 ` [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data Neil Armstrong
2017-01-17 14:48   ` Laurent Pinchart [this message]
2017-01-18 10:28   ` Jose Abreu
2017-01-18 11:24     ` Neil Armstrong
2017-01-18 20:49       ` Laurent Pinchart
2017-01-19 15:21         ` Jose Abreu
2017-01-19 15:30           ` Hans Verkuil
2017-01-19 16:45             ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5448085.cpOE2LFyiJ@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox