Re: [PATCH 2/2] drm/rockchip: dw_hdmi: add rk3568 support【请注意，邮件由linux-rockchip-bounces+algea.cao=rock-chips....@lists.infradead.org代发】
Hi Benjamin,
RK3568 hdmi phy ref clock source is HPLL. HPLL must be set when
switching resolution or plugging.
Whether to add the configuration for HPLL?
Thanks!
在 2021/7/5 22:03, Benjamin Gaignard 写道:
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 28 +
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 830bdd5e9b7ce..5817c3a9fe64b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -50,6 +50,10 @@
#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_HDMI_LCDC_SEL BIT(6)
+#define RK3568_GRF_VO_CON1 0x0364
+#define RK3568_HDMI_SDAIN_MSK BIT(15)
+#define RK3568_HDMI_SCLIN_MSK BIT(14)
+
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
/**
@@ -467,6 +471,19 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data
= {
.use_drm_infoframe = true,
};
+static struct rockchip_hdmi_chip_data rk3568_chip_data = {
+ .lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
+ .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mpll_cfg = rockchip_mpll_cfg,
+ .cur_ctr= rockchip_cur_ctr,
+ .phy_config = rockchip_phy_config,
+ .phy_data = _chip_data,
+ .use_drm_infoframe = true,
+};
+
static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
{ .compatible = "rockchip,rk3228-dw-hdmi",
.data = _hdmi_drv_data
@@ -480,6 +497,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[]
= {
{ .compatible = "rockchip,rk3399-dw-hdmi",
.data = _hdmi_drv_data
},
+ { .compatible = "rockchip,rk3568-dw-hdmi",
+ .data = _hdmi_drv_data
+ },
{},
};
MODULE_DEVICE_TABLE(of, dw_hdmi_rockchip_dt_ids);
@@ -536,6 +556,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ if (hdmi->chip_data == _chip_data) {
+ regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
+HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
+ RK3568_HDMI_SCLIN_MSK,
+ RK3568_HDMI_SDAIN_MSK |
+ RK3568_HDMI_SCLIN_MSK));
+ }
+
hdmi->phy = devm_phy_optional_get(dev, "hdmi");
if (IS_ERR(hdmi->phy)) {
ret = PTR_ERR(hdmi->phy);
Re: [PATCH v2 1/3] drm: rockchip: hdmi: fix clock rounding code
在 2020/9/23 4:31, Vicente Bergas 写道: Under certain conditions vop_crtc_mode_fixup rounds the clock 14850 to 148501000 which leads to the following error: dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock 148501000) The issue was found on RK3399 booting with u-boot. U-boot configures the display at 2560x1440 and then linux comes up with a black screen. A workaround was to un-plug and re-plug the HDMI display. Signed-off-by: Vicente Bergas Tested-by: Vicente Bergas --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index c80f7d9fd13f..92efbd899dee 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -1176,12 +1176,9 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc, * * 2. Get the clock framework to round the rate for us to tell us *what it will actually make. -* -* 3. Store the rounded up rate so that we don't need to worry about -*this in the actual clk_set_rate(). */ rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); - adjusted_mode->clock = DIV_ROUND_UP(rate, 1000); + adjusted_mode->clock = rate / 1000; return true; } @@ -1380,7 +1377,7 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc, VOP_REG_SET(vop, intr, line_flag_num[0], vact_end); - clk_set_rate(vop->dclk, adjusted_mode->clock * 1000); + clk_set_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); In some RK platform, such as RK3328, dclk is generated by the INNO HDMI PHY PLL, which support frac divider can support any dclk frequency. And The PLL must use the exact clock to determine the PLL configuration. So adjusted_mode->clock * 1000 + 999 may cause INNO HDMI PHY PLL couldn't find the right configuration. INNO HDMI PHY's driver path is: drivers/phy/rockchip/phy-rockchip-inno-hdmi.c VOP_REG_SET(vop, common, standby, 0); mutex_unlock(>vop_lock); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rockchip: hdmi: remove vop_crtc_mode_fixup to fix clock handling【请注意，邮件由linux-rockchip-bounces+andy.yan=rock-chips....@lists.infradead.org代发】
Hello Vicente,
在 2020/9/22 15:40, Andy Yan 写道:
Add our HDMI driver owner Algea to list.
On 9/22/20 2:18 AM, Vicente Bergas wrote:
Under certain conditions vop_crtc_mode_fixup rounds the clock
May I ask under what conditions that the clock of HDMI will
be changed to 148501000? In general, the description of clock
in EDID will not be detailed below the thousands place.
14850 to 148501000 which leads to the following error:
dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock
148501000)
The issue was found on RK3399 booting with u-boot. U-boot configures the
display at 2560x1440 and then linux comes up with a black screen.
A workaround was to un-plug and re-plug the HDMI display.
Signed-off-by: Vicente Bergas
Tested-by: Vicente Bergas
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 45 -
1 file changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..fe80da652994 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1142,50 +1142,6 @@ static void vop_crtc_disable_vblank(struct
drm_crtc *crtc)
spin_unlock_irqrestore(>irq_lock, flags);
}
-static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- struct vop *vop = to_vop(crtc);
- unsigned long rate;
-
- /*
- * Clock craziness.
- *
- * Key points:
- *
- * - DRM works in in kHz.
- * - Clock framework works in Hz.
- * - Rockchip's clock driver picks the clock rate that is the
- * same _OR LOWER_ than the one requested.
- *
- * Action plan:
- *
- * 1. When DRM gives us a mode, we should add 999 Hz to it.
That way
- * if the clock we need is 6001 Hz (~60 MHz) and DRM
tells us to
- * make 6 kHz then the clock framework will actually give us
- * the right clock.
- *
- * NOTE: if the PLL (maybe through a divider) could actually
make
- * a clock rate 999 Hz higher instead of the one we want then
this
- * could be a problem. Unfortunately there's not much we can do
- * since it's baked into DRM to use kHz. It shouldn't matter in
- * practice since Rockchip PLLs are controlled by tables and
- * even if there is a divider in the middle I wouldn't expect
PLL
- * rates in the table that are just a few kHz different.
- *
- * 2. Get the clock framework to round the rate for us to tell us
- * what it will actually make.
- *
- * 3. Store the rounded up rate so that we don't need to worry
about
- * this in the actual clk_set_rate().
- */
- rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 +
999);
- adjusted_mode->clock = DIV_ROUND_UP(rate, 1000);
-
- return true;
-}
-
static bool vop_dsp_lut_is_enabled(struct vop *vop)
{
return vop_read_reg(vop, 0, >data->common->dsp_lut_en);
@@ -1512,7 +1468,6 @@ static void vop_crtc_atomic_flush(struct
drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
- .mode_fixup = vop_crtc_mode_fixup,
.atomic_check = vop_crtc_atomic_check,
.atomic_begin = vop_crtc_atomic_begin,
.atomic_flush = vop_crtc_atomic_flush,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rockchip: hdmi: remove vop_crtc_mode_fixup to fix clock handling【请注意，邮件由linux-rockchip-bounces+andy.yan=rock-chips....@lists.infradead.org代发】
Hi, Douglas
在 2020/9/22 17:31, Vicente Bergas 写道:
On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
Hello Vicente,
在 2020/9/22 15:40, Andy Yan 写道:
Add our HDMI driver owner Algea to list.
On 9/22/20 2:18 AM, Vicente Bergas wrote:
Under certain conditions vop_crtc_mode_fixup rounds the clock
May I ask under what conditions that the clock of HDMI will
be changed to 148501000? In general, the description of clock
in EDID will not be detailed below the thousands place.
There is no clock in the EDID with 1KHz resolution, the clock is
14850 which has 500KHz resolution.
It is the function vop_crtc_mode_fixup that gets xxx and returns xxx1000
I checked the commit msg of commit 287422a95fe2 ("drm/rockchip: Round up
_before_ giving to the clock framework").
Round up hdmi clock is for some panels with special clocks. Are these
panels clock can't be divided correctly common?
14850 to 148501000 which leads to the following error:
dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock
148501000)
The issue was found on RK3399 booting with u-boot. U-boot configures the
display at 2560x1440 and then linux comes up with a black screen.
A workaround was to un-plug and re-plug the HDMI display.
Signed-off-by: Vicente Bergas
Tested-by: Vicente Bergas
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 45 -
1 file changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..fe80da652994 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1142,50 +1142,6 @@ static void vop_crtc_disable_vblank(struct
drm_crtc *crtc)
spin_unlock_irqrestore(>irq_lock, flags);
}
-static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
-struct vop *vop = to_vop(crtc);
-unsigned long rate;
-
-/*
- * Clock craziness.
- *
- * Key points:
- *
- * - DRM works in in kHz.
- * - Clock framework works in Hz.
- * - Rockchip's clock driver picks the clock rate that is the
- * same _OR LOWER_ than the one requested.
- *
- * Action plan:
- *
- * 1. When DRM gives us a mode, we should add 999 Hz to it.
That way
- *if the clock we need is 6001 Hz (~60 MHz) and DRM
tells us to
- *make 6 kHz then the clock framework will actually give us
- *the right clock.
- *
- *NOTE: if the PLL (maybe through a divider) could actually
make
- *a clock rate 999 Hz higher instead of the one we want then
this
- *could be a problem. Unfortunately there's not much we can do
- *since it's baked into DRM to use kHz. It shouldn't matter in
- *practice since Rockchip PLLs are controlled by tables and
- *even if there is a divider in the middle I wouldn't expect
PLL
- *rates in the table that are just a few kHz different.
- *
- * 2. Get the clock framework to round the rate for us to tell us
- *what it will actually make.
- *
- * 3. Store the rounded up rate so that we don't need to worry
about
- *this in the actual clk_set_rate().
- */
-rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 +
999);
-adjusted_mode->clock = DIV_ROUND_UP(rate, 1000);
-
-return true;
-}
-
static bool vop_dsp_lut_is_enabled(struct vop *vop)
{
return vop_read_reg(vop, 0, >data->common->dsp_lut_en);
@@ -1512,7 +1468,6 @@ static void vop_crtc_atomic_flush(struct
drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
-.mode_fixup = vop_crtc_mode_fixup,
.atomic_check = vop_crtc_atomic_check,
.atomic_begin = vop_crtc_atomic_begin,
.atomic_flush = vop_crtc_atomic_flush,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
Hi,
在 2020/9/1 3:53, Ville Syrjälä 写道:
On Fri, Aug 28, 2020 at 09:07:13AM +0800, crj wrote:
Hi Ville Syrjälä,
在 2020/8/27 18:57, Ville Syrjälä 写道:
On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
And what exactly do you want to do with that data?
We can get colorimetry data block from edid then support
HDMI colorimetry such as BT2020.
But what do you want to do with it? The patch does nothing
functional.
If we want to output BT2020 in HDMI driver, we can know whether TV
support BT2020
via connector->display_info.hdmi.colorimetry. If TV don't support
BT2020, HDMI shouldn't
ouput in BT2020.
Signed-off-by: Algea Cao
---
drivers/gpu/drm/drm_edid.c | 45 +
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 14
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 31496b6cfc56..67e607c04492 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
#define HDR_STATIC_METADATA_BLOCK0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
@@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 2)
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_hdmi_info *info = >display_info.hdmi;
+
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
+ if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
+ /* Byte 4 Bit 7: DCI-P3 */
+ if (db[3] & BIT(7))
+ info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
+
+ DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
+}
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != USE_EXTENDED_TAG)
@@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index af145608b5ed..d599c3b9e881 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,9 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /* @colorimetry: bitmap of supported colorimetry modes */
+ u16 colorimetry;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index cfa4f5af49af..98fa78c2f82d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,20 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/*
+ * Supported Colorimetry from colorimetry data block
+ * as per CEA 861-G spec
+ */
+#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
+#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
+#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
+#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
+#define DRM_EDID_CLRMETRY_ADB_RGB (
Re: [PATCH] drm: Parse Colorimetry data block from EDID
Hi Ville Syrjälä,
在 2020/8/27 18:57, Ville Syrjälä 写道:
On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
And what exactly do you want to do with that data?
We can get colorimetry data block from edid then support
HDMI colorimetry such as BT2020.
Signed-off-by: Algea Cao
---
drivers/gpu/drm/drm_edid.c | 45 +
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 14
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 31496b6cfc56..67e607c04492 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
@@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 2)
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_hdmi_info *info = >display_info.hdmi;
+
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
+ if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
+ /* Byte 4 Bit 7: DCI-P3 */
+ if (db[3] & BIT(7))
+ info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
+
+ DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
+}
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != USE_EXTENDED_TAG)
@@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index af145608b5ed..d599c3b9e881 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,9 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /* @colorimetry: bitmap of supported colorimetry modes */
+ u16 colorimetry;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index cfa4f5af49af..98fa78c2f82d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,20 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/*
+ * Supported Colorimetry from colorimetry data block
+ * as per CEA 861-G spec
+ */
+#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
+#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
+#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
+#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
+#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
+#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
+#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
+#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
+#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel
Re: [PATCH 4/6] drm/rockchip: dw_hdmi: Add vendor hdmi properties
Hi Lauren,
Thank you for your review.
在 2020/8/12 17:33, Laurent Pinchart 写道:
Hi Algea,
Thank you for the patch.
On Wed, Aug 12, 2020 at 04:35:43PM +0800, Algea Cao wrote:
Introduce struct dw_hdmi_property_ops in plat_data to support
vendor hdmi property.
Implement hdmi vendor properties color_depth_property and
hdmi_output_property to config hdmi output color depth and
color format.
The property "hdmi_output_format", the possible value
could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
Default value of the property is set to 0 = RGB, so no changes if you
don't set the property.
The property "hdmi_output_depth" possible value could be
- Automatic
This indicates prefer highest color depth, it is
30bit on rockcip platform.
- 24bit
- 30bit
The default value of property is 24bit.
Signed-off-by: Algea Cao
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 174
include/drm/bridge/dw_hdmi.h| 22 +++
2 files changed, 196 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 23de359a1dec..8f22d9a566db 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -52,6 +52,27 @@
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
+/* HDMI output pixel format */
+enum drm_hdmi_output_type {
+ DRM_HDMI_OUTPUT_DEFAULT_RGB, /* default RGB */
+ DRM_HDMI_OUTPUT_YCBCR444, /* YCBCR 444 */
+ DRM_HDMI_OUTPUT_YCBCR422, /* YCBCR 422 */
+ DRM_HDMI_OUTPUT_YCBCR420, /* YCBCR 420 */
+ DRM_HDMI_OUTPUT_YCBCR_HQ, /* Highest subsampled YUV */
+ DRM_HDMI_OUTPUT_YCBCR_LQ, /* Lowest subsampled YUV */
+ DRM_HDMI_OUTPUT_INVALID, /* Guess what ? */
+};
Vendor-specific properties shouldn't use names starting with drm_ or
DRM_, that's for the DRM core. But this doesn't seem specific to
Rockchip at all, it should be a standard property. Additionally, new
properties need to come with a userspace implementation showing their
usage, in X.org, Weston, the Android DRM/KMS HW composer, or another
relevant upstream project (a test tool is usually not enough).
We use these properties only in Android HW composer, But we can't upstream
our HW composer code right now. Can we use this properties as private
property
and do not upstream HW composer for the time being?
+
+enum dw_hdmi_rockchip_color_depth {
+ ROCKCHIP_HDMI_DEPTH_8,
+ ROCKCHIP_HDMI_DEPTH_10,
+ ROCKCHIP_HDMI_DEPTH_12,
+ ROCKCHIP_HDMI_DEPTH_16,
+ ROCKCHIP_HDMI_DEPTH_420_10,
+ ROCKCHIP_HDMI_DEPTH_420_12,
+ ROCKCHIP_HDMI_DEPTH_420_16
+};
+
/**
* struct rockchip_hdmi_chip_data - splite the grf setting of kind of chips
* @lcdsel_grf_reg: grf register offset of lcdc select
@@ -73,6 +94,12 @@ struct rockchip_hdmi {
struct clk *grf_clk;
struct dw_hdmi *hdmi;
struct phy *phy;
+
+ struct drm_property *color_depth_property;
+ struct drm_property *hdmi_output_property;
+
+ unsigned int colordepth;
+ enum drm_hdmi_output_type hdmi_output;
};
#define to_rockchip_hdmi(x) container_of(x, struct rockchip_hdmi, x)
@@ -327,6 +354,150 @@ static void dw_hdmi_rockchip_genphy_disable(struct
dw_hdmi *dw_hdmi, void *data)
phy_power_off(hdmi->phy);
}
+static const struct drm_prop_enum_list color_depth_enum_list[] = {
+ { 0, "Automatic" }, /* Prefer highest color depth */
+ { 8, "24bit" },
+ { 10, "30bit" },
+};
+
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
+ { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+ { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+ { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+ { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
+ { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling" },
+ { DRM_HDMI_OUTPUT_YCBCR_LQ, "output_ycbcr_low_subsampling" },
+ { DRM_HDMI_OUTPUT_INVALID, "invalid_output" },
+};
+
+static void
+dw_hdmi_rockchip_attach_properties(struct drm_connector *connector,
+ unsigned int color, int version,
+ void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ struct drm_property *prop;
+
+ switch (color) {
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ hdmi->hdmi_output = DRM_HDMI_OUTPUT_DEFAULT_RGB;
+ hdmi->colordepth = 10;
+ break;
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ hdmi->hdmi_output = DRM_HDMI_OUTPUT_YCBCR444;
+ hdmi->colordepth = 8;
+ break;
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ hdmi->hdmi_output = DRM_HDMI_OUTPUT_YCBCR444;
+ hdmi->colordepth = 10;
+ break;
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+
