Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

On 03/13/2017 12:43 PM, Jose Abreu wrote:
> Hi Neil,
> 
> 
> On 09-03-2017 14:27, Jose Abreu wrote:
>> Hi Neil,
>>
>>
>> On 08-03-2017 12:12, Neil Armstrong wrote:
>>> Hi Jose,
>>>
>>> It seems here that we only have the RGB444<->YUV444 8bit tables, from the 
>>> Amlogic
>>> source I have the following for 10bit, 12bit and 16bit for itu601 :
>>>
>>> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
>>> { 0x2000, 0x6926, 0x74fd, 0x043b },
>>> { 0x2000, 0x2cdd, 0x, 0x7a65 },
>>> { 0x2000, 0x, 0x38b4, 0x78ea }
>>> };
>>>
>>> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
>>> { 0x2000, 0x6926, 0x74fd, 0x10ee },
>>> { 0x2000, 0x2cdd, 0x, 0x6992 },
>>> { 0x2000, 0x, 0x38b4, 0x63a6 }
>>> };
>> These two do not match anything I have here.
>>
>>> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
>>> { 0x2591, 0x1322, 0x074b, 0x },
>>> { 0x6535, 0x2000, 0x7acc, 0x0800 },
>>> { 0x6acd, 0x7534, 0x2000, 0x0800 }
>>> };
>> This is more or less correct, I have small offsets. Note that I
>> even have offsets with the values that are in dw-hdmi driver,
>> which can be caused because I'm seeing the latest document that
>> contain these values. I guess they were updated.
>>
>>> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
>>> { 0x2591, 0x1322, 0x074b, 0x },
>>> { 0x6535, 0x2000, 0x7acc, 0x2000 },
>>> { 0x6acd, 0x7534, 0x2000, 0x2000 }
>>> };
>> The same for this.
>>
>>> But I miss the itu709 values.
>>>
>>> Could you confirm these values and maybe provide the itu709 values ?
>> I will have to check if I can provide you the values. I will get
>> back to you.
> 
> Sorry but looks like I won't be able to provide you the correct
> values :/ If you are working for a Synopsys customer you can
> contact our CAE (If so I can guide you to the correct CAE).
> 
> Anyway, unless you can test the values you have I suggest you
> don't use them, they do not match what I have here and I can't
> test them because right now I don't have a setup (I'm assuming
> that your CSC block within the controller was not modified).
> 
> Best regards,
> Jose Miguel Abreu
> 

Hi Jose,

Thanks for your effort, I will postpone this fix and only add the tables
needed by the Amlogic platform when needed.

Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Jose Abreu]

Hi Neil,


On 09-03-2017 14:27, Jose Abreu wrote:
> Hi Neil,
>
>
> On 08-03-2017 12:12, Neil Armstrong wrote:
>> Hi Jose,
>>
>> It seems here that we only have the RGB444<->YUV444 8bit tables, from the 
>> Amlogic
>> source I have the following for 10bit, 12bit and 16bit for itu601 :
>>
>> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
>>  { 0x2000, 0x6926, 0x74fd, 0x043b },
>>  { 0x2000, 0x2cdd, 0x, 0x7a65 },
>>  { 0x2000, 0x, 0x38b4, 0x78ea }
>> };
>>
>> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
>>  { 0x2000, 0x6926, 0x74fd, 0x10ee },
>>  { 0x2000, 0x2cdd, 0x, 0x6992 },
>>  { 0x2000, 0x, 0x38b4, 0x63a6 }
>> };
> These two do not match anything I have here.
>
>> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
>>  { 0x2591, 0x1322, 0x074b, 0x },
>>  { 0x6535, 0x2000, 0x7acc, 0x0800 },
>>  { 0x6acd, 0x7534, 0x2000, 0x0800 }
>> };
> This is more or less correct, I have small offsets. Note that I
> even have offsets with the values that are in dw-hdmi driver,
> which can be caused because I'm seeing the latest document that
> contain these values. I guess they were updated.
>
>> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
>>  { 0x2591, 0x1322, 0x074b, 0x },
>>  { 0x6535, 0x2000, 0x7acc, 0x2000 },
>>  { 0x6acd, 0x7534, 0x2000, 0x2000 }
>> };
> The same for this.
>
>> But I miss the itu709 values.
>>
>> Could you confirm these values and maybe provide the itu709 values ?
> I will have to check if I can provide you the values. I will get
> back to you.

Sorry but looks like I won't be able to provide you the correct
values :/ If you are working for a Synopsys customer you can
contact our CAE (If so I can guide you to the correct CAE).

