[PATCH] drm/ast: Support AST2500
From: "Y.C. Chen"
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_drv.h| 2 +
drivers/gpu/drm/ast/ast_main.c | 27 ++-
drivers/gpu/drm/ast/ast_mode.c | 25 +-
drivers/gpu/drm/ast/ast_post.c | 510 ++-
drivers/gpu/drm/ast/ast_tables.h | 57 -
5 files changed, 596 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 908011d..7e406ce 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -64,6 +64,7 @@ enum ast_chip {
AST2150,
AST2300,
AST2400,
+ AST2500,
AST1180,
};
@@ -80,6 +81,7 @@ enum ast_tx_chip {
#define AST_DRAM_1Gx32 3
#define AST_DRAM_2Gx16 6
#define AST_DRAM_4Gx16 7
+#define AST_DRAM_8Gx16 8
struct ast_fbdev;
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f75c642..40460ce 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -73,7 +73,10 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
ast->chip = AST1100;
DRM_INFO("AST 1180 detected\n");
} else {
- if (dev->pdev->revision >= 0x30) {
+ if (dev->pdev->revision >= 0x40) {
+ ast->chip = AST2500;
+ DRM_INFO("AST 2500 detected\n");
+ } else if (dev->pdev->revision >= 0x30) {
ast->chip = AST2400;
DRM_INFO("AST 2400 detected\n");
} else if (dev->pdev->revision >= 0x20) {
@@ -149,6 +152,8 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
ast->support_wide_screen = true;
if (ast->chip == AST2400 && data == 0x100) /* ast1400 */
ast->support_wide_screen = true;
+ if (ast->chip == AST2500 && data == 0x100) /* ast2510 */
+ ast->support_wide_screen = true;
}
break;
}
@@ -233,7 +238,24 @@ static int ast_get_dram_info(struct drm_device *dev)
else
ast->dram_bus_width = 32;
- if (ast->chip == AST2300 || ast->chip == AST2400) {
+ if (ast->chip == AST2500) {
+ switch (data & 0x03) {
+ case 0:
+ ast->dram_type = AST_DRAM_1Gx16;
+ break;
+ default:
+ case 1:
+ ast->dram_type = AST_DRAM_2Gx16;
+ break;
+ case 2:
+ ast->dram_type = AST_DRAM_4Gx16;
+ break;
+ case 3:
+ ast->dram_type = AST_DRAM_8Gx16;
+ break;
+ }
+ }
+ else if (ast->chip == AST2300 || ast->chip == AST2400) {
switch (data & 0x03) {
case 0:
ast->dram_type = AST_DRAM_512Mx16;
@@ -456,6 +478,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
ast->chip == AST2200 ||
ast->chip == AST2300 ||
ast->chip == AST2400 ||
+ ast->chip == AST2500 ||
ast->chip == AST1180) {
dev->mode_config.max_width = 1920;
dev->mode_config.max_height = 2048;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e26c98f..242ca7f 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -271,7 +271,10 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, struct
drm_display_mode *mod
{
struct ast_private *ast = crtc->dev->dev_private;
u8 jreg05 = 0, jreg07 = 0, jreg09 = 0, jregAC = 0, jregAD = 0, jregAE =
0;
- u16 temp;
+ u16 temp, precache = 0;
+
+if ((ast->chip == AST2500) && (vbios_mode->enh_table->flags &
AST2500PreCatchCRT))
+ precache = 40;
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x11, 0x7f, 0x00);
@@ -297,12 +300,12 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc,
struct drm_display_mode *mod
jregAD |= 0x01; /* HBE D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x03, 0xE0, (temp &
0x1f));
- temp = (mode->crtc_hsync_start >> 3) - 1;
+ temp = ((mode->crtc_hsync_start-precache) >> 3) - 1;
if (temp & 0x100)
jregAC |= 0x40; /* HRS D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x04, 0x00, temp);
- temp = ((mode->crtc_hsync_end >> 3) - 1) & 0x3f;
+ temp = (((mode->crtc_hsync_end-precache) >> 3) - 1) & 0x3f;
if (temp & 0x20)
jregAD |= 0x04; /* HRE D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x05, 0x60, (u8)((temp &
0x1f) | jreg05));
@@ -363,6 +366,11 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, struct
drm_display_mode *
[PATCH v7 1/4] drm/exynos: mic: Add mode_set callback function
Applied.
Thanks.
2017ë
01ì 05ì¼ 19:20ì Hoegeun Kwon ì´(ê°) ì´ ê¸:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
>
> Signed-off-by: Hoegeun Kwon
> Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..fed1a94 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
> }
> nodes[j++] = remote_node;
>
> - ret = of_get_videomode(remote_node,
> - &mic->vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
> break;
> default:
> DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,17 @@ static void mic_post_disable(struct drm_bridge *bridge)
> mutex_unlock(&mic_mutex);
> }
>
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(&mic_mutex);
> + drm_display_mode_to_videomode(mode, &mic->vm);
> + mutex_unlock(&mic_mutex);
> +}
> +
> static void mic_pre_enable(struct drm_bridge *bridge)
> {
> struct exynos_mic *mic = bridge->driver_private;
> @@ -377,6 +381,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
> static const struct drm_bridge_funcs mic_bridge_funcs = {
> .disable = mic_disable,
> .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
> .pre_enable = mic_pre_enable,
> .enable = mic_enable,
> };
>
[PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function
Applied.
Thanks.
2017ë
01ì 05ì¼ 19:20ì Hoegeun Kwon ì´(ê°) ì´ ê¸:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
> 1 file changed, 3 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index fed1a94..cf9361a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
> }
> nodes[j++] = remote_node;
>
> - switch (i) {
> - case ENDPOINT_DECON_NODE:
> - /* decon node */
> - if (of_get_child_by_name(remote_node,
> - "i80-if-timings"))
> - mic->i80_mode = 1;
> -
> - break;
> - case ENDPOINT_DSI_NODE:
> - /* panel node */
> - remote_node = get_remote_node(remote_node, 1);
> - if (!remote_node) {
> - ret = -EPIPE;
> - goto exit;
> - }
> - nodes[j++] = remote_node;
> -
> - break;
> - default:
> - DRM_ERROR("mic: Unknown endpoint from MIC");
> - break;
> - }
> + if (i == ENDPOINT_DECON_NODE &&
> + of_get_child_by_name(remote_node, "i80-if-timings"))
> + mic->i80_mode = 1;
> }
>
> exit:
>
[PATCH] drm: exynos: Add runtime PM support to MIC driver
2017ë
01ì 11ì¼ 10:39ì Chanwoo Choi ì´(ê°) ì´ ê¸:
> Hi Marek,
>
> On 2017ë
01ì 10ì¼ 21:57, Marek Szyprowski wrote:
>> This patch adds pm_runtime_get/put calls to notify device core when MIC
>> device is really in use. This is needed to let power domain with this
>> device to be turned off when display is turned off.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_mic.c | 17 -
>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> index a0def0be6d65..f643c380cb9a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> @@ -19,6 +19,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -323,6 +324,7 @@ static void mic_post_disable(struct drm_bridge *bridge)
>> for (i = NUM_CLKS - 1; i > -1; i--)
>> clk_disable_unprepare(mic->clks[i]);
>>
>> +pm_runtime_put(mic->dev);
>> mic->enabled = 0;
>
> It is minor comment.
>
> How about calling the pm_runtime_put() after 'mic->enabled = 0'?
This means it changes device status to 'disable' even through real hardware
status is still 'enable'. so it would be better to update device status after
making sure to disable real hardware.
Than that, how about adding dev_pm_ops callbacks - runtime_suspend and
runtime_resume - and moving clock contol codes into the callback functions?
Thanks.
> I think that you better to call the runtime_pm funtcion after completing
> the handle of data of mic device driver. Because this patch just notifies
> the status.
>
>>
>> already_disabled:
>> @@ -338,6 +340,8 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>> if (mic->enabled)
>> goto already_enabled;
>>
>> +pm_runtime_get_sync(mic->dev);
>> +
>> for (i = 0; i < NUM_CLKS; i++) {
>> ret = clk_prepare_enable(mic->clks[i]);
>> if (ret < 0) {
>> @@ -473,8 +477,18 @@ static int exynos_mic_probe(struct platform_device
>> *pdev)
>>
>> platform_set_drvdata(pdev, mic);
>>
>> +pm_runtime_enable(dev);
>> +
>> +ret = component_add(dev, &exynos_mic_component_ops);
>> +if (ret)
>> +goto err_pm;
>> +
>> DRM_DEBUG_KMS("MIC has been probed\n");
>> -return component_add(dev, &exynos_mic_component_ops);
>> +
>> +return 0;
>> +
>> +err_pm:
>> +pm_runtime_disable(dev);
>>
>> err:
>> return ret;
>> @@ -483,6 +497,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
>> static int exynos_mic_remove(struct platform_device *pdev)
>> {
>> component_del(&pdev->dev, &exynos_mic_component_ops);
>> +pm_runtime_disable(&pdev->dev);
>> return 0;
>> }
>>
>>
>
> If this patch just notifies the status(enabled or disabled)
> of mic device with pm runtime interface, looks good to me.
>
> Reviewed-by: Chanwoo Choi
>
[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index ddba2f8..6d362f9 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -18,6 +18,18 @@
compatible = "samsung,tm2", "samsung,exynos5433";
};
+&dsi {
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&hsi2c_9 {
status = "okay";
--
1.9.1
[PATCH v8 0/3] Add support for the S6E3HA2 panel on TM2 board
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Thank you for your review.
Changes for V8:
- Applied below two patches: (drm/exynos)
: drm/exynos: mic: Add mode_set callback function
: drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].
Change for V7:
- Fixed the mode_set callback function of mic device driver.
because the mic register is initialized when entering suspend
mode, so should set the reg value whenever pre_enable is
called.
Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
- Fixed from number size to ARRAY_SIZE().
- Fixed error handling in mipi_dsi_dcs_* functions.
- Fixed the clock of display_mode.
- Removed unnecessary casting and error log.
Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
callback, because mode_set should be performed every time.
Changes for V4:
- Removed display-timings in devicetree, the display-timings has
been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
because the exynos_drm_mic driver can not parse a videomode
struct by removing the display-timings from the devicetree.
Changes for V3:
- In the DT binding document, made it clearly that the panel is a
child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
Althogh the panel is a child of dsi, I think OF graph necessary.
because if a remote-endpoint is not specified, the dsi also
panel is not probed.
- The display-timings has been fixed to be provided by the device
driver. however, I think display-timings is necessary in dts.
because if dts does not have display-timings, dsi will not load.
Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
- Added active high or low after the description of the GPIOs.
- Removed the reg and added a description of the virtual
channel number of a DSI peripheral.
Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ (for-next
branch)
[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")
Hoegeun Kwon (2):
dt-bindings: Add support for samsung s6e3ha2 panel binding
drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hyungwon Hwang (1):
arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
.../bindings/display/panel/samsung,s6e3ha2.txt | 26 +
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 +
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 +
5 files changed, 799 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
--
1.9.1
[PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 ++
3 files changed, 761 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
Xperia Z2 tablets
+config DRM_PANEL_SAMSUNG_S6E3HA2
+ tristate "Samsung S6E3HA2 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee
+ * Hyungwon Hwang
+ * Hoegeun Kwon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT 35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x88, 0x89, 0x84, 0x88, 0x83, 0x82, 0x85, 0x84, 0x8c,
+ 0x91, 0x86, 0xac, 0xaa, 0x89, 0xc2, 0xa5, 0xbd, 0x00, 0x00, 0x
[PATCH v8 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..3e7892c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,26 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active low)
+ - enable-gpios: a GPIO spec for the panel enable pin (active high)
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+&dsi {
+ ...
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.9.1
[PATCH] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge
The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.
The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.
msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.
Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.
Cc: Laurent Pinchart
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index ec572f8..9593238 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
+ for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
+ msm_dsi->encoders[i] = encoders[i];
+
msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
if (IS_ERR(msm_dsi->bridge)) {
ret = PTR_ERR(msm_dsi->bridge);
@@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
- encoders[i]->bridge = msm_dsi->bridge;
- msm_dsi->encoders[i] = encoders[i];
- }
-
/*
* check if the dsi encoder output is connected to a panel or an
* external bridge. We create a connector only if we're connected to a
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH v11 00/12] MT2701 DRM support
This is MT2701 DRM support PATCH v10, based on 4.10-rc1. We add DSI interrupt control, transfer function for MIPI DSI panel support. Most codes are the same, except some register changed. For example: - DISP_OVL address offset changed, color format definition changed. - DISP_RDMA fifo size changed. - DISP_COLOR offset changed. - MIPI_TX setting changed. We add a new component DDP_COMPONENT_BLS, and the connections are updated. OVL -> RDMA -> COLOR -> BLS -> DSI RDMA -> DPI And we have shadow register support in MT2701. Changes since v10: - Add binding descriptions for newly added bindings - Remove color data pointer from generic mtk_ddp_comp - Remove "drm/mediatek: add mipi_tx data rate check" from the patch series - Remove "drm/mediatek: add dsi ulp mode control" from the patch series - Update descriptions for "drm/mediatek: add non-continuous clock mode and EOT packet control" - Fix DSI disable flow Changes since v9: - Split DSI patches into smaller parts - Use a real linux errno for return value - Add error handling in mtk_output_dsi_enable() - Remove unused changes and redundant delays - Add helpers and macros for configuration - Combine "drm/mediatek: rename macros, add chip prefix" and "drm/mediatek: add *driver_data for different hardware setting" Changes since v8: - enable 3 DSI interrupts only - move mtk_dsi_wait_for_irq_done() to the patch of irq control - use the name BLS in DRM driver part - move BLS declaration to a separate patch - update mtk_dsi_switch_to_cmd_mode() - update mtk_output_dsi_enable() and mtk_output_dsi_disable() Changes since v7: - Remove redundant codes - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update display module connections" - Move _dsi_irq_wait_queue into platform driver data - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt control" - Add more descriptions in the commit messages Changes since v6: - Change data type of irq_data to u32 - Rewrite mtk_dsi_host_transfer() for simplify - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for different hardware settings". - Remove device tree from this patch series Changes since v5: - Remove DPI device tree and compatible string - Use one wait queue to handle interrupt status - Update the interrupt check flow and DSI_INT_ALL_BITS - Use same function for host read/write command - various fixes Changes since v4: - Add messages when timeout in mtk_disp_mutex_acquire() - Add descriptions for DISP_REG_MUTEX registers - Move connection settings for display modules to a separate patch - Remove 'mt2701-disp-wdma' because it is unused - Move cleaning up and renaming to a separate patch - Use wait_event_interruptible_timeout() to replace polling - Remove irq_num from mtk_dsi structure - Remove redundant and debug codes Changes since v3: - Add DSI support for MIPI DSI panels - Update BLS binding to PWM nodes - Remove ufoe device nodes - Remove redundant parentheses - Remove global variable initialization Changes since v2: - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel - Update mt2701_mtk_ddp_ext components - Changed to prefix naming - Reorder the patch series - Use of_device_get_match_data() to get driver private data - Use iopoll macros to implement mtk_disp_mutex_acquire() - Removed empty device tree nodes Changes since v1: - Removed BLS bindings and codes, which belong to pwm driver - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config() - Split patch into smaller parts - Added const keyword to constant structure - Removed codes for special memory align Thanks, yt.shen YT Shen (10): dt-bindings: display: mediatek: update supported chips drm/mediatek: add helpers for coverting from the generic components drm/mediatek: add *driver_data for different hardware settings drm/mediatek: add shadow register support drm/mediatek: add BLS component drm/mediatek: update display module connections drm/mediatek: cleaning up and refine drm/mediatek: add non-continuous clock mode and EOT packet control drm/mediatek: update DSI sub driver flow for sending commands to panel drm/mediatek: add support for Mediatek SoC MT2701 shaoming chen (2): drm/mediatek: add dsi interrupt control drm/mediatek: add dsi transfer function .../bindings/display/mediatek/mediatek,disp.txt| 2 + .../bindings/display/mediatek/mediatek,dsi.txt | 2 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 64 +++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 39 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 75 ++-- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 138 +-- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 69 +++- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 2 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 54 ++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 9 + drivers/gpu/drm/mediatek/mtk_dsi.c
[PATCH v11 01/12] dt-bindings: display: mediatek: update supported chips
Add decriptions about supported chips, including MT2701 & MT8173 Signed-off-by: YT Shen --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++ Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index db6e77e..acf61f1 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -40,6 +40,7 @@ Required properties (all function blocks): "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex" - display mutex "mediatek,-disp-od"- overdrive + the supported chips are mt2701 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). @@ -54,6 +55,7 @@ Required properties (DMA function blocks): "mediatek,-disp-ovl" "mediatek,-disp-rdma" "mediatek,-disp-wdma" + the supported chips are mt2701 and mt8173. - larb: Should contain a phandle pointing to the local arbiter device as defined in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt - iommus: Should point to the respective IOMMU block with master port as diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index 2b1585a..fadf327 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -7,6 +7,7 @@ channel output. Required properties: - compatible: "mediatek,-dsi" + the supported chips are mt2701 and mt8173. - reg: Physical base address and length of the controller's registers - interrupts: The interrupt signal from the function block. - clocks: device clocks @@ -25,6 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY. Required properties: - compatible: "mediatek,-mipi-tx" + the supported chips are mt2701 and mt8173. - reg: Physical base address and length of the controller's registers - clocks: PLL reference clock - clock-output-names: name of the output clock line to the DSI encoder -- 1.9.1
[PATCH v11 02/12] drm/mediatek: add helpers for coverting from the generic components
define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl'
define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma'
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 15 +--
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +--
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index c703102..ce2759f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -57,6 +57,11 @@ struct mtk_disp_ovl {
struct drm_crtc *crtc;
};
+static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
+{
+ return container_of(comp, struct mtk_disp_ovl, ddp_comp);
+}
+
static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_ovl *priv = dev_id;
@@ -76,20 +81,18 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void
*dev_id)
static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
struct drm_crtc *crtc)
{
- struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
-ddp_comp);
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- priv->crtc = crtc;
+ ovl->crtc = crtc;
writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
}
static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
{
- struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
-ddp_comp);
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- priv->crtc = NULL;
+ ovl->crtc = NULL;
writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0df05f9..21eff6f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -49,6 +49,11 @@ struct mtk_disp_rdma {
struct drm_crtc *crtc;
};
+static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
+{
+ return container_of(comp, struct mtk_disp_rdma, ddp_comp);
+}
+
static irqreturn_t mtk_disp_rdma_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_rdma *priv = dev_id;
@@ -77,20 +82,18 @@ static void rdma_update_bits(struct mtk_ddp_comp *comp,
unsigned int reg,
static void mtk_rdma_enable_vblank(struct mtk_ddp_comp *comp,
struct drm_crtc *crtc)
{
- struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
- ddp_comp);
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
- priv->crtc = crtc;
+ rdma->crtc = crtc;
rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT,
RDMA_FRAME_END_INT);
}
static void mtk_rdma_disable_vblank(struct mtk_ddp_comp *comp)
{
- struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
- ddp_comp);
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
- priv->crtc = NULL;
+ rdma->crtc = NULL;
rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT, 0);
}
--
1.9.1
[PATCH v11 03/12] drm/mediatek: add *driver_data for different hardware settings
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
MIPI_TX pll setting changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 41 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 18 +++-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 71 +++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 25 +++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 24 +-
7 files changed, 181 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index ce2759f..4552178 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,18 +35,27 @@
#define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
-#define DISP_REG_OVL_ADDR(n) (0x0f40 + 0x20 * (n))
+#define DISP_REG_OVL_ADDR_MT8173 0x0f40
+#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
#defineOVL_RDMA_MEM_GMC0x40402020
#define OVL_CON_BYTE_SWAP BIT(24)
-#define OVL_CON_CLRFMT_RGB565 (0 << 12)
-#define OVL_CON_CLRFMT_RGB888 (1 << 12)
+#define OVL_CON_CLRFMT_RGB (1 << 12)
#define OVL_CON_CLRFMT_RGBA(2 << 12)
#define OVL_CON_CLRFMT_ARGB(3 << 12)
+#define OVL_CON_CLRFMT_RGB565(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
+ 0 : OVL_CON_CLRFMT_RGB)
+#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
+ OVL_CON_CLRFMT_RGB : 0)
#defineOVL_CON_AEN BIT(8)
#defineOVL_CON_ALPHA 0xff
+struct mtk_disp_ovl_data {
+ unsigned int addr;
+ bool fmt_rgb565_is_0;
+};
+
/**
* struct mtk_disp_ovl - DISP_OVL driver structure
* @ddp_comp - structure containing type enum and hardware resources
@@ -55,6 +64,7 @@
struct mtk_disp_ovl {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
+ const struct mtk_disp_ovl_data *data;
};
static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
@@ -141,18 +151,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp,
unsigned int idx)
writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
}
-static unsigned int ovl_fmt_convert(unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
{
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
- return OVL_CON_CLRFMT_RGB565;
+ return OVL_CON_CLRFMT_RGB565(ovl);
case DRM_FORMAT_BGR565:
- return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
+ return OVL_CON_CLRFMT_RGB565(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGB888:
- return OVL_CON_CLRFMT_RGB888;
+ return OVL_CON_CLRFMT_RGB888(ovl);
case DRM_FORMAT_BGR888:
- return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
+ return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
return OVL_CON_CLRFMT_ARGB;
@@ -171,6 +181,7 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
struct mtk_plane_state *state)
{
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
struct mtk_plane_pending_state *pending = &state->pending;
unsigned int addr = pending->addr;
unsigned int pitch = pending->pitch & 0x;
@@ -182,7 +193,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
if (!pending->enable)
mtk_ovl_layer_off(comp, idx);
- con = ovl_fmt_convert(fmt);
+ con = ovl_fmt_convert(ovl, fmt);
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
@@ -190,7 +201,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
- writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
+ writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));
if (pending->enable)
mtk_ovl_layer_on(comp, idx);
@@ -26
[PATCH v11 04/12] drm/mediatek: add shadow register support
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 -
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
4 files changed, 74 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd..b9b82e5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -329,6 +329,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
pm_runtime_put(drm->dev);
}
+static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
+{
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
+ struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ unsigned int i;
+
+ /*
+* TODO: instead of updating the registers here, we should prepare
+* working registers in atomic_commit and let the hardware command
+* queue update module registers on vblank.
+*/
+ if (state->pending_config) {
+ mtk_ddp_comp_config(ovl, state->pending_width,
+ state->pending_height,
+ state->pending_vrefresh, 0);
+
+ state->pending_config = false;
+ }
+
+ if (mtk_crtc->pending_planes) {
+ for (i = 0; i < OVL_LAYER_NR; i++) {
+ struct drm_plane *plane = &mtk_crtc->planes[i];
+ struct mtk_plane_state *plane_state;
+
+ plane_state = to_mtk_plane_state(plane->state);
+
+ if (plane_state->pending.config) {
+ mtk_ddp_comp_layer_config(ovl, i, plane_state);
+ plane_state->pending.config = false;
+ }
+ }
+ mtk_crtc->pending_planes = false;
+ }
+}
+
static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
@@ -405,6 +441,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0;
int i;
@@ -426,6 +463,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
if (crtc->state->color_mgmt_changed)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
+
+ if (priv->data->shadow_register) {
+ mtk_disp_mutex_acquire(mtk_crtc->mutex);
+ mtk_crtc_ddp_config(crtc);
+ mtk_disp_mutex_release(mtk_crtc->mutex);
+ }
}
static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -471,36 +514,10 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
- unsigned int i;
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
- /*
-* TODO: instead of updating the registers here, we should prepare
-* working registers in atomic_commit and let the hardware command
-* queue update module registers on vblank.
-*/
- if (state->pending_config) {
- mtk_ddp_comp_config(ovl, state->pending_width,
- state->pending_height,
- state->pending_vrefresh, 0);
-
- state->pending_config = false;
- }
-
- if (mtk_crtc->pending_planes) {
- for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i];
- struct mtk_plane_state *plane_state;
-
- plane_state = to_mtk_plane_state(plane->state);
-
- if (plane_state->pending.config) {
- mtk_ddp_comp_layer_config(ovl, i, plane_state);
- plane_state->pending.config = false;
- }
- }
- mtk_crtc->pending_planes = false;
- }
+ if (!priv->data->shadow_register)
+ mtk_crtc_ddp_config(crtc);
mtk_drm_finish_page_flip(mtk_crtc);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8030769..b77d456 100644
--- a/drivers/gpu/drm/me
[PATCH v5 0/2] drm/bridge: adv7511: Enable regulators
The patch below added regulator supplies to the ADV533 HDMI bridge on the DB410c, but the corresponding DT binding doc wasn't updated to list them: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=28546b09551190c727c94d1c5c96ca609065beb2 The first patch adds the regulator supply props to the binding docs for both ADV7511 and ADV7533. The second patch updates the drm bridge driver to enable these regulators. Changes in v5: - Switch back to having individual supplies for AVDD, DVDD, PVDD pins. Changes in v4: - Moved the regulator supply bindings from optional to mandatory. - Used unsigned int for num_supplies and iterator used for parsing the regulator supply properties. Changes in v3: - Revert back to having a common supply for AVDD, DVDD, PVDD pins. - Dropped the DB410c DT patches. Changes in v2: - Provide the regulator supply for ADV7511 too in the binding docs. - Update the driver to manage regulators for both ADV7511 and ADV7533. - Have separate supply entries for AVDD, DVDD, PVDD, A2VDD pins. - Use regulator_bulk_* API to configure regulators. Archit Taneja (2): dt-bindings: drm/bridge: adv7511: Add regulator bindings drm/bridge: adv7511: Initialize regulators .../bindings/display/bridge/adi,adv7511.txt| 12 +++ drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 86 +++--- 3 files changed, 93 insertions(+), 9 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
Add the regulator supply properties needed by ADV7511 and ADV7533.
Acked-by: Laurent Pinchart
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
---
v5:
- Bring back supplies for individual pins
- In v2, we had a v3p3-supply for DVDD_3V on ADV7511 and V3P3 pin
on ADV7533. We don't really need to force a common name here
(the adv7511 driver manages 2 different regulator name tables
anyway).
The supply on ADV7511 is called dvdd-3v-supply to match the
pin name.
.../devicetree/bindings/display/bridge/adi,adv7511.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 6532a59..00ea670 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -38,10 +38,22 @@ The following input format properties are required except
in "rgb 1x" and
- adi,input-justification: The input bit justification ("left", "evenly",
"right").
+- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
+- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
+- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
+- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
+ on the chip.
+- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
+ needed only for ADV7511.
+
The following properties are required for ADV7533:
- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
be one of 1, 2, 3 or 4.
+- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
+- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
+- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
+ either 1.2V or 1.8V.
Optional properties:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH v5 2/2] drm/bridge: adv7511: Initialize regulators
Maintain a table of regulator names expected by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.
Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.
Reviewed-by: Laurent Pinchart
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 86 +---
2 files changed, 81 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 0396791..fe18a5d 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -331,6 +332,9 @@ struct adv7511 {
struct gpio_desc *gpio_pd;
+ struct regulator_bulk_data *supplies;
+ unsigned int num_supplies;
+
/* ADV7533 DSI RX related params */
struct device_node *host_node;
struct mipi_dsi_device *dsi;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 24573e0..2f1aae7 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -859,6 +859,58 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
* Probe & remove
*/
+static const char * const adv7511_supply_names[] = {
+ "avdd",
+ "dvdd",
+ "pvdd",
+ "bgvdd",
+ "dvdd-3v",
+};
+
+static const char * const adv7533_supply_names[] = {
+ "avdd",
+ "dvdd",
+ "pvdd",
+ "a2vdd",
+ "v3p3",
+ "v1p2",
+};
+
+static int adv7511_init_regulators(struct adv7511 *adv)
+{
+ struct device *dev = &adv->i2c_main->dev;
+ const char * const *supply_names;
+ unsigned int i;
+ int ret;
+
+ if (adv->type == ADV7511) {
+ supply_names = adv7511_supply_names;
+ adv->num_supplies = ARRAY_SIZE(adv7511_supply_names);
+ } else {
+ supply_names = adv7533_supply_names;
+ adv->num_supplies = ARRAY_SIZE(adv7533_supply_names);
+ }
+
+ adv->supplies = devm_kcalloc(dev, adv->num_supplies,
+sizeof(*adv->supplies), GFP_KERNEL);
+ if (!adv->supplies)
+ return -ENOMEM;
+
+ for (i = 0; i < adv->num_supplies; i++)
+ adv->supplies[i].supply = supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, adv->num_supplies, adv->supplies);
+ if (ret)
+ return ret;
+
+ return regulator_bulk_enable(adv->num_supplies, adv->supplies);
+}
+
+static void adv7511_uninit_regulators(struct adv7511 *adv)
+{
+ regulator_bulk_disable(adv->num_supplies, adv->supplies);
+}
+
static int adv7511_parse_dt(struct device_node *np,
struct adv7511_link_config *config)
{
@@ -959,6 +1011,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
if (!adv7511)
return -ENOMEM;
+ adv7511->i2c_main = i2c;
adv7511->powered = false;
adv7511->status = connector_status_disconnected;
@@ -976,13 +1029,21 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
if (ret)
return ret;
+ ret = adv7511_init_regulators(adv7511);
+ if (ret) {
+ dev_err(dev, "failed to init regulators\n");
+ return ret;
+ }
+
/*
* The power down GPIO is optional. If present, toggle it from active to
* inactive to wake up the encoder.
*/
adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
- if (IS_ERR(adv7511->gpio_pd))
- return PTR_ERR(adv7511->gpio_pd);
+ if (IS_ERR(adv7511->gpio_pd)) {
+ ret = PTR_ERR(adv7511->gpio_pd);
+ goto uninit_regulators;
+ }
if (adv7511->gpio_pd) {
mdelay(5);
@@ -990,12 +1051,14 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
}
adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
- if (IS_ERR(adv7511->regmap))
- return PTR_ERR(adv7511->regmap);
+ if (IS_ERR(adv7511->regmap)) {
+ ret = PTR_ERR(adv7511->regmap);
+ goto uninit_regulators;
+ }
ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
if (ret)
- return ret;
+ goto uninit_regulators;
dev_dbg(dev, "Rev. %d\n", val);
if (adv7511->type == ADV7511)
@@ -1005,7 +1068,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
else
ret = adv7533_patch_registers(adv7511);
if (ret)
- return ret;
+ goto uninit_regulato
[PATCH v11 05/12] drm/mediatek: add BLS component
Add BLS component for PWM + GAMMA function
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3ff788c..f6e853a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -255,6 +255,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_PWM] = "pwm",
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
+ [MTK_DISP_BLS] = "bls",
};
struct mtk_ddp_comp_match {
@@ -265,6 +266,7 @@ struct mtk_ddp_comp_match {
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] =
{
[DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
@@ -336,7 +338,8 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
comp->id = comp_id;
comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;
- if (comp_id == DDP_COMPONENT_DPI0 ||
+ if (comp_id == DDP_COMPONENT_BLS ||
+ comp_id == DDP_COMPONENT_DPI0 ||
comp_id == DDP_COMPONENT_DSI0 ||
comp_id == DDP_COMPONENT_PWM0) {
comp->regs = NULL;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 22a33ee..0828cf8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -36,11 +36,13 @@ enum mtk_ddp_comp_type {
MTK_DISP_PWM,
MTK_DISP_MUTEX,
MTK_DISP_OD,
+ MTK_DISP_BLS,
MTK_DDP_COMP_TYPE_MAX,
};
enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL,
+ DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_DPI0,
--
1.9.1
[PATCH v11 06/12] drm/mediatek: update display module connections
update connections for OVL, RDMA, BLS, DSI
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..a9b209c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -32,6 +32,10 @@
#define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
+#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
+#define DISP_REG_CONFIG_OUT_SEL0x04c
+#define DISP_REG_CONFIG_DSI_SEL0x050
+
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
@@ -71,6 +75,10 @@
#define DPI0_SEL_IN_RDMA1 0x1
#define COLOR1_SEL_IN_OVL1 0x1
+#define OVL_MOUT_EN_RDMA 0x1
+#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
+#define DSI_SEL_IN_BLS 0x0
+
struct mtk_disp_mutex {
int id;
bool claimed;
@@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
*addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
value = OVL0_MOUT_EN_COLOR0;
+ } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
+ *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+ value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
@@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
value = COLOR1_SEL_IN_OVL1;
+ } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+ *addr = DISP_REG_CONFIG_DSI_SEL;
+ value = DSI_SEL_IN_BLS;
} else {
value = 0;
}
@@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id
cur,
return value;
}
+static void mtk_ddp_sout_sel(void __iomem *config_regs,
+enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next)
+{
+ if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+ writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+ config_regs + DISP_REG_CONFIG_OUT_SEL);
+}
+
void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
@@ -167,6 +190,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
writel_relaxed(reg, config_regs + addr);
}
+ mtk_ddp_sout_sel(config_regs, cur, next);
+
value = mtk_ddp_sel_in(cur, next, &addr);
if (value) {
reg = readl_relaxed(config_regs + addr) | value;
--
1.9.1
[PATCH v11 07/12] drm/mediatek: cleaning up and refine
cleaning up unused define and refine function name and variable
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 73 --
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 8 ++--
2 files changed, 39 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2c42f90..6f4b3bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -27,9 +27,6 @@
#include "mtk_drm_ddp_comp.h"
-#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
-#define DSI_HOST_FIFO_DEPTH64
-
#define DSI_START 0x00
#define DSI_CON_CTRL 0x10
@@ -46,7 +43,7 @@
#define MIX_MODE BIT(17)
#define DSI_TXRX_CTRL 0x18
-#define VC_NUM (2 << 0)
+#define VC_NUM BIT(1)
#define LANE_NUM (0xf << 2)
#define DIS_EOTBIT(6)
#define NULL_ENBIT(7)
@@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset,
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
}
-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
u32 ui, cycle_time;
@@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
}
-static void mtk_dsi_reset(struct mtk_dsi *dsi)
+static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
@@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}
mtk_dsi_enable(dsi);
- mtk_dsi_reset(dsi);
- dsi_phy_timconfig(dsi);
+ mtk_dsi_reset_engine(dsi);
+ mtk_dsi_phy_timconfig(dsi);
return 0;
@@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
return ret;
}
-static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
}
-static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
}
-static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
}
-static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
}
-static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
+static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
{
u32 tmp_reg1;
@@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
}
-static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
+static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
{
- if (enter && !dsi_clk_hs_state(dsi))
+ if (enter && !mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
- else if (!enter && dsi_clk_hs_state(dsi))
+ else if (!enter && mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
}
-static void dsi_set_mode(struct mtk_dsi *dsi)
+static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
{
u32 vid_mode = CMD_MODE;
@@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
}
-static void dsi_ps_control_vact(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
{
struct videomode *vm = &dsi->vm;
u32 dsi_buf_bpp, ps_wc;
@@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
}
-static void dsi_rxtx_control(struct mtk_dsi *dsi)
+static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
{
u32 tmp_reg;
@@ -397,9 +394,9 @@ static void dsi_rxtx_control(struct mtk_dsi *dsi)
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
}
-static void dsi_ps_control(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control(struct mtk_dsi *dsi)
{
- unsigned int dsi_tmp_buf_bpp;
+ u32 dsi_tmp_buf_bp
[PATCH v11 08/12] drm/mediatek: add dsi interrupt control
From: shaoming chen
add dsi interrupt control
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 6f4b3bb..474861a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,16 @@
#define DSI_START 0x00
+#define DSI_INTEN 0x08
+
+#define DSI_INTSTA 0x0c
+#define LPRX_RD_RDY_INT_FLAG BIT(0)
+#define CMD_DONE_INT_FLAG BIT(1)
+#define TE_RDY_INT_FLAGBIT(2)
+#define VM_DONE_INT_FLAG BIT(3)
+#define EXT_TE_RDY_INT_FLAGBIT(4)
+#define DSI_BUSY BIT(31)
+
#define DSI_CON_CTRL 0x10
#define DSI_RESET BIT(0)
#define DSI_EN BIT(1)
@@ -71,6 +82,9 @@
#define DSI_HSTX_CKL_WC0x64
+#define DSI_RACK 0x84
+#define RACK BIT(0)
+
#define DSI_PHY_LCCON 0x104
#define LC_HS_TX_ENBIT(0)
#define LC_ULPM_EN BIT(1)
@@ -137,6 +151,8 @@ struct mtk_dsi {
struct videomode vm;
int refcount;
bool enabled;
+ u32 irq_data;
+ wait_queue_head_t irq_wait_queue;
};
static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
}
+static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
+{
+ u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+ writel(inten, dsi->regs + DSI_INTEN);
+}
+
+static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
+{
+ dsi->irq_data |= irq_bit;
+}
+
+static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32
irq_bit)
+{
+ dsi->irq_data &= ~irq_bit;
+}
+
+static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32
irq_flag,
+unsigned int timeout)
+{
+ s32 ret = 0;
+ unsigned long jiffies = msecs_to_jiffies(timeout);
+
+ ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
+ dsi->irq_data & irq_flag,
+ jiffies);
+ if (ret == 0) {
+ DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
+
+ mtk_dsi_enable(dsi);
+ mtk_dsi_reset_engine(dsi);
+ }
+
+ return ret;
+}
+
+static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
+{
+ struct mtk_dsi *dsi = dev_id;
+ u32 status, tmp;
+ u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+ status = readl(dsi->regs + DSI_INTSTA) & flag;
+
+ if (status) {
+ do {
+ mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
+ tmp = readl(dsi->regs + DSI_INTSTA);
+ } while (tmp & DSI_BUSY);
+
+ mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
+ mtk_dsi_irq_data_set(dsi, status);
+ wake_up_interruptible(&dsi->irq_wait_queue);
+ }
+
+ return IRQ_HANDLED;
+}
+
static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
{
if (WARN_ON(dsi->refcount == 0))
@@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
mtk_dsi_ps_control_vact(dsi);
mtk_dsi_config_vdo_timing(dsi);
+ mtk_dsi_set_interrupt_enable(dsi);
mtk_dsi_set_mode(dsi);
mtk_dsi_clk_hs_mode(dsi, 1);
@@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *remote_node, *endpoint;
struct resource *regs;
+ int irq_num;
int comp_id;
int ret;
@@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}
+ irq_num = platform_get_irq(pdev, 0);
+ if (irq_num < 0) {
+ dev_err(&pdev->dev, "failed to request dsi irq resource\n");
+ return -EPROBE_DEFER;
+ }
+
+ irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
+ ret = devm_request_irq(&pdev->dev, irq_num, mtk_dsi_irq,
+ IRQF_TRIGGER_LOW, dev_name(&pdev->dev), dsi);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request mediatek dsi irq\n");
+ return -EPROBE_DEFER;
+ }
+
+ init_waitqueue_head(&dsi->irq_wait_queue);
+
platform_set_drvdata(pdev, dsi);
return component_add(&pdev->dev, &mtk_dsi_component_ops);
--
1.9.1
[PATCH v11 09/12] drm/mediatek: add dsi transfer function
From: shaoming chen
add dsi read/write commands for transfer function
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 168 -
1 file changed, 166 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 474861a..b3c7fd8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include "mtk_drm_ddp_comp.h"
@@ -80,8 +81,16 @@
#define DSI_HBP_WC 0x54
#define DSI_HFP_WC 0x58
+#define DSI_CMDQ_SIZE 0x60
+#define CMDQ_SIZE 0x3f
+
#define DSI_HSTX_CKL_WC0x64
+#define DSI_RX_DATA0 0x74
+#define DSI_RX_DATA1 0x78
+#define DSI_RX_DATA2 0x7c
+#define DSI_RX_DATA3 0x80
+
#define DSI_RACK 0x84
#define RACK BIT(0)
@@ -117,6 +126,15 @@
#define CLK_HS_POST(0xff << 8)
#define CLK_HS_EXIT(0xff << 16)
+#define DSI_CMDQ0 0x180
+#define CONFIG (0xff << 0)
+#define SHORT_PACKET 0
+#define LONG_PACKET2
+#define BTABIT(2)
+#define DATA_ID(0xff << 8)
+#define DATA_0 (0xff << 16)
+#define DATA_1 (0xff << 24)
+
#define T_LPX 5
#define T_HS_PREP 6
#define T_HS_TRAIL 8
@@ -125,6 +143,12 @@
#define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
+#define MTK_DSI_HOST_IS_READ(type) \
+ ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
+ (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
+ (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
+ (type == MIPI_DSI_DCS_READ))
+
struct phy;
struct mtk_dsi {
@@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32
irq_bit)
dsi->irq_data |= irq_bit;
}
-static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32
irq_bit)
+static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
{
dsi->irq_data &= ~irq_bit;
}
-static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32
irq_flag,
+static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
unsigned int timeout)
{
s32 ret = 0;
@@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
return 0;
}
+static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
+{
+ u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
+
+ while (timeout_ms--) {
+ if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
+ break;
+
+ usleep_range(2, 4);
+ }
+
+ if (timeout_ms == 0) {
+ DRM_WARN("polling dsi wait not busy timeout!\n");
+
+ mtk_dsi_enable(dsi);
+ mtk_dsi_reset_engine(dsi);
+ }
+}
+
+static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
+{
+ switch (type) {
+ case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+ case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+ return 1;
+ case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+ case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+ return 2;
+ case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
+ case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
+ return read_data[1] + read_data[2] * 16;
+ case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+ DRM_INFO("type is 0x02, try again\n");
+ break;
+ default:
+ DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
+ break;
+ }
+
+ return 0;
+}
+
+static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
+{
+ const char *tx_buf = msg->tx_buf;
+ u8 config, cmdq_size, cmdq_off, type = msg->type;
+ u32 reg_val, cmdq_mask, i;
+
+ if (MTK_DSI_HOST_IS_READ(type))
+ config = BTA;
+ else
+ config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
+
+ if (msg->tx_len > 2) {
+ cmdq_size = 1 + (msg->tx_len + 3) / 4;
+ cmdq_off = 4;
+ cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
+ reg_val = (msg->tx_len << 16) | (type << 8) | config;
+ } else {
+ cmdq_size = 1;
+ cmdq_off = 2;
+ cmdq_mask = CONFIG | DATA_ID;
+ reg_val = (type << 8) | config;
+ }
+
+ for (i = 0; i < msg->tx_len; i++)
+ writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+
+ mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+ mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
+}
[PATCH v11 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control
This patch will update dsi clock control method. 1. dsi non-continue clock mode will enhance antistatic effect for panel 2. EOT packet control will judge whether dsi send end of packet or not by customize Signed-off-by: shaoming chen Signed-off-by: YT Shen --- drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index b3c7fd8..85f22d2 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) break; } + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; + writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); } -- 1.9.1
[PATCH v11 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
This patch update enable/disable flow of DSI module.
Original flow works on there is a bridge chip: DSI -> bridge -> panel.
In this case: DSI -> panel, the DSI sub driver flow should be updated.
We need to initialize DSI first so that we can send commands to panel.
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 89 +++---
1 file changed, 74 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 85f22d2..21392c4 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -126,6 +126,10 @@
#define CLK_HS_POST(0xff << 8)
#define CLK_HS_EXIT(0xff << 16)
+#define DSI_VM_CMD_CON 0x130
+#define VM_CMD_EN BIT(0)
+#define TS_VFP_EN BIT(5)
+
#define DSI_CMDQ0 0x180
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
@@ -365,16 +369,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
u32 vid_mode = CMD_MODE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
- vid_mode = SYNC_PULSE_MODE;
-
- if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
- !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
vid_mode = BURST_MODE;
+ else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+ vid_mode = SYNC_PULSE_MODE;
+ else
+ vid_mode = SYNC_EVENT_MODE;
}
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
}
+static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
+{
+ mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
+ mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
+}
+
static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
{
struct videomode *vm = &dsi->vm;
@@ -512,6 +523,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
}
+static void mtk_dsi_stop(struct mtk_dsi *dsi)
+{
+ writel(0, dsi->regs + DSI_START);
+}
+
+static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
+{
+ writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
+}
+
static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
{
u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
@@ -570,6 +591,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
+{
+ mtk_dsi_irq_data_clear(dsi, irq_flag);
+ mtk_dsi_set_cmd_mode(dsi);
+
+ if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
+ DRM_ERROR("failed to switch cmd mode\n");
+ return -ETIME;
+ } else {
+ return 0;
+ }
+}
+
static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
{
if (WARN_ON(dsi->refcount == 0))
@@ -578,6 +612,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;
+ mtk_dsi_stop(dsi);
+ if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
+ if (dsi->panel) {
+ if (drm_panel_unprepare(dsi->panel)) {
+ DRM_ERROR("failed to unprepare the panel\n");
+ return;
+ }
+ }
+ }
+
+ mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -596,13 +641,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
if (dsi->enabled)
return;
- if (dsi->panel) {
- if (drm_panel_prepare(dsi->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return;
- }
- }
-
ret = mtk_dsi_poweron(dsi);
if (ret < 0) {
DRM_ERROR("failed to power on dsi\n");
@@ -610,22 +648,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
}
mtk_dsi_rxtx_control(dsi);
+ mtk_dsi_ps_control_vact(dsi);
+ mtk_dsi_set_vm_cmd(dsi);
+ mtk_dsi_config_vdo_timing(dsi);
+ mtk_dsi_set_interrupt_enable(dsi);
mtk_dsi_clk_ulp_mode_leave(dsi);
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
- mtk_dsi_set_mode(dsi);
- mtk_dsi_ps_control_vact(dsi);
- mtk_dsi_config_vdo_timing(dsi);
- mtk_dsi_set_interrupt_enable(dsi);
+ if (dsi->panel) {
+ if (drm_panel_prepare(dsi->panel)) {
+ DRM_ERROR("failed to prepare the panel\n");
+ goto err_dsi_power_off;
+ }
+ }
mtk_dsi_set_mode(dsi);
[PATCH v11 12/12] drm/mediatek: add support for Mediatek SoC MT2701
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 7 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 6 ++
7 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 4552178..a14d7d6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,6 +35,7 @@
#define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
+#define DISP_REG_OVL_ADDR_MT2701 0x0040
#define DISP_REG_OVL_ADDR_MT8173 0x0f40
#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
@@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT2701,
+ .fmt_rgb565_is_0 = false,
+};
+
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.fmt_rgb565_is_0 = true,
};
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-ovl",
+ .data = &mt2701_ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = &mt8173_ovl_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e5e5318..b68a513 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
+ .fifo_size = SZ_4K,
+};
+
static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
.fifo_size = SZ_8K,
};
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-rdma",
+ .data = &mt2701_rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = &mt8173_rdma_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a9b209c..8130f3d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -60,6 +60,13 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
+#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
+#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
+#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
+#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
+#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
+#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
#define MUTEX_SOF_DSI1 2
@@ -92,6 +99,15 @@ struct mtk_ddp {
const unsigned int *mutex_mod;
};
+static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
+ [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
+ [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
+ [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
}
static const struct of_device_id ddp_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index f6e853a..8b52416 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -39,6 +39,7 @@
#define DISP_REG_UFO_START 0x
#define DISP_COLOR_CFG_MAIN0x0400
+#define DISP_COLOR_START_MT27010x0f00
#define DI
[PATCH] drm: Fix error handling in drm_mm eviction kselftest
On ti, 2017-01-10 at 14:40 +, Chris Wilson wrote:
> Â Â Â Â Â Â Â Â drivers/gpu/drm/selftests/test-drm_mm.c:1277
> evict_everything()
> Â Â Â Â Â Â Â Â warn: calling list_del() inside list_for_each
>
> The list_del() inside the error handling in the eviction loop is
> overkill. We have to undo the eviction scan to return the drm_mm back to
> a recoverable state, so have to iterate over the full list, but we only
> want to report the error once and once we have an error we can return
> early.
>
> Reported-by: Dan Carpenter
> Fixes: 560b32842912 ("drm: kselftest for drm_mm and eviction")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
Ah, as mentioned previously, we soon need tests for the selftests :)
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
[Intel-gfx] [PATCH 01/10] drm : adds Y-coordinate and Colorimetry Format
On Tue, Jan 10, 2017 at 11:43:51PM +, Rodrigo Vivi wrote: > patch merged to dinq. thanks for patch and review. I already pinged Rodrigo about this on irc, but drm core patches need an ack from Dave for merging through a driver git tree. I've asked Rodrigo to update the dim scripting to catch this so it won't happen in the future again. Thanks, Daniel > > On Mon, Jan 2, 2017 at 3:34 AM vathsala nagaraju < > vathsala.nagaraju at intel.com> wrote: > > > PSR2 vsc revision number hb2( as per table 6-11)is updated to > > 4 or 5 based on Y cordinate and Colorimetry Format as below > > 04h = 3D stereo + PSR/PSR2 + Y-coordinate. > > 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry > > Format indication. A DP Source device is allowed to indicate the pixel > > encoding/colorimetry format to the DP Sink device with VSC SDP only when > > the DP Sink device supports it ( > > i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the > > DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; > > is set to 1). > > > > v2: (Jani) > > - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. > > - Add DP_PSR2_SU_GRANULARITY_REQUIRED. > > - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. > > - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. > > > > v3: (Jani) > > - Add support for bits 7:4 and 1 as per DP v1.4 for > > DPRX_FEATURE_ENUMERATION_LIST. > > > > Cc: Rodrigo Vivi > > Cc: Jim Bride > > Signed-off-by: Vathsala Nagaraju > > Signed-off-by: Patil Deepti > > Reviewed-by: Jani Nikula > > --- > > include/drm/drm_dp_helper.h | 13 - > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > index 55bbeb0..0468135 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -194,7 +194,8 @@ > > # define DP_PSR_SETUP_TIME_0(6 << 1) > > # define DP_PSR_SETUP_TIME_MASK (7 << 1) > > # define DP_PSR_SETUP_TIME_SHIFT1 > > - > > +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ > > +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ > > /* > > * 0x80-0x8f describe downstream port capabilities, but there are two > > layouts > > * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was > > not, > > @@ -568,6 +569,16 @@ > > #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ > > # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) > > > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 /* DP 1.3 */ > > +# define DP_GTC_CAP(1 << 0) /* DP > > 1.3 */ > > +# define DP_SST_SPLIT_SDP_CAP (1 << 1) /* DP > > 1.4 */ > > +# define DP_AV_SYNC_CAP(1 << 2) > > /* DP 1.3 */ > > +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED (1 << 3) /* DP > > 1.3 */ > > +# define DP_VSC_EXT_VESA_SDP_SUPPORTED (1 << 4) /* DP > > 1.4 */ > > +# define DP_VSC_EXT_VESA_SDP_CHAINING_SUPPORTED(1 << 5) > > /* DP 1.4 */ > > +# define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP > > 1.4 */ > > +# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP > > 1.4 */ > > + > > /* DP 1.2 Sideband message defines */ > > /* peer device type - DP 1.2a Table 2-92 */ > > #define DP_PEER_DEVICE_NONE0x0 > > -- > > 1.9.1 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] 4.10-rc2 oops in DRM connector code
On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: > On 01/10/2017 02:31 AM, Daniel Vetter wrote: > > commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e > > Author: Daniel Vetter > > Date: Sun Dec 18 14:35:45 2016 +0100 > > > > drm: prevent double-(un)registration for connectors > > > > Lack of that would perfectly explain that oops ... Otherwise still no idea > > what's going wrong. > > No... That's not in mainline as far as I can see. Should I test with > it applied? Hm, I guess failed to cc: stable that one properly, iirc we decided the race fix is too academic and can't be hit in reality ;-) Testing would be great. Probably conflicts because we extracted drm_connector.c only recently, but running s/drm_connector\.c/drm_crtc.c/ over the diff and then applying with some fudge should take care of that. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v8 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
On 11.01.2017 07:33, Hoegeun Kwon wrote:
> The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> Tested-by: Chanwoo Choi
> Reviewed-by: Andrzej Hajda
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 000..3e7892c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,26 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2"
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: I/O voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin (active low)
> + - enable-gpios: a GPIO spec for the panel enable pin (active high)
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +gpio pin (active high)
One more thing I didn't catch earlier, te-gpios property should be
optional - in case of hw-trigger we do not need it.
Regards
Andrzej
> +
> +Example:
> +&dsi {
> + ...
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> + };
> +};
[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 11.01.2017 07:33, Hoegeun Kwon wrote:
> From: Hyungwon Hwang
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Hoegeun Kwon
> Tested-by: Chanwoo Choi
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index ddba2f8..6d362f9 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,6 +18,18 @@
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
>
> +&dsi {
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
The same here (as in 1st comment) , te-gpios should be dropper - decon
uses hw-trigger.
Regards
Andrzej
> + };
> +};
> +
> &hsi2c_9 {
> status = "okay";
>
[PATCH v2] drm: get fbdev size from cmdline mode if it exists
On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote: > Hi Vincent, > > On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote: > > On 01/10/2017 12:39 PM, Daniel Vetter wrote: > > > On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote: > > >> In case no connector is found while creating the fbdev, gives the > > >> possibility to specify the default fbdev size by firstly checking if the > > >> command line is defining a preferred mode. Else go into fallback and set > > >> 1024x768 fbdev size as it was already done. > > >> > > >> Cc: Tomi Valkeinen > > >> Signed-off-by: Vincent Abriou > > > > > > btw on all this there's also the possible solution to delay setup of the > > > fbdev until the first connector switches to connected, and then only > > > allocting the fb and doing the setup. Tegra has that, and Thierry did some > > > patches to move that logic into the fb helpers. But there's some locking > > > issues that need to be fixed first, hence why those patches haven't landed > > > yet. > > > > > > But if you never probe the right mode, this here sounds like a good idea > > > too. > > > > The early creation of fbdev is useful for userland system. If fbdev > > creation is delayed until first connector is connected, userland systems > > startup could fails (like Android that check fbdev availability at startup). > > > > Today if no connector is connected, a default 1024x768 fbdev is created > > but it does not necessarily match the targeted CRTC size. When the > > connector is connected, fbdev is not reconfigured with the targeted CRTC > > size and it is anyway too late for the userland to take into account new > > fbdev size. Reading the cmdline is an easy way to solve this. > > Isn't it another case of working around userspace issue in the kernel ? > Shouldn't the offending userspace code be fixed ? And while at it, moved from > fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years ago to > use > DRM/KMS in the Android init process. I'm sure it doesn't apply cleanly > anymore, but I can share it if you're interested. So android still doesn't boot without fbdev? I thought that's been fixed ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm/probe-helpers: Drop locking from poll_enable
On Tue, Jan 10, 2017 at 05:10:50PM +, Chris Wilson wrote:
> On Tue, Jan 10, 2017 at 05:34:08PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 03:17:44PM +, Chris Wilson wrote:
> > > On Tue, Jan 10, 2017 at 03:29:10PM +0100, Daniel Vetter wrote:
> > > > -void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
> > > > +void drm_kms_helper_poll_enable(struct drm_device *dev)
> > > > {
> > > > bool poll = false;
> > > > struct drm_connector *connector;
> > > > struct drm_connector_list_iter conn_iter;
> > > > unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
> > > >
> > > > - WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
> > > > -
> > > > if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
> > > > return;
> > >
> > > Hmm, output_poll_execute() itself is not checking this correctly,
> > >
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 84b75709af90..cb3febc6e719 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -405,7 +405,7 @@ static void output_poll_execute(struct work_struct
> > > *work)
> > > changed = dev->mode_config.delayed_event;
> > > dev->mode_config.delayed_event = false;
> > >
> > > - if (!drm_kms_helper_poll)
> > > + if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
> > > goto out;
> >
> > The cancel_work_sync in poll_disable should make this impossible, but it
> > might be a good thing to check this with a WARN_ON? Care to type that
> > patch as a follow up please?
>
> Imagine a drm_kms_helper_poll_disable() run concurrently with
> drm_kms_helper_poll_enable(). The enable() gets past the is-enabled? check
> and begins iterating the list, meanwhile the disable() cancels the work
> and turns off the helper. The enable() is unaware of this and so
> reschedules the work, and as output_poll_execute() doesn't check for
> dev->mode_config.poll_enabled it stays active.
I thought I also added that this case is a driver bug to the kernel-docs,
but I failed. Driver needs to ensure this is all ordered reasonably well
(which it is, if you only call it from suspend/resume callbacks). I'll
respin with that fixed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm: Fix error handling in drm_mm eviction kselftest
On Wed, Jan 11, 2017 at 08:54:35AM +0200, Joonas Lahtinen wrote:
> On ti, 2017-01-10 at 14:40 +, Chris Wilson wrote:
> > Â Â Â Â Â Â Â Â drivers/gpu/drm/selftests/test-drm_mm.c:1277
> > evict_everything()
> > Â Â Â Â Â Â Â Â warn: calling list_del() inside list_for_each
> >
> > The list_del() inside the error handling in the eviction loop is
> > overkill. We have to undo the eviction scan to return the drm_mm back to
> > a recoverable state, so have to iterate over the full list, but we only
> > want to report the error once and once we have an error we can return
> > early.
> >
> > Reported-by: Dan Carpenter
> > Fixes: 560b32842912 ("drm: kselftest for drm_mm and eviction")
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: Daniel Vetter
>
> Ah, as mentioned previously, we soon need tests for the selftests :)
>
> Reviewed-by: Joonas Lahtinen
Applied, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)
On 09/01/17 06:59 PM, Daniel Vetter wrote: > On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote: >> Allows usage of the new page_flip_target hook for drivers implementing >> the atomic path. >> Provides default atomic helper for the new hook. >> >> v2: >> Update code sharing logic between exsiting and the new flip hooks. >> Improve kerneldoc. >> >> Signed-off-by: Andrey Grodzovsky > > Looks all reasonable, I think an ack from Alex that the amd side is in > shape too, and I'll pull this into drm-misc. Andrey, is there an updated patch 2 adapted to current patch 1? Other than that and some questionable indentation of parameters in function signatures, looks good to me FWIW. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
2017ë
01ì 11ì¼ 16:46ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Hoegeun Kwon
>> Tested-by: Chanwoo Choi
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>> compatible = "samsung,tm2", "samsung,exynos5433";
>> };
>>
>> +&dsi {
>> +panel at 0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <&ldo27_reg>;
>> +vci-supply = <&ldo28_reg>;
>> +reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.
Reasonable to remove te-gpios property but this change would make MIPI-DSI
driver probing to be failed so MIPI-DSI driver should be fixed together.
Thanks.
>
> Regards
> Andrzej
>> +};
>> +};
>> +
>> &hsi2c_9 {
>> status = "okay";
>>
>
>
>
>
[PATCH 0/5 v3] adv7511 EDID probing improvements
Hi, On 01/04/2017 01:11 AM, John Stultz wrote: > Hope everyone had a good newyears! > > Wanted to re-send out v3 of this patch set improving the EDID > probing on the adv7511 used on HiKey, for consideration for > merging for 4.11 > > The first three patches are fixups that are hopefully straight > forward, integrating feedback I got from Laurant. > > The last two patches try to clean up and resue code, which as > a side effect avoids an issue I'm seeing where something is > going wrong with the regmap cache state for the > ADV7511_REG_EDID_I2C_ADDR(0x43) register which results in > i2c_transfer errors if we don't do the > regcache_sync/_mark_dirty() calls. I suspect there might be a > better solution there, but have not gotten any other suggestions > so I wanted to go ahead and submit these. > > Thoughts and feedback would be appreciated! Tested on DB410c on 4.10-rc3. Works well for me. Thanks, Archit > > thanks > -john > > New in v3: > * Addressed naming improvements and drm_kms_helper_hotplug_event > usage corrections as suggested by Laurent. > > Cc: David Airlie > Cc: Archit Taneja > Cc: Wolfram Sang > Cc: Lars-Peter Clausen > Cc: Laurent Pinchart > Cc: dri-devel at lists.freedesktop.org > > Archit Taneja (1): > drm/bridge: adv7511: Enable HPD interrupts to support hotplug and > improve monitor detection > > John Stultz (4): > drm/bridge: adv7511: Use work_struct to defer hotplug handing to out > of irq context > drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event() > drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be > reused internally > drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 + > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 62 > +++- > 2 files changed, 44 insertions(+), 20 deletions(-) > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] drm/probe-helpers: Drop locking from poll_enable
It was only needed to protect the connector_list walking, see
commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter
Date: Thu Jul 9 23:44:26 2015 +0200
drm/probe-helper: Grab mode_config.mutex in poll_init/enable
Unfortunately the commit message of that patch fails to mention that
the new locking check was for the connector_list.
But that requirement disappeared in
commit c36a3254f7857f1ad9badbe3578ccc92be541a8e
Author: Daniel Vetter
Date: Thu Dec 15 16:58:43 2016 +0100
drm: Convert all helpers to drm_connector_list_iter
and so we can drop this again.
This fixes a locking inversion on nouveau, where the rpm code needs to
re-enable. But in other places the rpm_get() calls are nested within
the big modeset locks.
While at it, also improve the kerneldoc for these two functions a
notch.
v2: Update the kerneldoc even more to explain that these functions
can't be called concurrently, or bad things happen (Chris).
Cc: Dave Airlie
Reviewed-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_probe_helper.c | 51 ++--
drivers/gpu/drm/i915/intel_hotplug.c | 4 +--
include/drm/drm_crtc_helper.h| 1 -
3 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 20f48d1e2785..93381454bdf7 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -115,25 +115,28 @@ static int drm_helper_probe_add_cmdline_mode(struct
drm_connector *connector)
#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
/**
- * drm_kms_helper_poll_enable_locked - re-enable output polling.
+ * drm_kms_helper_poll_enable - re-enable output polling.
* @dev: drm_device
*
- * This function re-enables the output polling work without
- * locking the mode_config mutex.
+ * This function re-enables the output polling work, after it has been
+ * temporarily disabled using drm_kms_helper_poll_disable(), for example over
+ * suspend/resume.
*
- * This is like drm_kms_helper_poll_enable() however it is to be
- * called from a context where the mode_config mutex is locked
- * already.
+ * Drivers can call this helper from their device resume implementation. It is
+ * an error to call this when the output polling support has not yet been set
+ * up.
+ *
+ * Note that calls to enable and disable polling must be strictly ordered,
which
+ * is automatically the case when they're only call from suspend/resume
+ * callbacks.
*/
-void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
+void drm_kms_helper_poll_enable(struct drm_device *dev)
{
bool poll = false;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
- WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
-
if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
return;
@@ -163,7 +166,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device
*dev)
if (poll)
schedule_delayed_work(&dev->mode_config.output_poll_work,
delay);
}
-EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
+EXPORT_SYMBOL(drm_kms_helper_poll_enable);
static enum drm_connector_status
drm_connector_detect(struct drm_connector *connector, bool force)
@@ -290,7 +293,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
/* Re-enable polling in case the global poll config changed. */
if (drm_kms_helper_poll != dev->mode_config.poll_running)
- drm_kms_helper_poll_enable_locked(dev);
+ drm_kms_helper_poll_enable(dev);
dev->mode_config.poll_running = drm_kms_helper_poll;
@@ -484,8 +487,12 @@ static void output_poll_execute(struct work_struct *work)
* This function disables the output polling work.
*
* Drivers can call this helper from their device suspend implementation. It is
- * not an error to call this even when output polling isn't enabled or arlready
- * disabled.
+ * not an error to call this even when output polling isn't enabled or already
+ * disabled. Polling is re-enabled by calling drm_kms_helper_poll_enable().
+ *
+ * Note that calls to enable and disable polling must be strictly ordered,
which
+ * is automatically the case when they're only call from suspend/resume
+ * callbacks.
*/
void drm_kms_helper_poll_disable(struct drm_device *dev)
{
@@ -496,24 +503,6 @@ void drm_kms_helper_poll_disable(struct drm_device *dev)
EXPORT_SYMBOL(drm_kms_helper_poll_disable);
/**
- * drm_kms_helper_poll_enable - re-enable output polling.
- * @dev: drm_device
- *
- * This function re-enables the output polling work.
- *
- * Drivers can call this helper from their device resume implementation. It is
- * an error to call this when the output polling support has not yet been set
- * up.
- */
-void drm_kms_helper_poll_enable(struct drm_device *dev)
[PATCH v2] drm: get fbdev size from cmdline mode if it exists
On 01/11/2017 08:48 AM, Daniel Vetter wrote: > On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote: >> Hi Vincent, >> >> On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote: >>> On 01/10/2017 12:39 PM, Daniel Vetter wrote: On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote: > In case no connector is found while creating the fbdev, gives the > possibility to specify the default fbdev size by firstly checking if the > command line is defining a preferred mode. Else go into fallback and set > 1024x768 fbdev size as it was already done. > > Cc: Tomi Valkeinen > Signed-off-by: Vincent Abriou btw on all this there's also the possible solution to delay setup of the fbdev until the first connector switches to connected, and then only allocting the fb and doing the setup. Tegra has that, and Thierry did some patches to move that logic into the fb helpers. But there's some locking issues that need to be fixed first, hence why those patches haven't landed yet. But if you never probe the right mode, this here sounds like a good idea too. >>> >>> The early creation of fbdev is useful for userland system. If fbdev >>> creation is delayed until first connector is connected, userland systems >>> startup could fails (like Android that check fbdev availability at startup). >>> >>> Today if no connector is connected, a default 1024x768 fbdev is created >>> but it does not necessarily match the targeted CRTC size. When the >>> connector is connected, fbdev is not reconfigured with the targeted CRTC >>> size and it is anyway too late for the userland to take into account new >>> fbdev size. Reading the cmdline is an easy way to solve this. >> >> Isn't it another case of working around userspace issue in the kernel ? >> Shouldn't the offending userspace code be fixed ? And while at it, moved from >> fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years ago to >> use >> DRM/KMS in the Android init process. I'm sure it doesn't apply cleanly >> anymore, but I can share it if you're interested. Android is one example and it still give the possibility to start with fbdev. I'm not trying to fixe userspace issue (there is so many userspaces :)). The default case to set fbdev to 1024x768 already exist in the drm fb helpers. I just add a way to be flexible. Vincent > > So android still doesn't boot without fbdev? I thought that's been fixed > ... > -Daniel >
[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics
https://bugs.freedesktop.org/show_bug.cgi?id=98856 --- Comment #4 from Gregor Münch --- I managed to get a trace. Hope it works for you. https://drive.google.com/open?id=0B5KUmMDAwP-iUFNDdEpkd2xUMXc -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/18c948ac/attachment.html>
[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics
https://bugs.freedesktop.org/show_bug.cgi?id=98856 --- Comment #5 from Gregor Münch --- (In reply to Samuel Pitoiset from comment #3) > Does reverting that commit fix the issue? I can't test (I would do if someone could show me how). I do weekly Mesa builds and Im quite sure it broke in the week when this commit appeared. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/ca190355/attachment.html>
[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=99323 --- Comment #5 from kartik --- Created attachment 128884 --> https://bugs.freedesktop.org/attachment.cgi?id=128884&action=edit explicit dmesg setting with curruption -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/06546cb5/attachment.html>
[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=99323 --- Comment #6 from kartik --- Created attachment 128885 --> https://bugs.freedesktop.org/attachment.cgi?id=128885&action=edit explicit dmesg without forcing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/71e89b48/attachment.html>
[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=99323 --- Comment #7 from kartik --- Created attachment 128886 --> https://bugs.freedesktop.org/attachment.cgi?id=128886&action=edit Without explictly setting dpm and without curruption forced high performance mode -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/738fbca1/attachment.html>
[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 11.01.2017 09:40, Inki Dae wrote:
>
> 2017ë
01ì 11ì¼ 16:46ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>>> From: Hyungwon Hwang
>>>
>>> This patch add the panel device tree node for S6E3HA2 display
>>> controller to TM2 dts.
>>>
>>> Signed-off-by: Hyungwon Hwang
>>> Signed-off-by: Andrzej Hajda
>>> Signed-off-by: Chanwoo Choi
>>> Signed-off-by: Hoegeun Kwon
>>> Tested-by: Chanwoo Choi
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> index ddba2f8..6d362f9 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> @@ -18,6 +18,18 @@
>>> compatible = "samsung,tm2", "samsung,exynos5433";
>>> };
>>>
>>> +&dsi {
>>> + panel at 0 {
>>> + compatible = "samsung,s6e3ha2";
>>> + reg = <0>;
>>> + vdd3-supply = <&ldo27_reg>;
>>> + vci-supply = <&ldo28_reg>;
>>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>> The same here (as in 1st comment) , te-gpios should be dropper - decon
>> uses hw-trigger.
> Reasonable to remove te-gpios property but this change would make MIPI-DSI
> driver probing to be failed so MIPI-DSI driver should be fixed together.
>
> Thanks.
OK, I forgot it was not yet ported to mainline.
Regards
Andrzej
>
>> Regards
>> Andrzej
>>> + };
>>> +};
>>> +
>>> &hsi2c_9 {
>>> status = "okay";
>>>
>>
>>
>>
>
[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #1 from Michel Dänzer --- Please attach the dmesg output and maybe Xorg log file corresponding to the problem. You could try running some piglit tests PIGLIT_PLATFORM=gbm . That could help us narrow down if the problem is with the rendering or the display. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/f45ebae5/attachment-0001.html>
[GIT PULL] etnaviv-fixes for 4.10
Hi Dave, a single fix for a FE hang after IOVA rollover on GC3000. This isn't pretty, but is the minimal fix for the issue. A larger rework of the code, that will also fix this issue properly, is currently in the works, but that needs to wait for at least the next feature pull. Regards, Lucas The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: Linux 4.10-rc1 (2016-12-25 16:13:08 -0800) are available in the git repository at: https://git.pengutronix.de/git/lst/linux drm-etnaviv-fixes for you to fetch changes up to 3546fb0cdac25a79c89d87020566fab52b92867d: drm/etnaviv: trick drm_mm into giving out a low IOVA (2017-01-11 10:38:45 +0100) Lucas Stach (1): drm/etnaviv: trick drm_mm into giving out a low IOVA drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)
[Bug 99143] r9 390: Hardware cursor invisible after hibernate/resume
https://bugs.freedesktop.org/show_bug.cgi?id=99143 --- Comment #6 from Harald Judt --- Hi, sorry for not reporting earlier, but the holidays and lack of time... I will test this and also the reverting patch send to the mailing list tonight and verify that it helps. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/5a370585/attachment.html>
[Bug 99236] System (seems to) completely freeze when interacting with java swing applications.
https://bugs.freedesktop.org/show_bug.cgi?id=99236 --- Comment #15 from Michel Dänzer --- For any commits that you can't test, run git bisect skip Eventually, git bisect will either show the commit which introduced the problem, or the minimal set of candidates. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/d3ca836b/attachment.html>
[Bug 99323] White horizontal lines and graphics curruption in ATI HD 4570 when radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=99323 --- Comment #8 from kartik --- First I Have explicitly set radeon.dpm = 1 which did not solve the problem. Then I have explicitly set radeon.dpm = 1 and forced High performance mode. It did not solve the problem either. Then finally I did not explicitly set radeon.dpm = 1 but it was enabled implicitly and i forced High performance mode and no more currupton. Curruption is gone after forcing high performance mode in dpm or disabling dpm with radeon.dpm = 0 . Please look into this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/deb678ed/attachment.html>
[Bug 99330] Severe flickering with Fiji on Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=99330 --- Comment #7 from Michel Dänzer --- Please attach the dmesg output, preferably captured after the problem occurred. (In reply to Vedran MiletiÄ from comment #6) > Jan 10 17:44:30 localhost.localdomain gnome-shell[22110]: Failed to flip: > Invalid argument > > I also got the following in dmesg, but it's likely unrelated as I get it > with Xorg as well: > > [Tue Jan 10 17:44:29 2017] [drm:amdgpu_crtc_page_flip [amdgpu]] *ERROR* > failed to get vblank before flip It might be related. There might be similar messages about the page flip ioctl failing in the Xorg log file, Xorg might just be more resilient against it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/dd88f79f/attachment.html>
[PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 01/11/2017 04:46 PM, Andrzej Hajda wrote:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Hoegeun Kwon
>> Tested-by: Chanwoo Choi
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>> compatible = "samsung,tm2", "samsung,exynos5433";
>> };
>>
>> +&dsi {
>> +panel at 0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <&ldo27_reg>;
>> +vci-supply = <&ldo28_reg>;
>> +reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.
Hi Andrzej,
Thanks for your quick review.
Reasonable to remove te-gpios property,
The Tizen public already has [1] your patch applied and te-gpios removed.
So I will add [1] to the V9 patch.
[1]
https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=468769bf6abbaaed2547b8c43e989ab5dc787900
Best Regards,
Hoegeun
>
> Regards
> Andrzej
>> +};
>> +};
>> +
>> &hsi2c_9 {
>> status = "okay";
>>
>
>
>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #145 from Harald Judt --- You are certainly right and the files differ, so I assume it could be a problem with the firmware. But since amdgpu works fine for me now, I will simply use this and bother no longer. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/2aaf5b0c/attachment-0001.html>
[PATCH] drm: disable deep color when EDID violates spec
On Tue, 10 Jan 2017, Harry Wentland wrote: > On 2017-01-10 03:41 PM, Harry Wentland wrote: >> On 2017-01-10 03:10 PM, Alex Deucher wrote: >>> On Tue, Jan 10, 2017 at 3:02 PM, Ernst Sjöstrand >>> wrote: I kindof assume DP is the default connection these days and with Freesync you use DP or course, but this question was specifically for HDMI. I guess this patch doesn't affect deep color over DP? Anyway, only 17 of those monitors have FreeSync but almost all have DP, so perhaps they only support 10 bpc when connected with DP? >>> >>> We see 10 bpc only over HDMI a lot apparently. I guess a lot of >>> monitor vendors do the minimum necessary for deep color. >>> >> >> Yes, apparently there are a bunch of HDMI displays that we drive in >> 10bpc that might or might not report 12bpc support. From talking to our >> HDMI guys it sounds like this is a slightly ambiguous area in the spec, >> despite what the HDMI spec quote mentioned by Nicholas said. I'll see if >> I can get more info. >> > > Adding Ernst, Nicholas, Ville, Alex again. > > So apparently the spec is pretty clear and there's a sink compliance > test that should cover this. I don't really think it makes sense for the > source device to babysit the sink's behavior, though. > > In general we might want to try for a solution that gives the best user > experience and highest interoperability, so check what sink supports, > check what source supports, check what cable can do, and do an > intersection of all to give the best user experience. > > I suggest to block 10-bit on driver's that can't handle this. Agreed. Pretty much boils down to what I wrote in [1]. BR, Jani. [1] https://lists.freedesktop.org/archives/dri-devel/2017-January/129374.html > > Harry > > >> I'm not sure it makes sense to block all deep color modes in this case >> for all drivers. Other HW (e.g. AMD's) is perfectly capable of driving >> 10-bit. Would it make sense to just block this on the i915 side as Ville >> alluded to on another thread? >> >> Harry >> >>> Alex >>> Regards //Ernst 2017-01-10 20:54 GMT+01:00 Alex Deucher : > > On Tue, Jan 10, 2017 at 12:46 PM, Ville Syrjälä > wrote: >> On Tue, Jan 10, 2017 at 12:27:45PM -0500, Alex Deucher wrote: >>> On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand >>> wrote: Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm confusing the transport layer with the presentation capabilities...? Here are 201 monitors that claim 10bpc: http://pricespy.co.uk/category.php?l=s300859434&o=eg_401#prodlista >>> >>> FWIW, I've almost never seen a monitor that supports 12 bpc, but I've >>> see quite a few 10 bpc monitors. >> >> I've seen plenty of monitors that do 10bpc over DP, but I've never >> seen >> anything that does 10bpc over HDMI. 12bpc over HDMI is pretty common >> in "proper" TVs in my experience. >> >>> I can talk to our display team to >>> see what other OSes do. >> >> Thanks. That should give us some idea if anyone ever tried 10bpc >> over HDMI on these things. > > We apparently see this pretty commonly, especially with freesync > monitors, and we support it. It seems to be pretty prevalent because > you can support a higher refresh rate with a lower bpc. > > Alex > >> >>> >>> Alex >>> Regards //Ernst 2017-01-10 11:52 GMT+01:00 Ville Syrjälä : > > On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote: >> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color >> depths >> greater than 24 bits per pixel. The spec explicitly states, "All >> Deep >> Color modes are optional though if an HDMI Source or Sink supports >> any >> Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth >> Requirements). >> >> I came across a monitor (Acer X233H) that supplies an illegal EDID >> where >> DC_30bit is set and DC_36bit is not set. The end result is badly >> garbled >> output because the driver is sending 36BPP when the monitor can't >> handle >> it. >> >> Much of the intel hardware is incapable of operating at any >> bit-per-component setting outside of 8 or 12, and the spec seems >> to >> imply that if any deep color support is found, then it is a safe >> assumption to operate at 12. >> >> This patch ensures that the EDID is within the spec (specifically, >> that >> DC_36bit is set) before committing to going forward with any deep >> colors. There was already a check for this EDID inconsistency, >> but it >> resulted only in a warning and did
[Bug 98784] Talos Principle rendering flickering garbage on start instead of its logo and loading squares
https://bugs.freedesktop.org/show_bug.cgi?id=98784 Michel Dänzer changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #11 from Michel Dänzer --- The apitrace seems to confirm a Talos bug. It looks like Talos tries to clear the back buffer with glClear, but it still has a non-default framebuffer object bound with glBindFramebuffer, so the glClear doesn't affect the back buffer. I'd like someone else to take a look and confirm this though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170111/f963c282/attachment.html>
Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 01/11/2017 06:39 PM, Andrzej Hajda wrote:
On 11.01.2017 09:40, Inki Dae wrote:
2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
On 11.01.2017 07:33, Hoegeun Kwon wrote:
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index ddba2f8..6d362f9 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -18,6 +18,18 @@
compatible = "samsung,tm2", "samsung,exynos5433";
};
+&dsi {
+ panel@0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
The same here (as in 1st comment) , te-gpios should be dropper - decon
uses hw-trigger.
Reasonable to remove te-gpios property but this change would make MIPI-DSI
driver probing to be failed so MIPI-DSI driver should be fixed together.
Thanks.
OK, I forgot it was not yet ported to mainline.
Regards
Andrzej
I received a reply while I was writing the mail.
so, how about removing te-gpios later?
Best Regards,
Hoegeun
Regards
Andrzej
+ };
+};
+
&hsi2c_9 {
status = "okay";
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 01/11/2017 06:51 PM, hoegeun kwon wrote:
On 01/11/2017 04:46 PM, Andrzej Hajda wrote:
On 11.01.2017 07:33, Hoegeun Kwon wrote:
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index ddba2f8..6d362f9 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -18,6 +18,18 @@
compatible = "samsung,tm2", "samsung,exynos5433";
};
+&dsi {
+panel@0 {
+compatible = "samsung,s6e3ha2";
+reg = <0>;
+vdd3-supply = <&ldo27_reg>;
+vci-supply = <&ldo28_reg>;
+reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
The same here (as in 1st comment) , te-gpios should be dropper - decon
uses hw-trigger.
Hi Andrzej,
Thanks for your quick review.
Reasonable to remove te-gpios property,
The Tizen public already has [1] your patch applied and te-gpios removed.
So I will add [1] to the V9 patch.
[1]
https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=468769bf6abbaaed2547b8c43e989ab5dc787900
I'm sorry URL address is wrong.
Correct address below:
[1]
https://git.tizen.org/cgit/platform/kernel/linux-exynos/commit/?h=tizen&id=468769bf6abbaaed2547b8c43e989ab5dc787900
Regards,
Hoegeun
Best Regards,
Hoegeun
Regards
Andrzej
+};
+};
+
&hsi2c_9 {
status = "okay";
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On 11.01.2017 11:23, hoegeun kwon wrote:
>
> On 01/11/2017 06:39 PM, Andrzej Hajda wrote:
>> On 11.01.2017 09:40, Inki Dae wrote:
>>> 2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
On 11.01.2017 07:33, Hoegeun Kwon wrote:
> From: Hyungwon Hwang
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Hoegeun Kwon
> Tested-by: Chanwoo Choi
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index ddba2f8..6d362f9 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,6 +18,18 @@
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
>
> +&dsi {
> + panel@0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
The same here (as in 1st comment) , te-gpios should be dropper - decon
uses hw-trigger.
>>> Reasonable to remove te-gpios property but this change would make MIPI-DSI
>>> driver probing to be failed so MIPI-DSI driver should be fixed together.
>>>
>>> Thanks.
>> OK, I forgot it was not yet ported to mainline.
>>
>> Regards
>> Andrzej
> I received a reply while I was writing the mail.
> so, how about removing te-gpios later?
I think this is a good solution, just do not forget to change it to
optional in bindings, to make it removable.
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: get fbdev size from cmdline mode if it exists
Hi Vincent, On Wednesday 11 Jan 2017 09:03:07 Vincent ABRIOU wrote: > On 01/11/2017 08:48 AM, Daniel Vetter wrote: > > On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote: > >> On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote: > >>> On 01/10/2017 12:39 PM, Daniel Vetter wrote: > On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote: > > In case no connector is found while creating the fbdev, gives the > > possibility to specify the default fbdev size by firstly checking if > > the command line is defining a preferred mode. Else go into fallback > > and set 1024x768 fbdev size as it was already done. > > > > Cc: Tomi Valkeinen > > Signed-off-by: Vincent Abriou > > btw on all this there's also the possible solution to delay setup of > the fbdev until the first connector switches to connected, and then > only allocting the fb and doing the setup. Tegra has that, and Thierry > did some patches to move that logic into the fb helpers. But there's > some locking issues that need to be fixed first, hence why those > patches haven't landed yet. > > But if you never probe the right mode, this here sounds like a good > idea too. > >>> > >>> The early creation of fbdev is useful for userland system. If fbdev > >>> creation is delayed until first connector is connected, userland systems > >>> startup could fails (like Android that check fbdev availability at > >>> startup). > >>> > >>> Today if no connector is connected, a default 1024x768 fbdev is created > >>> but it does not necessarily match the targeted CRTC size. When the > >>> connector is connected, fbdev is not reconfigured with the targeted CRTC > >>> size and it is anyway too late for the userland to take into account new > >>> fbdev size. Reading the cmdline is an easy way to solve this. > >> > >> Isn't it another case of working around userspace issue in the kernel ? > >> Shouldn't the offending userspace code be fixed ? And while at it, moved > >> from fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years > >> ago to use DRM/KMS in the Android init process. I'm sure it doesn't > >> apply cleanly anymore, but I can share it if you're interested. > > Android is one example and it still give the possibility to start with > fbdev. I'm not trying to fixe userspace issue (there is so many userspaces > :)). The default case to set fbdev to 1024x768 already exist in the drm fb > helpers. I just add a way to be flexible. Sure, I understand that. My point is that, instead of making life easy for userspace that hasn't switched to DRM/KMS yet, wouldn't it be time to push them a bit more ? > > So android still doesn't boot without fbdev? I thought that's been fixed I haven't checked the latest version to be honest. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge
Hi Archit,
Thank you for the patch.
On Wednesday 11 Jan 2017 12:09:51 Archit Taneja wrote:
> The commit "drm: bridge: Link encoder and bridge in core code" updated
> the drm_bridge_attach() API to also include the drm_encoder pointer
> the bridge attaches to.
>
> The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
> pointer stored in msm_dsi->encoders to pass the encoder to the bridge
> API.
>
> msm_dsi->encoders is unfortunately set after this function is called,
> resulting in us passing a NULL pointer to drm_brigde_attach. This
> results in an error and the DSI driver probe fails.
>
> Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
> try to set the encoder's bridge. That's now managed by the bridge
> API.
>
> Cc: Laurent Pinchart
Acked-by: Laurent Pinchart
Sorry for having missed that :-(
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/dsi/dsi.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index ec572f8..9593238 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
> drm_device *dev, goto fail;
> }
>
> + for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
> + msm_dsi->encoders[i] = encoders[i];
> +
> msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
> if (IS_ERR(msm_dsi->bridge)) {
> ret = PTR_ERR(msm_dsi->bridge);
> @@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> struct drm_device *dev, goto fail;
> }
>
> - for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
> - encoders[i]->bridge = msm_dsi->bridge;
> - msm_dsi->encoders[i] = encoders[i];
> - }
> -
> /*
>* check if the dsi encoder output is connected to a panel or an
>* external bridge. We create a connector only if we're connected to a
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
On Wed, Jan 11, 2017 at 10:27:03AM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 10-01-2017 17:21, Ville Syrjälä wrote:
>
> [snip]
>
> >> But we already have color_formats field in drm_display_info
> >> struct, right? Shouldn't we instead create for example a helper
> >> which returns the best output colorspace? According to what you
> >> said it would be something like:
> >>
> >> if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
> >> return YCBCR444;
> >> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
> >> return YCBCR422;
> >> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR420
> >> && vic_is_420)
> >> return YCBCR420;
> >> else
> >> return RGB444; /* Mandatory by spec */
> > Perhaps. But it would have to be more involved than that since there
> > might limitations on eg. the max TMDS clock imposed by the source or
> > cable/dongle which presumably might require that we pick 4:2:0 over
> > 4:4:4.
> >
> > It would also need to account which formats are actually supported by
> > the source.
> >
> > I guess for bpc it would be enough to just consider 8bpc in such a
> > function, and then the driver can bump it up afterwards if possible.
>
> But the max tmds clock will probably be involved in deep color
> modes, as 24bpp has always a 1x factor in every YCbCr, except
> 4:2:0. So, the sink has a max tmds but this gets into account
> when the vic list present in the EDID is built, but not
> considered in deep color modes, unless the EDID is broken.
>
> >
> > As for the RGB vs. YCbCr question, I guess we should just prefer RGB444
> > for now. And fall back to YCbCr 4:2:2 or 4:2:0 if necessary. And that
> > leaves YCbCr 4:4:4 unsed since it has the same requirements as RGB
> > 4:4:4 and thus doesn't provide any benefit as such. We could later add
> > a property to let the user choose between RGB vs. YCbCr more explicitly.
> >
>
> Hmm, I am trying to implement this but I am facing a difficulty:
> how will I fallback to YCbCr? RGB is always supported and the max
> tmds only enters in deep color modes. For reference here is a
> simple struct i created with the different tmds character rate
> factors for the different encodings (I think they are correct,
> but cross check please):
>
> #define DRM_CS_DESC(cs, f, b) \
> .colorspace = (cs), .factor_to_khz = (f), .bpc = (b)
>
> static const struct drm_mode_colorspace_desc {
> u32 colorspace;
> u32 factor_to_khz;
> u32 bpc;
> } drm_mode_colorspace_factors = { /* Ordered by descending
> preference */
> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 2000, 48) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 2000, 48) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1500, 36) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1500, 36) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1250, 30) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1250, 30) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1000, 24) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1000, 24) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 24) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 30) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 36) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 1000, 48) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 750, 36) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 625, 30) },
> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 500, 24) },
>
> Notice how YCbCr 4:4:4 will never get picked: it has the same
> factor of RGB 4:4:4 for every bpc. So, the sink must support RGB
> 4:4:4 and may support YCbCr. What I didn't check was that if it
> is possible to have support for deep color YCbCr without having
> support for deep color RGB 4:4:4. Do you know if this can happen?
I don't think that's possible. So the 4:4:4 RGB vs. YCbCr choice is
probably something we have to leave up to the user. Although I have
a vague recollection that CEA-861 says that you should prefer YCbCr
for CE modes and RGB for IT modes. If we want to follow that I think we
want a property similar to the "Broadcast RGB" thing that allows you to
select between "Automatic", "RGB", and "YCbCr". Not sure if we should
also allow the user to explicitly select the subsampling mode for YCbCr.
I also think we should probably still fall back to YCbCr 4:2:0
automagically even if the user explicitly asked for RGB if we can't
light up the mode with RGB 4:4:4.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: disable deep color when EDID violates spec
On Wed, Jan 11, 2017 at 12:04:09PM +0200, Jani Nikula wrote: > On Tue, 10 Jan 2017, Harry Wentland wrote: > > On 2017-01-10 03:41 PM, Harry Wentland wrote: > >> On 2017-01-10 03:10 PM, Alex Deucher wrote: > >>> On Tue, Jan 10, 2017 at 3:02 PM, Ernst Sjöstrand > >>> wrote: > I kindof assume DP is the default connection these days and with > Freesync > you use > DP or course, but this question was specifically for HDMI. > I guess this patch doesn't affect deep color over DP? > > Anyway, only 17 of those monitors have FreeSync but almost all have > DP, so > perhaps they only support > 10 bpc when connected with DP? > >>> > >>> We see 10 bpc only over HDMI a lot apparently. I guess a lot of > >>> monitor vendors do the minimum necessary for deep color. > >>> > >> > >> Yes, apparently there are a bunch of HDMI displays that we drive in > >> 10bpc that might or might not report 12bpc support. From talking to our > >> HDMI guys it sounds like this is a slightly ambiguous area in the spec, > >> despite what the HDMI spec quote mentioned by Nicholas said. I'll see if > >> I can get more info. > >> > > > > Adding Ernst, Nicholas, Ville, Alex again. > > > > So apparently the spec is pretty clear and there's a sink compliance > > test that should cover this. I don't really think it makes sense for the > > source device to babysit the sink's behavior, though. > > > > In general we might want to try for a solution that gives the best user > > experience and highest interoperability, so check what sink supports, > > check what source supports, check what cable can do, and do an > > intersection of all to give the best user experience. > > > > I suggest to block 10-bit on driver's that can't handle this. > > Agreed. Pretty much boils down to what I wrote in [1]. > > BR, > Jani. > > [1] https://lists.freedesktop.org/archives/dri-devel/2017-January/129374.html After a bit of digging around I found my patch to check the DC_36 bit in i915 code: git://github.com/vsyrjala/linux.git hdmi_sink_tmds_limit_2 Nicholas, you want to give that go? > > > > > > > Harry > > > > > >> I'm not sure it makes sense to block all deep color modes in this case > >> for all drivers. Other HW (e.g. AMD's) is perfectly capable of driving > >> 10-bit. Would it make sense to just block this on the i915 side as Ville > >> alluded to on another thread? > >> > >> Harry > >> > >>> Alex > >>> > > Regards > //Ernst > > 2017-01-10 20:54 GMT+01:00 Alex Deucher : > > > > On Tue, Jan 10, 2017 at 12:46 PM, Ville Syrjälä > > wrote: > >> On Tue, Jan 10, 2017 at 12:27:45PM -0500, Alex Deucher wrote: > >>> On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand > >>> wrote: > Isn't 10bpc very common among monitors, and 12bpc very rare? Or > maybe > I'm > confusing the transport layer with the presentation capabilities...? > Here are 201 monitors that claim 10bpc: > http://pricespy.co.uk/category.php?l=s300859434&o=eg_401#prodlista > > >>> > >>> FWIW, I've almost never seen a monitor that supports 12 bpc, but I've > >>> see quite a few 10 bpc monitors. > >> > >> I've seen plenty of monitors that do 10bpc over DP, but I've never > >> seen > >> anything that does 10bpc over HDMI. 12bpc over HDMI is pretty common > >> in "proper" TVs in my experience. > >> > >>> I can talk to our display team to > >>> see what other OSes do. > >> > >> Thanks. That should give us some idea if anyone ever tried 10bpc > >> over HDMI on these things. > > > > We apparently see this pretty commonly, especially with freesync > > monitors, and we support it. It seems to be pretty prevalent because > > you can support a higher refresh rate with a lower bpc. > > > > Alex > > > >> > >>> > >>> Alex > >>> > Regards > //Ernst > > 2017-01-10 11:52 GMT+01:00 Ville Syrjälä > : > > > > On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote: > >> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color > >> depths > >> greater than 24 bits per pixel. The spec explicitly states, "All > >> Deep > >> Color modes are optional though if an HDMI Source or Sink supports > >> any > >> Deep Color mode, it shall support 36-bit mode." (6.2.4 Color Depth > >> Requirements). > >> > >> I came across a monitor (Acer X233H) that supplies an illegal EDID > >> where > >> DC_30bit is set and DC_36bit is not set. The end result is badly > >> garbled > >> output because the driver is sending 36BPP when the monitor can't > >> handle > >> it. > >> > >> Much of the intel hardware is incapable of operating at any > >> bit-per-componen
Re: [PATCH v8 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
Hi Hoegeun,
2017-01-11 15:33 GMT+09:00 Hoegeun Kwon :
> The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> Tested-by: Chanwoo Choi
I think my tested-by tag is improper against binding documentation.
Maybe you added the my tested-by tag when you split the panel
driver because I replied my tested-by tag to panel driver.
You better to drop the my tested-by tag from only this patch
(binding documentation).
> Reviewed-by: Andrzej Hajda
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 000..3e7892c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,26 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2"
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: I/O voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin (active low)
> + - enable-gpios: a GPIO spec for the panel enable pin (active high)
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +gpio pin (active high)
> +
> +Example:
> +&dsi {
> + ...
> +
> + panel@0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> + };
> +};
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: get fbdev size from cmdline mode if it exists
On Wed, Jan 11, 2017 at 01:11:45PM +0200, Laurent Pinchart wrote: > Hi Vincent, > > On Wednesday 11 Jan 2017 09:03:07 Vincent ABRIOU wrote: > > On 01/11/2017 08:48 AM, Daniel Vetter wrote: > > > On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote: > > >> On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote: > > >>> On 01/10/2017 12:39 PM, Daniel Vetter wrote: > > On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote: > > > In case no connector is found while creating the fbdev, gives the > > > possibility to specify the default fbdev size by firstly checking if > > > the command line is defining a preferred mode. Else go into fallback > > > and set 1024x768 fbdev size as it was already done. > > > > > > Cc: Tomi Valkeinen > > > Signed-off-by: Vincent Abriou > > > > btw on all this there's also the possible solution to delay setup of > > the fbdev until the first connector switches to connected, and then > > only allocting the fb and doing the setup. Tegra has that, and Thierry > > did some patches to move that logic into the fb helpers. But there's > > some locking issues that need to be fixed first, hence why those > > patches haven't landed yet. > > > > But if you never probe the right mode, this here sounds like a good > > idea too. > > >>> > > >>> The early creation of fbdev is useful for userland system. If fbdev > > >>> creation is delayed until first connector is connected, userland systems > > >>> startup could fails (like Android that check fbdev availability at > > >>> startup). > > >>> > > >>> Today if no connector is connected, a default 1024x768 fbdev is created > > >>> but it does not necessarily match the targeted CRTC size. When the > > >>> connector is connected, fbdev is not reconfigured with the targeted CRTC > > >>> size and it is anyway too late for the userland to take into account new > > >>> fbdev size. Reading the cmdline is an easy way to solve this. > > >> > > >> Isn't it another case of working around userspace issue in the kernel ? > > >> Shouldn't the offending userspace code be fixed ? And while at it, moved > > >> from fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years > > >> ago to use DRM/KMS in the Android init process. I'm sure it doesn't > > >> apply cleanly anymore, but I can share it if you're interested. > > > > Android is one example and it still give the possibility to start with > > fbdev. I'm not trying to fixe userspace issue (there is so many userspaces > > :)). The default case to set fbdev to 1024x768 already exist in the drm fb > > helpers. I just add a way to be flexible. > > Sure, I understand that. My point is that, instead of making life easy for > userspace that hasn't switched to DRM/KMS yet, wouldn't it be time to push > them a bit more ? Yeah, if the issue is just that by default android expects fbdev and gets confused if it's not there, then I don't think that patch makes much sense. If we need it because hw is horrible and this is the only way to make fbcon work reasonably well, I'm all fine with that. Either way, other people piping up with "I want this too" would help a lot. Even better when they do a full review :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: get fbdev size from cmdline mode if it exists
On 01/11/2017 12:11 PM, Laurent Pinchart wrote: > Hi Vincent, > > On Wednesday 11 Jan 2017 09:03:07 Vincent ABRIOU wrote: >> On 01/11/2017 08:48 AM, Daniel Vetter wrote: >>> On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote: On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote: > On 01/10/2017 12:39 PM, Daniel Vetter wrote: >> On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote: >>> In case no connector is found while creating the fbdev, gives the >>> possibility to specify the default fbdev size by firstly checking if >>> the command line is defining a preferred mode. Else go into fallback >>> and set 1024x768 fbdev size as it was already done. >>> >>> Cc: Tomi Valkeinen >>> Signed-off-by: Vincent Abriou >> >> btw on all this there's also the possible solution to delay setup of >> the fbdev until the first connector switches to connected, and then >> only allocting the fb and doing the setup. Tegra has that, and Thierry >> did some patches to move that logic into the fb helpers. But there's >> some locking issues that need to be fixed first, hence why those >> patches haven't landed yet. >> >> But if you never probe the right mode, this here sounds like a good >> idea too. > > The early creation of fbdev is useful for userland system. If fbdev > creation is delayed until first connector is connected, userland systems > startup could fails (like Android that check fbdev availability at > startup). > > Today if no connector is connected, a default 1024x768 fbdev is created > but it does not necessarily match the targeted CRTC size. When the > connector is connected, fbdev is not reconfigured with the targeted CRTC > size and it is anyway too late for the userland to take into account new > fbdev size. Reading the cmdline is an easy way to solve this. Isn't it another case of working around userspace issue in the kernel ? Shouldn't the offending userspace code be fixed ? And while at it, moved from fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years ago to use DRM/KMS in the Android init process. I'm sure it doesn't apply cleanly anymore, but I can share it if you're interested. >> >> Android is one example and it still give the possibility to start with >> fbdev. I'm not trying to fixe userspace issue (there is so many userspaces >> :)). The default case to set fbdev to 1024x768 already exist in the drm fb >> helpers. I just add a way to be flexible. > > Sure, I understand that. My point is that, instead of making life easy for > userspace that hasn't switched to DRM/KMS yet, wouldn't it be time to push > them a bit more ? > >>> So android still doesn't boot without fbdev? I thought that's been fixed > Android support fbdev and drm/kms. > I haven't checked the latest version to be honest. > The last Android version still support fbdev. Vincent ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/edid: Introduce drm_default_rgb_quant_range()
From: Ville Syrjälä
Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c| 18 ++
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hdmi.c| 4 +++-
include/drm/drm_edid.h| 2 ++
5 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4ff04aa84dd0..304c583b8000 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3768,6 +3768,24 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
}
EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
+/**
+ * drm_default_rgb_quant_range - default RGB quantization range
+ * @mode: display mode
+ *
+ * Determine the default RGB quantization range for the mode,
+ * as specified in CEA-861.
+ *
+ * Return: The default RGB quantization range for the mode
+ */
+enum hdmi_quantization_range
+drm_default_rgb_quant_range(const struct drm_display_mode *mode)
+{
+ return drm_match_cea_mode(mode) > 1 ?
+ HDMI_QUANTIZATION_RANGE_LIMITED :
+ HDMI_QUANTIZATION_RANGE_FULL;
+}
+EXPORT_SYMBOL(drm_default_rgb_quant_range);
+
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
const u8 *hdmi)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 343e1d9fa761..d4befbbe834a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1713,7 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
*/
pipe_config->limited_color_range =
- bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
+ bpp != 18 &&
+ drm_default_rgb_quant_range(adjusted_mode) ==
+ HDMI_QUANTIZATION_RANGE_LIMITED;
} else {
pipe_config->limited_color_range =
intel_dp->limited_color_range;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0bcfead14571..19bd13f53729 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1330,7 +1330,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
/* See CEA-861-E - 5.1 Default Encoding Parameters */
pipe_config->limited_color_range =
pipe_config->has_hdmi_sink &&
- drm_match_cea_mode(adjusted_mode) > 1;
+ drm_default_rgb_quant_range(adjusted_mode) ==
+ HDMI_QUANTIZATION_RANGE_LIMITED;
} else {
pipe_config->limited_color_range =
intel_hdmi->limited_color_range;
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c4cb2e26de32..d79466a42690 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -463,7 +463,9 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder
*encoder,
csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
VC4_HD_CSC_CTL_ORDER);
- if (vc4_encoder->hdmi_monitor && drm_match_cea_mode(mode) > 1) {
+ if (vc4_encoder->hdmi_monitor &&
+ drm_default_rgb_quant_range(adjusted_mode) ==
+ HDMI_QUANTIZATION_RANGE_LIMITED) {
/* CEA VICs other than #1 requre limited range RGB
* output unless overridden by an AVI infoframe.
* Apply a colorspace conversion to squash 0-255 down
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 838eaf2b42e9..25cdf5f7a0d8 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -441,6 +441,8 @@ enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8
video_code);
bool drm_detect_hdmi_monitor(struct edid *edid);
bool drm_detect_monitor_audio(struct edid *edid);
bool drm_rgb_quant_range_selectable(struct edid *edid);
+enum hdmi_quantization_range
+drm_default_rgb_quant_range(const struct drm_display_mode *mode);
int drm_add_modes_noedid(struct drm_connector *connector,
int hdisplay, int vdisplay);
void drm_set_preferred_mode(struct drm_connector *connector,
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/edid: Improve RGB limited range handling a bit
From: Ville Syrjälä While reading the HDMI 2.0 spec I noticed some new things related to the RGB quantization range stuff, and after cross checking with CEA-861-F I spotted a some other things as well. So I figured I should pimp up the code a bit. And since we now have two drivers that deal with this stuff, I decided to move a bunch of the code to the core to avoid duplicating the code and having different bugs/features for each driver. I still left the state computation part in the drivers, but eventually we might want to move that code into some helper as well. Entire series available here: git://github.com/vsyrjala/linux.git hdmi_quant_range_helpers Ville Syrjälä (5): drm/edid: Have drm_edid.h include hdmi.h drm/edid: Introduce drm_default_rgb_quant_range() drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range() drm/edid: Set AVI infoframe Q even when QS=0 drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F drivers/gpu/drm/drm_edid.c| 64 +++ drivers/gpu/drm/i915/intel_dp.c | 4 ++- drivers/gpu/drm/i915/intel_hdmi.c | 20 ++-- drivers/gpu/drm/vc4/vc4_hdmi.c| 18 +-- include/drm/drm_edid.h| 10 -- 5 files changed, 93 insertions(+), 23 deletions(-) -- 2.10.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F
From: Ville Syrjälä CEA-861-F tells us: "When transmitting any RGB colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore the YQ-field." So let's go ahead and do that. Perhaps there are sinks that don't ignore the YQ as they should for RGB? I wasn't able to find similar text in CEA-861-E, so it would seem to be a fairly "recent" addition. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index caa2435bac31..6ba9a1a6eae4 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4320,6 +4320,20 @@ drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, frame->quantization_range = rgb_quant_range; else frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT; + + /* +* CEA-861-F: +* "When transmitting any RGB colorimetry, the Source should set the +* YQ-field to match the RGB Quantization Range being transmitted +* (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, +* set YQ=1) and the Sink shall ignore the YQ-field." +*/ + if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) + frame->ycc_quantization_range = + HDMI_YCC_QUANTIZATION_RANGE_LIMITED; + else + frame->ycc_quantization_range = + HDMI_YCC_QUANTIZATION_RANGE_FULL; } EXPORT_SYMBOL(drm_hdmi_avi_infoframe_quant_range); -- 2.10.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()
From: Ville Syrjälä
Pull the logic to populate the quantization range information
in the AVI infoframe into a small helper. We'll be adding a bit
more logic to it, and having it in a central place seems like a
good idea since it's based on the CEA-861 spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c| 26 ++
drivers/gpu/drm/i915/intel_hdmi.c | 13 +
drivers/gpu/drm/vc4/vc4_hdmi.c| 14 +-
include/drm/drm_edid.h| 4
4 files changed, 40 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 304c583b8000..548c20250b95 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4291,6 +4291,32 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+/**
+ * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
+ *quantization range information
+ * @frame: HDMI AVI infoframe
+ * @rgb_quant_range: RGB quantization range (Q)
+ * @rgb_quant_range_selectable: Sink support selectable RGB quantization range
(QS)
+ */
+void
+drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
+ enum hdmi_quantization_range rgb_quant_range,
+ bool rgb_quant_range_selectable)
+{
+ /*
+* CEA-861:
+* "A Source shall not send a non-zero Q value that does not correspond
+* to the default RGB Quantization Range for the transmitted Picture
+* unless the Sink indicates support for the Q bit in a Video
+* Capabilities Data Block."
+*/
+ if (rgb_quant_range_selectable)
+ frame->quantization_range = rgb_quant_range;
+ else
+ frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_quant_range);
+
static enum hdmi_3d_structure
s3d_structure_from_display_mode(const struct drm_display_mode *mode)
{
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 19bd13f53729..351f837b09a0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -465,14 +465,11 @@ static void intel_hdmi_set_avi_infoframe(struct
drm_encoder *encoder,
return;
}
- if (intel_hdmi->rgb_quant_range_selectable) {
- if (crtc_state->limited_color_range)
- frame.avi.quantization_range =
- HDMI_QUANTIZATION_RANGE_LIMITED;
- else
- frame.avi.quantization_range =
- HDMI_QUANTIZATION_RANGE_FULL;
- }
+ drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+ crtc_state->limited_color_range ?
+ HDMI_QUANTIZATION_RANGE_LIMITED :
+ HDMI_QUANTIZATION_RANGE_FULL,
+
intel_hdmi->rgb_quant_range_selectable);
intel_write_infoframe(encoder, crtc_state, &frame);
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index d79466a42690..a588156b5410 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -356,15 +356,11 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
*encoder)
return;
}
- if (vc4_encoder->rgb_range_selectable) {
- if (vc4_encoder->limited_rgb_range) {
- frame.avi.quantization_range =
- HDMI_QUANTIZATION_RANGE_LIMITED;
- } else {
- frame.avi.quantization_range =
- HDMI_QUANTIZATION_RANGE_FULL;
- }
- }
+ drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+ vc4_encoder->limited_rgb_range ?
+ HDMI_QUANTIZATION_RANGE_LIMITED :
+ HDMI_QUANTIZATION_RANGE_FULL,
+ vc4_encoder->rgb_range_selectable);
vc4_hdmi_write_infoframe(encoder, &frame);
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 25cdf5f7a0d8..cfad4d89589f 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -345,6 +345,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
int
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
const struct drm_display_mode
*mode);
+void
+drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
+ enum hdmi_quantization_range rgb_quant_range,
+
[PATCH 4/5] drm/edid: Set AVI infoframe Q even when QS=0
From: Ville Syrjälä
HDMI 2.0 recommends that we set the Q bits in the AVI infoframe
even when the sink does not support quantization range selection (QS=0).
According to CEA-861 we can do that as long as the Q we send matches
the default quantization range for the mode.
Previosuly I think I had misread the spec as saying that you can't
send a non-zero Q at all when QS=0. But that's not what the spec
actually says.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c| 8 +++-
drivers/gpu/drm/i915/intel_hdmi.c | 6 --
drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
include/drm/drm_edid.h| 1 +
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 548c20250b95..caa2435bac31 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4295,11 +4295,13 @@ EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
* @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
* @rgb_quant_range: RGB quantization range (Q)
* @rgb_quant_range_selectable: Sink support selectable RGB quantization range
(QS)
*/
void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
+ const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
bool rgb_quant_range_selectable)
{
@@ -4309,8 +4311,12 @@ drm_hdmi_avi_infoframe_quant_range(struct
hdmi_avi_infoframe *frame,
* to the default RGB Quantization Range for the transmitted Picture
* unless the Sink indicates support for the Q bit in a Video
* Capabilities Data Block."
+*
+* HDMI 2.0 recommends sending non-zero Q when it does match the
+* default RGB quantization range for the mode, even when QS=0.
*/
- if (rgb_quant_range_selectable)
+ if (rgb_quant_range_selectable ||
+ rgb_quant_range == drm_default_rgb_quant_range(mode))
frame->quantization_range = rgb_quant_range;
else
frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 351f837b09a0..af16b0fa6b69 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -455,17 +455,19 @@ static void intel_hdmi_set_avi_infoframe(struct
drm_encoder *encoder,
const struct intel_crtc_state
*crtc_state)
{
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
union hdmi_infoframe frame;
int ret;
ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
-
&crtc_state->base.adjusted_mode);
+ adjusted_mode);
if (ret < 0) {
DRM_ERROR("couldn't fill AVI infoframe\n");
return;
}
- drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+ drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a588156b5410..f38fdbac2878 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -356,7 +356,7 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
*encoder)
return;
}
- drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+ drm_hdmi_avi_infoframe_quant_range(&frame.avi, mode,
vc4_encoder->limited_rgb_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index cfad4d89589f..43fb0ac5eb9c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -347,6 +347,7 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
const struct drm_display_mode
*mode);
void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
+ const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
bool rgb_quant_range_selectable);
--
2.10.2
__
[PATCH 1/5] drm/edid: Have drm_edid.h include hdmi.h
From: Ville Syrjälä
drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect,
so let's just include hdmi.h and drop some useless struct declarations.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_edid.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 38eabf65f19d..838eaf2b42e9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -24,6 +24,7 @@
#define __DRM_EDID_H__
#include
+#include
struct drm_device;
struct i2c_adapter;
@@ -322,8 +323,6 @@ struct cea_sad {
struct drm_encoder;
struct drm_connector;
struct drm_display_mode;
-struct hdmi_avi_infoframe;
-struct hdmi_vendor_infoframe;
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: fix drm_vm for NOMMU builds
When building DRM without an MMU, we run into a compile-time error because
pte_wrprotect() is not defined:
drivers/gpu/drm/drm_vm.c: In function 'drm_mmap_dma':
drivers/gpu/drm/drm_vm.c:496:9: error: implicit declaration of function
'pte_wrprotect' [-Werror=implicit-function-declaration]
The line is not meaningful here, so we can simply add another
compile-time check around it.
Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/drm_vm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index bd311c77c254..038946588ed7 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -488,7 +488,7 @@ static int drm_mmap_dma(struct file *filp, struct
vm_area_struct *vma)
vma->vm_flags &= ~(VM_WRITE | VM_MAYWRITE);
#if defined(__i386__) || defined(__x86_64__)
pgprot_val(vma->vm_page_prot) &= ~_PAGE_RW;
-#else
+#elif IS_ENABLED(CONFIG_MMU)
/* Ye gads this is ugly. With more thought
we could move this up higher and use
`protection_map' instead. */
@@ -572,7 +572,7 @@ static int drm_mmap_locked(struct file *filp, struct
vm_area_struct *vma)
vma->vm_flags &= ~(VM_WRITE | VM_MAYWRITE);
#if defined(__i386__) || defined(__x86_64__)
pgprot_val(vma->vm_page_prot) &= ~_PAGE_RW;
-#else
+#elif defined (CONFIG_MMU)
/* Ye gads this is ugly. With more thought
we could move this up higher and use
`protection_map' instead. */
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: add more MMU dependencies
Many DRM drivers only work with an MMU, and after the patch to enable
core DRM support without MMU, we already had one fixup for many of them.
The etnaviv, armada and msm drivers were missed and have the same problem:
warning: (DRM_ETNAVIV) selects IOMMU_SUPPORT which has unmet direct
dependencies (MMU)
warning: (DRM_I915 && DRM_MSM && DRM_ETNAVIV) selects SHMEM which has unmet
direct dependencies (MMU)
drivers/gpu/drm/armada/armada_gem.o: In function `armada_gem_vm_fault':
armada_gem.c:(.text.armada_gem_vm_fault+0x14): undefined reference to
`vm_insert_pfn'
arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap':
arch/arm/mm/dma-mapping.c:1390:4: error: 'VM_ARM_DMA_CONSISTENT' undeclared
(first use in this function)
arch/arm/mm/dma-mapping.c:1456:31: error: 'atomic_pool' undeclared (first use
in this function); did you mean 'atomic_xor'?
Fixes: 011cda589938 ("drm: fix compilations issues introduced by "drm: allow to
use mmuless SoC"")
Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/armada/Kconfig | 2 +-
drivers/gpu/drm/etnaviv/Kconfig | 1 +
drivers/gpu/drm/msm/Kconfig | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index 15f3ecfb16f1..eafaeeb7b5b1 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -1,6 +1,6 @@
config DRM_ARMADA
tristate "DRM support for Marvell Armada SoCs"
- depends on DRM && HAVE_CLK && ARM
+ depends on DRM && HAVE_CLK && ARM && MMU
select DRM_KMS_HELPER
help
Support the "LCD" controllers found on the Marvell Armada 510
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index 2cde7a5442fb..656c061b439d 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -3,6 +3,7 @@ config DRM_ETNAVIV
tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
depends on DRM
depends on ARCH_MXC || ARCH_DOVE
+ depends on MMU
select SHMEM
select TMPFS
select IOMMU_API
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index d96b2b6898a3..7f78da695dff 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -4,6 +4,7 @@ config DRM_MSM
depends on DRM
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on OF && COMMON_CLK
+ depends on MMU
select REGULATOR
select DRM_KMS_HELPER
select DRM_PANEL
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: add more MMU dependencies
Am Mittwoch, den 11.01.2017, 14:33 +0100 schrieb Arnd Bergmann:
> Many DRM drivers only work with an MMU, and after the patch to enable
> core DRM support without MMU, we already had one fixup for many of them.
> The etnaviv, armada and msm drivers were missed and have the same problem:
>
> warning: (DRM_ETNAVIV) selects IOMMU_SUPPORT which has unmet direct
> dependencies (MMU)
> warning: (DRM_I915 && DRM_MSM && DRM_ETNAVIV) selects SHMEM which has unmet
> direct dependencies (MMU)
> drivers/gpu/drm/armada/armada_gem.o: In function `armada_gem_vm_fault':
> armada_gem.c:(.text.armada_gem_vm_fault+0x14): undefined reference to
> `vm_insert_pfn'
> arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap':
> arch/arm/mm/dma-mapping.c:1390:4: error: 'VM_ARM_DMA_CONSISTENT' undeclared
> (first use in this function)
> arch/arm/mm/dma-mapping.c:1456:31: error: 'atomic_pool' undeclared (first use
> in this function); did you mean 'atomic_xor'?
>
> Fixes: 011cda589938 ("drm: fix compilations issues introduced by "drm: allow
> to use mmuless SoC"")
> Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
> Signed-off-by: Arnd Bergmann
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/armada/Kconfig | 2 +-
> drivers/gpu/drm/etnaviv/Kconfig | 1 +
> drivers/gpu/drm/msm/Kconfig | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
> index 15f3ecfb16f1..eafaeeb7b5b1 100644
> --- a/drivers/gpu/drm/armada/Kconfig
> +++ b/drivers/gpu/drm/armada/Kconfig
> @@ -1,6 +1,6 @@
> config DRM_ARMADA
> tristate "DRM support for Marvell Armada SoCs"
> - depends on DRM && HAVE_CLK && ARM
> + depends on DRM && HAVE_CLK && ARM && MMU
> select DRM_KMS_HELPER
> help
> Support the "LCD" controllers found on the Marvell Armada 510
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 2cde7a5442fb..656c061b439d 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -3,6 +3,7 @@ config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> depends on ARCH_MXC || ARCH_DOVE
> + depends on MMU
> select SHMEM
> select TMPFS
> select IOMMU_API
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index d96b2b6898a3..7f78da695dff 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -4,6 +4,7 @@ config DRM_MSM
> depends on DRM
> depends on ARCH_QCOM || (ARM && COMPILE_TEST)
> depends on OF && COMMON_CLK
> + depends on MMU
> select REGULATOR
> select DRM_KMS_HELPER
> select DRM_PANEL
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/edid: Introduce drm_default_rgb_quant_range()
From: Ville Syrjälä
Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.
v2: s/adjusted_mode/mode in vc4 to make it actually compile
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c| 18 ++
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hdmi.c| 4 +++-
include/drm/drm_edid.h| 2 ++
5 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4ff04aa84dd0..304c583b8000 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3768,6 +3768,24 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
}
EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
+/**
+ * drm_default_rgb_quant_range - default RGB quantization range
+ * @mode: display mode
+ *
+ * Determine the default RGB quantization range for the mode,
+ * as specified in CEA-861.
+ *
+ * Return: The default RGB quantization range for the mode
+ */
+enum hdmi_quantization_range
+drm_default_rgb_quant_range(const struct drm_display_mode *mode)
+{
+ return drm_match_cea_mode(mode) > 1 ?
+ HDMI_QUANTIZATION_RANGE_LIMITED :
+ HDMI_QUANTIZATION_RANGE_FULL;
+}
+EXPORT_SYMBOL(drm_default_rgb_quant_range);
+
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
const u8 *hdmi)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 343e1d9fa761..d4befbbe834a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1713,7 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
*/
pipe_config->limited_color_range =
- bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
+ bpp != 18 &&
+ drm_default_rgb_quant_range(adjusted_mode) ==
+ HDMI_QUANTIZATION_RANGE_LIMITED;
} else {
pipe_config->limited_color_range =
intel_dp->limited_color_range;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0bcfead14571..19bd13f53729 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1330,7 +1330,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
/* See CEA-861-E - 5.1 Default Encoding Parameters */
pipe_config->limited_color_range =
pipe_config->has_hdmi_sink &&
- drm_match_cea_mode(adjusted_mode) > 1;
+ drm_default_rgb_quant_range(adjusted_mode) ==
+ HDMI_QUANTIZATION_RANGE_LIMITED;
} else {
pipe_config->limited_color_range =
intel_hdmi->limited_color_range;
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c4cb2e26de32..5d49bf948162 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -463,7 +463,9 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder
*encoder,
csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
VC4_HD_CSC_CTL_ORDER);
- if (vc4_encoder->hdmi_monitor && drm_match_cea_mode(mode) > 1) {
+ if (vc4_encoder->hdmi_monitor &&
+ drm_default_rgb_quant_range(mode) ==
+ HDMI_QUANTIZATION_RANGE_LIMITED) {
/* CEA VICs other than #1 requre limited range RGB
* output unless overridden by an AVI infoframe.
* Apply a colorspace conversion to squash 0-255 down
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 838eaf2b42e9..25cdf5f7a0d8 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -441,6 +441,8 @@ enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8
video_code);
bool drm_detect_hdmi_monitor(struct edid *edid);
bool drm_detect_monitor_audio(struct edid *edid);
bool drm_rgb_quant_range_selectable(struct edid *edid);
+enum hdmi_quantization_range
+drm_default_rgb_quant_range(const struct drm_display_mode *mode);
int drm_add_modes_noedid(struct drm_connector *connector,
int hdisplay, int vdisplay);
void drm_set_preferred_mode(struct drm_connector *connector,
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99343] dEQP-GLES31.functional.shaders.builtin_functions.precision.{min, max}.highp_compute.scalar failures
https://bugs.freedesktop.org/show_bug.cgi?id=99343 --- Comment #1 from Marek Olšák --- Only VI can do FP32 denormals at full rate, which means only VI can enable them and not lose performance. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] drm: add fourcc codes for 16bit R and RG
On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote:
> Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
> >> From: Rainer Hochecker
> >>
> >> This adds fourcc codes for 16bit planes required for DRM buffer
> >> export to mesa.
> >>
> >> Signed-off-by: Rainer Hochecker
> > Reviewed-by: Ville Syrjälä
>
> Good to see some work landing on that part, patch is Acked-by: Christian
> König .
Has the userspace side of this been reviewed already?
/me wonders if it's safe to push this...
>
> >
> >> ---
> >> include/uapi/drm/drm_fourcc.h | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index a5890bf..d230e58 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -41,10 +41,17 @@ extern "C" {
> >> /* 8 bpp Red */
> >> #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /*
> >> [7:0] R */
> >>
> >> +/* 16 bpp Red */
> >> +#define DRM_FORMAT_R16fourcc_code('R', '1', '6', ' ') /*
> >> [15:0] R little endian */
> >> +
> >> /* 16 bpp RG */
> >> #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
> >> [15:0] R:G 8:8 little endian */
> >> #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
> >> [15:0] G:R 8:8 little endian */
> >>
> >> +/* 32 bpp RG */
> >> +#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
> >> 16:16 little endian */
> >> +#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> >> 16:16 little endian */
> >> +
> >> /* 8 bpp RGB */
> >> #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /*
> >> [7:0] R:G:B 3:3:2 */
> >> #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /*
> >> [7:0] B:G:R 2:3:3 */
> >> --
> >> 2.9.3
>
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code
On Wed, Jan 11, 2017 at 4:24 PM, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: >> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: >>> On 01/10/2017 02:31 AM, Daniel Vetter wrote: commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e Author: Daniel Vetter Date: Sun Dec 18 14:35:45 2016 +0100 drm: prevent double-(un)registration for connectors Lack of that would perfectly explain that oops ... Otherwise still no idea what's going wrong. >>> No... That's not in mainline as far as I can see. Should I test with >>> it applied? >> Hm, I guess failed to cc: stable that one properly, iirc we decided the >> race fix is too academic and can't be hit in reality ;-) >> >> Testing would be great. Probably conflicts because we extracted >> drm_connector.c only recently, but running s/drm_connector\.c/drm_crtc.c/ >> over the diff and then applying with some fudge should take care of that. > > It doesn't apply to mainline, with or without the substitution you suggest. > > Do you want that commit itself tested from -next? Hm, just cherry-picked it on top of Linus' latest 4.10 git, applies cleanly there. The substituation was for 4.9. I can send you the patch here, but seems all fine from what I can tell ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code
On Wed, Jan 11, 2017 at 07:24:45AM -0800, Dave Hansen wrote:
> On 01/10/2017 11:43 PM, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
> >> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
> >>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
> >>> Author: Daniel Vetter
> >>> Date: Sun Dec 18 14:35:45 2016 +0100
> >>>
> >>> drm: prevent double-(un)registration for connectors
> >>>
> >>> Lack of that would perfectly explain that oops ... Otherwise still no idea
> >>> what's going wrong.
> >> No... That's not in mainline as far as I can see. Should I test with
> >> it applied?
> > Hm, I guess failed to cc: stable that one properly, iirc we decided the
> > race fix is too academic and can't be hit in reality ;-)
> >
> > Testing would be great. Probably conflicts because we extracted
> > drm_connector.c only recently, but running s/drm_connector\.c/drm_crtc.c/
> > over the diff and then applying with some fudge should take care of that.
>
> It doesn't apply to mainline, with or without the substitution you suggest.
I was hoping that the locking was the real cause here and would be an
easy fix to apply. I did have a look at trying to reorder the DP-MST
worker with driver registration. Hacky to say the least.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
>From 30ac9092e934295f12775f03d73170fc480b7fc8 Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Tue, 10 Jan 2017 10:46:25 +
Subject: [PATCH] dp-mst-register
---
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 9 ++---
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f0f44cdbe4b4..fc10eb2c8563 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4762,7 +4762,17 @@ intel_dp_connector_register(struct drm_connector *connector)
intel_dp->aux.name, connector->kdev->kobj.name);
intel_dp->aux.dev = connector->kdev;
- return drm_dp_aux_register(&intel_dp->aux);
+ ret = drm_dp_aux_register(&intel_dp->aux);
+ if (ret)
+ return ret;
+
+ if (intel_dp->mst_mgr.cbs) {
+ intel_dp->can_mst = true;
+ if (intel_dp->attached_connector)
+ intel_dp->attached_connector->base.status = intel_dp_long_pulse(intel_dp->attached_connector);
+ }
+
+ return 0;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index c93c1999a494..f0a664041dbc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -582,16 +582,19 @@ intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int conn_ba
struct drm_device *dev = intel_dig_port->base.base.dev;
int ret;
- intel_dp->can_mst = true;
+ intel_dp->can_mst = false;
intel_dp->mst_mgr.cbs = &mst_cbs;
/* create encoders */
intel_dp_create_fake_mst_encoders(intel_dig_port);
- ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, dev->dev, &intel_dp->aux, 16, 3, conn_base_id);
+ ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, dev->dev,
+ &intel_dp->aux, 16, 3,
+ conn_base_id);
if (ret) {
- intel_dp->can_mst = false;
+ intel_dp->mst_mgr.cbs = NULL;
return ret;
}
+
return 0;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] drm: add fourcc codes for 16bit R and RG
On 17-01-11 17:05:04, Ville Syrjälä wrote:
On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote:
Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
>> From: Rainer Hochecker
>>
>> This adds fourcc codes for 16bit planes required for DRM buffer
>> export to mesa.
>>
>> Signed-off-by: Rainer Hochecker
> Reviewed-by: Ville Syrjälä
Good to see some work landing on that part, patch is Acked-by: Christian
König .
Has the userspace side of this been reviewed already?
/me wonders if it's safe to push this...
I acked the mesa side, and Rainer sent a version 2 which also looked fine to me.
Let me bump that thread...
>
>> ---
>> include/uapi/drm/drm_fourcc.h | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index a5890bf..d230e58 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -41,10 +41,17 @@ extern "C" {
>> /* 8 bpp Red */
>> #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /*
[7:0] R */
>>
>> +/* 16 bpp Red */
>> +#define DRM_FORMAT_R16fourcc_code('R', '1', '6', ' ') /*
[15:0] R little endian */
>> +
>> /* 16 bpp RG */
>> #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
>> #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
>>
>> +/* 32 bpp RG */
>> +#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
16:16 little endian */
>> +#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
>> +
>> /* 8 bpp RGB */
>> #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0]
R:G:B 3:3:2 */
>> #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0]
B:G:R 2:3:3 */
>> --
>> 2.9.3
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)
> -Original Message- > From: Michel Dänzer [mailto:mic...@daenzer.net] > Sent: Wednesday, January 11, 2017 3:33 AM > To: Daniel Vetter; Grodzovsky, Andrey > Cc: Deucher, Alexander; dri-devel@lists.freedesktop.org > Subject: Re: [PATCH] drm/atomic: Add target_vblank support in atomic > helpers (v2) > > On 09/01/17 06:59 PM, Daniel Vetter wrote: > > On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote: > >> Allows usage of the new page_flip_target hook for drivers > >> implementing the atomic path. > >> Provides default atomic helper for the new hook. > >> > >> v2: > >> Update code sharing logic between exsiting and the new flip hooks. > >> Improve kerneldoc. > >> > >> Signed-off-by: Andrey Grodzovsky > > > > Looks all reasonable, I think an ack from Alex that the amd side is in > > shape too, and I'll pull this into drm-misc. > > Andrey, is there an updated patch 2 adapted to current patch 1? Other than > that and some questionable indentation of parameters in function > signatures, looks good to me FWIW. We are unable to use the atomic helpers both for page_flip and page_flip_target At their current form mostly due to DRM_MODE_PAGE_FLIP_ASYNC flag rejection they do. I discussed this with Daniel Vetter on IRC and suggested to remove the rejection but he said the precise semantics of atomic async flip is not clear yet and it's better to leave that out for now until there is a userspace asking for it. So I tested it by just hacking the helper to remove the rejection. Until that settled the original change [PATCH 2/2] drm/amd/dal: Switch to page_flip_target hook in DAL Is what we plan to use in DAL Andrey > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:for-linux-next 1/4] htmldocs: drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No description found for parameter 'vm'
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: c781c978e784c50dcd7cb312fe17f5281923f55b commit: e007b19d7ba7424735fd4f17a355b145ae153e4c [1/4] drm/i915: Use the MRU stack search after evicting reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/drm/drm_drv.h:441: warning: No description found for parameter 'firstopen' include/drm/drm_drv.h:441: warning: No description found for parameter 'open' include/drm/drm_drv.h:441: warning: No description found for parameter 'preclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'postclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'lastclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_ioctl' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_quiescent' include/drm/drm_drv.h:441: warning: No description found for parameter 'context_dtor' include/drm/drm_drv.h:441: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_handler' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_preinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_postinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_uninstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_cleanup' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'vgaarb_irq' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:441: warning: No description found for parameter 'major' include/drm/drm_drv.h:441: warning: No description found for parameter 'minor' include/drm/drm_drv.h:441: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:441: warning: No description found for parameter 'name' include/drm/drm_drv.h:441: warning: No description found for parameter 'desc' include/drm/drm_drv.h:441: warning: No description found for parameter 'date' include/drm/drm_drv.h:441: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:441: warning: No description found for parameter 'dev_priv_size' include/drm/drm_drv.h:441: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'fops' include/drm/drm_drv.h:441: warning: No description found for parameter 'legacy_dev_list' >> drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No description found for >> parameter 'vm' >> drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No description found for >> parameter 'node' >> drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No description found for >> parameter 'size' >> drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No description found for >> parameter 'alignment' >> drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No descri
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix POWER_DOMAIN_AUDIO refcounting.
On Thu, Dec 15, 2016 at 03:29:43PM +0100, Maarten Lankhorst wrote:
> If the crtc was brought up with audio before the driver loads,
> then crtc_disable will remove a refcount to audio that doesn't exist
> before.
>
> Fortunately we already set power domains on readout, so we can just add
> the power domain handling to get_crtc_power_domains, which will update
> the power domains correctly in all cases.
>
> This was found when testing module reload on CI with the crtc enabled,
> which resulted in the following warn after module reload + modeset:
>
> [ 24.197041] [ cut here ]
> [ 24.197075] WARNING: CPU: 0 PID: 99 at
> drivers/gpu/drm/i915/intel_runtime_pm.c:1790
> intel_display_power_put+0x134/0x140 [i915]
> [ 24.197076] Use count on domain AUDIO is already zero
> [ 24.197098] CPU: 0 PID: 99 Comm: kworker/u8:2 Not tainted
> 4.9.0-CI-Trybot_393+ #1
> [ 24.197099] Hardware name: /NUC6i5SYB, BIOS
> SYSKLi35.86A.0042.2016.0409.1246 04/09/2016
> [ 24.197102] Workqueue: events_unbound async_run_entry_fn
> [ 24.197105] c93c7688 81435b35 c93c76d8
>
> [ 24.197107] c93c76c8 8107e4d6 06fe5dc36f28
> 88025dc30054
> [ 24.197109] 88025dc36f28 88025dc3 88025dc3
> 0015
> [ 24.197110] Call Trace:
> [ 24.197113] [] dump_stack+0x67/0x92
> [ 24.197116] [] __warn+0xc6/0xe0
> [ 24.197118] [] warn_slowpath_fmt+0x4a/0x50
> [ 24.197149] [] intel_display_power_put+0x134/0x140
> [i915]
> [ 24.197187] [] intel_disable_ddi+0x4d/0x80 [i915]
> [ 24.197223] [] intel_encoders_disable.isra.74+0x7f/0x90
> [i915]
> [ 24.197257] [] haswell_crtc_disable+0x55/0x170 [i915]
> [ 24.197292] [] intel_atomic_commit_tail+0x108/0xfd0
> [i915]
> [ 24.197295] [] ? __lock_is_held+0x66/0x90
> [ 24.197330] [] intel_atomic_commit+0x429/0x560 [i915]
> [ 24.197332] []
> ?drm_atomic_add_affected_connectors+0x56/0xf0
> [ 24.197334] [] drm_atomic_commit+0x46/0x50
> [ 24.197336] [] restore_fbdev_mode+0x147/0x270
> [ 24.197337] []
> drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
> [ 24.197339] [] drm_fb_helper_set_par+0x28/0x50
> [ 24.197374] [] intel_fbdev_set_par+0x13/0x70 [i915]
> [ 24.197376] [] fbcon_init+0x57a/0x600
> [ 24.197379] [] visual_init+0xd1/0x130
> [ 24.197381] [] do_bind_con_driver+0x1bc/0x3a0
> [ 24.197384] [] do_take_over_console+0x111/0x180
> [ 24.197386] [] do_fbcon_takeover+0x52/0xb0
> [ 24.197387] [] fbcon_event_notify+0x723/0x850
> [ 24.197390] [] ?__blocking_notifier_call_chain+0x30/0x70
> [ 24.197392] [] notifier_call_chain+0x34/0xa0
> [ 24.197394] [] __blocking_notifier_call_chain+0x48/0x70
> [ 24.197397] [] blocking_notifier_call_chain+0x11/0x20
> [ 24.197398] [] fb_notifier_call_chain+0x16/0x20
> [ 24.197400] [] register_framebuffer+0x24c/0x330
> [ 24.197402] [] drm_fb_helper_initial_config+0x219/0x3c0
> [ 24.197436] [] intel_fbdev_initial_config+0x13/0x30
> [i915]
> [ 24.197438] [] async_run_entry_fn+0x34/0x140
> [ 24.197440] [] process_one_work+0x1ec/0x6b0
> [ 24.197442] [] ? process_one_work+0x166/0x6b0
> [ 24.197445] [] worker_thread+0x49/0x490
> [ 24.197447] [] ? process_one_work+0x6b0/0x6b0
> [ 24.197448] [] kthread+0xeb/0x110
> [ 24.197451] [] ? kthread_park+0x60/0x60
> [ 24.197453] [] ret_from_fork+0x27/0x40
> [ 24.197476] ---[ end trace bda64b683b8e8162 ]---
>
> Signed-off-by: Maarten Lankhorst
Do we still need this with patch 3? I know it'd be nice if we could
faithfully restore any state we can also program, but then that's also a
lot of complexity ...
Otoh patch 3 means we'll stop testing a lot of the fastboot code while
reloading the driver. But then that's been the thing in the past, and as
long as we still boot up we have at least some test coverage fo the
fastboot code (I'm mostly concerned about the plane/buffer readout code,
since that's not covered by the state checker).
But for now I'd say let's just go with patch 3 only.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 14 ++
> drivers/gpu/drm/i915/intel_display.c | 4
> drivers/gpu/drm/i915/intel_dp_mst.c | 9 ++---
> 3 files changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index d808a2ccc29e..8c9ce850760b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1835,8 +1835,6 @@ static void intel_enable_ddi(struct intel_encoder
> *intel_encoder,
>struct drm_connector_state *conn_state)
> {
> struct drm_encoder *encoder = &intel_encoder->base;
> - struct drm_crtc *crtc = encoder->crtc;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> enum port port = intel_ddi_get_encoder_port(intel_encoder);
>
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Disable all crtcs during driver unload.
On Thu, Dec 15, 2016 at 03:29:44PM +0100, Maarten Lankhorst wrote: > We may keep the crtc's enabled when userspace unsets all framebuffers but > keeps the crtc active. This exposes a WARN in fbc_global disable, and > a lot of bugs in our hardware readout code. Solve this by disabling > all crtc's for now. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/i915_drv.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 6428588518aa..bb0d7517b678 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -43,6 +43,7 @@ > > #include > #include > +#include > #include > > #include "i915_drv.h" > @@ -1282,6 +1283,10 @@ void i915_driver_unload(struct drm_device *dev) > > intel_display_power_get(dev_priv, POWER_DOMAIN_INIT); > > + drm_modeset_lock_all(dev); > + drm_atomic_helper_disable_all(dev, dev->mode_config.acquire_ctx); > + drm_modeset_unlock_all(dev); Bikeshed: I think we should phase out lock_all and do an explicit acquire context here. And maybe get a bit better at refactoring the boilerplate that brings along. But also as-is: Reviewed-by: Daniel Vetter > + > i915_driver_unregister(dev_priv); > > drm_vblank_cleanup(dev); > -- > 2.7.4 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: Resurrect atomic rmfb code, v2
On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote:
> From: Daniel Vetter
>
> This was somehow lost between v3 and the merged version in Maarten's
> patch merged as:
>
> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> Author: Maarten Lankhorst
> Date: Wed May 4 14:38:26 2016 +0200
>
> drm/core: Do not preserve framebuffer on rmfb, v4.
>
> Actual code copied from Maarten's patch, but with the slight change to
> just use dev->mode_config.funcs->atomic_commit to decide whether to
> use the atomic path or not.
>
> v2:
> - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
> - Add WARN_ON when atomic_remove_fb fails.
> - Always call drm_atomic_state_put.
>
> Signed-off-by: Daniel Vetter
> Signed-off-by: Daniel Vetter
> Signed-off-by: Maarten Lankhorst
Would be great if someone else could r-b this, I've proven pretty well
that I don't understand the complexity here :(
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 64
> +
> drivers/gpu/drm/drm_crtc_internal.h | 1 +
> drivers/gpu/drm/drm_framebuffer.c | 7
> 3 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d1d252261bf1..23a3845542e1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2059,6 +2059,70 @@ static void complete_crtc_signaling(struct drm_device
> *dev,
> kfree(fence_state);
> }
>
> +int drm_atomic_remove_fb(struct drm_framebuffer *fb)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_device *dev = fb->dev;
> + struct drm_atomic_state *state;
> + struct drm_plane *plane;
> + int ret = 0;
> + unsigned plane_mask;
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state)
> + return -ENOMEM;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> + state->acquire_ctx = &ctx;
> +
> +retry:
> + plane_mask = 0;
> + ret = drm_modeset_lock_all_ctx(dev, &ctx);
> + if (ret)
> + goto unlock;
> +
> + drm_for_each_plane(plane, dev) {
> + struct drm_plane_state *plane_state;
> +
> + if (plane->state->fb != fb)
> + continue;
> +
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state)) {
> + ret = PTR_ERR(plane_state);
> + goto unlock;
> + }
> +
> + drm_atomic_set_fb_for_plane(plane_state, NULL);
> + ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> + if (ret)
> + goto unlock;
> +
> + plane_mask |= BIT(drm_plane_index(plane));
> +
> + plane->old_fb = plane->fb;
> + }
> +
> + if (plane_mask)
> + ret = drm_atomic_commit(state);
> +
> +unlock:
> + if (plane_mask)
> + drm_atomic_clean_old_fb(dev, plane_mask, ret);
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + }
> +
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> + return ret;
> +}
> +
> int drm_mode_atomic_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv)
> {
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index cdf6860c9d22..121e250853d2 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -178,6 +178,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
> struct drm_property *property, uint64_t *val);
> int drm_mode_atomic_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> +int drm_atomic_remove_fb(struct drm_framebuffer *fb);
>
>
> /* drm_plane.c */
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index cbf0c893f426..c358bf8280a8 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -770,6 +770,12 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>* in this manner.
>*/
> if (drm_framebuffer_read_refcount(fb) > 1) {
> + if (dev->mode_config.funcs->atomic_commit) {
> + int ret = drm_atomic_remove_fb(fb);
> + WARN(ret, "atomic remove_fb failed with %i\n", ret);
> + goto out;
> + }
> +
> drm_modeset_lock_all(dev);
> /* remove from any CRTC */
> drm_for_each_crtc(crtc, dev) {
> @@ -787,6 +793,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
> drm_modeset_unlock_all(dev);
> }
>
> +out:
> drm_framebuffer_unreference(fb);
> }
> EXPORT_SYMBOL(drm_framebuffer_remove);
> --
> 2.7.4
>
--
Daniel Vetter
Software Engin
Re: [Intel-gfx] [PATCH 2/5] drm/edid: Introduce drm_default_rgb_quant_range()
On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the code selecting the RGB quantization range a little less magicy
> by wrapping it up in a small helper.
>
> Signed-off-by: Ville Syrjälä
Needs cc: for driver maintainers, Eric for vc4 here.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c| 18 ++
> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 4 +++-
> include/drm/drm_edid.h| 2 ++
> 5 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 4ff04aa84dd0..304c583b8000 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3768,6 +3768,24 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
> }
> EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
>
> +/**
> + * drm_default_rgb_quant_range - default RGB quantization range
> + * @mode: display mode
> + *
> + * Determine the default RGB quantization range for the mode,
> + * as specified in CEA-861.
> + *
> + * Return: The default RGB quantization range for the mode
> + */
> +enum hdmi_quantization_range
> +drm_default_rgb_quant_range(const struct drm_display_mode *mode)
> +{
> + return drm_match_cea_mode(mode) > 1 ?
> + HDMI_QUANTIZATION_RANGE_LIMITED :
> + HDMI_QUANTIZATION_RANGE_FULL;
> +}
> +EXPORT_SYMBOL(drm_default_rgb_quant_range);
> +
> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> const u8 *hdmi)
> {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 343e1d9fa761..d4befbbe834a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1713,7 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
>*/
> pipe_config->limited_color_range =
> - bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> + bpp != 18 &&
> + drm_default_rgb_quant_range(adjusted_mode) ==
> + HDMI_QUANTIZATION_RANGE_LIMITED;
> } else {
> pipe_config->limited_color_range =
> intel_dp->limited_color_range;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 0bcfead14571..19bd13f53729 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1330,7 +1330,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
> *encoder,
> /* See CEA-861-E - 5.1 Default Encoding Parameters */
> pipe_config->limited_color_range =
> pipe_config->has_hdmi_sink &&
> - drm_match_cea_mode(adjusted_mode) > 1;
> + drm_default_rgb_quant_range(adjusted_mode) ==
> + HDMI_QUANTIZATION_RANGE_LIMITED;
> } else {
> pipe_config->limited_color_range =
> intel_hdmi->limited_color_range;
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index c4cb2e26de32..d79466a42690 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -463,7 +463,9 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder
> *encoder,
> csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
> VC4_HD_CSC_CTL_ORDER);
>
> - if (vc4_encoder->hdmi_monitor && drm_match_cea_mode(mode) > 1) {
> + if (vc4_encoder->hdmi_monitor &&
> + drm_default_rgb_quant_range(adjusted_mode) ==
> + HDMI_QUANTIZATION_RANGE_LIMITED) {
> /* CEA VICs other than #1 requre limited range RGB
>* output unless overridden by an AVI infoframe.
>* Apply a colorspace conversion to squash 0-255 down
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 838eaf2b42e9..25cdf5f7a0d8 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -441,6 +441,8 @@ enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const
> u8 video_code);
> bool drm_detect_hdmi_monitor(struct edid *edid);
> bool drm_detect_monitor_audio(struct edid *edid);
> bool drm_rgb_quant_range_selectable(struct edid *edid);
> +enum hdmi_quantization_range
> +drm_default_rgb_quant_range(const struct drm_display_mode *mode);
> int drm_add_modes_noedid(struct drm_connector *connector,
>int hdisplay, int vdisplay);
> void drm_set_preferred_mode(struct drm_connector *connector,
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Softwa
Re: [PATCH 2/2] drm: add more MMU dependencies
On Wed, Jan 11, 2017 at 03:02:39PM +0100, Lucas Stach wrote:
> Am Mittwoch, den 11.01.2017, 14:33 +0100 schrieb Arnd Bergmann:
> > Many DRM drivers only work with an MMU, and after the patch to enable
> > core DRM support without MMU, we already had one fixup for many of them.
> > The etnaviv, armada and msm drivers were missed and have the same problem:
> >
> > warning: (DRM_ETNAVIV) selects IOMMU_SUPPORT which has unmet direct
> > dependencies (MMU)
> > warning: (DRM_I915 && DRM_MSM && DRM_ETNAVIV) selects SHMEM which has unmet
> > direct dependencies (MMU)
> > drivers/gpu/drm/armada/armada_gem.o: In function `armada_gem_vm_fault':
> > armada_gem.c:(.text.armada_gem_vm_fault+0x14): undefined reference to
> > `vm_insert_pfn'
> > arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap':
> > arch/arm/mm/dma-mapping.c:1390:4: error: 'VM_ARM_DMA_CONSISTENT' undeclared
> > (first use in this function)
> > arch/arm/mm/dma-mapping.c:1456:31: error: 'atomic_pool' undeclared (first
> > use in this function); did you mean 'atomic_xor'?
> >
> > Fixes: 011cda589938 ("drm: fix compilations issues introduced by "drm:
> > allow to use mmuless SoC"")
> > Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
> > Signed-off-by: Arnd Bergmann
>
> Acked-by: Lucas Stach
Applied to drm-misc, thanks.
-Daniel
>
> > ---
> > drivers/gpu/drm/armada/Kconfig | 2 +-
> > drivers/gpu/drm/etnaviv/Kconfig | 1 +
> > drivers/gpu/drm/msm/Kconfig | 1 +
> > 3 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
> > index 15f3ecfb16f1..eafaeeb7b5b1 100644
> > --- a/drivers/gpu/drm/armada/Kconfig
> > +++ b/drivers/gpu/drm/armada/Kconfig
> > @@ -1,6 +1,6 @@
> > config DRM_ARMADA
> > tristate "DRM support for Marvell Armada SoCs"
> > - depends on DRM && HAVE_CLK && ARM
> > + depends on DRM && HAVE_CLK && ARM && MMU
> > select DRM_KMS_HELPER
> > help
> > Support the "LCD" controllers found on the Marvell Armada 510
> > diff --git a/drivers/gpu/drm/etnaviv/Kconfig
> > b/drivers/gpu/drm/etnaviv/Kconfig
> > index 2cde7a5442fb..656c061b439d 100644
> > --- a/drivers/gpu/drm/etnaviv/Kconfig
> > +++ b/drivers/gpu/drm/etnaviv/Kconfig
> > @@ -3,6 +3,7 @@ config DRM_ETNAVIV
> > tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> > depends on DRM
> > depends on ARCH_MXC || ARCH_DOVE
> > + depends on MMU
> > select SHMEM
> > select TMPFS
> > select IOMMU_API
> > diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> > index d96b2b6898a3..7f78da695dff 100644
> > --- a/drivers/gpu/drm/msm/Kconfig
> > +++ b/drivers/gpu/drm/msm/Kconfig
> > @@ -4,6 +4,7 @@ config DRM_MSM
> > depends on DRM
> > depends on ARCH_QCOM || (ARM && COMPILE_TEST)
> > depends on OF && COMMON_CLK
> > + depends on MMU
> > select REGULATOR
> > select DRM_KMS_HELPER
> > select DRM_PANEL
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds
On Wed, Jan 11, 2017 at 02:33:34PM +0100, Arnd Bergmann wrote:
> When building DRM without an MMU, we run into a compile-time error because
> pte_wrprotect() is not defined:
>
> drivers/gpu/drm/drm_vm.c: In function 'drm_mmap_dma':
> drivers/gpu/drm/drm_vm.c:496:9: error: implicit declaration of function
> 'pte_wrprotect' [-Werror=implicit-function-declaration]
>
> The line is not meaningful here, so we can simply add another
> compile-time check around it.
>
> Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
> Signed-off-by: Arnd Bergmann
We don't need drm_vm.c on modern drivers, and the idea was to simply not
compile it when not needed. See:
commit 99c48e1e38f0aeaa107ad67c8d91f6c9d9d567a9
Author: Benjamin Gaignard
Date: Wed Jan 4 10:12:56 2017 +0100
drm: compile drm_vm.c only when needed
How did you manage to enable this stuff?
-Daniel
> ---
> drivers/gpu/drm/drm_vm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index bd311c77c254..038946588ed7 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -488,7 +488,7 @@ static int drm_mmap_dma(struct file *filp, struct
> vm_area_struct *vma)
> vma->vm_flags &= ~(VM_WRITE | VM_MAYWRITE);
> #if defined(__i386__) || defined(__x86_64__)
> pgprot_val(vma->vm_page_prot) &= ~_PAGE_RW;
> -#else
> +#elif IS_ENABLED(CONFIG_MMU)
> /* Ye gads this is ugly. With more thought
> we could move this up higher and use
> `protection_map' instead. */
> @@ -572,7 +572,7 @@ static int drm_mmap_locked(struct file *filp, struct
> vm_area_struct *vma)
> vma->vm_flags &= ~(VM_WRITE | VM_MAYWRITE);
> #if defined(__i386__) || defined(__x86_64__)
> pgprot_val(vma->vm_page_prot) &= ~_PAGE_RW;
> -#else
> +#elif defined (CONFIG_MMU)
> /* Ye gads this is ugly. With more thought
> we could move this up higher and use
> `protection_map' instead. */
> --
> 2.9.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] drm/edid: Introduce drm_default_rgb_quant_range()
On Wed, Jan 11, 2017 at 05:16:54PM +0100, Daniel Vetter wrote:
> On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make the code selecting the RGB quantization range a little less magicy
> > by wrapping it up in a small helper.
> >
> > Signed-off-by: Ville Syrjälä
>
> Needs cc: for driver maintainers, Eric for vc4 here.
Eric was cc:d. I was just too lazy to add the cc:s to all the commit
messages, and so i just used --cc on the whole lot.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_edid.c| 18 ++
> > drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
> > drivers/gpu/drm/vc4/vc4_hdmi.c| 4 +++-
> > include/drm/drm_edid.h| 2 ++
> > 5 files changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 4ff04aa84dd0..304c583b8000 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3768,6 +3768,24 @@ bool drm_rgb_quant_range_selectable(struct edid
> > *edid)
> > }
> > EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
> >
> > +/**
> > + * drm_default_rgb_quant_range - default RGB quantization range
> > + * @mode: display mode
> > + *
> > + * Determine the default RGB quantization range for the mode,
> > + * as specified in CEA-861.
> > + *
> > + * Return: The default RGB quantization range for the mode
> > + */
> > +enum hdmi_quantization_range
> > +drm_default_rgb_quant_range(const struct drm_display_mode *mode)
> > +{
> > + return drm_match_cea_mode(mode) > 1 ?
> > + HDMI_QUANTIZATION_RANGE_LIMITED :
> > + HDMI_QUANTIZATION_RANGE_FULL;
> > +}
> > +EXPORT_SYMBOL(drm_default_rgb_quant_range);
> > +
> > static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> >const u8 *hdmi)
> > {
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 343e1d9fa761..d4befbbe834a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1713,7 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> > * VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
> > */
> > pipe_config->limited_color_range =
> > - bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> > + bpp != 18 &&
> > + drm_default_rgb_quant_range(adjusted_mode) ==
> > + HDMI_QUANTIZATION_RANGE_LIMITED;
> > } else {
> > pipe_config->limited_color_range =
> > intel_dp->limited_color_range;
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 0bcfead14571..19bd13f53729 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1330,7 +1330,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
> > *encoder,
> > /* See CEA-861-E - 5.1 Default Encoding Parameters */
> > pipe_config->limited_color_range =
> > pipe_config->has_hdmi_sink &&
> > - drm_match_cea_mode(adjusted_mode) > 1;
> > + drm_default_rgb_quant_range(adjusted_mode) ==
> > + HDMI_QUANTIZATION_RANGE_LIMITED;
> > } else {
> > pipe_config->limited_color_range =
> > intel_hdmi->limited_color_range;
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index c4cb2e26de32..d79466a42690 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -463,7 +463,9 @@ static void vc4_hdmi_encoder_mode_set(struct
> > drm_encoder *encoder,
> > csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
> > VC4_HD_CSC_CTL_ORDER);
> >
> > - if (vc4_encoder->hdmi_monitor && drm_match_cea_mode(mode) > 1) {
> > + if (vc4_encoder->hdmi_monitor &&
> > + drm_default_rgb_quant_range(adjusted_mode) ==
> > + HDMI_QUANTIZATION_RANGE_LIMITED) {
> > /* CEA VICs other than #1 requre limited range RGB
> > * output unless overridden by an AVI infoframe.
> > * Apply a colorspace conversion to squash 0-255 down
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 838eaf2b42e9..25cdf5f7a0d8 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -441,6 +441,8 @@ enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const
> > u8 video_code);
> > bool drm_detect_hdmi_monitor(struct edid *edid);
> > bool drm_detect_monitor_audio(struct edid *edid);
> > bool drm_rgb_quant_range_selectable(struct edid *edid);
> > +enum hdmi_quantization_range
> > +drm_default_rgb_quant_range(const struct drm_display_mode *mode);
> > int drm_add_modes_noedid(struct drm_conne
Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds
On Wednesday, January 11, 2017 5:27:13 PM CET Daniel Vetter wrote:
> On Wed, Jan 11, 2017 at 02:33:34PM +0100, Arnd Bergmann wrote:
> > When building DRM without an MMU, we run into a compile-time error because
> > pte_wrprotect() is not defined:
> >
> > drivers/gpu/drm/drm_vm.c: In function 'drm_mmap_dma':
> > drivers/gpu/drm/drm_vm.c:496:9: error: implicit declaration of function
> > 'pte_wrprotect' [-Werror=implicit-function-declaration]
> >
> > The line is not meaningful here, so we can simply add another
> > compile-time check around it.
> >
> > Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
> > Signed-off-by: Arnd Bergmann
>
> We don't need drm_vm.c on modern drivers, and the idea was to simply not
> compile it when not needed. See:
>
> commit 99c48e1e38f0aeaa107ad67c8d91f6c9d9d567a9
> Author: Benjamin Gaignard
> Date: Wed Jan 4 10:12:56 2017 +0100
>
> drm: compile drm_vm.c only when needed
>
>
> How did you manage to enable this stuff?
> -Daniel
This was a randconfig build, the DRM specific symbols here are
CONFIG_DRM=y
CONFIG_DRM_MIPI_DSI=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_MM_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
# CONFIG_DRM_FBDEV_EMULATION is not set
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
CONFIG_DRM_VM=y
#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
CONFIG_DRM_I2C_SIL164=y
# CONFIG_DRM_I2C_NXP_TDA998X is not set
CONFIG_DRM_ARM=y
CONFIG_DRM_HDLCD=y
CONFIG_DRM_HDLCD_SHOW_UNDERRUN=y
# CONFIG_DRM_MALI_DISPLAY is not set
#
# ACP (Audio CoProcessor) Configuration
#
CONFIG_DRM_VGEM=y
CONFIG_DRM_ROCKCHIP=y
CONFIG_ROCKCHIP_ANALOGIX_DP=y
CONFIG_ROCKCHIP_DW_HDMI=m
CONFIG_ROCKCHIP_DW_MIPI_DSI=y
CONFIG_ROCKCHIP_INNO_HDMI=m
# CONFIG_DRM_UDL is not set
CONFIG_DRM_ARMADA=y
CONFIG_DRM_ATMEL_HLCDC=m
CONFIG_DRM_RCAR_DU=y
# CONFIG_DRM_RCAR_HDMI is not set
CONFIG_DRM_RCAR_LVDS=y
# CONFIG_DRM_SHMOBILE is not set
CONFIG_DRM_SUN4I=y
CONFIG_DRM_TILCDC=m
CONFIG_DRM_TILCDC_SLAVE_COMPAT=y
CONFIG_DRM_MSM=y
CONFIG_DRM_MSM_REGISTER_LOGGING=y
CONFIG_DRM_MSM_HDMI_HDCP=y
CONFIG_DRM_MSM_DSI=y
# CONFIG_DRM_MSM_DSI_PLL is not set
# CONFIG_DRM_MSM_DSI_28NM_PHY is not set
# CONFIG_DRM_MSM_DSI_20NM_PHY is not set
CONFIG_DRM_MSM_DSI_28NM_8960_PHY=y
# CONFIG_DRM_FSL_DCU is not set
# CONFIG_DRM_TEGRA is not set
CONFIG_DRM_PANEL=y
#
# Display Panels
#
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_PANEL_JDI_LT070ME05000=m
CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00=m
# CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0 is not set
# CONFIG_DRM_PANEL_SHARP_LQ101R1SX01 is not set
# CONFIG_DRM_PANEL_SHARP_LS043T1LE01 is not set
CONFIG_DRM_BRIDGE=y
#
# Display Interface Bridges
#
CONFIG_DRM_ANALOGIX_ANX78XX=y
CONFIG_DRM_DUMB_VGA_DAC=m
CONFIG_DRM_DW_HDMI=m
CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
# CONFIG_DRM_NXP_PTN3460 is not set
CONFIG_DRM_PARADE_PS8622=m
# CONFIG_DRM_SIL_SII8620 is not set
# CONFIG_DRM_SII902X is not set
# CONFIG_DRM_TOSHIBA_TC358767 is not set
CONFIG_DRM_TI_TFP410=y
CONFIG_DRM_ANALOGIX_DP=y
# CONFIG_DRM_I2C_ADV7511 is not set
CONFIG_DRM_VC4=m
CONFIG_DRM_ETNAVIV=m
# CONFIG_DRM_ETNAVIV_REGISTER_LOGGING is not set
CONFIG_DRM_ARCPGU=m
CONFIG_DRM_MXS=y
CONFIG_DRM_MXSFB=m
CONFIG_DRM_MESON=y
CONFIG_DRM_LEGACY=y
# CONFIG_DRM_LIB_RANDOM is not set
No idea what did it in the end.
I also have some older build fixes applied, so it may be something that
happens on my tree but not on plain linux-next.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds
On Wed, Jan 11, 2017 at 5:33 PM, Arnd Bergmann wrote:
> On Wednesday, January 11, 2017 5:27:13 PM CET Daniel Vetter wrote:
>> On Wed, Jan 11, 2017 at 02:33:34PM +0100, Arnd Bergmann wrote:
>> > When building DRM without an MMU, we run into a compile-time error because
>> > pte_wrprotect() is not defined:
>> >
>> > drivers/gpu/drm/drm_vm.c: In function 'drm_mmap_dma':
>> > drivers/gpu/drm/drm_vm.c:496:9: error: implicit declaration of function
>> > 'pte_wrprotect' [-Werror=implicit-function-declaration]
>> >
>> > The line is not meaningful here, so we can simply add another
>> > compile-time check around it.
>> >
>> > Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
>> > Signed-off-by: Arnd Bergmann
>>
>> We don't need drm_vm.c on modern drivers, and the idea was to simply not
>> compile it when not needed. See:
>>
>> commit 99c48e1e38f0aeaa107ad67c8d91f6c9d9d567a9
>> Author: Benjamin Gaignard
>> Date: Wed Jan 4 10:12:56 2017 +0100
>>
>> drm: compile drm_vm.c only when needed
>>
>>
>> How did you manage to enable this stuff?
>> -Daniel
>
> This was a randconfig build, the DRM specific symbols here are
>
> CONFIG_DRM=y
> CONFIG_DRM_MIPI_DSI=y
> # CONFIG_DRM_DP_AUX_CHARDEV is not set
> # CONFIG_DRM_DEBUG_MM is not set
> # CONFIG_DRM_DEBUG_MM_SELFTEST is not set
> CONFIG_DRM_KMS_HELPER=y
> CONFIG_DRM_KMS_FB_HELPER=y
> # CONFIG_DRM_FBDEV_EMULATION is not set
> CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> CONFIG_DRM_GEM_CMA_HELPER=y
> CONFIG_DRM_KMS_CMA_HELPER=y
> CONFIG_DRM_VM=y
Does randconfig just set this for fun, despite that it's a hidden
Kconfig symbol? Should we add a depends !NOMMU to it to make sure it
never gets enabled when it shouldn't be?
tbh I have no idea how Kconfig works, I'm just really good at breaking it :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] drm: add fourcc codes for 16bit R and RG
On Wed, Jan 11, 2017 at 07:44:05AM -0800, Ben Widawsky wrote:
> On 17-01-11 17:05:04, Ville Syrjälä wrote:
> >On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote:
> >> Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> >> > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
> >> >> From: Rainer Hochecker
> >> >>
> >> >> This adds fourcc codes for 16bit planes required for DRM buffer
> >> >> export to mesa.
> >> >>
> >> >> Signed-off-by: Rainer Hochecker
> >> > Reviewed-by: Ville Syrjälä
> >>
> >> Good to see some work landing on that part, patch is Acked-by: Christian
> >> König .
> >
> >Has the userspace side of this been reviewed already?
> >
> >/me wonders if it's safe to push this...
> >
>
> I acked the mesa side, and Rainer sent a version 2 which also looked fine to
> me.
> Let me bump that thread...
Thanks everyone. I've pushed this patch to drm-misc-next.
>
> >>
> >> >
> >> >> ---
> >> >> include/uapi/drm/drm_fourcc.h | 7 +++
> >> >> 1 file changed, 7 insertions(+)
> >> >>
> >> >> diff --git a/include/uapi/drm/drm_fourcc.h
> >> >> b/include/uapi/drm/drm_fourcc.h
> >> >> index a5890bf..d230e58 100644
> >> >> --- a/include/uapi/drm/drm_fourcc.h
> >> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> >> @@ -41,10 +41,17 @@ extern "C" {
> >> >> /* 8 bpp Red */
> >> >> #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /*
> >> >> [7:0] R */
> >> >>
> >> >> +/* 16 bpp Red */
> >> >> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> >> >> [15:0] R little endian */
> >> >> +
> >> >> /* 16 bpp RG */
> >> >> #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8')
> >> >> /* [15:0] R:G 8:8 little endian */
> >> >> #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8')
> >> >> /* [15:0] G:R 8:8 little endian */
> >> >>
> >> >> +/* 32 bpp RG */
> >> >> +#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /*
> >> >> [31:0] R:G 16:16 little endian */
> >> >> +#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /*
> >> >> [31:0] G:R 16:16 little endian */
> >> >> +
> >> >> /* 8 bpp RGB */
> >> >> #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /*
> >> >> [7:0] R:G:B 3:3:2 */
> >> >> #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /*
> >> >> [7:0] B:G:R 2:3:3 */
> >> >> --
> >> >> 2.9.3
> >>
> >
> >--
> >Ville Syrjälä
> >Intel OTC
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds
On Wed, Jan 11, 2017 at 5:36 PM, Daniel Vetter wrote: > On Wed, Jan 11, 2017 at 5:33 PM, Arnd Bergmann wrote: >> CONFIG_DRM_VM=y > > Does randconfig just set this for fun, despite that it's a hidden > Kconfig symbol? Should we add a depends !NOMMU to it to make sure it > never gets enabled when it shouldn't be? > > tbh I have no idea how Kconfig works, I'm just really good at breaking it :( no, randconfig won't try to set symbols that a user doesn't see. This is what 'menuconfig' says enabled it. │ Selected by: DRM_NOUVEAU [=n] && HAS_IOMEM [=y] && DRM [=y] && PCI [=n] && MMU [=n] && (BACKLIGHT_CLASS_DEVICE [=m] || !ACPI) || DRM_LEGACY [=y] && HAS_IOMEM [=y] && DRM [=y] It must be the 'DRM_LEGACY' option that is actually user visible and that contains 'select DRM_VM'. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: fix drm_vm for NOMMU builds
2017-01-11 17:59 GMT+01:00 Arnd Bergmann : > On Wed, Jan 11, 2017 at 5:36 PM, Daniel Vetter wrote: >> On Wed, Jan 11, 2017 at 5:33 PM, Arnd Bergmann wrote: >>> CONFIG_DRM_VM=y >> >> Does randconfig just set this for fun, despite that it's a hidden >> Kconfig symbol? Should we add a depends !NOMMU to it to make sure it >> never gets enabled when it shouldn't be? >> >> tbh I have no idea how Kconfig works, I'm just really good at breaking it :( > > no, randconfig won't try to set symbols that a user doesn't see. This > is what 'menuconfig' > says enabled it. > > │ Selected by: DRM_NOUVEAU [=n] && HAS_IOMEM [=y] && DRM [=y] && > PCI [=n] && MMU [=n] && (BACKLIGHT_CLASS_DEVICE [=m] || !ACPI) || > DRM_LEGACY [=y] && HAS_IOMEM [=y] && DRM [=y] > > It must be the 'DRM_LEGACY' option that is actually user visible and > that contains > 'select DRM_VM'. We should add "MMU" on DRM_LEGACY and DRM_VM dependencies to be sure that they won't be select without MMU support > > Arnd -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix broken VT switch with video=1366x768 option
On Tue, Jan 10, 2017 at 01:41:42PM +0100, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 12:36:50PM +0100, Takashi Iwai wrote:
> > On Tue, 10 Jan 2017 12:28:36 +0100,
> > Ville Syrjälä wrote:
> > >
> > > On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > > > I noticed that the VT switch doesn't work any longer with a Dell
> > > > laptop with 1366x768 eDP when the machine is connected with a DP
> > > > monitor. It behaves as if VT were switched, but the graphics remain
> > > > frozen. Actually the keyboard works, so I could switch back to VT7
> > > > again.
> > > >
> > > > I tried to track down the problem, and encountered a long story until
> > > > we reach to this error:
> > > >
> > > > - The machine is booted with video=1366x768 option (the distro
> > > > installer seems to add it as default).
> > > > - Recently, drm_helper_probe_single_connector_modes() deals with
> > > > cmdline modes, and it tries to create a new mode when no
> > > > matching mode is found.
> > > > - The drm_mode_create_from_cmdline_mode() creates a mode based on
> > > > either CVT of GFT according to the given cmdline mode; in our case,
> > > > it's 1366x768.
> > > > - Since both CVT and GFT can't express the width 1366 due to
> > > > alignment, the resultant mode becomes 1368x768, slightly larger than
> > > > the given size.
> > > > - Later on, the atomic commit is performed, and in
> > > > drm_atomic_check_only(), the size of each plane is checked.
> > > > - The size check of 1366x768 fails due to the above, and eventually
> > > > the whole VT switch fails.
> > > >
> > > > Back in the history, we've had a manual fix-up of 1368x768 in various
> > > > places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
> > > > panel"), but they have been all in drm_edid.c at probing the modes
> > > > from EDID. For addressing the problem above, we need a similar hack
> > > > to the mode newly created from cmdline, manually adjusting the width
> > > > when the expected size is 1366 while we get 1368 instead.
> > > >
> > > > Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
> > > > Cc:
> > > > Signed-off-by: Takashi Iwai
> > > > ---
> > > > drivers/gpu/drm/drm_modes.c | 7 +++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > > index ac6a35212501..e6b19bc9021a 100644
> > > > --- a/drivers/gpu/drm/drm_modes.c
> > > > +++ b/drivers/gpu/drm/drm_modes.c
> > > > @@ -1460,6 +1460,13 @@ drm_mode_create_from_cmdline_mode(struct
> > > > drm_device *dev,
> > > > return NULL;
> > > >
> > > > mode->type |= DRM_MODE_TYPE_USERDEF;
> > > > + /* fix up 1368x768: GFT/CVT can't express 1366 width due to
> > > > alignment */
> > > > + if (cmd->xres == 1366 && mode->hdisplay == 1368) {
> > > > + mode->hdisplay = 1366;
> > > > + mode->hsync_start--;
> > > > + mode->hsync_end--;
> > > > + drm_mode_set_name(mode);
> > > > + }
> > >
> > > Maybe give fixup_mode_1366x768() a drm_ prefix and make in non-static to
> > > avoid duplicating the code? And I guess move it to drm_modes.c?
> >
> > Yes, that'll be a good cleanup. I was afraid of symbol export, but
> > both are in the same module, so far. I can post a follow-up once when
> > this one gets accepted.
>
> For the follow up, pls put the decl into drm_crtc_internal.h, so that
> drivers aren't tempted to use it. That header is for module-internal
> shared code only.
>
> > > Otherwise lgtm:
> > > Reviewed-by: Ville Syrjälä
> >
> > Thanks!
>
> Ville, can you pls also apply this one to drm-misc-fixes?
Pushed. Thanks for the patch.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] GPU hang with kernel 4.10rc3
On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: > With kernel 4.10rc3 running as Xen dm0 I get at each boot: > > [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell > [1431], reason: Hang on render ring, action: reset > [ 49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire > gfx stack, including userspace. > [ 49.213700] [drm] Please file a _new_ bug report on > bugs.freedesktop.org against DRI -> DRM/Intel > [ 49.213700] [drm] drm/i915 developers can then reassign to the right > component if it's not a kernel issue. > [ 49.213700] [drm] The gpu crash dump is required to analyze gpu > hangs, so please always attach it. > [ 49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error > [ 49.213755] drm/i915: Resetting chip after gpu hang > [ 60.213769] drm/i915: Resetting chip after gpu hang > [ 71.189737] drm/i915: Resetting chip after gpu hang > [ 82.165747] drm/i915: Resetting chip after gpu hang > [ 93.205727] drm/i915: Resetting chip after gpu hang > > The dump is attached. That's a nasty one. The first couple of pages of the batchbuffer appear to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That may be a concurrent write by either the GPU or CPU, or we may have incorrected mapped a set of pages. That it doesn't recovered suggests that the corruption occurs frequently, probably on every request/batch. Is this a new bug? Bisection would be the fastest way to triage it. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:for-linux-next 2/4] htmldocs: drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for parameter 'offset'
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: c781c978e784c50dcd7cb312fe17f5281923f55b commit: 625d988acc28f3fe1d44f3798426561c17387a59 [2/4] drm/i915: Extract reserving space in the GTT to a helper reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/drm/drm_drv.h:441: warning: No description found for parameter 'firstopen' include/drm/drm_drv.h:441: warning: No description found for parameter 'open' include/drm/drm_drv.h:441: warning: No description found for parameter 'preclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'postclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'lastclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_ioctl' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_quiescent' include/drm/drm_drv.h:441: warning: No description found for parameter 'context_dtor' include/drm/drm_drv.h:441: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_handler' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_preinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_postinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_uninstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_cleanup' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'vgaarb_irq' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:441: warning: No description found for parameter 'major' include/drm/drm_drv.h:441: warning: No description found for parameter 'minor' include/drm/drm_drv.h:441: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:441: warning: No description found for parameter 'name' include/drm/drm_drv.h:441: warning: No description found for parameter 'desc' include/drm/drm_drv.h:441: warning: No description found for parameter 'date' include/drm/drm_drv.h:441: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:441: warning: No description found for parameter 'dev_priv_size' include/drm/drm_drv.h:441: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'fops' include/drm/drm_drv.h:441: warning: No description found for parameter 'legacy_dev_list' drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for parameter 'vm' drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for parameter 'node' drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for parameter 'size' >> drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description found for >> parameter 'offset' drivers/gpu/drm/i915/i915_gem_gtt.c:3586: warning: No description
Re: [PATCH] drm: Fix broken VT switch with video=1366x768 option
On Wed, 11 Jan 2017 18:05:12 +0100,
Ville Syrjälä wrote:
>
> On Tue, Jan 10, 2017 at 01:41:42PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 12:36:50PM +0100, Takashi Iwai wrote:
> > > On Tue, 10 Jan 2017 12:28:36 +0100,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > > > > I noticed that the VT switch doesn't work any longer with a Dell
> > > > > laptop with 1366x768 eDP when the machine is connected with a DP
> > > > > monitor. It behaves as if VT were switched, but the graphics remain
> > > > > frozen. Actually the keyboard works, so I could switch back to VT7
> > > > > again.
> > > > >
> > > > > I tried to track down the problem, and encountered a long story until
> > > > > we reach to this error:
> > > > >
> > > > > - The machine is booted with video=1366x768 option (the distro
> > > > > installer seems to add it as default).
> > > > > - Recently, drm_helper_probe_single_connector_modes() deals with
> > > > > cmdline modes, and it tries to create a new mode when no
> > > > > matching mode is found.
> > > > > - The drm_mode_create_from_cmdline_mode() creates a mode based on
> > > > > either CVT of GFT according to the given cmdline mode; in our case,
> > > > > it's 1366x768.
> > > > > - Since both CVT and GFT can't express the width 1366 due to
> > > > > alignment, the resultant mode becomes 1368x768, slightly larger than
> > > > > the given size.
> > > > > - Later on, the atomic commit is performed, and in
> > > > > drm_atomic_check_only(), the size of each plane is checked.
> > > > > - The size check of 1366x768 fails due to the above, and eventually
> > > > > the whole VT switch fails.
> > > > >
> > > > > Back in the history, we've had a manual fix-up of 1368x768 in various
> > > > > places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
> > > > > panel"), but they have been all in drm_edid.c at probing the modes
> > > > > from EDID. For addressing the problem above, we need a similar hack
> > > > > to the mode newly created from cmdline, manually adjusting the width
> > > > > when the expected size is 1366 while we get 1368 instead.
> > > > >
> > > > > Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
> > > > > Cc:
> > > > > Signed-off-by: Takashi Iwai
> > > > > ---
> > > > > drivers/gpu/drm/drm_modes.c | 7 +++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > > > index ac6a35212501..e6b19bc9021a 100644
> > > > > --- a/drivers/gpu/drm/drm_modes.c
> > > > > +++ b/drivers/gpu/drm/drm_modes.c
> > > > > @@ -1460,6 +1460,13 @@ drm_mode_create_from_cmdline_mode(struct
> > > > > drm_device *dev,
> > > > > return NULL;
> > > > >
> > > > > mode->type |= DRM_MODE_TYPE_USERDEF;
> > > > > + /* fix up 1368x768: GFT/CVT can't express 1366 width due to
> > > > > alignment */
> > > > > + if (cmd->xres == 1366 && mode->hdisplay == 1368) {
> > > > > + mode->hdisplay = 1366;
> > > > > + mode->hsync_start--;
> > > > > + mode->hsync_end--;
> > > > > + drm_mode_set_name(mode);
> > > > > + }
> > > >
> > > > Maybe give fixup_mode_1366x768() a drm_ prefix and make in non-static to
> > > > avoid duplicating the code? And I guess move it to drm_modes.c?
> > >
> > > Yes, that'll be a good cleanup. I was afraid of symbol export, but
> > > both are in the same module, so far. I can post a follow-up once when
> > > this one gets accepted.
> >
> > For the follow up, pls put the decl into drm_crtc_internal.h, so that
> > drivers aren't tempted to use it. That header is for module-internal
> > shared code only.
> >
> > > > Otherwise lgtm:
> > > > Reviewed-by: Ville Syrjälä
> > >
> > > Thanks!
> >
> > Ville, can you pls also apply this one to drm-misc-fixes?
>
> Pushed. Thanks for the patch.
Thanks!
Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99313] A few amdgpu errors with kernel 4.10-rc2 (Kaveri + Topaz)
https://bugs.freedesktop.org/show_bug.cgi?id=99313 --- Comment #2 from SET --- On further testing with 4.10-rcX up to commit cff3b2c : 'UVD not responding' error occurs if pg_mask is not specified. When pg_mask is explicitly set to 0 or 1, no UVD errors are reported. X session is then normally usable. This is seen on another laptop with Kabini also. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99313] A few amdgpu errors with kernel 4.10-rc2 (Kaveri + Topaz)
https://bugs.freedesktop.org/show_bug.cgi?id=99313 Alex Deucher changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=192161 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 192161] Amdgpu UVD init failures at boot
https://bugzilla.kernel.org/show_bug.cgi?id=192161 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher --- See also: https://bugs.freedesktop.org/show_bug.cgi?id=99313 Rex is working on a fix. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
