[RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver
Hi all [Resend this v7 version series, since there are 5 mails have gone missing, last week] This version does not change the existing v6 patches, just to add the "bandwidth fix" patch back, since we really need it. This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of RK3399 is almost the same as RK3288, except a little bit of difference in phy clock controlling and port id selection register. These patches add RK3399 support and the power domain support. And these patches base on John Keeping's v3 patches[0], it fixes many bugs, they have been tested on rk3288 evb board. [0]: [01/24] https://patchwork.kernel.org/patch/9544089 [02/24] https://patchwork.kernel.org/patch/9544061 [03/24] https://patchwork.kernel.org/patch/9544065 [04/24] https://patchwork.kernel.org/patch/9544077 [05/24] https://patchwork.kernel.org/patch/9544033 [06/24] https://patchwork.kernel.org/patch/9544037 [07/24] https://patchwork.kernel.org/patch/9544029 [08/24] https://patchwork.kernel.org/patch/9544031 [09/24] https://patchwork.kernel.org/patch/9544083 [10/24] https://patchwork.kernel.org/patch/9544063 [11/24] https://patchwork.kernel.org/patch/9544085 [12/24] https://patchwork.kernel.org/patch/9544093 [13/24] https://patchwork.kernel.org/patch/9544081 [14/24] https://patchwork.kernel.org/patch/9544057 [15/24] https://patchwork.kernel.org/patch/9544079 [16/24] https://patchwork.kernel.org/patch/9544035 [17/24] https://patchwork.kernel.org/patch/9544105 [18/24] https://patchwork.kernel.org/patch/9544059 [21/24] https://patchwork.kernel.org/patch/9544009 [22/24] https://patchwork.kernel.org/patch/9544049 [23/24] https://patchwork.kernel.org/patch/9544055 [24/24] https://patchwork.kernel.org/patch/9544109 Changes in v6: - no need check phy_cfg_clk before enable/disable Changes in v5: - check the error of phy_cfg_clk in dw_mipi_dsi_bind Changes in v4: - remove the unrelated change Changes in v3: - base on John Keeping's patch series Chris Zhong (7): dt-bindings: add rk3399 support for dw-mipi-rockchip drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi drm/rockchip/dsi: dw-mipi: correct the coding style drm/rockchip/dsi: remove mode_valid function dt-bindings: add power domain node for dw-mipi-rockchip drm/rockchip/dsi: fix insufficient bandwidth of some panel drm/rockchip/dsi: add dw-mipi power domain support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 160 - 2 files changed, 100 insertions(+), 67 deletions(-) -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v7 3/7] drm/rockchip/dsi: dw-mipi: correct the coding style
correct the coding style, according the checkpatch scripts
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4e74681..836cb83 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -157,7 +157,6 @@
#define LPRX_TO_CNT(p) ((p) & 0x)
#define DSI_BTA_TO_CNT 0x8c
-
#define DSI_LPCLK_CTRL 0x94
#define AUTO_CLKLANE_CTRL BIT(1)
#define PHY_TXREQUESTCLKHS BIT(0)
@@ -223,11 +222,11 @@
#define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
-#define INPUT_DIVIDER(val) ((val - 1) & 0x7f)
+#define INPUT_DIVIDER(val) (((val) - 1) & 0x7f)
#define LOW_PROGRAM_EN 0
#define HIGH_PROGRAM_ENBIT(7)
-#define LOOP_DIV_LOW_SEL(val) ((val - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) (((val - 1) >> 5) & 0x1f)
+#define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
#define PLL_LOOP_DIV_ENBIT(5)
#define PLL_INPUT_DIV_EN BIT(4)
@@ -369,6 +368,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct
drm_encoder *encoder)
{
return container_of(encoder, struct dw_mipi_dsi, encoder);
}
+
static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
{
writel(val, dsi->base + reg);
@@ -380,7 +380,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
}
static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
-u8 test_data)
+ u8 test_data)
{
/*
* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
@@ -496,7 +496,6 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
-
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
@@ -571,7 +570,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
if (device->lanes > dsi->pdata->max_data_lanes) {
dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
- device->lanes);
+ device->lanes);
return -EINVAL;
}
@@ -1060,14 +1059,14 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
*encoder,
return 0;
}
-static struct drm_encoder_helper_funcs
+static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.enable = dw_mipi_dsi_encoder_enable,
.disable = dw_mipi_dsi_encoder_disable,
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
};
-static struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -1103,7 +1102,7 @@ static void dw_mipi_dsi_drm_connector_destroy(struct
drm_connector *connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
+static const struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = dw_mipi_dsi_drm_connector_destroy,
@@ -1113,7 +1112,7 @@ static struct drm_connector_funcs
dw_mipi_dsi_atomic_connector_funcs = {
};
static int dw_mipi_dsi_register(struct drm_device *drm,
- struct dw_mipi_dsi *dsi)
+ struct dw_mipi_dsi *dsi)
{
struct drm_encoder *encoder = &dsi->encoder;
struct drm_connector *connector = &dsi->connector;
@@ -1134,14 +1133,14 @@ static int dw_mipi_dsi_register(struct drm_device *drm,
drm_encoder_helper_add(&dsi->encoder,
&dw_mipi_dsi_encoder_helper_funcs);
ret = drm_encoder_init(drm, &dsi->encoder, &dw_mipi_dsi_encoder_funcs,
-DRM_MODE_ENCODER_DSI, NULL);
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
dev_err(dev, "Failed to initialize encoder with drm\n");
return ret;
}
drm_connector_helper_add(connector,
- &dw_mipi_dsi_connector_helper_funcs);
+&dw_mipi_dsi_connector_helper_funcs);
drm_connector_init(drm, &dsi->connector,
&dw_mipi_dsi_atomic_connector_funcs,
@@ -1
[RESEND PATCH v7 5/7] dt-bindings: add power domain node for dw-mipi-rockchip
Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 0f82568..188f6f7 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -15,6 +15,9 @@ Required properties: - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. +Optional properties: +- power-domains: a phandle to mipi dsi power domain node. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/media/video-interfaces.txt -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v7 6/7] drm/rockchip/dsi: fix insufficient bandwidth of some panel
Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
for some panel, it will cause the screen display is not normal, so
increases the badnwidth to 1 / 0.8.
Signed-off-by: Chris Zhong
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index c2d7674..a653384 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -532,8 +532,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
- /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
- tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
+ /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
+ tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
if (tmp < max_mbps)
target_mbps = tmp;
else
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v7 4/7] drm/rockchip/dsi: remove mode_valid function
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Signed-off-by: Chris Zhong
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 836cb83..c2d7674 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -1077,23 +1075,8 @@ static int dw_mipi_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
- enum drm_mode_status mode_status = MODE_OK;
-
- if (dsi->pdata->mode_valid)
- mode_status = dsi->pdata->mode_valid(connector, mode);
-
- return mode_status;
-}
-
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
- .mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1164,33 +1147,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi
*dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
- if (mode->hdisplay > 0x7ff)
- return MODE_BAD_HVALUE;
-
- /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
- if (mode->vdisplay > 0x7ff)
- return MODE_BAD_VVALUE;
-
- return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
- .mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v7 2/7] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
Reviewed-by: Sean Paul
---
Changes in v6:
- no need check phy_cfg_clk before enable/disable
Changes in v5:
- check the error of phy_cfg_clk in dw_mipi_dsi_bind
Changes in v4:
- remove the unrelated change
Changes in v3:
- base on John Keeping's patch series
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 72 +-
1 file changed, 62 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index cc58ada..4e74681 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -29,9 +29,17 @@
#define DRIVER_NAME"dw-mipi-dsi"
-#define GRF_SOC_CON60x025c
-#define DSI0_SEL_VOP_LIT(1 << 6)
-#define DSI1_SEL_VOP_LIT(1 << 9)
+#define RK3288_GRF_SOC_CON60x025c
+#define RK3288_DSI0_SEL_VOP_LITBIT(6)
+#define RK3288_DSI1_SEL_VOP_LITBIT(9)
+
+#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_DSI0_SEL_VOP_LITBIT(0)
+#define RK3399_DSI1_SEL_VOP_LITBIT(4)
+
+/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
+#define RK3399_GRF_SOC_CON22 0x6258
+#define RK3399_GRF_DSI_MODE0x
#define DSI_VERSION0x00
#define DSI_PWR_UP 0x04
@@ -265,6 +273,11 @@ enum {
};
struct dw_mipi_dsi_plat_data {
+ u32 dsi0_en_bit;
+ u32 dsi1_en_bit;
+ u32 grf_switch_reg;
+ u32 grf_dsi0_mode;
+ u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
@@ -281,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk *phy_cfg_clk;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -425,6 +439,12 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
+ ret = clk_prepare_enable(dsi->phy_cfg_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+ return ret;
+ }
+
dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
VCO_RANGE_CON_SEL(vco) |
VCO_IN_CAP_CON_LOW |
@@ -481,17 +501,18 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to wait for phy lock state\n");
- return ret;
+ goto phy_init_end;
}
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & STOP_STATE_CLK_LANE, 1000,
PHY_STATUS_TIMEOUT_US);
- if (ret < 0) {
+ if (ret < 0)
dev_err(dsi->dev,
"failed to wait for phy clk lane stop state\n");
- return ret;
- }
+
+phy_init_end:
+ clk_disable_unprepare(dsi->phy_cfg_clk);
return ret;
}
@@ -960,6 +981,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
+ const struct dw_mipi_dsi_plat_data *pdata = dsi->pdata;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
@@ -985,6 +1007,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
+ if (pdata->grf_dsi0_mode_reg)
+ regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
+pdata->grf_dsi0_mode);
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(mode);
@@ -998,11 +1024,11 @@ static void dw_mipi_dsi_encoder_enable(struct
drm_encoder *encoder)
clk_disable_unprepare(dsi->pclk);
if (mux)
- val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+ val = pdata->dsi0_en_bit | (pdata->dsi0_en_bit << 16);
else
- val = DSI0_SEL_VOP_LIT << 16;
+ val = pdata->dsi0_en_bit << 16;
- regmap_write(dsi->grf_regmap, GRF_SOC_CON6, val);
+ regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, va
[RESEND PATCH v7 1/7] dt-bindings: add rk3399 support for dw-mipi-rockchip
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has additional phy config clock. Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 1753f0c..0f82568 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -5,10 +5,12 @@ Required properties: - #address-cells: Should be <1>. - #size-cells: Should be <0>. - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi". + "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference - clock(ref) and APB clock(pclk), as described in [1]. + clock(ref) and APB clock(pclk). For RK3399, a phy config clock + (phy_cfg) is additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v7 7/7] drm/rockchip/dsi: add dw-mipi power domain support
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a653384..b32e4fc 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -293,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
+ int dpms_mode;
unsigned int lane_mbps; /* per lane */
u32 channel;
u32 lanes;
@@ -960,6 +962,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+ if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+ return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
@@ -971,7 +976,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
drm_panel_unprepare(dsi->panel);
dw_mipi_dsi_disable(dsi);
+ pm_runtime_put(dsi->dev);
clk_disable_unprepare(dsi->pclk);
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
}
static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
@@ -987,11 +994,15 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
if (ret < 0)
return;
+ if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+ return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
}
+ pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
dw_mipi_dsi_dpi_config(dsi, mode);
dw_mipi_dsi_packet_handler_config(dsi);
@@ -1027,6 +1038,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
+ dsi->dpms_mode = DRM_MODE_DPMS_ON;
}
static int
@@ -1194,6 +1206,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dsi->dev = dev;
dsi->pdata = pdata;
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
@@ -1274,6 +1287,8 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, dsi);
+ pm_runtime_enable(dev);
+
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1296,6 +1311,7 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct
device *master,
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
mipi_dsi_host_unregister(&dsi->dsi_host);
+ pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 5/6] drm/i915: enable scrambling
Hello Ville, Jani
I have addressed all your review comments in this patch set (V3).
Can you please have a look if this seems ok ?
Link: https://patchwork.kernel.org/patch/9567061/
Regards
Shashank
-Original Message-
From: Sharma, Shashank
Sent: Friday, February 10, 2017 9:59 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
jose.ab...@synopsys.com; jani.nik...@linux.intel.com
Cc: ville.syrj...@linux.intel.com; tred...@nvidia.com; Vetter, Daniel
; Sharma, Shashank
Subject: [PATCH v3 5/6] drm/i915: enable scrambling
Geminilake platform sports a native HDMI 2.0 controller, and is capable of
driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these
higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required, enables
it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++
drivers/gpu/drm/i915/intel_ddi.c | 28 ++
drivers/gpu/drm/i915/intel_drv.h | 14 +
drivers/gpu/drm/i915/intel_hdmi.c | 106 ++
4 files changed, 152 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 141a5c1..81cf10b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7819,7 +7819,11 @@ enum {
#define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
+#define TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7) #define
+TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
#define TRANS_DDI_BFI_ENABLE (1<<4)
+#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
/* DisplayPort Transport Control */
#define _DP_TP_CTL_A 0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd6fedd..bd8293d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+ if (IS_GEMINILAKE(dev_priv))
+ temp = intel_hdmi_handle_source_scrambling(
+ intel_encoder,
+ &intel_crtc->config->base.adjusted_mode, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1; @@ -1843,6
+1848,21 @@ static void intel_enable_ddi(struct intel_encoder *intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
+ if (IS_GEMINILAKE(dev_priv)) {
+ struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
+ /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by sink, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+ intel_hdmi_handle_sink_scrambling(intel_encoder,
+ conn_state->connector,
+ crtc->config, true);
+ }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
* are ignored so nothing special needs to be done besides
* enabling the port.
@@ -1875,6 +1895,14 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder,
if (old_crtc_state->has_audio)
intel_audio_codec_disable(intel_encoder);
+ if (type == INTEL_OUTPUT_HDMI) {
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+
+ intel_hdmi_handle_sink_scrambling(intel_encoder,
+ old_conn_state->connector,
+ intel_crtc->config, false);
+ }
+
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
diff --git a
Re: [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications
Hi,
On 16-02-17 20:02, Jani Nikula wrote:
On Thu, 16 Feb 2017, Ville Syrjälä wrote:
On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
the bus is accessed to avoid needing to do any forcewakes, which need
PMIC bus access, while the PMIC bus is busy:
This fixes errors like these showing up in dmesg, usually followed
by a gfx or system freeze:
[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack
request.
[drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake ack
request.
i2c_designware 808622C1:06: punit semaphore timed out, resetting
i2c_designware 808622C1:06: PUNIT SEM: 2
i2c_designware 808622C1:06: couldn't acquire bus ownership
Downside of this approach is that it causes wakeups whenever the PMIC
bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
to go idle when we hit a race, as forcewakes may be done from interrupt
handlers where we cannot sleep to wait for the i2c PMIC bus access to
finish.
Note that the notifications and thus the wakeups will only happen on
baytrail / cherrytrail devices using PMICs with a shared i2c bus for
P-Unit and host PMIC access (i2c busses with a _SEM method in their
APCI node), e.g. an axp288 PMIC.
I plan to write some patches for drivers accessing the PMIC bus to
limit their bus accesses to a bare minimum (e.g. cache registers, do not
update battery level more often then 4 times a minute), to limit the
amount of wakeups.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede
Tested-by: tagorereddy
I gave the previous versions a quick whirl on a few machines here, but
them not being CR versions I guess this stuff doesn't kick in at all.
And I don't see any _SEM stuff in the DSDT/SSDT, so I guess that
confirms it. Which is fine since I've not seem any stability issues
on those machines. So at least nothing seemed to break :)
Anyways the changes look all right to me, so for both i915 patches
Reviewed-by: Ville Syrjälä
Acked-by: Jani Nikula
for merging the i915 patches through some other tree if that makes
managing the pile easier.
Actually the idea was for the entire pile to go through the drm-intel
tree. Daniel can you pick these up please (they seem to be ready) ?
Regards,
Hans
---
Changes in v2:
-Spelling: P-Unit, PMIC
Changes in v3:
-Improve comment explaining why we call intel_uncore_forcewake_get(ALL) on
MBI_PMIC_BUS_ACCESS_BEGIN notification
---
drivers/gpu/drm/i915/Kconfig| 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 39 +
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1ae0bb9..a5cd5da 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -20,6 +20,7 @@ config DRM_I915
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
select SYNC_FILE
+ select IOSF_MBI
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 998239f..4e405d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -725,6 +725,7 @@ struct intel_uncore {
const struct intel_forcewake_range *fw_domains_table;
unsigned int fw_domains_table_entries;
+ struct notifier_block pmic_bus_access_nb;
struct intel_uncore_funcs funcs;
unsigned fifo_count;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b6d726b..1be3cdc 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -25,6 +25,7 @@
#include "intel_drv.h"
#include "i915_vgpu.h"
+#include
#include
#define FORCEWAKE_ACK_TIMEOUT_MS 50
@@ -436,12 +437,16 @@ static void __intel_uncore_early_sanitize(struct
drm_i915_private *dev_priv,
void intel_uncore_suspend(struct drm_i915_private *dev_priv)
{
+ iosf_mbi_unregister_pmic_bus_access_notifier(
+ &dev_priv->uncore.pmic_bus_access_nb);
intel_uncore_forcewake_reset(dev_priv, false);
}
void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
{
__intel_uncore_early_sanitize(dev_priv, true);
+ iosf_mbi_register_pmic_bus_access_notifier(
+ &dev_priv->uncore.pmic_bus_access_nb);
i915_check_and_clear_faults(dev_priv);
}
@@ -1329,6 +1334,32 @@ static void intel_uncore_fw_domains_init(struct
drm_i915_private *dev_priv)
dev_priv->uncore.fw_domains_table_entries = ARRAY_SIZE((d)); \
}
+static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+ struct drm_i915_private *dev_priv = c
[PATCH] drm/rockchip: vop: no need wait vblank on crtc enable
Since atomic framework, crtc enable and disable are in pairs,
no need to wait vblank.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 -
1 file changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..8dab2af 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -900,42 +900,6 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
return;
}
- /*
-* If dclk rate is zero, mean that scanout is stop,
-* we don't need wait any more.
-*/
- if (clk_get_rate(vop->dclk)) {
- /*
-* Rk3288 vop timing register is immediately, when configure
-* display timing on display time, may cause tearing.
-*
-* Vop standby will take effect at end of current frame,
-* if dsp hold valid irq happen, it means standby complete.
-*
-* mode set:
-*standby and wait complete --> |
-* | display time
-* |
-* |---> dsp hold irq
-* configure display timing --> |
-* standby exit |
-* | new frame start.
-*/
-
- reinit_completion(&vop->dsp_hold_completion);
- vop_dsp_hold_valid_irq_enable(vop);
-
- spin_lock(&vop->reg_lock);
-
- VOP_CTRL_SET(vop, standby, 1);
-
- spin_unlock(&vop->reg_lock);
-
- wait_for_completion(&vop->dsp_hold_completion);
-
- vop_dsp_hold_valid_irq_disable(vop);
- }
-
pin_pol = BIT(DCLK_INVERT);
pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ?
0 : BIT(HSYNC_POSITIVE);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph
2017년 02월 20일 16:27에 Krzysztof Kozlowski 이(가) 쓴 글: > On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote: >> Hi Krzysztof, >> >> Can you merge patch 2 and 5 to your tree so that they can go to mainline? >> Otherwise, I can merge them to my tree if you give me acked-by. > > Hi, > > Hm? Why do you need them to be merged? Do you mean that the first > patch breaks not only ABI but also bisectability? Then this has to be > reworked because: > > 1. The DTS patches cannot go through non-DT tree so no, you cannot > take them into your branch. I will merge them according to point 4 > below. > 2. Bisectability has to be preserved. > 3. DTS changes in general should not be a dependency for driver changes. Krzysztof, I know that. I didn't check you gave a comment to Hoegun do rework this patch series. I just checked reviewed-by from Andrzej H. and thought no problem. Ideally you are right. DT changes should be no any dependency of driver changes but now Exynos DT is broken. So if we have to keep the bisectability between driver and device tree patches - this means that all drivers should always keep the backward compatibility - then the drivers will be messed up. About this, we had a discussion and I think you agreed, https://patchwork.kernel.org/patch/9477957/ Do you want the backward compatibility to be kept always when new dt binding relevant patch - which fixes up the wrong usage of dt binding - is posted? It would be good for the backward compatibility to be kept as long as we can do but there would be several cases to make the driver to be messed up like this patch series. > 4 . Usually DTS patches wait for driver to be acked by devicetree > maintainers or merging by driver maintainer. This did not happen so > DTS patches wait. Also these were sent too late to merge for this > cycle so the only chance is v4.12. Yes, maybe. Thanks, Inki Dae > > Best regards, > Krzysztof > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: add drm_get_connector_force_name
Follow the naming in debugfs also for logging, add "unknown" for values
beyond the enumerated ones.
v2: add \n in connector_show, make internal to drm (Chris)
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
It's easy enough to move the declaration to include/drm/drm_connector.h
and add EXPORT_SYMBOL later should anyone need it.
---
drivers/gpu/drm/drm_connector.c | 40 ++---
drivers/gpu/drm/drm_crtc_internal.h | 1 +
drivers/gpu/drm/drm_debugfs.c | 24 +-
3 files changed, 26 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 45464c8b797d..4d66099f4572 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -128,22 +128,8 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
return;
if (mode->force) {
- const char *s;
-
- switch (mode->force) {
- case DRM_FORCE_OFF:
- s = "OFF";
- break;
- case DRM_FORCE_ON_DIGITAL:
- s = "ON - dig";
- break;
- default:
- case DRM_FORCE_ON:
- s = "ON";
- break;
- }
-
- DRM_INFO("forcing %s connector %s\n", connector->name, s);
+ DRM_INFO("forcing %s connector %s\n", connector->name,
+drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
@@ -488,6 +474,28 @@ const char *drm_get_connector_status_name(enum
drm_connector_status status)
}
EXPORT_SYMBOL(drm_get_connector_status_name);
+/**
+ * drm_get_connector_force_name - return a string for connector force
+ * @force: connector force to get name of
+ *
+ * Returns: const pointer to name.
+ */
+const char *drm_get_connector_force_name(enum drm_connector_force force)
+{
+ switch (force) {
+ case DRM_FORCE_UNSPECIFIED:
+ return "unspecified";
+ case DRM_FORCE_OFF:
+ return "off";
+ case DRM_FORCE_ON:
+ return "on";
+ case DRM_FORCE_ON_DIGITAL:
+ return "digital";
+ default:
+ return "unknown";
+ }
+}
+
#ifdef CONFIG_LOCKDEP
static struct lockdep_map connector_list_iter_dep_map = {
.name = "drm_connector_list_iter"
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 955c5690bf64..81bc0a390f41 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -142,6 +142,7 @@ int drm_mode_connector_set_obj_prop(struct drm_mode_object
*obj,
struct drm_property *property,
uint64_t value);
int drm_connector_create_standard_properties(struct drm_device *dev);
+const char *drm_get_connector_force_name(enum drm_connector_force force);
/* IOCTL */
int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 2290a74a6e46..8b2c61ae0004 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -261,30 +261,8 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
static int connector_show(struct seq_file *m, void *data)
{
struct drm_connector *connector = m->private;
- const char *status;
- switch (connector->force) {
- case DRM_FORCE_ON:
- status = "on\n";
- break;
-
- case DRM_FORCE_ON_DIGITAL:
- status = "digital\n";
- break;
-
- case DRM_FORCE_OFF:
- status = "off\n";
- break;
-
- case DRM_FORCE_UNSPECIFIED:
- status = "unspecified\n";
- break;
-
- default:
- return 0;
- }
-
- seq_puts(m, status);
+ seq_printf(m, "%s\n", drm_get_connector_force_name(connector->force));
return 0;
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] mxsfb fixes
On 20 Feb. 2017 18:29, "Marek Vasut" wrote: On 02/20/2017 03:56 AM, Dave Airlie wrote: > On 19 February 2017 at 08:25, Marek Vasut wrote: >> On 02/17/2017 09:34 PM, Dave Airlie wrote: >>> On 17 February 2017 at 18:00, Marek Vasut wrote: On 02/17/2017 03:41 AM, Dave Airlie wrote: > On 16 February 2017 at 08:16, Marek Vasut wrote: >> Hi, >> >> I collected the MXSFB fixes, based on top of airlied/drm-fixes: > > At this stage I'd rather not give these to Linus, can you rebase them onto > drm-next, and resend, feel free to add stable cc's. > > Fixes like this should really be getting to me sooner than rc8. I know, sorry about that. I was totally overloaded in the past weeks. What about getting them to rc1, any chance for that ? >>> >>> Yes if you can rebase them onto drm-next. >> >> Ha, got it. Try the following: >> >> The following changes since commit 9ca70356a9260403c1bda40d942935 e55d00c11c: >> >> Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git >> c72a2ec8208b40683fbd2970684ffbf3a8c7d17e > > Nearly, put please use a tag :-) I'm sure you can pull this batch without a tag ;-) No, I really need tags preferably signed. Otherwise the merge is all ugly. What do you have in mind for the next PR Not sure I follow. Dave -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
On 02/16/2017 03:34 AM, Rob Herring wrote: > On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote: >> Signed-off-by: Yannick Fertre >> --- >> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 >> +++ >> 1 file changed, 7 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> >> diff --git >> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> >> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> new file mode 100644 >> index 000..f59e3c4 >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> @@ -0,0 +1,7 @@ >> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel >> + >> +Required properties: >> +- compatible: should be "ampire,am-480272h3tmqw-t01h" > > No GPIO controls or power supply for this panel? > > Rob > Hi Rob, thank for your reply. There is no gpio or power supply control for this panel with the eval board stm429x9i. This binding is similar to all panel bindings which are link to panel simple. Details on gpio & power supply are describe with simple-panel binding. Best regards Example nvd,9128.txt: New Vision Display 7.0" 800 RGB x 480 TFT LCD panel Required properties: - compatible: should be "nvd,9128" This binding is compatible with the simple-panel binding, which is specified in simple-panel.txt in this directory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: Avoid decomposing a signal-on-any fence-array
On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
> The code currently assumes that all fence arrays it sees are the normal
> signal-on-all variety, and decomposes the array into its individual
> fences so that it can extract the native i915 fences. If the fence array
> is using signal-on-any, we should not decompose as we must not wait on
> them all, just the first in *that* set.
>
> Signed-off-by: Chris Wilson
> CC: Joonas Lahtinen
> Cc: Tvrtko Ursulin
>
> @@ -696,7 +696,8 @@ i915_gem_request_await_dma_fence(struct
> drm_i915_gem_request *req,
> if (dma_fence_is_i915(fence))
> return i915_gem_request_await_request(req, to_request(fence));
>
> - if (!dma_fence_is_array(fence)) {
> + if (!dma_fence_is_array(fence) ||
> + test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, &fence->flags)) {
Smells like a helper function? While that helper is finding the way
upstream;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/sti: fix build warnings in sti_drv.c and sti_vtg.c files
Fix compilation warning introduced by:
commit 0c7ff84f7f9d ("drm/sti: remove deprecated legacy vtg slave")
commit 5e60f595d6ca ("drm/sti: use atomic_helper for commit")
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_drv.c | 9 -
drivers/gpu/drm/sti/sti_vtg.c | 1 -
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index e6c1646..20fc0fbf 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -117,15 +117,6 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
return ret;
}
-static void sti_drm_dbg_cleanup(struct drm_minor *minor)
-{
- drm_debugfs_remove_files(sti_drm_dbg_list,
-ARRAY_SIZE(sti_drm_dbg_list), minor);
-
- drm_debugfs_remove_files((struct drm_info_list *)&sti_drm_fps_fops,
-1, minor);
-}
-
static int sti_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
{
diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index 943bce5..2dcba1d 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -389,7 +389,6 @@ static irqreturn_t vtg_irq(int irq, void *arg)
static int vtg_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct device_node *np;
struct sti_vtg *vtg;
struct resource *res;
int ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: Avoid decomposing a signal-on-any fence-array
On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
> > The code currently assumes that all fence arrays it sees are the normal
> > signal-on-all variety, and decomposes the array into its individual
> > fences so that it can extract the native i915 fences. If the fence array
> > is using signal-on-any, we should not decompose as we must not wait on
> > them all, just the first in *that* set.
> >
> > Signed-off-by: Chris Wilson
> > CC: Joonas Lahtinen
> > Cc: Tvrtko Ursulin
>
>
>
> >
> > @@ -696,7 +696,8 @@ i915_gem_request_await_dma_fence(struct
> > drm_i915_gem_request *req,
> > if (dma_fence_is_i915(fence))
> > return i915_gem_request_await_request(req, to_request(fence));
> >
> > - if (!dma_fence_is_array(fence)) {
> > + if (!dma_fence_is_array(fence) ||
> > + test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, &fence->flags)) {
>
> Smells like a helper function? While that helper is finding the way
> upstream;
Blurgh.
enum dma_fence_array_signal_mode {
DMA_FENCE_ARRAY_SIGNAL_ON_ALL = 0,
DMA_FENCE_ARRAY_SIGNAL_ON_ANY,
};
enum dma_fence_array_signal_mode
dma_fence_array_get_signaling_mode(struct dma_fence_array *array)
{
return test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, &array->base.flags) ?
DMA_FENCE_ARRAY_SIGNAL_ON_ANY : DMA_FENCE_ARRAY_SIGNAL_ON_ALL;
}
if (!dma_fence_is_array(fence) ||
dma_fence_array_get_signaling_mode(to_dma_fence_array(fence)) ==
DMA_FENCE_ARRAY_SIGNAL_ON_ANY)
Hmm. Not happy with that yet.
-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
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid decomposing a signal-on-any fence-array
Op 20-02-17 om 13:03 schreef Chris Wilson:
> On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
>> On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
>>> The code currently assumes that all fence arrays it sees are the normal
>>> signal-on-all variety, and decomposes the array into its individual
>>> fences so that it can extract the native i915 fences. If the fence array
>>> is using signal-on-any, we should not decompose as we must not wait on
>>> them all, just the first in *that* set.
>>>
>>> Signed-off-by: Chris Wilson
>>> CC: Joonas Lahtinen
>>> Cc: Tvrtko Ursulin
>>
>>
>>> @@ -696,7 +696,8 @@ i915_gem_request_await_dma_fence(struct
>>> drm_i915_gem_request *req,
>>> if (dma_fence_is_i915(fence))
>>> return i915_gem_request_await_request(req, to_request(fence));
>>>
>>> - if (!dma_fence_is_array(fence)) {
>>> + if (!dma_fence_is_array(fence) ||
>>> + test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, &fence->flags)) {
>> Smells like a helper function? While that helper is finding the way
>> upstream;
> Blurgh.
>
> enum dma_fence_array_signal_mode {
> DMA_FENCE_ARRAY_SIGNAL_ON_ALL = 0,
> DMA_FENCE_ARRAY_SIGNAL_ON_ANY,
> };
>
> enum dma_fence_array_signal_mode
> dma_fence_array_get_signaling_mode(struct dma_fence_array *array)
> {
> return test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, &array->base.flags) ?
> DMA_FENCE_ARRAY_SIGNAL_ON_ANY : DMA_FENCE_ARRAY_SIGNAL_ON_ALL;
> }
>
> if (!dma_fence_is_array(fence) ||
> dma_fence_array_get_signaling_mode(to_dma_fence_array(fence)) ==
> DMA_FENCE_ARRAY_SIGNAL_ON_ANY)
>
> Hmm. Not happy with that yet.
> -Chris
>
bool dma_fence_array_signal_on_any with a WARN_ON(!dma_fence_is_array(fence))?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_printer: add __printf validation
On Wednesday, 2017-02-15 15:33:18 -0800, Joe Perches wrote:
> drm_printf does not currently use the compiler to verify
> format and arguments. Make it do so.
>
> Miscellanea:
>
> o Add appropriate #include files for __printf and struct va_format
> o Convert dev_printk to dev_info
I think these unrelated changes should be in 4 patches:
1 - add annotation to check the format string against the arguments
(linux/compiler.h should be added here)
2 - add missing linux/printk.h header for struct va_format
Note that I think a forward declaration is more appropriate here, as
we only use pointers to this struct in this file, we never try to
look inside. On the other hand:
3 - drm_print.c needs the header in drm_printf(), but as a separate
patch
4 - convert dev_printk to dev_info (you need to include linux/device.h
there)
You can add my r-b on all four patches when you send them to the list :)
Cheers,
Eric
>
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/drm_print.c | 2 +-
> include/drm/drm_print.h | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 02a107d50706..74c466aca622 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -36,7 +36,7 @@ EXPORT_SYMBOL(__drm_printfn_seq_file);
>
> void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf)
> {
> - dev_printk(KERN_INFO, p->arg, "[" DRM_NAME "] %pV", vaf);
> + dev_info(p->arg, "[" DRM_NAME "] %pV", vaf);
> }
> EXPORT_SYMBOL(__drm_printfn_info);
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 7d98763c0444..ca4d7c6321f2 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -26,6 +26,8 @@
> #ifndef DRM_PRINT_H_
> #define DRM_PRINT_H_
>
> +#include
> +#include
> #include
> #include
>
> @@ -75,6 +77,7 @@ void __drm_printfn_seq_file(struct drm_printer *p, struct
> va_format *vaf);
> void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
> void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
>
> +__printf(2, 3)
> void drm_printf(struct drm_printer *p, const char *f, ...);
>
>
> --
> 2.10.0.rc2.1.g053435c
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: enable scrambling
Op 10-02-17 om 17:29 schreef Shashank Sharma:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
>
> V2: Addressed review comments from Ville:
> - Do not track scrambling status in DRM layer, track somewhere in
> driver like in intel_crtc_state.
> - Don't talk to monitor at such a low layer, set monitor scrambling
> in intel_enable_ddi() before enabling the port.
>
> V3: Addressed review comments from Jani
> - In comments, function names, use "sink" instead of "monitor",
> so that the implementation could be close to the language of
> HDMI spec.
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 ++
> drivers/gpu/drm/i915/intel_ddi.c | 28 ++
> drivers/gpu/drm/i915/intel_drv.h | 14 +
> drivers/gpu/drm/i915/intel_hdmi.c | 106
> ++
> 4 files changed, 152 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 141a5c1..81cf10b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7819,7 +7819,11 @@ enum {
> #define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
> #define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
> #define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
> +#define TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
> #define TRANS_DDI_BFI_ENABLE(1<<4)
> +#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
> +#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
>
> /* DisplayPort Transport Control */
> #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cd6fedd..bd8293d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
> *crtc)
> temp |= TRANS_DDI_MODE_SELECT_HDMI;
> else
> temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (IS_GEMINILAKE(dev_priv))
> + temp = intel_hdmi_handle_source_scrambling(
> + intel_encoder,
> + &intel_crtc->config->base.adjusted_mode, temp);
> } else if (type == INTEL_OUTPUT_ANALOG) {
> temp |= TRANS_DDI_MODE_SELECT_FDI;
> temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> @@ -1843,6 +1848,21 @@ static void intel_enable_ddi(struct intel_encoder
> *intel_encoder,
> struct intel_digital_port *intel_dig_port =
> enc_to_dig_port(encoder);
>
> + if (IS_GEMINILAKE(dev_priv)) {
> + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> + /*
> + * GLK sports a native HDMI 2.0 controller. If required
> + * clock rate is > 340 Mhz && scrambling is supported
> + * by sink, enable scrambling before enabling the
> + * HDMI 2.0 port. The sink can choose to disable the
> + * scrambling if it doesn't detect a scrambled within
> + * 100 ms.
> + */
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + conn_state->connector,
> + crtc->config, true);
> + }
> +
> /* In HDMI/DVI mode, the port width, and swing/emphasis values
>* are ignored so nothing special needs to be done besides
>* enabling the port.
> @@ -1875,6 +1895,14 @@ static void intel_disable_ddi(struct intel_encoder
> *intel_encoder,
> if (old_crtc_state->has_audio)
> intel_audio_codec_disable(intel_encoder);
>
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> +
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + old_conn_state->connector,
> + intel_crtc->config, false);
> + }
> +
> if (type == INTEL_OUTPUT_EDP) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6e37fba..df0170b88 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -691,6 +691,12 @@ struct intel_crtc_state {
>
> /* Gamma mode programmed on the pipe */
> uint32_t gamma_mode;
> +
> + /* HDMI scrambling status (sink) */
> + bool scrambling;
>
Re: KMS backlight ABI proposition
+plasma-devel, as suggested by Martin Gräßlin. On 17/02/17 14:58, Martin Peres wrote: Hey everyone, We have been working towards exposing the backlight as a KMS property instead of relying on the backlight drivers. We have CC:ed the people we have found to be the more likely to be interested in the discussion but please add everyone you think would have some experience with this issue. == Introduction == We are trying to bring the same level of support for the backlight on both the xf86-video-intel and -modesetting DDX. Looking into the situation of the backlight, we identified these problems which are almost show-stoppers for -modesetting and wayland compositors: - There is no mapping between the backlight driver and DRM-connectors. This means that, in case there are multiple backlight drivers, the userspace has to have knowledge of the machine to know which driver should be used. See the priority list for the intel driver [0]. - The luminance curve of the backlight drivers is not specified, which can lead to a bad user experience: Little changes in the highest levels but drastic changes in the low levels. - Writing to the backlight driver still requires root rights. Given that the xserver and wayland compositors are now running root-less, this means we would need a complex dance involving a setuid helper [1]. Hans de Goede has already given a presentation about these issues at XDC2014. The slides are a good read[2]. [0] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259 [1] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348 [2] https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf == Proposal == Since David Hermann already worked on this and proposed what I consider being greats foundations for building towards a solution addressing the issues above, I will just ask you to read his original words: https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html == Open issues == Here are the open issues we have identified with the solution proposed by David: 1) Backlight device interoperability: How far should we support mixing the backlight device and brightness property? Should it be unidirectional or bi-directional? What about the start-up value exposed by the brightness property? 2) How many steps should be exposed: fixed or driver-dependent? 3) Expected output curve: power? luminance? Simply monotonically increasing? 4) Should the userspace be able to turn off the backlight? If so, how should it do it? What can we do to let the userspace distinguish between backlight off or on? 5) Should we expose to the userspace what is the current backlight power? Here is our current point of view on the matter: === 1) Backlight device interoperability === Since we need to keep backward compatibility of the backlight, we have to keep the current backlight drivers. Here are possible options: - Exclusive access: Unregister a backlight device when the drm brightness property is requested/used; - Unidirectional access: When writing to the backlight property, update the backlight device; - Bi-directional access: Propagate back changes from the backlight device to the property's value. Being bi-directional would be of course the best, but this requires that both drivers have the same number of steps, otherwise, we may write a value to the property, but get another one when reading it right after, due to the non-bijective nature of the transformation. Uni-directional would work in all cases, with the caveat that mixing calls to the KMS property and the backlight device will not be supported (changes mades through the sysfs interface of the backlight driver will not be reflected in the KMS property). At boot time, we should however initialize the value of the backlight property with a value close to what is currently set in the backlight driver. Giving exclusive access does not sound very good to me, as it would be hard for the userspace to deal with disappearing drivers... === 2) How many steps should be exposed === If the KMS property exposes the same number of steps as the backlight driver, it allows us to get a bijective function between the two interfaces, and allow a bi-directional communication. The downside of this is that it forces the userspace to deal with a variable number of steps which can range from 4 to 1k+. Also, the userspace would be able to handle the case where there are less steps than it would like to expose. If the KMS property exposes a fixed number of steps (say 100), it becomes easy for the userspace to express the wanted brightness. However, on drivers exposing less than these 100 steps, we cannot guarantee that any change in the value will produce any change. If there is only one possible value (on or off), the user may be trying the change the brightness, a GUI would show what is the expected backlight state,
Re: [PATCH 1/9] gpu: ipu-v3: remove AXI ID setting for IC channel
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote: > This is a pretty minor optimization for the IC channel to get > out-of-order AXI returns, but clashes with the AXI ID assignment > that needs to be done for the display channels on QuadPlus. > > Signed-off-by: Lucas Stach > --- > drivers/gpu/ipu-v3/ipu-image-convert.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c > b/drivers/gpu/ipu-v3/ipu-image-convert.c > index 805b6fa7b5f4..5e3cc6bd98fc 100644 > --- a/drivers/gpu/ipu-v3/ipu-image-convert.c > +++ b/drivers/gpu/ipu-v3/ipu-image-convert.c > @@ -671,8 +671,6 @@ static void init_idmac_channel(struct > ipu_image_convert_ctx *ctx, > ipu_ic_task_idma_init(chan->ic, channel, width, height, > burst_size, rot_mode); > > - ipu_cpmem_set_axi_id(channel, 1); > - The IC IDMAC channels were set to AXI ID 1 to avoid starving the scanout channels. AXI ID 0 is set to the highest QoS priority in imx6q_axi_init, AXI ID 1 is set slightly lower for that reason. This should be kept for all the non-plus models. > ipu_idmac_set_double_buffer(channel, ctx->double_buffering); > } > regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915: Dealing with 90° rotated display ?
Hi, On 16-02-17 17:58, Ville Syrjälä wrote: On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote: Hi, On 15-02-17 15:59, Ville Syrjälä wrote: On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote: Hi Jani, As discussed here: https://bugs.freedesktop.org/show_bug.cgi?id=94894 I've a mini-laptop which uses a phone-screen, so the native orientation of the screen is portrait, where as for a clam-shell device one wants it to be landscape. Ideally there would be a flag somewhere to tell the i915 driver that the panel is mounted 90° rotated in its bezel and have the i915 driver apply that rotation on top of whatever rotation userspace requests. So question is there already a place (variable) in the i915 driver where one can set such a rotation offset to apply on top of what userspace requests ? If not do you have any idea how feasible adding one would be and can you give me a few pointers / hints where to start with such a thing ? You could have a look at my branch (which I pointed out in the bug). Ok, so the patch that actually is relevant to this discussion (and not just a cleanup / bug-fix) seems to be: https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e Right ? Looks that way, yes. AFAICT that will make fbcon inherit the rotation setting of the primary plan on the primary crt. That may solve the original bug as reported, but not the case / device I'm talking about. What I would like to see is a "rotation offset" field somewhere to be applied to all rotations in a way which is hidden from userspace. Specifically the device I've has a screen which is 720x1280 in resolution, but I want userspace to see it as a 1280x720 screen because that is how it is used in the hardware. So I want a 90° rotation to be applied which is completely hidden from userspace. That's not necessarily the best way since rotation may impose additional restrictions on what the hardware can do. Which would mean that your 0 degree setting would no longer be the setting that should give the highest chance of success. That doesn't leave much chance of userspace being able to work out a fallback strategy when things don't succeed. Oh, and the cursor plane can't even do 90/270 degree rotation, so there's just no way to hide this fully. Ok, I see that sucks, but I understand. That said, I did once implement a "full pipe rotation" thing, and even added a knob into debugfs that allowed me to flip it without userspace being involved. That's just something I used for testing the rotation code initially. I just pushed some version of it here [1]. Obviously 90/270 effective rotation for the cursor still won't work. [1] git://github.com/vsyrjala/linux.git full_pipe_rotation So when userspace (e.g. the Xorg server + modesetting driver) asks for 0° degree rotation under the hood they get 90 applied, when they aks for the panel resolution they get 1280x720 instead of 720x1280. The idea was that userspace will inherit the initial rotation. That does work correctly at least with the intel ddx. Ah (userspace will inherit the initial rotation) I've yet to patch the kernel to set up an initial rotation for this, I will give this a try and see if that helps. Given that our rotation properties are per-plane, that would mean userspace would have to deduce that the entire screen is rotation by simply looking at the rotation of the primary plane. Or I suppose we could make the kernel use the same default rotation for all planes, even the disabled ines. I think having userspace inherit the setting of the primary plane is fine. Basically the idea is that the kernel as the HAL it is supposed to be (amongst other things) hide the hardware weirdness / quirk of using a portrait panel in a landscape bezel. As said we can't really hide without causing additional grief to userspace in the form of potential failures in configuring the planes/crtcs. Ack, not nice, but ack. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates
Use drm_plane_helper_check_state to clip raw user coordinates to crtc
bounds. This checks for full plane coverage and scaling already, so
we can drop some custom checks. Use the clipped coordinates everywhere.
Suggested-by: Ville Syrjälä
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Reverted check for negative crtc_x/y. Unsupported configurations will be
catched by the eba and ubo/vbo alignment checks. This is identical to v3.
---
drivers/gpu/drm/imx/ipuv3-plane.c | 80 +++
1 file changed, 38 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index e74a0ad52950c..bb2a7d7c8333f 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -70,8 +70,8 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
{
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
- int x = state->src_x >> 16;
- int y = state->src_y >> 16;
+ int x = state->src.x1 >> 16;
+ int y = state->src.y1 >> 16;
cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
BUG_ON(!cma_obj);
@@ -86,8 +86,8 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
- int x = state->src_x >> 16;
- int y = state->src_y >> 16;
+ int x = state->src.x1 >> 16;
+ int y = state->src.y1 >> 16;
cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
BUG_ON(!cma_obj);
@@ -105,8 +105,8 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
- int x = state->src_x >> 16;
- int y = state->src_y >> 16;
+ int x = state->src.x1 >> 16;
+ int y = state->src.y1 >> 16;
cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
BUG_ON(!cma_obj);
@@ -218,7 +218,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *fb = state->fb;
struct drm_framebuffer *old_fb = old_state->fb;
unsigned long eba, ubo, vbo, old_ubo, old_vbo;
+ bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
+ struct drm_rect clip;
int hsub, vsub;
+ int ret;
/* Ok to disable */
if (!fb)
@@ -232,44 +235,35 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ ret = drm_plane_helper_check_state(state, &clip,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ can_position, true);
+ if (ret)
+ return ret;
+
/* CRTC should be enabled */
if (!crtc_state->enable)
return -EINVAL;
- /* no scaling */
- if (state->src_w >> 16 != state->crtc_w ||
- state->src_h >> 16 != state->crtc_h)
- return -EINVAL;
-
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
- /* full plane doesn't support partial off screen */
- if (state->crtc_x || state->crtc_y ||
- state->crtc_w != crtc_state->adjusted_mode.hdisplay ||
- state->crtc_h != crtc_state->adjusted_mode.vdisplay)
- return -EINVAL;
-
/* full plane minimum width is 13 pixels */
- if (state->crtc_w < 13)
+ if (drm_rect_width(&state->dst) < 13)
return -EINVAL;
break;
case DRM_PLANE_TYPE_OVERLAY:
- if (state->crtc_x < 0 || state->crtc_y < 0)
- return -EINVAL;
-
- if (state->crtc_x + state->crtc_w >
- crtc_state->adjusted_mode.hdisplay)
- return -EINVAL;
- if (state->crtc_y + state->crtc_h >
- crtc_state->adjusted_mode.vdisplay)
- return -EINVAL;
break;
default:
- dev_warn(dev, "Unsupported plane type\n");
+ dev_warn(dev, "Unsupported plane type %d\n", plane->type);
return -EINVAL;
}
- if (state->crtc_h < 2)
+ if (drm_rect_height(&state->dst) < 2)
return -EINVAL;
/*
@@ -279,9 +273,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
* callback. The planes will be reenabled in plane's ->atomic_update
* callback.
*/
- if (old_fb && (state->src_w != old_state->src_w ||
-
[PATCH] drm: zte: fix static checker warning on variable 'fmt'
From: Shawn Guo
Commit 4e986d3705df ("drm: zte: add overlay plane support") introduces
the following static checker warning:
drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup()
warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'
Fix it by change 'fmt' type to integer.
Reported-by: Dan Carpenter
Fixes: 4e986d3705df ("drm: zte: add overlay plane support")
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 1d08ba381098..d646ac931663 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -159,7 +159,7 @@ static void zx_vl_rsz_setup(struct zx_plane *zplane,
uint32_t format,
void __iomem *rsz = zplane->rsz;
u32 src_chroma_w = src_w;
u32 src_chroma_h = src_h;
- u32 fmt;
+ int fmt;
/* Set up source and destination resolution */
zx_writel(rsz + RSZ_SRC_CFG, RSZ_VER(src_h - 1) | RSZ_HOR(src_w - 1));
@@ -203,7 +203,7 @@ static void zx_vl_plane_atomic_update(struct drm_plane
*plane,
u32 src_x, src_y, src_w, src_h;
u32 dst_x, dst_y, dst_w, dst_h;
uint32_t format;
- u32 fmt;
+ int fmt;
int num_planes;
int i;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates
Use drm_plane_helper_check_state to clip raw user coordinates to crtc
bounds. This checks for full plane coverage and scaling already, so
we can drop some custom checks. Use the clipped coordinates everywhere.
Suggested-by: Ville Syrjälä
Signed-off-by: Philipp Zabel
---
Changes since v5:
- Rebased onto drm-next to follow the s/fb->pixel_format/fb->format->format/
change.
---
drivers/gpu/drm/imx/ipuv3-plane.c | 80 +++
1 file changed, 38 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 8b5294d47ceee..ef31faaf5e165 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -70,8 +70,8 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
{
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
- int x = state->src_x >> 16;
- int y = state->src_y >> 16;
+ int x = state->src.x1 >> 16;
+ int y = state->src.y1 >> 16;
cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
BUG_ON(!cma_obj);
@@ -86,8 +86,8 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
- int x = state->src_x >> 16;
- int y = state->src_y >> 16;
+ int x = state->src.x1 >> 16;
+ int y = state->src.y1 >> 16;
cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
BUG_ON(!cma_obj);
@@ -105,8 +105,8 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
- int x = state->src_x >> 16;
- int y = state->src_y >> 16;
+ int x = state->src.x1 >> 16;
+ int y = state->src.y1 >> 16;
cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
BUG_ON(!cma_obj);
@@ -218,7 +218,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *fb = state->fb;
struct drm_framebuffer *old_fb = old_state->fb;
unsigned long eba, ubo, vbo, old_ubo, old_vbo;
+ bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
+ struct drm_rect clip;
int hsub, vsub;
+ int ret;
/* Ok to disable */
if (!fb)
@@ -232,44 +235,35 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ ret = drm_plane_helper_check_state(state, &clip,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ can_position, true);
+ if (ret)
+ return ret;
+
/* CRTC should be enabled */
if (!crtc_state->enable)
return -EINVAL;
- /* no scaling */
- if (state->src_w >> 16 != state->crtc_w ||
- state->src_h >> 16 != state->crtc_h)
- return -EINVAL;
-
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
- /* full plane doesn't support partial off screen */
- if (state->crtc_x || state->crtc_y ||
- state->crtc_w != crtc_state->adjusted_mode.hdisplay ||
- state->crtc_h != crtc_state->adjusted_mode.vdisplay)
- return -EINVAL;
-
/* full plane minimum width is 13 pixels */
- if (state->crtc_w < 13)
+ if (drm_rect_width(&state->dst) < 13)
return -EINVAL;
break;
case DRM_PLANE_TYPE_OVERLAY:
- if (state->crtc_x < 0 || state->crtc_y < 0)
- return -EINVAL;
-
- if (state->crtc_x + state->crtc_w >
- crtc_state->adjusted_mode.hdisplay)
- return -EINVAL;
- if (state->crtc_y + state->crtc_h >
- crtc_state->adjusted_mode.vdisplay)
- return -EINVAL;
break;
default:
- dev_warn(dev, "Unsupported plane type\n");
+ dev_warn(dev, "Unsupported plane type %d\n", plane->type);
return -EINVAL;
}
- if (state->crtc_h < 2)
+ if (drm_rect_height(&state->dst) < 2)
return -EINVAL;
/*
@@ -279,9 +273,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
* callback. The planes will be reenabled in plane's ->atomic_update
* callback.
*/
- if (old_fb && (state->src_w != old_state->src_w ||
- state->src_h != old_state->src_h ||
-
Re: [PATCH v5] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates
On Mon, 2017-02-20 at 14:30 +0100, Philipp Zabel wrote: > Use drm_plane_helper_check_state to clip raw user coordinates to crtc > bounds. This checks for full plane coverage and scaling already, so > we can drop some custom checks. Use the clipped coordinates everywhere. > > Suggested-by: Ville Syrjälä > Signed-off-by: Philipp Zabel Please ignore, I've sent a new version based on drm-next due to the removal of fb->pixel_format. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS backlight ABI proposition
On 20/02/17 12:46, Martin Peres wrote: +plasma-devel, as suggested by Martin Gräßlin. This reply also adds the current drivers/video/backlight maintainers (I forwarded the original mail to them separately, so I've been pretty brutal with the delete key when quoting the original mail). On 17/02/17 14:58, Martin Peres wrote: === 1) Backlight device interoperability === Since we need to keep backward compatibility of the backlight, we have to keep the current backlight drivers. Here are possible options: - Exclusive access: Unregister a backlight device when the drm brightness property is requested/used; - Unidirectional access: When writing to the backlight property, update the backlight device; - Bi-directional access: Propagate back changes from the backlight device to the property's value. Being bi-directional would be of course the best, but this requires that both drivers have the same number of steps, otherwise, we may write a value to the property, but get another one when reading it right after, due to the non-bijective nature of the transformation. I don't accept that bi-directional transfer requires the step range to be the same. Isn't all that is required is acceptance that both sides maintain a copy of the current value in their own number range and that if X is written to then Y may change value (i.e. when mapping between 0..100 and 0..10 then if 0..100 is at 11 and 0..10 gets 1 written then 0..100 is allowed to change to 10). I'd note also that the mechanisms inside backlight to support sysfs_notify would mean *implementing* bi-directional comms isn't too bloated even if the two sides used different number ranges. Uni-directional would work in all cases, with the caveat that mixing calls to the KMS property and the backlight device will not be supported (changes mades through the sysfs interface of the backlight driver will not be reflected in the KMS property). At boot time, we should however initialize the value of the backlight property with a value close to what is currently set in the backlight driver. Giving exclusive access does not sound very good to me, as it would be hard for the userspace to deal with disappearing drivers... +1 :-) == Current KMS ABI proposal == The current ABI proposal has mostly been proposed by Jani Nikula, as a result of his experience and our discussions. It takes the following approach: - Fixed number of steps (I think we should change it to expose the same number of steps) Fixing a large number of steps over an inflexible (lets say 8 level) backlight device creates a new problem. User actions to increase/decrease the backlight don't work unless the userspace knows the hardware step size... The 0..100 proposal below will encourage the userspace to implement hotkeys that jump by 9 (because 0 is reserved with a special meaning). and thus there will be deadspots where the hot key has no effect. - Uni-directional: KMS -> backlight See above. - Do not deal yet with 3) and 4): I have ideas, but I have been procrastinating long-enough to send this email and we already have much to discuss! Do any of those ideas involve adding *new* API to provide information to userspace to help it correct the curves (e.g. somewhat like ALSA)? It's not that I object to such an approach but I consider it pointless to present fixed range brightness levels if the userspace were to end up responsible for curve correction. - Does not expose the current backlight power as we want to let the kernel deal with DPMS on its own >> === ABI proposal === The brightness property MUST have values 0...100 inclusive. I'm somewhat unconvinced by re-ranging the hardware capability but if this is the way we want to go perhaps consider -1..100 as the range. There's a risk of bikeshedding here but -1 is a more obvious "special" value and it offers more flexibility for natural hotkey strides. The display brightness MUST be a monotonically increasing function of the brightness property. Brightness property value 1 MUST mean the minimum supported visible brightness. Brightness property value 100 MUST mean the maximum supported brightness. Brightness property value 0 SHOULD mean backlight off or equivalent for non-backlight brightness adjustment, typically completely black. Brightness property value 0 MUST NOT switch the display or pipe off [1]. If the hardware is not capable of supporting zero brightness, and the driver knows this, value 0 MUST be equal to value 1. If the driver does not know whether the hardware is capable of supporting zero brightness, the driver SHOULD err on the side of 0 not being off rather than 1 meaning off. In this case, value 0 is likely different from value 1, and the minimum brightness can only be reached via property value 0 [2]. If the brightness gets changed outside of the property interface, reading the property value MAY be out of sync with the actual brightness [3]. Already discuss
Re: [PATCH v2 1/7] dt-bindings: display: add STM32 LTDC driver
On 02/16/2017 04:15 AM, Rob Herring wrote:
> On Fri, Feb 10, 2017 at 04:24:28PM +0100, Yannick Fertre wrote:
>> Signed-off-by: Yannick Fertre
>> ---
>> .../devicetree/bindings/display/st,stm32-ltdc.txt | 37
>> ++
>> 1 file changed, 37 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>> b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>> new file mode 100644
>> index 000..b93e1c8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>> @@ -0,0 +1,37 @@
>> +* STMicroelectronics STM32 lcd-tft display controller
>> +
>> +- ltdc: lcd-tft display controller host
>> + must be a sub-node of st-display-subsystem
>> + Required properties:
>> + - compatible: "st,stm32-ltdc"
>
> Kind of generic. There's only one version for all stm32 parts?
Hi Rob,
ltdc is the IP use for all stm32. Several options could be set depending
on stm32.
Fortunately, ltdc contains several registers which describes all options.
Br
>
>> + - reg: Physical base address of the IP registers and length of memory
>> mapped region.
>> + - clocks: A list of phandle + clock-specifier pairs, one for each
>> +entry in 'clock-names'.
>> + - clock-names: A list of clock names. For ltdc it should contain:
>> + - "clk-lcd" for the clock feeding the output pixel clock & IP clock.
>> + - resets: reset to be used by the device (defined by use of RCC macro).
>> + Required nodes:
>> +- Video port for RGB output.
>> +
>> +Example:
>> +
>> +/ {
>> +...
>> +soc {
>> +...
>> +ltdc: stm32-ltdc@40016800 {
>
> display-controller@...
OK
>
>> +compatible = "st,stm32-ltdc";
>> +reg = <0x40016800 0x200>;
>> +interrupts = <88>, <89>;
>> +resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
>> +clocks = <&rcc 1 CLK_LCD>;
>> +clock-names = "lcd";
>> +status = "disabled";
>
> Don't need to show status in examples.
OK
>
>> +
>> +port {
>> +ltdc_out_rgb: endpoint {
>> +};
>> +};
>> +};
>> +};
>> +};
>> --
>> 1.9.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Engine
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> The Prefetch Resolve Engine is a prefetch and tile resolve engine
> which prefetches display data from DRAM to an internal SRAM region.
> It has a single clock for configuration register access and the
> functional units. A single shared interrupt is used for status and
> error signaling.
>
> The only external dependency is the SRAM region to use for the
> prefetch double buffer.
>
> Signed-off-by: Lucas Stach
> ---
> .../bindings/display/imx/fsl-imx-drm.txt | 26
> ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> index 971c3eedb1c7..1bd777d7c37d 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> @@ -53,6 +53,32 @@ ipu: ipu@1800 {
> };
> };
>
> +Freescale i.MX PRE (Prefetch Resolve Engine)
> +
> +
> +Required properties:
> +- compatible: should be "fsl,imx6qp-pre"
> +- reg: should be register base and length as documented in the
> + datasheet
> +- clocks : phandle to the PRE axi clock input, as described
> + in Documentation/devicetree/bindings/clock/clock-bindings.txt and
> + Documentation/devicetree/bindings/clock/imx6q-clock.txt.
> +- clock-names: should be "axi"
> +- interrupts: should contain the PRE interrupt
> +- fsl,ocram: phandle pointing to the mmio-sram device node, that should be
> + used for the PRE SRAM double buffer.
> +
> +example:
> +
> +pre@021c8000 {
> + compatible = "fsl,imx6qp-pre";
> + reg = <0x021c8000 0x1000>;
> + interrupts = ;
> + clocks = <&clks IMX6QDL_CLK_PRE0>;
> + clock-names = "axi";
> + fsl,ocram = <&ocram2>;
Nitpick: the CODA property for this is called iram. Should we do the
same here in case the PRE is later used on other SoCs that call their
on-chip SRAM differently?
There is no mention of OCRAM in the PRE chapter in the i.MX6QP reference
manual, but Figures 38-1 and 38-5 mention an "IRAM Double Buffer".
> +};
> +
> Parallel display support
>
>
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] gpu: ipu-v3: add driver for Prefetch Resolve Engine
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote: > This adds support for the i.MX6 QuadPlus PRE units. Currently only > linear prefetch into SRAM is supported, other modes of operation > like the tiled-to-linear conversion will be added later. > > Signed-off-by: Lucas Stach > --- > drivers/gpu/ipu-v3/Makefile | 2 +- > drivers/gpu/ipu-v3/ipu-pre.c | 290 > +++ > drivers/gpu/ipu-v3/ipu-prv.h | 11 ++ > 3 files changed, 302 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/ipu-v3/ipu-pre.c > > diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile > index 5f961416c4ee..8ae90de46b4d 100644 > --- a/drivers/gpu/ipu-v3/Makefile > +++ b/drivers/gpu/ipu-v3/Makefile > @@ -2,4 +2,4 @@ obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o > > imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \ > ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-image-convert.o \ > - ipu-smfc.o ipu-vdi.o > + ipu-pre.o ipu-smfc.o ipu-vdi.o > diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c > new file mode 100644 > index ..febe0cb8b094 > --- /dev/null > +++ b/drivers/gpu/ipu-v3/ipu-pre.c > @@ -0,0 +1,290 @@ > +/* > + * Copyright (c) 2017 Lucas Stach, Pengutronix > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms and conditions of the GNU General Public License, > + * version 2, as published by the Free Software Foundation. > + * > + * This program is distributed in the hope it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "ipu-prv.h" > + > +#define IPU_PRE_MAX_WIDTH2048 > +#define IPU_PRE_NUM_SCANLINES8 > + > +#define IPU_PRE_CTRL 0x000 > +#define IPU_PRE_CTRL_SET 0x004 > +#define IPU_PRE_CTRL_ENABLE (1 << 0) Single bit fields could use BIT(0) etc. > +#define IPU_PRE_CTRL_BLOCK_EN (1 << 1) > +#define IPU_PRE_CTRL_BLOCK_16 (1 << 2) > +#define IPU_PRE_CTRL_SDW_UPDATE (1 << 4) > +#define IPU_PRE_CTRL_VFLIP (1 << 5) > +#define IPU_PRE_CTRL_SO (1 << 6) > +#define IPU_PRE_CTRL_INTERLACED_FIELD (1 << 7) > +#define IPU_PRE_CTRL_HANDSHAKE_EN (1 << 8) > +#define IPU_PRE_CTRL_HANDSHAKE_LINE_NUM(v) ((v & 0x3) << 9) > +#define IPU_PRE_CTRL_HANDSHAKE_ABORT_SKIP_EN(1 << 11) > +#define IPU_PRE_CTRL_EN_REPEAT (1 << 28) > +#define IPU_PRE_CTRL_TPR_REST_SEL (1 << 29) > +#define IPU_PRE_CTRL_CLKGATE(1 << 30) > +#define IPU_PRE_CTRL_SFTRST (1 << 31) > + > +#define IPU_PRE_CUR_BUF 0x030 > + > +#define IPU_PRE_NEXT_BUF 0x040 > + > +#define IPU_PRE_TPR_CTRL 0x070 > +#define IPU_PRE_TPR_CTRL_TILE_FORMAT(v) ((v & 0xff) << 0) > +#define IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK 0xff > + > +#define IPU_PRE_PREFETCH_ENG_CTRL0x080 > +#define IPU_PRE_PREF_ENG_CTRL_PREFETCH_EN (1 << 0) > +#define IPU_PRE_PREF_ENG_CTRL_RD_NUM_BYTES(v) ((v & 0x7) << 1) > +#define IPU_PRE_PREF_ENG_CTRL_INPUT_ACTIVE_BPP(v) ((v & 0x3) << 4) > +#define IPU_PRE_PREF_ENG_CTRL_INPUT_PIXEL_FORMAT(v) ((v & 0x7) << 8) > +#define IPU_PRE_PREF_ENG_CTRL_SHIFT_BYPASS (1 << 11) > +#define IPU_PRE_PREF_ENG_CTRL_FIELD_INVERSE (1 << 12) > +#define IPU_PRE_PREF_ENG_CTRL_PARTIAL_UV_SWAP (1 << 14) > +#define IPU_PRE_PREF_ENG_CTRL_TPR_COOR_OFFSET_EN(1 << 15) > + > +#define IPU_PRE_PREFETCH_ENG_INPUT_SIZE 0x0a0 > +#define IPU_PRE_PREFETCH_ENG_INPUT_SIZE_WIDTH(v)((v & 0x) << 0) > +#define IPU_PRE_PREFETCH_ENG_INPUT_SIZE_HEIGHT(v) ((v & 0x) << 16) > + > +#define IPU_PRE_PREFETCH_ENG_PITCH 0x0d0 > +#define IPU_PRE_PREFETCH_ENG_PITCH_Y(v) ((v & 0x) << 0) > +#define IPU_PRE_PREFETCH_ENG_PITCH_UV(v)((v & 0x) << 16) > + > +#define IPU_PRE_STORE_ENG_CTRL 0x110 > +#define IPU_PRE_STORE_ENG_CTRL_STORE_EN (1 << 0) > +#define IPU_PRE_STORE_ENG_CTRL_WR_NUM_BYTES(v) ((v & 0x7) << 1) > +#define IPU_PRE_STORE_ENG_CTRL_OUTPUT_ACTIVE_BPP(v) ((v & 0x3) << 4) > + > +#define IPU_PRE_STORE_ENG_SIZE 0x130 > +#define IPU_PRE_STORE_ENG_SIZE_INPUT_WIDTH(v)
Re: [PATCH 2/2] drm/ast: Support AST2500
On 18 February 2017 at 22:22, Benjamin Herrenschmidt wrote: > On Sat, 2017-02-18 at 15:43 +, Emil Velikov wrote: >> >> Out of curiosity - can you try testing with and w/o the ddr_test_2500 >> bug fix(?). >> Would be interesting to see if any of the omitted code [in >> ast_dram_init_2500] has noticeable effect. > > Afaik, the original ddr_test_2500 from aspeed wasn't buggy, was it ? > I stand corrected - yes the original code did not have the [ddr_test_2500 always returns false] bug. Pardon, for my earlier blunder. Regards, Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
1.1.
When a sink that supports deep color is connected to the output, the
receiver will send EDIDs that advertise this capability, even if it
isn't possible with HDMI versions earlier than 1.3.
Currently the kernel is assuming that deep color is possible and the
sink displays an error.
This quirk will make sure that deep color isn't used with this
particular receiver.
Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
References: https://bugs.freedesktop.org/show_bug.cgi?id=99869
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 24e7b282f16c..d994ccf94f88 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -148,6 +148,9 @@ static const struct edid_quirk {
/* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
{ "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
+
+ /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
+ { "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
};
/*
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] gpu: ipu-v3: add driver for Prefetch Resolve Gasket
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> This adds support for the i.MX6 QUadPlus PRG unit. It glues together the
> IPU and the PRE units.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/ipu-v3/Makefile | 2 +-
> drivers/gpu/ipu-v3/ipu-prg.c | 413
> +++
> drivers/gpu/ipu-v3/ipu-prv.h | 3 +
> include/video/imx-ipu-v3.h | 15 ++
> 4 files changed, 432 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/ipu-v3/ipu-prg.c
>
> diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
> index 8ae90de46b4d..1ab9bceee755 100644
> --- a/drivers/gpu/ipu-v3/Makefile
> +++ b/drivers/gpu/ipu-v3/Makefile
> @@ -2,4 +2,4 @@ obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
>
> imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
> ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-image-convert.o \
> - ipu-pre.o ipu-smfc.o ipu-vdi.o
> + ipu-pre.o ipu-prg.o ipu-smfc.o ipu-vdi.o
> diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
> new file mode 100644
> index ..c1e1ab0ec5c5
> --- /dev/null
> +++ b/drivers/gpu/ipu-v3/ipu-prg.c
> @@ -0,0 +1,413 @@
> +/*
> + * Copyright (c) 2016-2017 Lucas Stach, Pengutronix
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ipu-prv.h"
> +
> +#define IPU_PRG_CTL 0x00
> +#define IPU_PRG_CTL_BYPASS(i) (1 << (0 + i))
> +#define IPU_PRG_CTL_SOFT_ARID_MASK 0x3
> +#define IPU_PRG_CTL_SOFT_ARID_SHIFT(i) (8 + i * 2)
> +#define IPU_PRG_CTL_SOFT_ARID(i, v) ((v & 0x3) << (8 + 2 * i))
> +#define IPU_PRG_CTL_SO(i) (1 << (16 + i))
> +#define IPU_PRG_CTL_VFLIP(i)(1 << (19 + i))
> +#define IPU_PRG_CTL_BLOCK_MODE(i) (1 << (22 + i))
> +#define IPU_PRG_CTL_CNT_LOAD_EN(i) (1 << (25 + i))
> +#define IPU_PRG_CTL_SOFTRST (1 << 30)
> +#define IPU_PRG_CTL_SHADOW_EN (1 << 31)
> +
> +#define IPU_PRG_STATUS 0x04
> +#define IPU_PRG_STATUS_BUFFER0_READY(i) (1 << (0 + i * 2))
> +#define IPU_PRG_STATUS_BUFFER1_READY(i) (1 << (1 + i * 2))
> +
> +#define IPU_PRG_QOS 0x08
> +#define IPU_PRG_QOS_ARID_MASK 0xf
> +#define IPU_PRG_QOS_ARID_SHIFT(i) (0 + i * 4)
> +
> +#define IPU_PRG_REG_UPDATE 0x0c
> +#define IPU_PRG_REG_UPDATE_REG_UPDATE (1 << 0)
> +
> +#define IPU_PRG_STRIDE(i)(0x10 + i * 0x4)
> +#define IPU_PRG_STRIDE_STRIDE_MASK 0x3fff
> +
> +#define IPU_PRG_CROP_LINE0x1c
> +
> +#define IPU_PRG_THD 0x20
> +
> +#define IPU_PRG_BADDR(i) (0x24 + i * 0x4)
> +
> +#define IPU_PRG_OFFSET(i)(0x30 + i * 0x4)
> +
> +#define IPU_PRG_ILO(i) (0x3c + i * 0x4)
> +
> +#define IPU_PRG_HEIGHT(i)(0x48 + i * 0x4)
> +#define IPU_PRG_HEIGHT_PRE_HEIGHT_MASK 0xfff
> +#define IPU_PRG_HEIGHT_PRE_HEIGHT_SHIFT 0
> +#define IPU_PRG_HEIGHT_IPU_HEIGHT_MASK 0xfff
> +#define IPU_PRG_HEIGHT_IPU_HEIGHT_SHIFT 16
> +
> +struct ipu_prg_channel {
> + boolenabled;
> + int used_pre;
> +};
> +
> +struct ipu_prg {
> + struct list_headlist;
> + struct device *dev;
> + int id;
> +
> + void __iomem*regs;
> + struct clk *clk_ipg, *clk_axi;
> + struct regmap *iomuxc_gpr;
> + struct ipu_pre *pres[3];
> +
> + struct ipu_prg_channel chan[3];
> +};
> +
> +static DEFINE_MUTEX(ipu_prg_list_mutex);
> +static LIST_HEAD(ipu_prg_list);
> +
> +struct ipu_prg *
> +ipu_prg_get_by_ipu_device(struct device *dev)
Same as for the PRE, I'd prefer this to be called "lookup" instead of
"get", and to pass the "fsl,prg" string from the IPU driver, to whose DT
binding it belongs.
> +{
> + struct device_node *prg_node = of_parse_phandle(dev->of_node,
> + "fsl,prg", 0);
> + struct ipu_prg *prg;
> +
> + mutex_lock(&ipu_prg_list_mutex);
> + list_for_each_entry(prg, &ipu_prg_list, list) {
> + if (prg_node == p
Re: imxdrm issue on SABRE Lite
Hi Dan, On Sat, 2017-02-11 at 21:09 +, Dan MacDonald wrote: > Hi Phillipp > > I'm having trouble getting xf86-video-armada working properly on a > Element 14 / Embest SABRE Lite board running Arch Linux with kernel > 4.9.8. I have been in touch with RMK and he's confident the crash > below is caused by a kernel issue relating to imxdrm and a null > pointer dereference. I can't reproduce this on v4.9.8 with a Nitrogen6X with 1280x800 LDVS panel and 1920x1080 HDMI monitor using modetest from libdrm. Does this only happen with X? Do you have framebuffer console emulation enabled? Does this still happen if you disable the LVDS panel in the device tree? > The first indiction of X/armada not being happy it that it only starts > in 720x480 when connected to a 4K HDMI display, and when I try > running: > > xrandr --output HDMI1 --mode 1920x1080 > > X crashes. > > Here's the serial console output for X loading and then crashing after > I try running that xrandr command: > > Arch Linux 4.9.8-1-ARCH (ttymxc1) > > alarm login: [ 19.197477] fec 2188000.ethernet eth0: Link is Up - > 1Gbps/Full - flow control rx/tx > [ 19.205165] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > [ 33.08] vgaarb: this pci device is not a vga device > [ 33.203520] vgaarb: this pci device is not a vga device > [ 33.447051] imx-ipuv3 240.ipu: DC stop timeout after 50 ms Does the "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch (https://patchwork.kernel.org/patch/9417683) do anything to improve the situation, besides removing the above warning? > [ 33.707042] [ cut here ] > [ 33.711682] WARNING: CPU: 1 PID: 316 at > drivers/gpu/drm/drm_atomic_helper.c:1140 > drm_atomic_helper_wait_for_vblanks+0x274/0x278 > [ 33.723187] [CRTC:24] vblank wait timed out > [ 33.727395] Modules linked in: snd_soc_sgtl5000 snd_soc_fsl_ssi > snd_soc_imx_sgtl5000 imx_pcm_fiq imx_pcm_dma snd_soc_fsl_asrc > snd_soc_fsl_asoc_card snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine > caam_jr imx_ipuv3_crtc snd_ac97_codec coda v4l2_mem2mem > videobuf2_dma_contig ac97_bus imx_ipu_v3 snd_soc_imx_audmux snd_pcm > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core > dw_hdmi_imx caam imx2_wdt ofpart spi_imx evdev dw_hdmi etnaviv imx_ldb > pwm_imx snd_timer parallel_display uio_pdrv_genirq uio imxdrm > sch_fq_codel ip_tables x_tables > [ 33.776237] CPU: 1 PID: 316 Comm: Xorg Not tainted 4.9.8-1-ARCH #1 > [ 33.782419] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) > [ 33.788965] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 33.796719] [] (show_stack) from [] > (dump_stack+0x88/0x9c) > [ 33.803951] [] (dump_stack) from [] (__warn+0xe8/0x100) > [ 33.810919] [] (__warn) from [] > (warn_slowpath_fmt+0x48/0x6c) > [ 33.818410] [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks+0x274/0x278) > [ 33.828516] [] (drm_atomic_helper_wait_for_vblanks) from > [] (imx_drm_atomic_commit_tail+0x48/0x58 [imxdrm]) > [ 33.840004] [] (imx_drm_atomic_commit_tail [imxdrm]) from > [] (commit_tail+0x40/0x5c) > [ 33.849489] [] (commit_tail) from [] > (drm_atomic_helper_commit+0x94/0xd8) > [ 33.858019] [] (drm_atomic_helper_commit) from > [] (drm_atomic_helper_set_config+0x78/0x9c) > [ 33.868028] [] (drm_atomic_helper_set_config) from > [] (drm_mode_set_config_internal+0x58/0xdc) > [ 33.878382] [] (drm_mode_set_config_internal) from > [] (drm_mode_setcrtc+0x4a4/0x550) > [ 33.887867] [] (drm_mode_setcrtc) from [] > (drm_ioctl+0x214/0x44c) > [ 33.895704] [] (drm_ioctl) from [] > (do_vfs_ioctl+0xac/0x980) > [ 33.903104] [] (do_vfs_ioctl) from [] > (SyS_ioctl+0x6c/0x7c) > [ 33.910422] [] (SyS_ioctl) from [] > (ret_fast_syscall+0x0/0x3c) > [ 33.918023] ---[ end trace e8a77aa320be7e55 ]--- > [ 43.997066] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* > [CRTC:24:crtc-0] flip_done timed out > [ 55.517063] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* > [CRTC:24:crtc-0] flip_done timed out > [ 56.958264] alloc_contig_range: [4d0b7, 4d0b8) PFNs busy > [ 90.896615] usb 1-1.2.3: new low-speed USB device number 6 using ci_hdrc > [ 91.050796] usb 1-1.2.3: New USB device found, idVendor=0458, > idProduct=003a > [ 91.057888] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [ 91.065382] usb 1-1.2.3: Product: Optical Mouse > [ 91.069944] usb 1-1.2.3: Manufacturer: Genius > [ 91.082071] input: Genius Optical Mouse as > /devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/0003:0458:003A.0003/input/input3 > [ 91.098116] hid-generic 0003:0458:003A.0003: input,hidraw2: USB HID > v1.11 Mouse [Genius Optical Mouse] on usb-ci_hdrc.1-1.2.3/input0 > [ 91.162048] mousedev: PS/2 mouse device common for all mice > [ 214.765689] imx-ipuv3 240.ipu: DC stop timeout after 50 ms > [ 214.825688] Unable to handle kernel NULL pointer dereference at > virtual address 0
[PATCH v3 7/7] ARM: configs: stm32: ADD LDTC support
This patch adds STM32 LTDC support & simple panel support in stm32_defconfig file Signed-off-by: Yannick Fertre --- arch/arm/configs/stm32_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index e995209..d6a00b8 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -70,3 +70,8 @@ CONFIG_MAGIC_SYSRQ=y # CONFIG_FTRACE is not set CONFIG_CRC_ITU_T=y CONFIG_CRC7=y +CONFIG_DRM=y +CONFIG_DRM_ST=y +CONFIG_DRM_PANEL=y +CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
Signed-off-by: Yannick Fertre --- .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt new file mode 100644 index 000..f59e3c4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt @@ -0,0 +1,7 @@ +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel + +Required properties: +- compatible: should be "ampire,am-480272h3tmqw-t01h" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/7] ARM: dts: stm32: Add ltdc support on stm32f429 MCU
Add LTDC (Lcd-tft Display Controller) support.
Signed-off-by: Yannick Fertre
---
arch/arm/boot/dts/stm32f429.dtsi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..4cd8244 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,6 +48,8 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include
+#include
+#include
/ {
clocks {
@@ -206,7 +208,7 @@
reg = <0x40007000 0x400>;
};
- pin-controller {
+ pinctrl: pin-controller {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,stm32f429-pinctrl";
@@ -426,6 +428,21 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+ ltdc: display-controller@40016800 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x40016800 0x200>;
+ interrupts = <88>, <89>;
+ resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
+ clocks = <&rcc 1 CLK_LCD>;
+ clock-names = "lcd";
+ status = "disabled";
+
+ port {
+ ltdc_out_rgb: endpoint {
+ };
+ };
+ };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H
Add simple-panel support for the Ampire AM-480272H3TMQW-T01H,
which is a 4.3" WQVGA panel.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-simple.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..ee5d2ff 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -386,6 +386,32 @@ static void panel_simple_shutdown(struct device *dev)
panel_simple_disable(&panel->base);
}
+static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 2,
+ .hsync_end = 480 + 2 + 41,
+ .htotal = 480 + 2 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 2,
+ .vsync_end = 272 + 2 + 10,
+ .vtotal = 272 + 2 + 10 + 2,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc ampire_am_480272h3tmqw_t01h = {
+ .modes = &ire_am_480272h3tmqw_t01h_mode,
+ .num_modes = 1,
+ .bpc = 8,
+
+ .size = {
+ .width = 105,
+ .height = 67,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
.clock = 3,
.hdisplay = 800,
@@ -1715,6 +1741,9 @@ static void panel_simple_shutdown(struct device *dev)
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "ampire,am-480272h3tmqw-t01h",
+ .data = &ire_am_480272h3tmqw_t01h,
+ }, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
}, {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] dt-bindings: display: add STM32 LTDC driver
Signed-off-by: Yannick Fertre
---
.../devicetree/bindings/display/st,stm32-ltdc.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
new file mode 100644
index 000..e8d39c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -0,0 +1,36 @@
+* STMicroelectronics STM32 lcd-tft display controller
+
+- ltdc: lcd-tft display controller host
+ must be a sub-node of st-display-subsystem
+ Required properties:
+ - compatible: "st,stm32-ltdc"
+ - reg: Physical base address of the IP registers and length of memory mapped
region.
+ - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+ - clock-names: A list of clock names. For ltdc it should contain:
+ - "clk-lcd" for the clock feeding the output pixel clock & IP clock.
+ - resets: reset to be used by the device (defined by use of RCC macro).
+ Required nodes:
+- Video port for RGB output.
+
+Example:
+
+/ {
+ ...
+ soc {
+ ...
+ ltdc: display-controller@40016800 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x40016800 0x200>;
+ interrupts = <88>, <89>;
+ resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
+ clocks = <&rcc 1 CLK_LCD>;
+ clock-names = "lcd";
+
+ port {
+ ltdc_out_rgb: endpoint {
+ };
+ };
+ };
+ };
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] ARM: dts: stm32: Enable ltdc & simple panel on stm32f429-Eval board
Enable ltdc & enable am-480272h3tmqw-t01h panel.
Signed-off-by: Yannick Fertre
---
arch/arm/boot/dts/stm32429i-eval.dts | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 601a22a..5a5f941 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -110,6 +110,52 @@
clocks = <&rcc 0 30>;
clock-names = "main_clk";
};
+
+ panel_rgb: panel-rgb {
+ compatible = "ampire,am-480272h3tmqw-t01h";
+ status = "okay";
+ port {
+ panel_in_rgb: endpoint {
+ remote-endpoint = <;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ pinctrl_ltdc: ltdc@0 {
+ pins {
+ pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ slew-rate = <2>;
+ };
+ };
};
&clk_hse {
@@ -146,3 +192,16 @@
pinctrl-names = "default";
status = "okay";
};
+
+;
+ pinctrl-names = "default";
+ dma-ranges;
+
+ port {
+ ltdc_out_rgb: endpoint {
+ remote-endpoint = <&panel_in_rgb>;
+ };
+ };
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] STM32 LCD-TFT display controller
Version 3: - Update "st,stm32-ltdc.txt" binding. - Add a commit to "ARM: configs: stm32: ADD LDTC support" patch. Version 2: - Rename driver directory from st to stm. - Rename compatiblity from st,ltdc to st,stm32-ltdc. - Remove compatibility st,display-subsystem. - Rename driver from st-drm to stm-drm. - Rework probe sequence & remove display-subsystem part. - I keep clock name which is necessary for devm_regmap_init_mmio_clk call. Version 1: - Initial commit The purpose of this set of patches is to add a new driver for stm32f429. This driver was developed and tested on evaluation board stm32429i. Stm32f4 is a MCU platform which don't have MMU so the last patches developed by Benjamin Gaignard regarding "DRM: allow to use mmuless devices" are necessary. The board stm429i embeds a Ampire AM-480272H3TMQW-T01H screen. A new simple panel am-480272h3tmqw-t01h have been added to support it. Yannick Fertre (7): dt-bindings: display: add STM32 LTDC driver drm/st: Add STM32 LTDC driver dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H ARM: dts: stm32: Add ltdc support on stm32f429 MCU ARM: dts: stm32: Enable ltdc & simple panel on stm32f429-Eval board ARM: configs: stm32: ADD LDTC support .../display/panel/ampire,am-480272h3tmqw-t01h.txt |7 + .../devicetree/bindings/display/st,stm32-ltdc.txt | 36 + arch/arm/boot/dts/stm32429i-eval.dts | 59 + arch/arm/boot/dts/stm32f429.dtsi | 19 +- arch/arm/configs/stm32_defconfig |5 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/panel/panel-simple.c | 29 + drivers/gpu/drm/stm/Kconfig| 14 + drivers/gpu/drm/stm/Makefile |7 + drivers/gpu/drm/stm/drv.c | 232 drivers/gpu/drm/stm/drv.h | 24 + drivers/gpu/drm/stm/ltdc.c | 1381 drivers/gpu/drm/stm/ltdc.h | 22 + 14 files changed, 1837 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt create mode 100644 drivers/gpu/drm/stm/Kconfig create mode 100644 drivers/gpu/drm/stm/Makefile create mode 100644 drivers/gpu/drm/stm/drv.c create mode 100644 drivers/gpu/drm/stm/drv.h create mode 100644 drivers/gpu/drm/stm/ltdc.c create mode 100644 drivers/gpu/drm/stm/ltdc.h -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/7] drm/st: Add STM32 LTDC driver
This patch adds support for the STM32 LCD-TFT display controller.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/stm/Kconfig | 14 +
drivers/gpu/drm/stm/Makefile |7 +
drivers/gpu/drm/stm/drv.c| 232 +++
drivers/gpu/drm/stm/drv.h| 24 +
drivers/gpu/drm/stm/ltdc.c | 1381 ++
drivers/gpu/drm/stm/ltdc.h | 22 +
8 files changed, 1683 insertions(+)
create mode 100644 drivers/gpu/drm/stm/Kconfig
create mode 100644 drivers/gpu/drm/stm/Makefile
create mode 100644 drivers/gpu/drm/stm/drv.c
create mode 100644 drivers/gpu/drm/stm/drv.h
create mode 100644 drivers/gpu/drm/stm/ltdc.c
create mode 100644 drivers/gpu/drm/stm/ltdc.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 90bc65d..b6dea28 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -237,6 +237,8 @@ source "drivers/gpu/drm/fsl-dcu/Kconfig"
source "drivers/gpu/drm/tegra/Kconfig"
+source "drivers/gpu/drm/stm/Kconfig"
+
source "drivers/gpu/drm/panel/Kconfig"
source "drivers/gpu/drm/bridge/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 92de399..a4bcb95 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_DRM_BOCHS) += bochs/
obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
obj-$(CONFIG_DRM_MSM) += msm/
obj-$(CONFIG_DRM_TEGRA) += tegra/
+obj-$(CONFIG_DRM_STM) += stm/
obj-$(CONFIG_DRM_STI) += sti/
obj-$(CONFIG_DRM_IMX) += imx/
obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
new file mode 100644
index 000..2b91db6
--- /dev/null
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -0,0 +1,14 @@
+config DRM_STM
+ tristate "DRM Support for STMicroelectronics SoC Series"
+ depends on DRM && (ARCH_STM32 || ARCH_MULTIPLATFORM)
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_PANEL
+ select VIDEOMODE_HELPERS
+ select FB_PROVIDE_GET_FB_UNMAPPED_AREA
+ help
+ Choose this option if you have an ST STMicroelectronics SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called stm-drm.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
new file mode 100644
index 000..e114d45
--- /dev/null
+++ b/drivers/gpu/drm/stm/Makefile
@@ -0,0 +1,7 @@
+ccflags-y := -Iinclude/drm
+
+stm-drm-y := \
+ drv.o \
+ ltdc.o
+
+obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
new file mode 100644
index 000..d98b6a1
--- /dev/null
+++ b/drivers/gpu/drm/stm/drv.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu
+ * Yannick Fertre
+ * Fabien Dessenne
+ * Mickael Reulier
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "drv.h"
+#include "ltdc.h"
+
+#define DRIVER_NAME"stm"
+#define DRIVER_DESC"STMicroelectronics SoC DRM"
+#define DRIVER_DATE"20170209"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCH_LEVEL 0
+
+#define ST_MAX_FB_WIDTH2048
+#define ST_MAX_FB_HEIGHT 2048 /* same as width to handle orientation */
+
+static void drv_output_poll_changed(struct drm_device *ddev)
+{
+ struct stm_private *priv = ddev->dev_private;
+
+ drm_fbdev_cma_hotplug_event(priv->fbdev);
+}
+
+static const struct drm_mode_config_funcs drv_mode_config_funcs = {
+ .fb_create = drm_fb_cma_create,
+ .output_poll_changed = drv_output_poll_changed,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static const struct file_operations drv_driver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release = drm_release,
+ .unlocked_ioctl = drm_ioctl,
+ .compat_ioctl = drm_compat_ioctl,
+ .poll = drm_poll,
+ .read = drm_read,
+ .mmap = drm_gem_cma_mmap,
+ .get_unmapped_area = drm_gem_cma_get_unmapped_area,
+};
+
+static void drv_lastclose(struct drm_device *ddev)
+{
+ struct stm_private *priv = ddev->dev_private;
+
+ DRM_DEBUG("%s\n", __func__);
+
+ drm_fbdev_cma_restore_mode(priv->fbdev);
+}
+
+static struct drm_driver drv_driver = {
+ .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+ .lastclose = drv_lastclose,
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+ .patchlevel = DRIVER_PATCH_LEVEL,
+ .fops = &drv_driver_fops,
+ .dumb_cr
Re: KMS backlight ABI proposition
Cc'ing Daniel, Lee and Jingoo, the backlight subsystem maintainers. On 17/02/17 14:58, Martin Peres wrote: > Hey everyone, > > We have been working towards exposing the backlight as a KMS property > instead of relying on the backlight drivers. We have CC:ed the people we > have found to be the more likely to be interested in the discussion but > please add everyone you think would have some experience with this issue. First off, I welcome this effort, because I think we really need something like this. However, I had attempted to tackle this around the time of FOSDEM 2014 and even had a working prototype, but when discussing this on IRC there were a couple of senior DRM maintainers that objected to the idea and said it couldn't be done. I don't remember the exact details, but I think the objection was that my prototype was hooking up backlights essentially from devicetree links (via panels, in that case) and at the time the general opinion had been that it couldn't be done on x86 and therefore we weren't supposed to have it at all. You might want to check with Dave and Daniel explicitly to make sure they're on board this time. It seems like the general opinion might have changed in the meantime, so I'll keep my fingers crossed. > == Introduction == > > We are trying to bring the same level of support for the backlight on > both the xf86-video-intel and -modesetting DDX. > > Looking into the situation of the backlight, we identified these > problems which are almost show-stoppers for -modesetting and wayland > compositors: > > - There is no mapping between the backlight driver and DRM-connectors. > This means that, in case there are multiple backlight drivers, the > userspace has to have knowledge of the machine to know which driver > should be used. See the priority list for the intel driver [0]. This is a fairly trivial issue for ARM (and other device tree based architectures) because we explicitly link the backlight to the panel already. The prototype that I had would look at the panel and see if brightness support was implemented and expose that as a connector property. > - The luminance curve of the backlight drivers is not specified, which > can lead to a bad user experience: Little changes in the highest levels > but drastic changes in the low levels. I think this is something that the backlight framework should specify. It's fairly unlikely that you could get this right every time in the display driver. I suppose for something like x86 this might actually work, but I don't think it'll work on something like ARM where you'd have to encode this based on what backlight driver was actually being used. > - Writing to the backlight driver still requires root rights. Given > that the xserver and wayland compositors are now running root-less, this > means we would need a complex dance involving a setuid helper [1]. > > Hans de Goede has already given a presentation about these issues at > XDC2014. The slides are a good read[2]. > > [0] > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259 > > > [1] > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348 > > > [2] > https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf > > == Proposal == > > Since David Hermann already worked on this and proposed what I consider > being greats foundations for building towards a solution addressing the > issues above, I will just ask you to read his original words: > > https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html > > == Open issues == > > Here are the open issues we have identified with the solution proposed > by David: > > 1) Backlight device interoperability: How far should we support > mixing the backlight device and brightness property? Should it be > unidirectional or bi-directional? What about the start-up value > exposed by the brightness property? > > 2) How many steps should be exposed: fixed or driver-dependent? > > 3) Expected output curve: power? luminance? Simply monotonically > increasing? > > 4) Should the userspace be able to turn off the backlight? If so, how > should it do it? What can we do to let the userspace distinguish > between backlight off or on? > > 5) Should we expose to the userspace what is the current backlight > power? > > Here is our current point of view on the matter: > > === 1) Backlight device interoperability === > > Since we need to keep backward compatibility of the backlight, we have > to keep the current backlight drivers. > > Here are possible options: > > - Exclusive access: Unregister a backlight device when the drm > brightness property is requested/used; > - Unidirectional access: When writing to the backlight property, update > the backlight device; > - Bi-directional access: Propagate back changes from the backlight > device to the property's value. > > Being bi-directional would be
Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements
On Fri, Feb 17, 2017 at 04:43:41PM +0100, Maxime Ripard wrote: > On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote: > > Hello Maxime, > > > > Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: > > >> I was wondering about the following. Wasn't there some strict > > >> requirement about code going upstream, which also included that there > > >> was a full open-source driver stack for it? > > >> > > >> I don't see how this is the case for Mali, neither in the kernel, nor in > > >> userspace. I'm aware that the Mali kernel driver is open-source. But it > > >> is not upstream, maintained out of tree, and won't land upstream in its > > >> current form (no resemblence to a DRM driver at all). And let's not talk > > >> about the userspace part. > > >> > > >> So, why should this be here? > > > > > > The device tree is a representation of the hardware itself. The state > > > of the driver support doesn't change the hardware you're running on, > > > just like your BIOS/UEFI on x86 won't change the device it reports to > > > Linux based on whether it has a driver for it. > > > > Like Emil already said, the new bindings and the DT entries are solely > > introduced to support a proprietary out-of-tree module. > > No. This new binding and the DT entries are solely introduced to > describe a device found in a number of SoCs, just like any other DT > binding we have. > > > The current workflow when introducing new DT entries is the following: > > - upstream a driver that uses the entries > > - THEN add the new entries > > And that's never been the preferred workflow, for *any* patches. Actually it has. How else are you going to test that your driver really works? You've got to have both pieces before you can verify that they're both adequate. So the typical workflow is to: 1) define the bindings 2) write a driver that implements the bindings 3) add entries to device tree files Usually it doesn't matter in which order you do the above because they are all part of the same patch series. But that's not what you're doing here. The more general problem here is that you're providing device tree content (and therefore ABI) that's based on a binding which has no upstream users. So you don't actually have a way of validating that what you merge is going to be an adequate description. You're probably going to respond: "but DT describes hardware, so it must be known already, there won't be a need for changes". Unfortunately that is only partially true. We've had a number of occasions where it later turned out that a binding was in fact not an adequate description, and then we've had to jump through hoops in order to preserve backwards compatibility. That's already annoying enough if you've got in-tree users, but it's going to be even more painful if you start out with an out-of-tree user. All of that said, you've got an Acked-by from Rob and that's about as good as it's going to get. So I'm not going to NAK this. But I will caution against this, because I don't think you're doing yourself any favours with this. So perhaps the question that we should ask is this: what do you gain by merging this series? The fact remains that you don't have an upstream driver that implements this binding, so ultimately you're going to be carrying patches in some development tree anyway. Why not simply stash these patches into the same tree? That should be about the same amount of work for you and your users, but it has the advantage of not locking you into something that you may regret. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 96999] r600_shader.c:1590: warning: array subscript is above array bounds
https://bugs.freedesktop.org/show_bug.cgi?id=96999 Jan Ziak <0xe2.0x9a.0...@gmail.com> changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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] drm: drm_printer: add __printf validation
On Mon, 2017-02-20 at 12:17 +, Eric Engestrom wrote: > On Wednesday, 2017-02-15 15:33:18 -0800, Joe Perches wrote: > > drm_printf does not currently use the compiler to verify > > format and arguments. Make it do so. > > > > Miscellanea: > > > > o Add appropriate #include files for __printf and struct va_format > > o Convert dev_printk to dev_info > > I think these unrelated changes should be in 4 patches: > 1 - add annotation to check the format string against the arguments > (linux/compiler.h should be added here) > 2 - add missing linux/printk.h header for struct va_format > Note that I think a forward declaration is more appropriate here, as > we only use pointers to this struct in this file, we never try to > look inside. On the other hand: > 3 - drm_print.c needs the header in drm_printf(), but as a separate > patch > 4 - convert dev_printk to dev_info (you need to include linux/device.h > there) I am not a big fan of making trivial patches into a series. > You can add my r-b on all four patches when you send them to the list :) If you want to break it up, go ahead. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev
Hi Maxime, sorry, I have missed the discussion about the double buffering/virtual surface size patch series two weeks ago. My comments about the patch are inline: On Wed, Feb 15, 2017 at 05:19:08PM +0100, Maxime Ripard wrote: > From: Xinliang Liu Mabye you should take the authorship here. Taking the credit and the blame, because the patch was heavily modified by you and me. But I don't really know what the offical police about that is. > > This patch add a config to support to create multi buffer for cma fbdev. > Such as double buffer and triple buffer. > > Cma fbdev is convient to add a legency fbdev. And still many Android > devices use fbdev now and at least double buffer is needed for these > Android devices, so that a buffer flip can be operated. It will need > some time for Android device vendors to abondon legency fbdev. So multi > buffer for fbdev is needed. > > Signed-off-by: Xinliang Liu > [s.chr...@phytec.de: Picking patch from > https://lkml.org/lkml/2015/9/14/188] > Signed-off-by: Stefan Christ > Signed-off-by: Maxime Ripard Reviewed-by: Stefan Lengfeld My surname has changed from "Christ" to "Lengfeld" recently. So my review tag contains the new name. > --- > drivers/gpu/drm/Kconfig | 9 + > drivers/gpu/drm/drm_fb_helper.c | 10 ++ > 2 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index ebfe8404c25f..700c8b8e57a9 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -84,6 +84,15 @@ config DRM_FBDEV_EMULATION > > If in doubt, say "Y". > > +config DRM_FBDEV_OVERALLOC > + int "Overallocation of the fbdev buffer" > + depends on DRM_FBDEV_EMULATION > + default 100 > + help > + Defines the fbdev buffer overallocation in percent. Default > + is 100. Typical values for double buffering will be 200, > + triple buffering 300. > + > config DRM_LOAD_EDID_FIRMWARE > bool "Allow to specify an EDID data set instead of probing for it" > depends on DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index e934b541feea..c6de87abaca8 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -48,6 +48,12 @@ module_param_named(fbdev_emulation, drm_fbdev_emulation, > bool, 0600); > MODULE_PARM_DESC(fbdev_emulation, >"Enable legacy fbdev emulation [default=true]"); > > +static int drm_fbdev_overalloc = CONFIG_DRM_FBDEV_OVERALLOC; > +module_param(drm_fbdev_overalloc, int, 0444); Maybe the variable should be of type "uint" instead of "int". This would rule out the negative numbers error case. > +MODULE_PARM_DESC(drm_fbdev_overalloc, > + "Overallocation of the fbdev buffer (%) [default=" > + __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]"); > + > static LIST_HEAD(kernel_fb_helper_list); > static DEFINE_MUTEX(kernel_fb_helper_lock); > > @@ -1573,6 +1579,10 @@ static int drm_fb_helper_single_fb_probe(struct > drm_fb_helper *fb_helper, > sizes.fb_height = sizes.surface_height = 768; > } > > + /* Handle our overallocation */ > + sizes.surface_height *= drm_fbdev_overalloc; > + sizes.surface_height /= 100; > + The code can trigger an arithmetic overflow, but I think we can ignore this error case here. But there should be a check for drm_fbdev_overalloc not be smaller than 100. If it is smaller, the variable drm_fbdev_overalloc should have the default value "100". Otherwise the virtual surface height can be smaller than the physical height. This could trigger a lot of errors in existing code paths. Kind regards, Stefan Lengfeld > /* push down into drivers */ > ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes); > if (ret < 0) > -- > git-series 0.8.11 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] hdlcd gets confused about base address
Hi Russell, On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote: > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote: > > Something I also noticed is this: > > > > scanout_start = gem->paddr + plane->state->fb->offsets[0] + > > plane->state->crtc_y * plane->state->fb->pitches[0] + > > plane->state->crtc_x * bpp / 8; > > > > Surely this should be using src_[xy] (which are the position in the > > source - iow, memory, and not crtc_[xy] which is the position on the > > CRTC displayed window. To put it another way, the src_* define the > > region of the source material that is mapped onto a rectangular area > > on the display defined by crtc_*. > > This problem still exists... Sorry, looks like this fell through the cracks of us trying to fix the other issues you were seeing. I'm attaching a patch, please let me know if this works for you. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001 From: Liviu Dudau Date: Mon, 20 Feb 2017 17:44:42 + Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address The framebuffer start address uses the CRTC's x,y position rather than the source framebuffer's. Fix that. Reported-by: Russell King Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index 798a3cc480a2..4c1ab73d9e07 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane, struct drm_framebuffer *fb = plane->state->fb; struct hdlcd_drm_private *hdlcd; struct drm_gem_cma_object *gem; - u32 src_w, src_h, dest_w, dest_h; + u32 src_x, src_y, dest_w, dest_h; dma_addr_t scanout_start; if (!fb) return; - src_w = plane->state->src_w >> 16; - src_h = plane->state->src_h >> 16; + src_x = plane->state->src_x >> 16; + src_y = plane->state->src_y >> 16; dest_w = plane->state->crtc_w; dest_h = plane->state->crtc_h; gem = drm_fb_cma_get_gem_obj(fb, 0); scanout_start = gem->paddr + fb->offsets[0] + - plane->state->crtc_y * fb->pitches[0] + - plane->state->crtc_x * - fb->format->cpp[0]; + src_y * fb->pitches[0] + + src_x * fb->format->cpp[0]; hdlcd = plane->dev->dev_private; hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] hdlcd gets confused about base address
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote: > Hi Russell, > > On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote: > > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote: > > > Something I also noticed is this: > > > > > > scanout_start = gem->paddr + plane->state->fb->offsets[0] + > > > plane->state->crtc_y * plane->state->fb->pitches[0] + > > > plane->state->crtc_x * bpp / 8; > > > > > > Surely this should be using src_[xy] (which are the position in the > > > source - iow, memory, and not crtc_[xy] which is the position on the > > > CRTC displayed window. To put it another way, the src_* define the > > > region of the source material that is mapped onto a rectangular area > > > on the display defined by crtc_*. > > > > This problem still exists... > > Sorry, looks like this fell through the cracks of us trying to fix the > other issues you were seeing. I'm attaching a patch, please let me know > if this works for you. > > Best regards, > Liviu > > > > > -- > > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > > according to speedtest.net. > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ > >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001 > From: Liviu Dudau > Date: Mon, 20 Feb 2017 17:44:42 + > Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address > > The framebuffer start address uses the CRTC's x,y position rather > than the source framebuffer's. Fix that. > > Reported-by: Russell King > Signed-off-by: Liviu Dudau > --- > drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c > index 798a3cc480a2..4c1ab73d9e07 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane > *plane, > struct drm_framebuffer *fb = plane->state->fb; > struct hdlcd_drm_private *hdlcd; > struct drm_gem_cma_object *gem; > - u32 src_w, src_h, dest_w, dest_h; > + u32 src_x, src_y, dest_w, dest_h; > dma_addr_t scanout_start; > > if (!fb) > return; > > - src_w = plane->state->src_w >> 16; > - src_h = plane->state->src_h >> 16; > + src_x = plane->state->src_x >> 16; > + src_y = plane->state->src_y >> 16; This stuff should be using the clipped coordinates, not the user coordinates. And it doesn't look like this guy is even calling the clip helper thing. malidp seems to be calling that thing, but it still doesn't manage to program the hw with the right coordinates from what I can see. /me feels a bit like a broken record... > dest_w = plane->state->crtc_w; > dest_h = plane->state->crtc_h; > gem = drm_fb_cma_get_gem_obj(fb, 0); > scanout_start = gem->paddr + fb->offsets[0] + > - plane->state->crtc_y * fb->pitches[0] + > - plane->state->crtc_x * > - fb->format->cpp[0]; > + src_y * fb->pitches[0] + > + src_x * fb->format->cpp[0]; > > hdlcd = plane->dev->dev_private; > hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]); > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS backlight ABI proposition
On 17 February 2017 at 22:58, Martin Peres wrote: > Hey everyone, > > We have been working towards exposing the backlight as a KMS property > instead of relying on the backlight drivers. We have CC:ed the people we > have found to be the more likely to be interested in the discussion but > please add everyone you think would have some experience with this issue. > > == Introduction == > > We are trying to bring the same level of support for the backlight on both > the xf86-video-intel and -modesetting DDX. > > Looking into the situation of the backlight, we identified these problems > which are almost show-stoppers for -modesetting and wayland compositors: > > - There is no mapping between the backlight driver and DRM-connectors. This > means that, in case there are multiple backlight drivers, the userspace has > to have knowledge of the machine to know which driver should be used. See > the priority list for the intel driver [0]. > > - The luminance curve of the backlight drivers is not specified, which can > lead to a bad user experience: Little changes in the highest levels but > drastic changes in the low levels. > > - Writing to the backlight driver still requires root rights. Given that > the xserver and wayland compositors are now running root-less, this means we > would need a complex dance involving a setuid helper [1]. > > Hans de Goede has already given a presentation about these issues at > XDC2014. The slides are a good read[2]. > > [0] > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259 > > [1] > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348 > > [2] > https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf > > == Proposal == > > Since David Hermann already worked on this and proposed what I consider > being greats foundations for building towards a solution addressing the > issues above, I will just ask you to read his original words: > > https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html You might want to read the rest of that thread, the response posted by Matthew This is really messy and we made a decision to put the policy to pick which backlight driver into userspace because it's not something the kernel can figure out properly. Things might have changed now a bit with Win10 not using ACPI backlight controls if memory serves, but it's still an unholy mess. I think MBPs can expose 3 backlights (ACPI, gmux and driver) and only the gmux one does anything. How do you tackle that end of the problem, how does the i915/drm core know when the driver for the one backlight it needs has appeared, and is working, by deferring this to userspace we let the system load all the drivers and the policy of picking the correct one is left there. I'm not saying this is pretty,and we have libbacklight to "solve" the problems for generic userspace, but any solution is going to a be a lot uglier than you think. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99857] Radeon R7 M260/M265 *ERROR* amdgpu asic reset failed - Suspending notebook freezes it
https://bugs.freedesktop.org/show_bug.cgi?id=99857 --- Comment #1 from Nayan Deshmukh --- What is the kernel version that you are using? -- 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: KMS backlight ABI proposition
Hi,
On 20-02-17 20:27, Dave Airlie wrote:
On 17 February 2017 at 22:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be interested in the discussion but
please add everyone you think would have some experience with this issue.
== Introduction ==
We are trying to bring the same level of support for the backlight on both
the xf86-video-intel and -modesetting DDX.
Looking into the situation of the backlight, we identified these problems
which are almost show-stoppers for -modesetting and wayland compositors:
- There is no mapping between the backlight driver and DRM-connectors. This
means that, in case there are multiple backlight drivers, the userspace has
to have knowledge of the machine to know which driver should be used. See
the priority list for the intel driver [0].
- The luminance curve of the backlight drivers is not specified, which can
lead to a bad user experience: Little changes in the highest levels but
drastic changes in the low levels.
- Writing to the backlight driver still requires root rights. Given that
the xserver and wayland compositors are now running root-less, this means we
would need a complex dance involving a setuid helper [1].
Hans de Goede has already given a presentation about these issues at
XDC2014. The slides are a good read[2].
[0]
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259
[1]
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348
[2]
https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf
== Proposal ==
Since David Hermann already worked on this and proposed what I consider
being greats foundations for building towards a solution addressing the
issues above, I will just ask you to read his original words:
https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html
Jumping in in the middle of the thread here, I'll reply to the top-level post
later.
You might want to read the rest of that thread, the response posted by Matthew
This is really messy and we made a decision to put the policy to pick
which backlight
driver into userspace because it's not something the kernel can figure
out properly.
That is actually not really true, the only policy which in practice lives
in userspace is picking firmware type backlight interfaces over platform /
raw. Everything, really EVERYTHING else is already handled in the kernel,
using quirk tables in various places. David Herrmann's proposal actually
might improve upon this by having a default binding behavior in the kernel
and then allow fixing up the binding between backlight interface and
drm connector through udev rules triggered by hwdb entries, which means
(some (*)) new quirks could be handled in userspace.
Things might have changed now a bit with Win10 not using ACPI backlight controls
if memory serves, but it's still an unholy mess.
I think MBPs can expose 3 backlights (ACPI, gmux and driver) and only
the gmux one does anything.
Correct which is why we have this in the kernel:
drivers/gpu/drm/nouveau/nouveau_backlight.c :
if (apple_gmux_present()) {
NV_INFO(drm, "Apple GMUX detected: not registering Nouveau backlight
interface\n");
return 0;
}
How do you tackle that end of the problem, how does the i915/drm core
know when the
driver for the one backlight it needs has appeared, and is working, by
deferring this to
userspace we let the system load all the drivers and the policy of
picking the correct one
is left there.
Except in practice it is not, each desktop-environment and then some
other bits and pieces all have their own code to pick which backlight
interface to use. Which luckily all are as simple as prefer firmware
over platform/raw, since doing something more smart would be a big
mess as everything has its own code for handling this.
And to work around this we end up with things like hiding the
acpi_video interface on win10 devices since it usually is broken,
but as it has a type of firmware it will be preferred when visible.
Really we are already dealing with this in the kernel, it is one of
the things I've been spending my time on the last 3 years, since
I've blogged and presented about this people tend to know to find
me when it comes to bugs related to this, so I'm quite familiar
with this.
All this proposal does is make the userspace interface for backlight
suck less, we already have all the pain in the kernel anyways.
I'm not saying this is pretty,and we have libbacklight to "solve" the
problems for generic
userspace,
libbacklight ? Never heard of it, ah google gives me:
https://cgit.freedesktop.org/libbacklight/
Last commit 2011, number of users (AFAIK) 0, certainly not used by
gnome, upower, xf86-video-intel, etc.
> but any solution is going to a be a
Re: KMS backlight ABI proposition
Hi All, On 17-02-17 13:58, Martin Peres wrote: Hey everyone, We have been working towards exposing the backlight as a KMS property instead of relying on the backlight drivers. We have CC:ed the people we have found to be the more likely to be interested in the discussion but please add everyone you think would have some experience with this issue. == Introduction == We are trying to bring the same level of support for the backlight on both the xf86-video-intel and -modesetting DDX. Looking into the situation of the backlight, we identified these problems which are almost show-stoppers for -modesetting and wayland compositors: - There is no mapping between the backlight driver and DRM-connectors. This means that, in case there are multiple backlight drivers, the userspace has to have knowledge of the machine to know which driver should be used. See the priority list for the intel driver [0]. - The luminance curve of the backlight drivers is not specified, which can lead to a bad user experience: Little changes in the highest levels but drastic changes in the low levels. - Writing to the backlight driver still requires root rights. Given that the xserver and wayland compositors are now running root-less, this means we would need a complex dance involving a setuid helper [1]. Hans de Goede has already given a presentation about these issues at XDC2014. The slides are a good read[2]. [0] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259 [1] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348 [2] https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf == Proposal == Since David Hermann already worked on this and proposed what I consider being greats foundations for building towards a solution addressing the issues above, I will just ask you to read his original words: https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html == Open issues == Here are the open issues we have identified with the solution proposed by David: 1) Backlight device interoperability: How far should we support mixing the backlight device and brightness property? Should it be unidirectional or bi-directional? What about the start-up value exposed by the brightness property? 2) How many steps should be exposed: fixed or driver-dependent? 3) Expected output curve: power? luminance? Simply monotonically increasing? 4) Should the userspace be able to turn off the backlight? If so, how should it do it? What can we do to let the userspace distinguish between backlight off or on? 5) Should we expose to the userspace what is the current backlight power? Here is our current point of view on the matter: === 1) Backlight device interoperability === Since we need to keep backward compatibility of the backlight, we have to keep the current backlight drivers. Here are possible options: - Exclusive access: Unregister a backlight device when the drm brightness property is requested/used; - Unidirectional access: When writing to the backlight property, update the backlight device; - Bi-directional access: Propagate back changes from the backlight device to the property's value. Being bi-directional would be of course the best, but this requires that both drivers have the same number of steps, otherwise, we may write a value to the property, but get another one when reading it right after, due to the non-bijective nature of the transformation. Uni-directional would work in all cases, with the caveat that mixing calls to the KMS property and the backlight device will not be supported (changes mades through the sysfs interface of the backlight driver will not be reflected in the KMS property). At boot time, we should however initialize the value of the backlight property with a value close to what is currently set in the backlight driver. Giving exclusive access does not sound very good to me, as it would be hard for the userspace to deal with disappearing drivers... === 2) How many steps should be exposed === If the KMS property exposes the same number of steps as the backlight driver, it allows us to get a bijective function between the two interfaces, and allow a bi-directional communication. The downside of this is that it forces the userspace to deal with a variable number of steps which can range from 4 to 1k+. Also, the userspace would be able to handle the case where there are less steps than it would like to expose. If the KMS property exposes a fixed number of steps (say 100), it becomes easy for the userspace to express the wanted brightness. However, on drivers exposing less than these 100 steps, we cannot guarantee that any change in the value will produce any change. If there is only one possible value (on or off), the user may be trying the change the brightness, a GUI would show what is the expected backlight state, b
[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 Alex Deucher changed: What|Removed |Added Attachment #129726|text/x-log |text/plain mime type|| -- 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 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #14 from Alex Deucher --- (In reply to intermedi...@hotmail.com from comment #9) > Created attachment 129726 [details] > xorg new > > Hi Alex, > making more tests changing totally my inside pci setting and . > no ring issue but xorg crash totally if i select the radeon. the only way Let's start with the case where the kernel ring tests succeed. What slot was that? The kernel driver needs to work correctly before we try anything else. Now, in the case where the kernel driver loads properly with no errors, what happens next? What do you mean by "xorg crash totally if i select the radeon"? segfault? blank screen? Something else? Can you provide the xorg log when this happens? -- 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 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #15 from Alex Deucher --- (In reply to Christian Zigotzky from comment #12) > Hi All, > > I have the same problem. > > System: > > A-EON AmigaOne X1000 PowerPC > Nemo board with a P.A. Semi PA6T-1682M CPU > 8GB RAM > ASUS Radeon HD7790 1GB VRAM > ubuntu MATE 17.04 PowerPC (PPC32) with the kernels 4.10-rc8 (DRM 2.49.0) and > 4.9.10 (DRM 2.48.0) > Mesa 17.0.0 (In reply to Sinan Gürkan from comment #13) > (In reply to Christian Zigotzky from comment #12) > > > Hello everyone.. > > I also have the same problem.. > > A-EON Amiga X5000 PowerPC > Varisys Cyrus Board with P5020 > 8GB RAM > ASUS Radeon R7 265 > Ubuntu Mate 17.04 - Mesa 17.0.0 > Kernel 4.10-rc8 Please try to provide more details. It sounds like there may be several issues at play here. What do you mean by the same problem? ring test errors in the kernel driver? Some sort of Xorg "crash"? -- 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] [RFC] drm: Nerf DRM_CONTROL nodes
On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.
I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your control tool is
using (i.e. which ioctl), plus links to the source code for future
references. Also not sold on the immediate revert, this stuff has been
merged since months.
-Daniel
>
> /Thomas
>
>
> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>> Hi!
>>
>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>> node to tell DRM about the monitor layout...
>>
>> /Thomas
>>
>>
>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>>> Looking at the ioctl permission checks I noticed that it's impossible
>>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>>> also don't work, so no joy with dma-bufs.
>>>
>>> The only way to do anything with a control node is by drawing stuff
>>> into a dumb buffer and displaying that. I suspect control nodes are an
>>> entirely unused thing, and a cursory check shows that there does not
>>> seem to be any callers of drmOpenControl nor of the other drmOpen
>>> functions using DRM_MODE_CONTROL.
>>>
>>> Since I don't like dead uabi, let's remove it. But since this would be
>>> a really big change I think it's better to start out small by simply
>>> not registering anything. We can garbage-collect the dead code later
>>> on, once we're sure it's really not used anywhere.
>>>
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/drm_drv.c | 6 --
>>> 1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 6efdba4993fc..f085e28ffc6f 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>> goto err_free;
>>> }
>>>
>>> -if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>>> -ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>>> -if (ret)
>>> -goto err_minors;
>>> -}
>>> -
>>> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>> if (ret)
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
--
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: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to drm_crtc_helper_funcs
I thought about this some more, I think what we need to fix this mess
properly is:
- mode_valid helper callbacks for crtc, encoder, bridges, with the
same interface as for connectors.
- calling all these new mode_valid hooks from the probe helpers, but
with the restriction that we only reject a mode if all possible
crtc/encoders combos reject it. We need to filter by
possible_encoders/crtcs for these checks. Bridges have a fixed routing
to their encoder, so those are easy.
- add calls to mode_valid in the atomic helpers, right before we call
mode_fixup or atomic_check in drm_atomic_helper_check_modesets.
- convert drivers to move code from mode_fixup into mode_valid
wherever possible, to make sure we can share as much of the check
logic between probe and atomic comit code.
- update docs for all the hooks, plus update the overview sections accordingly.
I think this should give us a good approximation of nirvana. For I
long time I thought we could get away without adding mode_valid
everywhere, but in the probe paths we really can't fake the
adjusted_mode (and other atomic state), so adding dedicated hooks
which are called from both places is probably the only option.
-Daniel
On Tue, Feb 14, 2017 at 8:25 PM, John Stultz wrote:
> Currently, on the hikey board, we have the adv7511 bridge wired
> up to the kirin ade drm driver. Unfortunately, the kirin ade
> core cannot generate accurate byteclocks for all pixel clock
> values.
>
> Thus if a mode clock is selected that we cannot calculate a
> matching byteclock, the device will boot with a blank screen.
>
> Unfortunately, currently the only place we can properly check
> potential modes for this issue in the connector mode_valid
> helper. Again, hikey uses the adv7511 bridge, which is shared
> between a number of different devices, so its improper to put
> restrictions caused by the kirin drm driver in the adv7511
> logic.
>
> So this patch tries to correct for that, by adding some
> infrastructure so that the drm_crtc_helper_funcs can optionally
> implement a mode_valid check, so that the probe helpers can
> check to make sure there are not any restrictions at the crtc
> level as well.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Rob Clark
> Cc: Xinliang Liu
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Chen Feng
> Cc: Archit Taneja
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/gpu/drm/drm_probe_helper.c | 24
> include/drm/drm_modeset_helper_vtables.h | 26 ++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index cf8f012..a808348 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -170,6 +170,28 @@ drm_connector_detect(struct drm_connector *connector,
> bool force)
> connector_status_connected;
> }
>
> +static enum drm_mode_status
> +drm_connector_check_crtc_modes(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + struct drm_device *dev = connector->dev;
> + const struct drm_crtc_helper_funcs *crtc_funcs;
> + struct drm_crtc *c;
> +
> + if (mode->status != MODE_OK)
> + return mode->status;
> +
> + /* Check all the crtcs on a connector to make sure the mode is valid
> */
> + drm_for_each_crtc(c, dev) {
> + crtc_funcs = c->helper_private;
> + if (crtc_funcs && crtc_funcs->mode_valid)
> + mode->status = crtc_funcs->mode_valid(c, mode);
> + if (mode->status != MODE_OK)
> + break;
> + }
> + return mode->status;
> +}
> +
> /**
> * drm_helper_probe_single_connector_modes - get complete set of display
> modes
> * @connector: connector to probe
> @@ -338,6 +360,8 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> if (mode->status == MODE_OK && connector_funcs->mode_valid)
> mode->status = connector_funcs->mode_valid(connector,
>mode);
> +
> + mode->status = drm_connector_check_crtc_modes(connector,
> mode);
> }
>
> prune:
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 69c3974..53ca0e4 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -105,6 +105,32 @@ struct drm_crtc_helper_funcs {
> void (*commit)(struct drm_crtc *crtc);
>
> /**
> +* @mode_valid:
> +*
> +* Callback to validate a mode for a crtc, irrespective of the
> +* specific display configuration.
> +*
> +* This callback is used by the probe helpers to filter the
Re: [PATCH v2] drm/dp/mst: fix kernel oops when turning off secondary monitor
For next time around, pls cc dri-devel (it's in MAINTAINERS,
get_maintainers.pl gets it right) too.
-Daniel
On Mon, Dec 5, 2016 at 10:49 PM, Pierre-Louis Bossart
wrote:
> 100% reproducible issue found on SKL SkullCanyon NUC with two external
> DP daisy-chained monitors in DP/MST mode. When turning off or changing
> the input of the second monitor the machine stops with a kernel
> oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.
>
> This issue is traced to an inconsistent control flow in
> drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at
> the same time as 'req_payload.num_slots' is set to zero, but the pointer
> is dereferenced even when req_payload.num_slot is zero.
>
> The problematic dereference was introduced in commit dfda0df34
> ("drm/mst: rework payload table allocation to conform better")
> and may impact all versions since v3.18
>
> The fix suggested by Chris Wilson removes the kernel oops and was found to
> work well after 10mn of monkey-testing with the second monitor power and
> input buttons
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
> Cc: Dave Airlie
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index aa64448..f59771d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1817,7 +1817,7 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> mgr->payloads[i].vcpi = req_payload.vcpi;
> } else if (mgr->payloads[i].num_slots) {
> mgr->payloads[i].num_slots = 0;
> - drm_dp_destroy_payload_step1(mgr, port,
> port->vcpi.vcpi, &mgr->payloads[i]);
> + drm_dp_destroy_payload_step1(mgr, port,
> mgr->payloads[i].vcpi, &mgr->payloads[i]);
> req_payload.payload_state =
> mgr->payloads[i].payload_state;
> mgr->payloads[i].start_slot = 0;
> }
> --
> 2.7.4
>
--
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: KMS backlight ABI proposition
On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie wrote: > On 17 February 2017 at 22:58, Martin Peres > wrote: >> Hey everyone, >> >> We have been working towards exposing the backlight as a KMS property >> instead of relying on the backlight drivers. We have CC:ed the people we >> have found to be the more likely to be interested in the discussion but >> please add everyone you think would have some experience with this issue. >> >> == Introduction == >> >> We are trying to bring the same level of support for the backlight on both >> the xf86-video-intel and -modesetting DDX. >> >> Looking into the situation of the backlight, we identified these problems >> which are almost show-stoppers for -modesetting and wayland compositors: >> >> - There is no mapping between the backlight driver and DRM-connectors. This >> means that, in case there are multiple backlight drivers, the userspace has >> to have knowledge of the machine to know which driver should be used. See >> the priority list for the intel driver [0]. >> >> - The luminance curve of the backlight drivers is not specified, which can >> lead to a bad user experience: Little changes in the highest levels but >> drastic changes in the low levels. >> >> - Writing to the backlight driver still requires root rights. Given that >> the xserver and wayland compositors are now running root-less, this means we >> would need a complex dance involving a setuid helper [1]. >> >> Hans de Goede has already given a presentation about these issues at >> XDC2014. The slides are a good read[2]. >> >> [0] >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259 >> >> [1] >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348 >> >> [2] >> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf >> >> == Proposal == >> >> Since David Hermann already worked on this and proposed what I consider >> being greats foundations for building towards a solution addressing the >> issues above, I will just ask you to read his original words: >> >> https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html > > You might want to read the rest of that thread, the response posted by Matthew > > This is really messy and we made a decision to put the policy to pick > which backlight > driver into userspace because it's not something the kernel can figure > out properly. > > Things might have changed now a bit with Win10 not using ACPI backlight > controls > if memory serves, but it's still an unholy mess. > > I think MBPs can expose 3 backlights (ACPI, gmux and driver) and only > the gmux one > does anything. Even on non-Macs, hybrid laptops can be problematic. In some, the backlight control was muxed, in some it was not. Fortunately, muxed laptops are a thing of the past, at least for non-Macs. Alex > > How do you tackle that end of the problem, how does the i915/drm core > know when the > driver for the one backlight it needs has appeared, and is working, by > deferring this to > userspace we let the system load all the drivers and the policy of > picking the correct one > is left there. > > I'm not saying this is pretty,and we have libbacklight to "solve" the > problems for generic > userspace, but any solution is going to a be a lot uglier than you think. > > Dave. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #16 from intermedi...@hotmail.com --- Created attachment 129780 --> https://bugs.freedesktop.org/attachment.cgi?id=129780&action=edit my xorg log 7xxx (In reply to Alex Deucher from comment #14) > (In reply to intermedi...@hotmail.com from comment #9) > > Created attachment 129726 [details] > > xorg new > > > > Hi Alex, > > making more tests changing totally my inside pci setting and . > > no ring issue but xorg crash totally if i select the radeon. the only way > > Let's start with the case where the kernel ring tests succeed. What slot > was that? The kernel driver needs to work correctly before we try anything > else. Now, in the case where the kernel driver loads properly with no > errors, what happens next? What do you mean by "xorg crash totally if i > select the radeon"? segfault? blank screen? Something else? Can you > provide the xorg log when this happens? Hi alex now the only slot usable is the first one the 16x, before xorg 1.6 the only way for have not apple gpu was the 8x and there there was not issue. Now radeon 4xxx work on 16x with accelerations but freeze, radeon 5xxx and 6xxx work but have (cafedead)only fbdev run. 7xxx run no issue but glamor crash. I open another bug for the glamor. Michel Danze ask a gdb debug of xorg.. but im not able to made it in fedora if i run xorg on gdb i have a black screen with only a cursor on the top of the screen :-/ i will check if on ubuntu mate i will able to make a gdb of xorg. where there i have fence errors on ring 0 and 3 or glitched video. if i delete the glemoregl.so module xorg work i have desktop but no gpu accelerations. i atteached my xorg.log with 7750 The other guys i think have my same issue with radeonsi/amdgpu on ppc hw. why im sure it is an xorg issue or one of xorg component issue (cafedead),because on Lubuntu 14.04.5 i had kernel 4.9 and no issue but xorg was 1.6 -- 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 99857] Radeon R7 M260/M265 *ERROR* amdgpu asic reset failed - Suspending notebook freezes it
https://bugs.freedesktop.org/show_bug.cgi?id=99857 --- Comment #2 from Ederson --- In the `dmesg` attachment I've sent, I was using 4.9.8. I've just updated to 4.9.9 on Arch, and the issue is still here. -- 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: KMS backlight ABI proposition
I don't work on this anymore, but, even disregarding the mess that is ACPI backlight: I think when people start interfacing with the Backlight API, they wonder why it's not normalized. And then you start implementing it, and you realize that some writes don't do anything. And that when you read back, it's not what you just read. In any real implementation, I would want to know the step number that causes a level of brightness. And once I have that, I'm effectively doing 100/step to get a real hardware max level anyway, so I'm effectively working around the normalized behavior. These have all caused strange bugs for me in the past. Caching what's read and what's written sounds like a solution until you realize that userspace has plenty of DBus services and wrapper libraries to abstract out implementation details and it's hard to figure out where you should put that cache, and having it twice can also cause strange bugs. Normalizing to 100 would make simple cases subtly wrong and make complex cases impossible. Instead of normalizing to 100, I think we should expose a max level, and specify that's max brightness. Every single step in the range should have a visible difference in output lumens. 0 is minimum brightness -- this means the backlight is still on. Backlight being off should be -1 or we should recommend people use DPMS. This allows userspace to know everything it should and still provide for a 10-step "Brightness Up" button. On Mon, Feb 20, 2017 at 2:40 PM, Alex Deucher wrote: > On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie wrote: > > On 17 February 2017 at 22:58, Martin Peres > wrote: > >> Hey everyone, > >> > >> We have been working towards exposing the backlight as a KMS property > >> instead of relying on the backlight drivers. We have CC:ed the people we > >> have found to be the more likely to be interested in the discussion but > >> please add everyone you think would have some experience with this > issue. > >> > >> == Introduction == > >> > >> We are trying to bring the same level of support for the backlight on > both > >> the xf86-video-intel and -modesetting DDX. > >> > >> Looking into the situation of the backlight, we identified these > problems > >> which are almost show-stoppers for -modesetting and wayland compositors: > >> > >> - There is no mapping between the backlight driver and DRM-connectors. > This > >> means that, in case there are multiple backlight drivers, the userspace > has > >> to have knowledge of the machine to know which driver should be used. > See > >> the priority list for the intel driver [0]. > >> > >> - The luminance curve of the backlight drivers is not specified, which > can > >> lead to a bad user experience: Little changes in the highest levels but > >> drastic changes in the low levels. > >> > >> - Writing to the backlight driver still requires root rights. Given > that > >> the xserver and wayland compositors are now running root-less, this > means we > >> would need a complex dance involving a setuid helper [1]. > >> > >> Hans de Goede has already given a presentation about these issues at > >> XDC2014. The slides are a good read[2]. > >> > >> [0] > >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ > tree/src/backlight.c#n259 > >> > >> [1] > >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ > tree/src/backlight.c#n348 > >> > >> [2] > >> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ > backlight.pdf > >> > >> == Proposal == > >> > >> Since David Hermann already worked on this and proposed what I consider > >> being greats foundations for building towards a solution addressing the > >> issues above, I will just ask you to read his original words: > >> > >> https://lists.freedesktop.org/archives/dri-devel/2014- > September/067984.html > > > > You might want to read the rest of that thread, the response posted by > Matthew > > > > This is really messy and we made a decision to put the policy to pick > > which backlight > > driver into userspace because it's not something the kernel can figure > > out properly. > > > > Things might have changed now a bit with Win10 not using ACPI backlight > controls > > if memory serves, but it's still an unholy mess. > > > > I think MBPs can expose 3 backlights (ACPI, gmux and driver) and only > > the gmux one > > does anything. > > Even on non-Macs, hybrid laptops can be problematic. In some, the > backlight control was muxed, in some it was not. Fortunately, muxed > laptops are a thing of the past, at least for non-Macs. > > Alex > > > > > How do you tackle that end of the problem, how does the i915/drm core > > know when the > > driver for the one backlight it needs has appeared, and is working, by > > deferring this to > > userspace we let the system load all the drivers and the policy of > > picking the correct one > > is left there. > > > > I'm not saying this is pretty,and we have libbacklight to "solve" the > > problems for generic > > userspace, but any solution
Re: [PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph
2017년 02월 20일 17:55에 Krzysztof Kozlowski 이(가) 쓴 글: > On Mon, Feb 20, 2017 at 10:32 AM, Inki Dae wrote: >> >> >> 2017년 02월 20일 16:27에 Krzysztof Kozlowski 이(가) 쓴 글: >>> On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote: Hi Krzysztof, Can you merge patch 2 and 5 to your tree so that they can go to mainline? Otherwise, I can merge them to my tree if you give me acked-by. >>> >>> Hi, >>> >>> Hm? Why do you need them to be merged? Do you mean that the first >>> patch breaks not only ABI but also bisectability? Then this has to be >>> reworked because: >>> >>> 1. The DTS patches cannot go through non-DT tree so no, you cannot >>> take them into your branch. I will merge them according to point 4 >>> below. >>> 2. Bisectability has to be preserved. >>> 3. DTS changes in general should not be a dependency for driver changes. >> >> Krzysztof, >> >> I know that. I didn't check you gave a comment to Hoegun do rework this >> patch series. I just checked reviewed-by from Andrzej H. and thought no >> problem. >> >> Ideally you are right. DT changes should be no any dependency of driver >> changes but now Exynos DT is broken. > > I didn't receive any bug reports that Exynos DT is broken so I am > quite surprised hearing that. What do you mean by that? Wrong usage of Display relevant DT ABI is being fixed without the backward compatibility of the DT ABI. This means device driver doesn't consider old DT binding. So the use of old DTB binary will make kernel booting not to work correctly. > >> So if we have to keep the bisectability between driver and device tree >> patches - this means that all drivers should always keep the backward >> compatibility - then the drivers will be messed up. > > No, you are mixing two things. Bisectability is different than > backward compatibility. For the backward DT ABI compatibility, we > agreed that in this case it can be dropped. However bisectability is > something totally different. The DTS changes always go through > separate branch, so the driver has to be *always* ready for such case > and should still be fully bisectable. This is a general rule existing I meant that if this patch series considers old DT binding to keep the bisectability, then this driver would be messed up because the driver should try to bind same properties at different places and one of these two cases should be bound. So this driver doesn't consider the old DT binding, which means that the old DTB binary isn't compatible with this driver - exynos_drm_dsi.c. This means if only one side is merged then this driver wouldn't work correctly. > for long time and every deviation from the rule is pointed out by > arm-soc guys. Whenever I accepted breaking of this rule, I had hard > times with arm-soc so no - I am no longer giving up basic rule just > because developer might not care. Understood and reasonable. Seems I just hurried up. For the bisectability, this driver will have a little messed up code temporarily, and this messed up code will be removed after dt change is merged. This thing was really what I want to avoid - if even the messed up code should be keeped forever for the backward compatibility then it would be really terribble. :( Do you have a better idea? > > There are many ways to solve the bisectability problem. Recently for > example Marek found nice way to solve the PMU syscon handle dependency Thanks for share but this would be a different case. Thanks, Inki Dae > [1]. One can also merge first DTS changes and in next release, merge > the driver. > >> About this, we had a discussion and I think you agreed, >> https://patchwork.kernel.org/patch/9477957/ > > Again, this discussion was about DT ABI. Not bisectability. > >> Do you want the backward compatibility to be kept always when new dt binding >> relevant patch - which fixes up the wrong usage of dt binding - is posted? >> It would be good for the backward compatibility to be kept as long as we can >> do but there would be several cases to make the driver to be messed up like >> this patch series. > > Again, DT ABI not bisectability. > > Best regards, > Krzysztof > > [1] > https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/commit/?h=for-v4.11/drivers-soc-exynos-pmu-the-joy-never-ends&id=76640b84bd7a9d68c70d8bc8ecd02cdc4bd8855e > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 Bug ID: 99881 Summary: Lockup/Freezes on Laptop with switchable graphics Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: matt...@tech3.me Created attachment 129781 --> https://bugs.freedesktop.org/attachment.cgi?id=129781&action=edit dmesg log Hi, I have a HP Pavilion dv6-3111sa laptop (circa 2010) with 2 GPUs: 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] [1002:9712] 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] [1002:68e0] (rev ff) I am running Ubuntu 16.04.2 with kernel Ubuntu 4.8.0-36.36~16.04.1-generic 4.8.11 The screen usually freezes for a fraction of a second and then again a few seconds later. It may do this several times. In addition, the computer usually locks up before/after graphical login requiring a hard shutdown, although it doesn't always lock up. It seems to be preventing the computer from shutting down normally as well. This appears in dmesg output whenever a freeze occurs: 186.427140] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 186.431201] [drm] PCIE GART of 512M enabled (table at 0x0014C000). [ 186.431293] radeon :02:00.0: WB enabled [ 186.431301] radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x958c0f4f3c00 [ 186.431306] radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x958c0f4f3c0c [ 186.431703] radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xad3d81a1c418 [ 186.447926] [drm] ring test on 0 succeeded in 1 usecs [ 186.447934] [drm] ring test on 3 succeeded in 2 usecs [ 186.634582] [drm] ring test on 5 succeeded in 1 usecs [ 186.634592] [drm] UVD initialized successfully. [ 186.634648] [drm] ib test on ring 0 succeeded in 0 usecs [ 186.634686] [drm] ib test on ring 3 succeeded in 0 usecs [ 186.805724] [drm] ib test on ring 5 succeeded [ 186.838322] snd_hda_intel :02:00.1: Enabling via vga_switcheroo [ 186.942052] snd_hda_intel :02:00.1: CORB reset timeout#2, CORBRP = 65535 [ 196.033454] snd_hda_intel :02:00.1: Disabling via vga_switcheroo [ 196.646111] snd_hda_intel :02:00.1: Cannot lock devices! Adding radeon.runpm=0 to my boot cmdline solves the issues as a workaround. With previous ubuntu/kernel versions, the main issue was the freezing which would happen every seven seconds with the corresponding dmesg block. This would continue ad infinitum, although on rare occasions it would stop after many freezes. However with my current kernel this pattern doesn't seem to occur - it freezes a few times before the freezing stops and the freezes do not occur at regular intervals. I'm not sure if this is a graphics or sound issue from the dmesg block. There's also some ACPI errors in the dmesg log so maybe a firmware problem, or faulty hardware? I tried some lower level debugging previously but couldn't conclude anything. Thanks for any assistance. -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #1 from Matthew Fox --- Created attachment 129782 --> https://bugs.freedesktop.org/attachment.cgi?id=129782&action=edit lspci.log -- 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 v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph
On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote: > Hi Krzysztof, > > Can you merge patch 2 and 5 to your tree so that they can go to mainline? > Otherwise, I can merge them to my tree if you give me acked-by. Hi, Hm? Why do you need them to be merged? Do you mean that the first patch breaks not only ABI but also bisectability? Then this has to be reworked because: 1. The DTS patches cannot go through non-DT tree so no, you cannot take them into your branch. I will merge them according to point 4 below. 2. Bisectability has to be preserved. 3. DTS changes in general should not be a dependency for driver changes. 4 . Usually DTS patches wait for driver to be acked by devicetree maintainers or merging by driver maintainer. This did not happen so DTS patches wait. Also these were sent too late to merge for this cycle so the only chance is v4.12. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction
Hi Sean, Could you give some comments for this patch? Thanks Zain 在 2017/2/13 17:27, zain wang 写道: The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. But sometimes we will send a bare address packet to start the transaction, like drm_dp_i2c_xfer() show: .. /* Send a bare address packet to start the transaction. * Zero sized messages specify an address only (bare * address) transaction. */ msg.buffer = NULL; msg.size = 0; err = drm_dp_i2c_do_msg(aux, &msg); .. In this case, the msg->size is zero, so the num_transferred will be zero too. We can't return -EBUSY here, let's we return num_transferred if num_transferred equals msg->size. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 303083a..5384aca 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) msg->reply = DP_AUX_NATIVE_REPLY_ACK; - return num_transferred > 0 ? num_transferred : -EBUSY; + return (num_transferred == msg->size) ? num_transferred : -EBUSY; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] mm: cma: Export a few symbols
On Mon 13-02-17 14:44:16, Maxime Ripard wrote: > Hi Michal, > > On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote: > > [CC CMA people] > > > > On Thu 09-02-17 17:39:17, Maxime Ripard wrote: > > > Modules might want to check their CMA pool size and address for debugging > > > and / or have additional checks. > > > > > > The obvious way to do this would be through dev_get_cma_area and > > > cma_get_base and cma_get_size, that are currently not exported, which > > > results in a build failure. > > > > > > Export them to prevent such a failure. > > > > Who actually uses those exports. None of the follow up patches does > > AFAICS. > > This is for the ARM Mali GPU driver that is out of tree, unfortunately. We do not export symbols which do not have any in-tree users. > In one case (using the legacy fbdev API), the driver wants to (and > probably should) validate that the buffer as indeed been allocated > from the memory allocation pool. > > Rob suggested that instead of hardcoding it to cover the whole RAM > (which defeats the purpose of that check in the first place), we used > the memory-region bindings in the DT and follow that, which does work > great, but we still have to retrieve the base address and size of that > region, hence why this patches are needed. Anyway I would suggest talking to CMA people to find a better API for modules to use... -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
On Mon, Feb 20, 2017 at 9:09 AM, 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(+) Please use scripts/get_maintainer.pl to get the list of people to CC. Here you missed Javier, so I am worried that you run this driver not on mainline kernel but on some old one... Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] mxsfb fixes
On 02/20/2017 03:56 AM, Dave Airlie wrote: > On 19 February 2017 at 08:25, Marek Vasut wrote: >> On 02/17/2017 09:34 PM, Dave Airlie wrote: >>> On 17 February 2017 at 18:00, Marek Vasut wrote: On 02/17/2017 03:41 AM, Dave Airlie wrote: > On 16 February 2017 at 08:16, Marek Vasut wrote: >> Hi, >> >> I collected the MXSFB fixes, based on top of airlied/drm-fixes: > > At this stage I'd rather not give these to Linus, can you rebase them onto > drm-next, and resend, feel free to add stable cc's. > > Fixes like this should really be getting to me sooner than rc8. I know, sorry about that. I was totally overloaded in the past weeks. What about getting them to rc1, any chance for that ? >>> >>> Yes if you can rebase them onto drm-next. >> >> Ha, got it. Try the following: >> >> The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c: >> >> Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git >> c72a2ec8208b40683fbd2970684ffbf3a8c7d17e > > Nearly, put please use a tag :-) I'm sure you can pull this batch without a tag ;-) What do you have in mind for the next PR ? -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction
Hi Tomasz, 在 2017/2/20 10:40, Tomasz Figa 写道: Hi Zain, On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote: The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. But sometimes we will send a bare address packet to start the transaction, like drm_dp_i2c_xfer() show: .. /* Send a bare address packet to start the transaction. * Zero sized messages specify an address only (bare * address) transaction. */ msg.buffer = NULL; msg.size = 0; err = drm_dp_i2c_do_msg(aux, &msg); .. In this case, the msg->size is zero, so the num_transferred will be zero too. We can't return -EBUSY here, let's we return num_transferred if num_transferred equals msg->size. Please see my question inline. Signed-off-by: zain wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 303083a..5384aca 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) msg->reply = DP_AUX_NATIVE_REPLY_ACK; - return num_transferred > 0 ? num_transferred : -EBUSY; + return (num_transferred == msg->size) ? num_transferred : -EBUSY; I might be missing something but, looking at the code, I don't see any possibility of num_transferred ever being different than msg->size. To be honest, it doesn't seem to even make any sense keeping the local variable there, because msg->size can be simply always returned, as errors are handled by jumping to aux_error label. Yeah, I agree with you. The better way to fix this issue is to revert the changes https://patchwork.kernel.org/patch/9411711/ (returning num_transferred directly may be better here) Maybe we can revert the changes above with some new comment. @Sean, How do you think about Tomasz's comment? Thanks Zain Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/via: use get_user_pages_unlocked()
On 6 January 2017 at 07:09, Lorenzo Stoakes wrote:
>
> Adding Andrew, as this may be another less active corner of the corner,
> thanks!
Hi all,
Thought I'd also give this one a gentle nudge now the merge window has
re-opened, Andrew - are you ok to pick this up? I've checked the patch
and it still applies, for convenience the raw patch is available at
https://marc.info/?l=linux-mm&m=147802942832515&q=raw - let me know if
there's anything else I can do on this or if you'd prefer a re-send.
Best, Lorenzo
> On 3 January 2017 at 20:23, Lorenzo Stoakes wrote:
>> Hi All,
>>
>> Just a gentle ping on this one :)
>>
>> Cheers, Lorenzo
>>
>> On 1 November 2016 at 19:43, Lorenzo Stoakes wrote:
>>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the
>>> code
>>> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>>>
>>> Signed-off-by: Lorenzo Stoakes
>>> ---
>>> drivers/gpu/drm/via/via_dmablit.c | 10 +++---
>>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/via/via_dmablit.c
>>> b/drivers/gpu/drm/via/via_dmablit.c
>>> index 1a3ad76..98aae98 100644
>>> --- a/drivers/gpu/drm/via/via_dmablit.c
>>> +++ b/drivers/gpu/drm/via/via_dmablit.c
>>> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,
>>> drm_via_dmablit_t *xfer)
>>> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
>>> if (NULL == vsg->pages)
>>> return -ENOMEM;
>>> - down_read(¤t->mm->mmap_sem);
>>> - ret = get_user_pages((unsigned long)xfer->mem_addr,
>>> -vsg->num_pages,
>>> -(vsg->direction == DMA_FROM_DEVICE) ?
>>> FOLL_WRITE : 0,
>>> -vsg->pages, NULL);
>>> -
>>> - up_read(¤t->mm->mmap_sem);
>>> + ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
>>> + vsg->num_pages, vsg->pages,
>>> + (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE :
>>> 0);
>>> if (ret != vsg->num_pages) {
>>> if (ret < 0)
>>> return ret;
>>> --
>>> 2.10.2
>>>
--
Lorenzo Stoakes
https://ljs.io
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources
Pandiyan, Dhinakaran schreef op ma 13-02-2017 om 22:48 [+]:
> On Mon, 2017-02-13 at 21:26 +, Pandiyan, Dhinakaran wrote:
> >
> > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > >
> > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > >
> > > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > > >
> > > > >
> > > > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-
> > > > > 0800]:
> > > > > >
> > > > > >
> > > > > > Having a ->atomic_release callback is useful to release
> > > > > > shared
> > > > > > resources
> > > > > > that get allocated in compute_config(). This function is
> > > > > > expected
> > > > > > to
> > > > > > be
> > > > > > called in the atomic_check() phase before new resources are
> > > > > > acquired.
> > > > > >
> > > > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > > >
> > > > > > Suggested-by: Daniel Vetter
> > > > > > Signed-off-by: Dhinakaran Pandiyan > > > > > el.com
> > > > > > >
> > > > > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_atomic_helper.c | 19
> > > > > > +++
> > > > > > include/drm/drm_modeset_helper_vtables.h | 13
> > > > > > +
> > > > > > 2 files changed, 32 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > index 8795088..92bd741 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > > > drm_device *dev,
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > + for_each_connector_in_state(state, connector,
> > > > > > connector_state, i) {
> > > > > > + const struct drm_connector_helper_funcs
> > > > > > *conn_funcs;
> > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > +
> > > > > > + conn_funcs = connector->helper_private;
> > > > > > + if (!conn_funcs->atomic_release)
> > > > > > + continue;
> > > > > > +
> > > > > > + if (!connector->state->crtc)
> > > > > > + continue;
> > > > > > +
> > > > > > + crtc_state =
> > > > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > > > >
> > > > > > > crtc);
> > > > > > +
> > > > > > + if (crtc_state->connectors_changed ||
> > > > > > + crtc_state->mode_changed ||
> > > > > > + (crtc_state->active_changed &&
> > > > > > !crtc_state-
> > > > > > >
> > > > > > >
> > > > > > > active))
> > > > > > + conn_funcs-
> > > > > > >atomic_release(connector,
> > > > > > connector_state);
> > > > > > + }
> > > > >
> > > > > Could we deal with the VCPI state separately in
> > > > > intel_modeset_checks,
> > > > > like we do with dpll?
> > > >
> > > > We'd want to release the VCPI slots before they are acquired in
> > > > ->compute_config(). intel_modeset_checks() will be too late to
> > > > release
> > > > them. Are you suggesting both acquiring and releasing slots
> > > > should be
> > > > done in intel_modeset_checks()?
> > >
> > > That makes things a bit more nasty. Maybe add a
> > > conn_funcs->atomic_check that always gets called, something like
> > > I did
> > > below?
> > >
> > > I'd love to use it for some atomic connector properties too.
> >
> >
> > Adding and unconditionally calling conn_funcs->atomic_check()
> > should be
> > doable. It also follows the pattern we have for encoders and CRTCs.
> > But
> > I'll have to move the connector->state->crtc state checks inside
> > the
> > function.
> >
> > -DK
>
>
> This is what I mean -https://pastebin.ubuntu.com/23991405/
> But, I do have one concern with calling this conn_func-
> >atomic_check().
> We are not validating the new connector_state like atomic_check()
> seems
> to do generally but only cleaning up vcpi resources for
> compute_config()
> to later acquire. Let me know if I am wrong in my understanding what
> atomic_check() is expected to do.
Yeah looks good. I think it makes sense to have such a validation
function. There may not be much in it now but that could change when
i915 connector properties are made atomic. :)
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] mxsfb fixes
On 02/20/2017 10:05 AM, Dave Airlie wrote: > On 20 Feb. 2017 18:29, "Marek Vasut" wrote: > > On 02/20/2017 03:56 AM, Dave Airlie wrote: >> On 19 February 2017 at 08:25, Marek Vasut wrote: >>> On 02/17/2017 09:34 PM, Dave Airlie wrote: On 17 February 2017 at 18:00, Marek Vasut wrote: > On 02/17/2017 03:41 AM, Dave Airlie wrote: >> On 16 February 2017 at 08:16, Marek Vasut wrote: >>> Hi, >>> >>> I collected the MXSFB fixes, based on top of airlied/drm-fixes: >> >> At this stage I'd rather not give these to Linus, can you rebase them > onto >> drm-next, and resend, feel free to add stable cc's. >> >> Fixes like this should really be getting to me sooner than rc8. > > I know, sorry about that. I was totally overloaded in the past weeks. > What about getting them to rc1, any chance for that ? Yes if you can rebase them onto drm-next. >>> >>> Ha, got it. Try the following: >>> >>> The following changes since commit 9ca70356a9260403c1bda40d942935 > e55d00c11c: >>> >>> Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 > +1000) >>> >>> are available in the git repository at: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git >>> c72a2ec8208b40683fbd2970684ffbf3a8c7d17e >> >> Nearly, put please use a tag :-) > > I'm sure you can pull this batch without a tag ;-) > > > No, I really need tags preferably signed. > > Otherwise the merge is all ugly. > > > What do you have in mind for the next PR > > > Not sure I follow. What do you need to get these five fixes applied, ideally without much further annoyance to either of us. Ideally point me to some docs. -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm: convert drivers to use of_graph_get_remote_node
On 02/09/17 21:05, Rob Herring wrote: > Convert drivers to use the new of_graph_get_remote_node() helper > instead of parsing the endpoint node and then getting the remote device > node. Now drivers can just specify the device node and which > port/endpoint and get back the connected remote device node. The details > of the graph binding are nicely abstracted into the core OF graph code. > > This changes some error messages to debug messages (in the graph core). > Graph connections are often "no connects" depending on the particular > board, so we want to avoid spurious messages. Plus the kernel is not a > DT validator. > > Signed-off-by: Rob Herring > Acked-by: Neil Armstrong > Acked-by: Philipp Zabel > Tested-by: Liviu Dudau > Tested-by: Eric Anholt For tilcdc part: Tested-by: Jyri Sarha Cheers, Jyri ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/rockchip: cdn-dp: Fix error handling
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Christophe JAILLET
---
V2: rename label
add missing call to 'pm_runtime_put_sync()' in error path
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a670885..0fe1ec8b8fb1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -111,7 +111,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
ret = pm_runtime_get_sync(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
- goto err_pclk;
+ goto err_pm_runtime_get;
}
reset_control_assert(dp->core_rst);
@@ -133,6 +133,8 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
return 0;
err_set_rate:
+ pm_runtime_put(dp->dev);
+err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
clk_disable_unprepare(dp->pclk);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] hdlcd gets confused about base address
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote: > Something I also noticed is this: > > scanout_start = gem->paddr + plane->state->fb->offsets[0] + > plane->state->crtc_y * plane->state->fb->pitches[0] + > plane->state->crtc_x * bpp / 8; > > Surely this should be using src_[xy] (which are the position in the > source - iow, memory, and not crtc_[xy] which is the position on the > CRTC displayed window. To put it another way, the src_* define the > region of the source material that is mapped onto a rectangular area > on the display defined by crtc_*. This problem still exists... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] arm: dts: Remove the OF graph from DSI node for exynos3250 dts
On Thu, Feb 9, 2017 at 3:26 AM, Hoegeun Kwon wrote: > The OF graph is not needed because the panel is a child of dsi. So > Remove the ports node and move burst and esc clock frequency > properties to the parent (DSI node). > > Signed-off-by: Hoegeun Kwon > --- > arch/arm/boot/dts/exynos3250-rinato.dts | 23 ++- > 1 file changed, 2 insertions(+), 21 deletions(-) > Please use scripts/get_maintainers.pl to get the list of people and maling lists to CC. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] hdlcd gets confused about base address
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote: > Sorry, looks like this fell through the cracks of us trying to fix the > other issues you were seeing. I'm attaching a patch, please let me know > if this works for you. I don't have time to test right now, but it looks similar to what I had. Only nit is - is dest_w used apart from being written once? (That's probably something for a separate patch.) There's also the issue which Daniel Vetter followed up with to my comment about this calculation - the plane state validation is insufficient, and it would be a good idea if it used drm_plane_helper_check_state(). Also, I've since noticed that it doesn't check state->rotation, and I don't think this driver supports any rotation options. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] hdlcd gets confused about base address
On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote: > This stuff should be using the clipped coordinates, not the user > coordinates. And it doesn't look like this guy is even calling the > clip helper thing. > > malidp seems to be calling that thing, but it still doesn't > manage to program the hw with the right coordinates from what > I can see. > > /me feels a bit like a broken record... If you mean drm_plane_helper_check_state(), then... $ grep drm_plane_helper_check_state Documentation/gpu/ -r So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's the following, and I think this really isn't helping people understand what's required: * This helper library has two parts. The first part has support to implement * primary plane support on top of the normal CRTC configuration interface. * Since the legacy ->set_config interface ties the primary plane together with * the CRTC state this does not allow userspace to disable the primary plane * itself. To avoid too much duplicated code use * drm_plane_helper_check_update() which can be used to enforce the same * restrictions as primary planes had thus. The default primary plane only * expose XRBG and ARGB as valid pixel formats for the attached * framebuffer. * * Drivers are highly recommended to implement proper support for primary * planes, and newly merged drivers must not rely upon these transitional * helpers. Which functions are defined as "these transitional helpers" - the above is rather ambiguous. Is drm_plane_helper_check_state() a "transitional helper" or is it not? (It probably isn't, but the documentation does not make that clear.) It then goes on to: * The second part also implements transitional helpers which allow drivers to So maybe the second paragraph needs to be moved after this line to remove the confusion? If you find that you're repeating something to many people, it's always a good idea to re-read the documentation that's supposed to be giving people guidance. Now, when you say that we're supposed to program "clipped coordinates" maybe you can give a hint what those are and where they come from? Is that the vaguely documented "clip" parameter in drm_plane_helper_check_state() ? * @clip: integer clipping coordinates If it is, that doesn't really describe it, and neither does the description of what the function does, nor what it returns: * Checks that a desired plane update is valid. Drivers that provide * their own plane handling rather than helper-provided implementations may * still wish to call this function to avoid duplication of error checking * code. * * RETURNS: * Zero if update appears valid, error code on failure So, some improvement there could go a long way towards eliminating some of these issues... Atomic modeset is hideously complex... having poor documentation doesn't help. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: imxdrm issue on SABRE Lite
Hi Phillipp On Mon, Feb 20, 2017 at 3:42 PM, Philipp Zabel wrote: > Hi Dan, > > On Sat, 2017-02-11 at 21:09 +, Dan MacDonald wrote: >> Hi Phillipp >> >> I'm having trouble getting xf86-video-armada working properly on a >> Element 14 / Embest SABRE Lite board running Arch Linux with kernel >> 4.9.8. I have been in touch with RMK and he's confident the crash >> below is caused by a kernel issue relating to imxdrm and a null >> pointer dereference. > > I can't reproduce this on v4.9.8 with a Nitrogen6X with 1280x800 LDVS > panel and 1920x1080 HDMI monitor using modetest from libdrm. Does this > only happen with X? I have read that there are supposedly differences between the Element 14 SL and the Boundary Devices board of the same name but I have yet to find out exactly what they are as the specs are the same on paper. Saying that, all of the uboot and OS images for the BD SL that I've tried have worked without issue, including the GLES demos on the BD Ubuntu 16.04 image. I've never used wayland. The console works fine with my 4K display and I have been able to get X running at 720x480 under Arch with armada but no other resolution. > Do you have framebuffer console emulation enabled? Not sure - will need to check if thats enable by default under ALARM? I've not manually enabled it. > Does this still happen if you disable the LVDS panel in the device tree? Russell sent me a different dtb file which seemed to fix some of my kernel probs. Russell will be able to explain that better than me. > >> The first indiction of X/armada not being happy it that it only starts >> in 720x480 when connected to a 4K HDMI display, and when I try >> running: >> >> xrandr --output HDMI1 --mode 1920x1080 >> >> X crashes. >> >> Here's the serial console output for X loading and then crashing after >> I try running that xrandr command: >> >> Arch Linux 4.9.8-1-ARCH (ttymxc1) >> >> alarm login: [ 19.197477] fec 2188000.ethernet eth0: Link is Up - >> 1Gbps/Full - flow control rx/tx >> [ 19.205165] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready >> [ 33.08] vgaarb: this pci device is not a vga device >> [ 33.203520] vgaarb: this pci device is not a vga device >> [ 33.447051] imx-ipuv3 240.ipu: DC stop timeout after 50 ms > > Does the "gpu: ipu-v3: remove IRQ dance on DC channel disable" patch > (https://patchwork.kernel.org/patch/9417683) do anything to improve the > situation, besides removing the above warning? After trying Russells dtb, he asked me to try booting with: setenv bootargs cma=256M Then X failed to start with the error: [ 57.705889] imx-drm display-subsystem: failed to allocate buffer with size 33177600 Do you think that patch could fix such an issue? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph
On Mon, Feb 20, 2017 at 10:32 AM, Inki Dae wrote: > > > 2017년 02월 20일 16:27에 Krzysztof Kozlowski 이(가) 쓴 글: >> On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote: >>> Hi Krzysztof, >>> >>> Can you merge patch 2 and 5 to your tree so that they can go to mainline? >>> Otherwise, I can merge them to my tree if you give me acked-by. >> >> Hi, >> >> Hm? Why do you need them to be merged? Do you mean that the first >> patch breaks not only ABI but also bisectability? Then this has to be >> reworked because: >> >> 1. The DTS patches cannot go through non-DT tree so no, you cannot >> take them into your branch. I will merge them according to point 4 >> below. >> 2. Bisectability has to be preserved. >> 3. DTS changes in general should not be a dependency for driver changes. > > Krzysztof, > > I know that. I didn't check you gave a comment to Hoegun do rework this patch > series. I just checked reviewed-by from Andrzej H. and thought no problem. > > Ideally you are right. DT changes should be no any dependency of driver > changes but now Exynos DT is broken. I didn't receive any bug reports that Exynos DT is broken so I am quite surprised hearing that. What do you mean by that? > So if we have to keep the bisectability between driver and device tree > patches - this means that all drivers should always keep the backward > compatibility - then the drivers will be messed up. No, you are mixing two things. Bisectability is different than backward compatibility. For the backward DT ABI compatibility, we agreed that in this case it can be dropped. However bisectability is something totally different. The DTS changes always go through separate branch, so the driver has to be *always* ready for such case and should still be fully bisectable. This is a general rule existing for long time and every deviation from the rule is pointed out by arm-soc guys. Whenever I accepted breaking of this rule, I had hard times with arm-soc so no - I am no longer giving up basic rule just because developer might not care. There are many ways to solve the bisectability problem. Recently for example Marek found nice way to solve the PMU syscon handle dependency [1]. One can also merge first DTS changes and in next release, merge the driver. > About this, we had a discussion and I think you agreed, > https://patchwork.kernel.org/patch/9477957/ Again, this discussion was about DT ABI. Not bisectability. > Do you want the backward compatibility to be kept always when new dt binding > relevant patch - which fixes up the wrong usage of dt binding - is posted? > It would be good for the backward compatibility to be kept as long as we can > do but there would be several cases to make the driver to be messed up like > this patch series. Again, DT ABI not bisectability. Best regards, Krzysztof [1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/commit/?h=for-v4.11/drivers-soc-exynos-pmu-the-joy-never-ends&id=76640b84bd7a9d68c70d8bc8ecd02cdc4bd8855e ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 Michel Dänzer changed: What|Removed |Added Attachment #129781|text/x-log |text/plain mime type|| -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #2 from Michel Dänzer --- It sounds like you have the environment variable DRI_PRIME=1 set for all applications? Those dmesg messages are normal when the dedicated GPU is powered up, which takes some time. With runpm enabled, it's powered off automatically when nothing uses it for a while. -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #3 from Matthew Fox --- Hi Michel, Just a slight correction to my description - I am running Ubuntu Gnome 16.04.2. This is a fresh install and I have not set that env var anywhere. Where could I check for that? Does that mean with radeon.runpm=0 the laptop would be using more power & generating more heat? Thanks Matthew -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #4 from Michel Dänzer --- (In reply to Matthew Fox from comment #3) > This is a fresh install and I have not set that env var anywhere. Where > could I check for that? What does env | grep DRI_ say? > Does that mean with radeon.runpm=0 the laptop would be using more power & > generating more heat? Yes (assuming the dedicated GPU is off most of the time with runpm on). -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #5 from Matthew Fox --- > What does > > env | grep DRI_ > > say? That printed nothing. My session with runtime pm enabled (no radeon.runpm=0 in cmdline) had been running for a couple of hours without problem (apart from a bit of freezing at the start). However, just after running that command, some new radeon errors appeared in dmesg that I haven't seen before. I think they were ring test failures. The PC has locked up now anyway so I can only hard shut it down. I was switching ttys with CTRL+ALT at the same time which might have caused it. -- 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
[PATCH 2/2] drm/rockchip: vop: verify pixelclock for hdmi and displayport
Hdmi or DisplayPort request a accurate clock,
reject the display mode if clock is not good.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7ec5d7f..a7c118e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -868,14 +868,24 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
{
struct vop *vop = to_vop(crtc);
const struct vop_data *vop_data = vop->data;
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+ int clock;
if (mode->hdisplay > vop_data->max_output.width)
return false;
if (mode->vdisplay > vop_data->max_output.height)
return false;
- adjusted_mode->clock =
- clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
+ clock = clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
+ /*
+* Hdmi or DisplayPort request a Accurate clock.
+*/
+ if (s->output_type == DRM_MODE_CONNECTOR_HDMIA ||
+ s->output_type == DRM_MODE_CONNECTOR_DisplayPort)
+ if (clock != mode->clock)
+ return false;
+
+ adjusted_mode->clock = clock;
return true;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/rockchip: vop: verify display mode with vop max_output
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 8dab2af..7ec5d7f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -867,6 +867,12 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
{
struct vop *vop = to_vop(crtc);
+ const struct vop_data *vop_data = vop->data;
+
+ if (mode->hdisplay > vop_data->max_output.width)
+ return false;
+ if (mode->vdisplay > vop_data->max_output.height)
+ return false;
adjusted_mode->clock =
clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 5a4faa85..de5a714 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -135,6 +135,11 @@ struct vop_win_data {
enum drm_plane_type type;
};
+struct vop_rect {
+ int width;
+ int height;
+};
+
struct vop_data {
const struct vop_reg_data *init_table;
unsigned int table_size;
@@ -142,6 +147,8 @@ struct vop_data {
const struct vop_intr *intr;
const struct vop_win_data *win;
unsigned int win_size;
+ struct vop_rect max_input;
+ struct vop_rect max_output;
};
/* interrupt define */
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 91fbc7b..f4ffb677 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -132,6 +132,8 @@
};
static const struct vop_data rk3036_vop = {
+ .max_input = {1920, 1080},
+ .max_output = {1920, 1080},
.init_table = rk3036_vop_init_reg_table,
.table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
@@ -273,6 +275,13 @@
};
static const struct vop_data rk3288_vop = {
+ .max_input = {4096, 8192},
+ /*
+* TODO: rk3288 have two vop, big one support 3840x2160,
+* little one only support 2560x1600.
+* Now force use 3840x2160.
+*/
+ .max_output = {3840, 2160},
.init_table = rk3288_init_reg_table,
.table_size = ARRAY_SIZE(rk3288_init_reg_table),
.intr = &rk3288_vop_intr,
@@ -341,6 +350,8 @@
};
static const struct vop_data rk3399_vop_big = {
+ .max_input = {4096, 8192},
+ .max_output = {4096, 2160},
.init_table = rk3399_init_reg_table,
.table_size = ARRAY_SIZE(rk3399_init_reg_table),
.intr = &rk3399_vop_intr,
@@ -360,6 +371,8 @@
};
static const struct vop_data rk3399_vop_lit = {
+ .max_input = {4096, 8192},
+ .max_output = {2560, 1600},
.init_table = rk3399_init_reg_table,
.table_size = ARRAY_SIZE(rk3399_init_reg_table),
.intr = &rk3399_vop_intr,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #6 from Michel Dänzer --- Note that you should run env | grep DRI_ in an X terminal, not in a console TTY. -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #7 from Matthew Fox --- (In reply to Michel Dänzer from comment #6) > Note that you should run > > env | grep DRI_ > > in an X terminal, not in a console TTY. Same result in both :/ -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #8 from Michel Dänzer --- Please attach the corresponding Xorg log file. -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #9 from Matthew Fox --- (In reply to Michel Dänzer from comment #8) > Please attach the corresponding Xorg log file. Hi, The only Xorg logs I have are for my new session. They weren't in /var/log/ but /home/matthew/.local/share/xorg/Xorg.1.log /var/lib/gdm3/.local/share/xorg/Xorg.0.log for some reason. They are attached. Also attached is a dmesg log for my current session. When I said: With previous ubuntu/kernel versions, the main issue was the freezing which would happen every seven seconds with the corresponding dmesg block. This would continue ad infinitum, although on rare occasions it would stop after many freezes. However with my current kernel this pattern doesn't seem to occur - it freezes a few times before the freezing stops and the freezes do not occur at regular intervals. - this seems to be true of my current kernel. From the current dmesg.log, the 'Disabling via vga_switcheroo' happened at 14, 33, 41 and finally 48 (seven seconds apart, except 14-33): [ 14.146303] snd_hda_intel :02:00.1: Disabling via vga_switcheroo [ 15.586313] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 15.588655] [drm] PCIE GART of 512M enabled (table at 0x0014C000). [ 15.588728] radeon :02:00.0: WB enabled [ 15.588731] radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x90180fa71c00 [ 15.588733] radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x90180fa71c0c [ 15.589099] radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xbdbf41a1c418 [ 15.605265] [drm] ring test on 0 succeeded in 1 usecs [ 15.605270] [drm] ring test on 3 succeeded in 2 usecs [ 15.791907] [drm] ring test on 5 succeeded in 1 usecs [ 15.791914] [drm] UVD initialized successfully. [ 15.791956] [drm] ib test on ring 0 succeeded in 0 usecs [ 15.791986] [drm] ib test on ring 3 succeeded in 0 usecs [ 16.482332] [drm] ib test on ring 5 succeeded [ 16.515177] snd_hda_intel :02:00.1: Enabling via vga_switcheroo [ 16.619344] snd_hda_intel :02:00.1: CORB reset timeout#2, CORBRP = 65535 [ 33.089549] snd_hda_intel :02:00.1: Disabling via vga_switcheroo [ 33.389563] snd_hda_intel :02:00.1: Cannot lock devices! [ 34.733597] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 34.735932] [drm] PCIE GART of 512M enabled (table at 0x0014C000). [ 34.736006] radeon :02:00.0: WB enabled [ 34.736009] radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x90180fa71c00 [ 34.736011] radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x90180fa71c0c [ 34.736378] radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xbdbf41a1c418 [ 34.753251] [drm] ring test on 0 succeeded in 1 usecs [ 34.753256] [drm] ring test on 3 succeeded in 2 usecs [ 34.939919] [drm] ring test on 5 succeeded in 1 usecs [ 34.939926] [drm] UVD initialized successfully. [ 34.939969] [drm] ib test on ring 0 succeeded in 0 usecs [ 34.940006] [drm] ib test on ring 3 succeeded in 0 usecs [ 35.617560] [drm] ib test on ring 5 succeeded [ 35.650390] snd_hda_intel :02:00.1: Enabling via vga_switcheroo [ 35.753848] snd_hda_intel :02:00.1: CORB reset timeout#2, CORBRP = 65535 [ 41.025246] snd_hda_intel :02:00.1: Disabling via vga_switcheroo [ 41.325632] snd_hda_intel :02:00.1: Cannot lock devices! [ 42.665278] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 42.667593] [drm] PCIE GART of 512M enabled (table at 0x0014C000). [ 42.667666] radeon :02:00.0: WB enabled [ 42.667670] radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x90180fa71c00 [ 42.667671] radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x90180fa71c0c [ 42.668038] radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xbdbf41a1c418 [ 42.684185] [drm] ring test on 0 succeeded in 1 usecs [ 42.684189] [drm] ring test on 3 succeeded in 2 usecs [ 42.870780] [drm] ring test on 5 succeeded in 1 usecs [ 42.870784] [drm] UVD initialized successfully. [ 42.870821] [drm] ib test on ring 0 succeeded in 0 usecs [ 42.870850] [drm] ib test on ring 3 succeeded in 0 usecs [ 43.553259] [drm] ib test on ring 5 succeeded [ 43.582109] snd_hda_intel :02:00.1: Enabling via vga_switcheroo [ 43.685717] snd_hda_intel :02:00.1: CORB reset timeout#2, CORBRP = 65535 [ 48.960919] snd_hda_intel :02:00.1: Disabling via vga_switcheroo [ 49.261324] snd_hda_intel :02:00.1: Cannot lock devices! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #10 from Matthew Fox --- Created attachment 129783 --> https://bugs.freedesktop.org/attachment.cgi?id=129783&action=edit dmesg.log 2 -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #11 from Matthew Fox --- Created attachment 129784 --> https://bugs.freedesktop.org/attachment.cgi?id=129784&action=edit Xorg.1.log -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 --- Comment #12 from Matthew Fox --- Created attachment 129785 --> https://bugs.freedesktop.org/attachment.cgi?id=129785&action=edit Xorg.0.log -- 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 99881] Lockup/Freezes on Laptop with switchable graphics
https://bugs.freedesktop.org/show_bug.cgi?id=99881 Matthew Fox changed: What|Removed |Added Attachment #129782|text/x-log |text/plain mime type|| -- 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