Anyway, unless you can test the values you have I suggest you
don't use them, they do not match what I have here and I can't
test them because right now I don't have a setup (I'm assuming
that your CSC block within the controller was not modified).

Best regards,
Jose Miguel Abreu

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Jose Abreu]

Hi Neil,


On 08-03-2017 12:12, Neil Armstrong wrote:
>
> Hi Jose,
>
> It seems here that we only have the RGB444<->YUV444 8bit tables, from the 
> Amlogic
> source I have the following for 10bit, 12bit and 16bit for itu601 :
>
> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
>   { 0x2000, 0x6926, 0x74fd, 0x043b },
>   { 0x2000, 0x2cdd, 0x, 0x7a65 },
>   { 0x2000, 0x, 0x38b4, 0x78ea }
> };
>
> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
>   { 0x2000, 0x6926, 0x74fd, 0x10ee },
>   { 0x2000, 0x2cdd, 0x, 0x6992 },
>   { 0x2000, 0x, 0x38b4, 0x63a6 }
> };

These two do not match anything I have here.

>
> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
>   { 0x2591, 0x1322, 0x074b, 0x },
>   { 0x6535, 0x2000, 0x7acc, 0x0800 },
>   { 0x6acd, 0x7534, 0x2000, 0x0800 }
> };

This is more or less correct, I have small offsets. Note that I
even have offsets with the values that are in dw-hdmi driver,
which can be caused because I'm seeing the latest document that
contain these values. I guess they were updated.

>
> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
>   { 0x2591, 0x1322, 0x074b, 0x },
>   { 0x6535, 0x2000, 0x7acc, 0x2000 },
>   { 0x6acd, 0x7534, 0x2000, 0x2000 }
> };

The same for this.

>
> But I miss the itu709 values.
>
> Could you confirm these values and maybe provide the itu709 values ?

I will have to check if I can provide you the values. I will get
back to you.

Best regards,
Jose Miguel Abreu

>
> Thanks !
> Neil
>


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

On 03/07/2017 06:35 PM, Jose Abreu wrote:
> Hi Neil,
> 
> 
> On 07-03-2017 16:42, 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 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 322 
>> +-
>>  include/drm/bridge/dw_hdmi.h  |  63 ++
>>  2 files changed, 290 insertions(+), 95 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 1ed8bc1..348311c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -30,17 +30,14 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +#include 
>> +
>>  #include "dw-hdmi.h"
>>  #include "dw-hdmi-audio.h"
>>  
>>  #define HDMI_EDID_LEN   512
>>  
>> -#define RGB 0
>> -#define YCBCR4441
>> -#define YCBCR422_16BITS 2
>> -#define YCBCR422_8BITS  3
>> -#define XVYCC4444
>> -
>>  enum hdmi_datamap {
>>  RGB444_8B = 0x01,
>>  RGB444_10B = 0x03,
>> @@ -94,10 +91,10 @@ struct hdmi_vmode {
>>  };
>>  
>>  struct hdmi_data_info {
>> -unsigned int enc_in_format;
>> -unsigned int enc_out_format;
>> -unsigned int enc_color_depth;
>> -unsigned int colorimetry;
>> +unsigned int enc_in_bus_format;
>> +unsigned int enc_out_bus_format;
>> +unsigned int enc_in_encoding;
>> +unsigned int enc_out_encoding;
>>  unsigned int pix_repet_factor;
>>  unsigned int hdcp_enable;
>>  struct hdmi_vmode video_mode;
>> @@ -557,6 +554,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>>  
>> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +return 8;
>> +
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +return 10;
>> +
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +return 12;
>> +
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return 16;
>> +
>> +default:
>> +return 0;
> 
> Maybe fallback to 8bpp in case of error as this is the most
> common supported.
> 
>> +}
>> +}
>> +
>>  /*
>>   * this submodule is responsible for the video data synchronization.
>>   * for example, for RGB 4:4:4 input, the data map is defined as
>> @@ -569,37 +652,45 @@ 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_color_depth == 8)
>> -color_format = 0x01;
>> -else if (hdmi->hdmi_data.enc_color_depth == 10)
>> -color_format = 0x03;
>> -else if (hdmi->hdmi_data.enc_color_depth == 12)
>> -color_format = 0x05;
>> -else if (hdmi->hdmi_data.enc_color_depth == 16)
>> -

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

On 03/07/2017 06:35 PM, Jose Abreu wrote:
> Hi Neil,
> 
> 
> On 07-03-2017 16:42, 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 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 322 
>> +-
>>  include/drm/bridge/dw_hdmi.h  |  63 ++
>>  2 files changed, 290 insertions(+), 95 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 1ed8bc1..348311c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -30,17 +30,14 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +#include 
>> +
>>  #include "dw-hdmi.h"
>>  #include "dw-hdmi-audio.h"
>>  
>>  #define HDMI_EDID_LEN   512
>>  
>> -#define RGB 0
>> -#define YCBCR4441
>> -#define YCBCR422_16BITS 2
>> -#define YCBCR422_8BITS  3
>> -#define XVYCC4444
>> -
>>  enum hdmi_datamap {
>>  RGB444_8B = 0x01,
>>  RGB444_10B = 0x03,
>> @@ -94,10 +91,10 @@ struct hdmi_vmode {
>>  };
>>  
>>  struct hdmi_data_info {
>> -unsigned int enc_in_format;
>> -unsigned int enc_out_format;
>> -unsigned int enc_color_depth;
>> -unsigned int colorimetry;
>> +unsigned int enc_in_bus_format;
>> +unsigned int enc_out_bus_format;
>> +unsigned int enc_in_encoding;
>> +unsigned int enc_out_encoding;
>>  unsigned int pix_repet_factor;
>>  unsigned int hdcp_enable;
>>  struct hdmi_vmode video_mode;
>> @@ -557,6 +554,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>>  
>> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +return 8;
>> +
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +return 10;
>> +
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +return 12;
>> +
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return 16;
>> +
>> +default:
>> +return 0;
> 
> Maybe fallback to 8bpp in case of error as this is the most
> common supported.

The "return 0" mimics when enc_color_depth was set to 0, and it has a meaning
when used in other functions.
To be honest, I'm not sure if these cases are legit.

> 
>> +}
>> +}
>> +
>>  /*
>>   * this submodule is responsible for the video data synchronization.
>>   * for example, for RGB 4:4:4 input, the data map is defined as
>> @@ -569,37 +652,45 @@ 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_color_depth == 8)
>> -color_format = 0x01;
>> -else if (hdmi->hdmi_data.enc_color_depth == 10)
>> -color_format = 0x03;
>> -

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Jose Abreu]

Hi Neil,


On 07-03-2017 16:42, 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 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 322 
> +-
>  include/drm/bridge/dw_hdmi.h  |  63 ++
>  2 files changed, 290 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 1ed8bc1..348311c 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -30,17 +30,14 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  #include "dw-hdmi.h"
>  #include "dw-hdmi-audio.h"
>  
>  #define HDMI_EDID_LEN512
>  
> -#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,10 +91,10 @@ struct hdmi_vmode {
>  };
>  
>  struct hdmi_data_info {
> - unsigned int enc_in_format;
> - unsigned int enc_out_format;
> - unsigned int enc_color_depth;
> - unsigned int colorimetry;
> + unsigned int enc_in_bus_format;
> + unsigned int enc_out_bus_format;
> + unsigned int enc_in_encoding;
> + unsigned int enc_out_encoding;
>   unsigned int pix_repet_factor;
>   unsigned int hdcp_enable;
>   struct hdmi_vmode video_mode;
> @@ -557,6 +554,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>  
> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_UYVY8_1_1X24:
> + case MEDIA_BUS_FMT_UYVY10_1_1X30:
> + case MEDIA_BUS_FMT_UYVY12_1_1X36:
> + case MEDIA_BUS_FMT_UYVY16_1_1X48:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_1_1X24:
> + return 8;
> +
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_UYVY10_1_1X30:
> + return 10;
> +
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + case MEDIA_BUS_FMT_UYVY12_1_1X36:
> + return 12;
> +
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + case MEDIA_BUS_FMT_UYVY16_1_1X48:
> + return 16;
> +
> + default:
> + return 0;

Maybe fallback to 8bpp in case of error as this is the most
common supported.

> + }
> +}
> +
>  /*
>   * this submodule is responsible for the video data synchronization.
>   * for example, for RGB 4:4:4 input, the data map is defined as
> @@ -569,37 +652,45 @@ 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_color_depth == 8)
> - color_format = 0x01;
> - else if (hdmi->hdmi_data.enc_color_depth == 10)
> - color_format = 0x03;
> - else if (hdmi->hdmi_data.enc_color_depth == 12)
> - color_format = 0x05;
> - else if (hdmi->hdmi_data.enc_color_depth == 16)
> - color_format = 0x07;
> - else
> - return;
> - } else if