Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 09:22:50AM -0700, Dylan Baker wrote:
> Quoting Jani Nikula (2017-03-21 07:44:55)
> > On Thu, 16 Mar 2017, Dylan Baker  wrote:
> > > First it's written in python, [...]
> > 
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> 
> Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
> released in 2012. It's also worth nothing that a couple of us have been 
> working
> to get mesa's python scripts python3 compatible, so in the (hopefully) near
> future python2 wouldn't be required.

Mesa only requires python for development versions not to build
releases.  Changing to a build system that uses python3 to parse JSON
like files to generate ninja would change that.

> 
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> 
> Meson makes backwards compatible changes, and the version can be queried using
> `meson.version()`, which works using meson's version comparison mechanism. I
> would say this about meson, it's not a 'python project', it's 'a project 
> written
> in python', and they've taken great pains to not expose python in meson, and
> reserve the right to reimplement in a different language if python becomes an
> issue.
> 
> 
> > BR,
> > Jani.
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> 
> Dylan



> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Bug 100308] *ERROR* clock recovery reached max voltage

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100308

Bug ID: 100308
   Summary: *ERROR* clock recovery reached max voltage
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: alex.c.li...@gmail.com

The following starting happening after upradeing to
xf86-video-ati-1:7.9.0-1-x86_64.pkg.tar.xz on arch linux. (ALL Monitors go
blank) First thought it was kernel and tried rolling back a few versions and
was still happening. On the new kernel versions it just happens ramdonly. On
the older kernels it only happens when trying to wake monitors. It's always the
following errors.

Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery reached max voltage
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery failed


I've switched to AMDGPU since it now has experimental support for southern
islands. 

Thx much for the hardwork



stack trace...
[ cut here ]
Mar 18 10:05:00 showdownarch kernel: WARNING: CPU: 3 PID: 13100 at
./include/drm/drm_crtc.h:1403 drm_helper_choose_encoder_dpms+0x8a/0x90
[drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel: Modules linked in: xt_multiport
iptable_filter overlay snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_codec_hdmi iTCO_wdt gpio_ich iTCO_ven
Mar 18 10:05:00 showdownarch kernel:  mii fb_sys_fops i2c_algo_bit button
snd_timer snd mei_me soundcore mei intel_agp shpchp intel_gtt acpi_cpufreq
tpm_tis tpm_tis_core tpm sch_fq_
Mar 18 10:05:00 showdownarch kernel: CPU: 3 PID: 13100 Comm: kworker/3:256
Tainted: GW   4.9.14-1-lts #1
Mar 18 10:05:00 showdownarch kernel: Hardware name: Gigabyte Technology Co.,
Ltd. H55-USB3/H55-USB3, BIOS F7 08/20/2010
Mar 18 10:05:00 showdownarch kernel: Workqueue: events radeon_dp_work_func
[radeon]
Mar 18 10:05:00 showdownarch kernel:  c90010d63d20 812f890d
 
Mar 18 10:05:00 showdownarch kernel:  c90010d63d60 8107cb0b
057b9e861d09 88030a843000
Mar 18 10:05:00 showdownarch kernel:  88030ffe7a00 88030f5f9000
0003 88030aa92660
Mar 18 10:05:00 showdownarch kernel: Call Trace:
Mar 18 10:05:00 showdownarch kernel:  [] dump_stack+0x63/0x86
Mar 18 10:05:00 showdownarch kernel:  [] __warn+0xcb/0xf0
Mar 18 10:05:00 showdownarch kernel:  []
warn_slowpath_null+0x1d/0x20
Mar 18 10:05:00 showdownarch kernel:  []
drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel:  []
drm_helper_connector_dpms+0x4b/0x100 [drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel:  [] ?
drm_dp_dpcd_read_link_status+0x1b/0x20 [drm_kms_helper]
Mar 18 10:05:00 showdownarch kernel:  []
radeon_connector_hotplug+0xf7/0x100 [radeon]
Mar 18 10:05:00 showdownarch kernel:  []
radeon_dp_work_func+0x3f/0x60 [radeon]
Mar 18 10:05:00 showdownarch kernel:  []
process_one_work+0x1e9/0x440
Mar 18 10:05:00 showdownarch kernel:  []
worker_thread+0x4b/0x4f0
Mar 18 10:05:00 showdownarch kernel:  [] ?
process_one_work+0x440/0x440
Mar 18 10:05:00 showdownarch kernel:  [] kthread+0xd9/0xf0
Mar 18 10:05:00 showdownarch kernel:  [] ?
__switch_to+0x2ce/0x5b0
Mar 18 10:05:00 showdownarch kernel:  [] ?
kthread_park+0x60/0x60
Mar 18 10:05:00 showdownarch kernel:  []
ret_from_fork+0x25/0x30
Mar 18 10:05:00 showdownarch kernel: ---[ end trace 6a290eae4410f871 ]---
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery reached max voltage
Mar 18 10:05:00 showdownarch kernel: [drm:radeon_dp_link_train [radeon]]
*ERROR* clock recovery failed

-- 
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 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100306

Michel Dänzer  changed:

   What|Removed |Added

Version|unspecified |17.0
 QA Contact|xorg-t...@lists.x.org   |dri-devel@lists.freedesktop
   ||.org
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
Product|xorg|Mesa
  Component|Driver/Radeon   |Drivers/Gallium/radeonsi

--- Comment #9 from Michel Dänzer  ---
Looks like GPU lockups, which are most likely due to an issue in
Mesa/LLVM/kernel. Reassigning to Mesa for now.

-- 
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 100242] radeon buffer allocation failure during startup of Factorio

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100242

--- Comment #7 from Michel Dänzer  ---
I indeed misread your comment, sorry. Can you bisect Mesa?

-- 
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 v4 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

[Chris Zhong]

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
add the description for this clock.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
---

Changes in v4:
- remove "additional"

Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 +-
 1 file changed, 1 insertion(+), 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 188f6f7..1d722f5 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -10,7 +10,7 @@ Required properties:
 - 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). For RK3399, a phy config clock
-  (phy_cfg) is additional required. As described in [1].
+  (phy_cfg) and a grf clock(grf) are 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

[Bug 100242] radeon buffer allocation failure during startup of Factorio

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100242

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130279|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

[PATCH v4 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

[Chris Zhong]

For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is
disabled, MIPI phy can not work. Let's return a error if there is no
phy_cfg_clk in dts property, when the pdata match RK3399.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
---

Changes in v4: None
Changes in v3:
- add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399

Changes in v2: None

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f84f9ae..68f48b0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -251,6 +251,8 @@
 #define THS_PRE_PROGRAM_EN BIT(7)
 #define THS_ZERO_PROGRAM_ENBIT(6)
 
+#define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
+
 enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -279,6 +281,7 @@ struct dw_mipi_dsi_plat_data {
u32 grf_switch_reg;
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
+   unsigned int flags;
unsigned int max_data_lanes;
 };
 
@@ -1136,6 +1139,7 @@ static struct dw_mipi_dsi_plat_data 
rk3399_mipi_dsi_drv_data = {
.grf_switch_reg = RK3399_GRF_SOC_CON19,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
+   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
.max_data_lanes = 4,
 };
 
@@ -1227,15 +1231,13 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
clk_disable_unprepare(dsi->pclk);
}
 
-   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
-   if (IS_ERR(dsi->phy_cfg_clk)) {
-   ret = PTR_ERR(dsi->phy_cfg_clk);
-   if (ret != -ENOENT) {
+   if (pdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
+   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
+   if (IS_ERR(dsi->phy_cfg_clk)) {
+   ret = PTR_ERR(dsi->phy_cfg_clk);
dev_err(dev, "Unable to get phy_cfg_clk: %d\n", ret);
return ret;
}
-   dsi->phy_cfg_clk = NULL;
-   dev_dbg(dev, "have not phy_cfg_clk\n");
}
 
ret = clk_prepare_enable(dsi->pllref_clk);
-- 
2.6.3

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

[PATCH v4 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

[Chris Zhong]

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
not RK3399_GRF_SOC_CON19.

Signed-off-by: Chris Zhong 
Reviewed-by: Brian Norris 
Reviewed-by: Sean Paul 
---

Changes in v4: None
Changes in v3: None
Changes in v2: 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 dc8fd22..3aedcba 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -34,7 +34,7 @@
 #define RK3288_DSI0_SEL_VOP_LITBIT(6)
 #define RK3288_DSI1_SEL_VOP_LITBIT(9)
 
-#define RK3399_GRF_SOC_CON19   0x6250
+#define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_DSI0_SEL_VOP_LITBIT(0)
 #define RK3399_DSI1_SEL_VOP_LITBIT(4)
 
@@ -1151,7 +1151,7 @@ static struct dw_mipi_dsi_plat_data 
rk3288_mipi_dsi_drv_data = {
 static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
-   .grf_switch_reg = RK3399_GRF_SOC_CON19,
+   .grf_switch_reg = RK3399_GRF_SOC_CON20,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
.flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
-- 
2.6.3

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

[PATCH v4 0/4] RK3399 dw-mipi-dsi patches

[Chris Zhong]

Hi all

This series set the phy_cfg_clk to be a required clock for RK3399, and
add a grf clock control in dw-mipi-dsi driver. And then correct a
register name.


Changes in v4:
- remove "additional"
- print the err after clk_prepare_enable(dsi->grf_clk)

Changes in v3:
- add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
- add a DW_MIPI_NEEDS_GRF_CLK for RK3399

Changes in v2:
- check the grf_clk only for RK3399

Chris Zhong (4):
  drm/rockchip/dsi: check phy_cfg_clk only for RK3399
  dt-bindings: add the grf clock for dw-mipi-dsi
  drm/rockchip/dsi: enable the grf clk before writing grf registers
  drm/rockchip/dsi: correct the grf_switch_reg name

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |  2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 42 +-
 2 files changed, 35 insertions(+), 9 deletions(-)

-- 
2.6.3

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

[PATCH v4 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

[Chris Zhong]

For RK3399, the grf clk should be enabled before writing grf registers,
otherwise the register value can not be changed.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
---

Changes in v4:
- print the err after clk_prepare_enable(dsi->grf_clk)

Changes in v3:
- add a DW_MIPI_NEEDS_GRF_CLK for RK3399

Changes in v2:
- check the grf_clk only for RK3399

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 68f48b0..dc8fd22 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -252,6 +252,7 @@
 #define THS_ZERO_PROGRAM_ENBIT(6)
 
 #define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
+#define DW_MIPI_NEEDS_GRF_CLK  BIT(1)
 
 enum {
BANDGAP_97_07,
@@ -294,6 +295,7 @@ struct dw_mipi_dsi {
struct regmap *grf_regmap;
void __iomem *base;
 
+   struct clk *grf_clk;
struct clk *pllref_clk;
struct clk *pclk;
struct clk *phy_cfg_clk;
@@ -982,6 +984,17 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
 
+   /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register. And for RK3288 or other soc, this grf_clk must be NULL,
+* the clk_prepare_enable return true directly.
+*/
+   ret = clk_prepare_enable(dsi->grf_clk);
+   if (ret) {
+   dev_err(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
+   return;
+   }
+
if (pdata->grf_dsi0_mode_reg)
regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
 pdata->grf_dsi0_mode);
@@ -1006,6 +1019,8 @@ 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;
+
+   clk_disable_unprepare(dsi->grf_clk);
 }
 
 static int
@@ -1139,7 +1154,7 @@ static struct dw_mipi_dsi_plat_data 
rk3399_mipi_dsi_drv_data = {
.grf_switch_reg = RK3399_GRF_SOC_CON19,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
-   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
+   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
.max_data_lanes = 4,
 };
 
@@ -1240,6 +1255,15 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
}
}
 
+   if (pdata->flags & DW_MIPI_NEEDS_GRF_CLK) {
+   dsi->grf_clk = devm_clk_get(dev, "grf");
+   if (IS_ERR(dsi->grf_clk)) {
+   ret = PTR_ERR(dsi->grf_clk);
+   dev_err(dev, "Unable to get grf_clk: %d\n", ret);
+   return ret;
+   }
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
-- 
2.6.3

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

[PATCH v3 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

[Chris Zhong]

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.

Signed-off-by: Chris Zhong 
Reviewed-by: Brian Norris 
---

Changes in v3: None
Changes in v2: None

 .../bindings/display/panel/innolux,p079zca.txt | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
new file mode 100644
index 000..5c70a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -0,0 +1,23 @@
+Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p079zca"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   _dsi {
+   panel {
+   compatible = "innolux,p079zca";
+   reg = <0>;
+   power-supply = <...>;
+   backlight = <>;
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

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

[PATCH v3 2/2] drm/panel: add innolux,p079zca panel driver

[Chris Zhong]

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
Tested-by: Brian Norris 
---

Changes in v3:
- printk err after regulator_disable(innolux->supply)

Changes in v2:
- add some error check
- always use Low power mode to send commend
- add comments for all the sleep
- use DRM_DEV_ERROR instead of dev_err

 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 345 ++
 3 files changed, 357 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..99dd010 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_INNOLUX_P079ZCA
+   tristate "Innolux P079ZCA panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Innolux P079ZCA
+ TFT-LCD modules. The panel has a 1024x768 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..bda2aa4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
new file mode 100644
index 000..9f3423a0
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -0,0 +1,345 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct innolux_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct innolux_panel, base);
+}
+
+static int innolux_panel_disable(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->enabled)
+   return 0;
+
+   if (innolux->backlight) {
+   innolux->backlight->props.power = FB_BLANK_POWERDOWN;
+   backlight_update_status(innolux->backlight);
+   }
+
+   err = mipi_dsi_dcs_set_display_off(innolux->link);
+   if (err < 0)
+   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
+   innolux->enabled = false;
+
+   return 0;
+}
+
+static int innolux_panel_unprepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->prepared)
+   return 0;
+
+   err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
+   if (err < 0) {
+   DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
+ err);
+   return err;
+   }
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   /* T8: 80ms - 1000ms */
+   msleep(80);
+
+   err = regulator_disable(innolux->supply);
+   if (err < 0)
+   return err;
+
+   innolux->prepared = false;
+
+   return 0;
+}
+
+static int innolux_panel_prepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err, regulator_err;
+
+   if (innolux->prepared)
+   return 0;
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   err = regulator_enable(innolux->supply);
+   if (err < 0)
+   return err;
+
+ 

Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function

[Hoegeun Kwon]

Hi inki,

Could you check the this patch?
For reference, patch 1/5 and 2/5 have already been applied to Krzysztof 
tree.


Best regards,
Hoegeun


On 03/08/2017 01:54 PM, Hoegeun Kwon wrote:

The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for the case fimd + dsi + panel.

Parse the Pll burst and esc clock frequency properties in dsi_parse_dt()
and create a bridge_node only if there is an OF graph associated with dsi.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 
  1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index f5c04d0..2d4e118 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
  
-	ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);

-   if (!ep) {
-   dev_err(dev, "no output port with endpoint specified\n");
-   return -EINVAL;
-   }
-
-   ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
+   ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
 >burst_clk_rate);
if (ret < 0)
-   goto end;
+   return ret;
  
-	ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",

+   ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
 >esc_clk_rate);
if (ret < 0)
-   goto end;
-
-   of_node_put(ep);
+   return ret;
  
  	ep = of_graph_get_next_endpoint(node, NULL);

-   if (!ep) {
-   ret = -EINVAL;
-   goto end;
-   }
-
-   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
-   if (!dsi->bridge_node) {
-   ret = -EINVAL;
-   goto end;
+   if (ep) {
+   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
}
-end:
-   of_node_put(ep);
  
-	return ret;

+   return 0;
  }
  
  static int exynos_dsi_bind(struct device *dev, struct device *master,


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

[Bug 100303] Adding a single, meaningless if-else to a shader source leads to different image

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100303

Samuel Pitoiset  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|glsl-compiler
 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

--- Comment #1 from Samuel Pitoiset  ---
Hi Hugues, thanks for reporting this.

Reassigned to glsl-compiler because this can be reproduced with Nouveau and
llvmpipe.

-- 
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 v3 2/3] drm/pl111: Initial drm/kms driver for pl111

[Russell King - ARM Linux]

On Mon, Mar 20, 2017 at 04:36:14PM -0700, Eric Anholt wrote:
> +static struct amba_driver pl111_amba_driver = {
> + .drv = {
> + .name = "clcd-pl11x",

either:

.name = "clcd-pl111",

or:

.name = "drm-clcd-pl111",

otherwise the driver names will clash in sysfs - driver names must be
unique.

> + },
> + .probe = pl111_amba_probe,
> + .remove = pl111_amba_remove,
> + .id_table = pl111_id_table,
> +};
> +#endif /* CONFIG_ARM_AMBA */
> +
> +module_amba_driver(pl111_amba_driver);
> +
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_AUTHOR("ARM Ltd.");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:pl111_drm");

Does the platform alias make sense for an OF-only driver?

-- 
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 v3 0/4] RK3399 dw-mipi-dsi patches

[Brian Norris]

On Fri, Mar 17, 2017 at 11:54:20AM +0800, Chris Zhong wrote:
> Hi all
> 
> This series set the phy_cfg_clk to be a required clock for RK3399, and
> add a grf clock control in dw-mipi-dsi driver. And then correct a
> register name.

Series looks good to me, and works well on RK3399.

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

[PATCH v7] drm/rockchip: Refactor the component match logic.

[Jeffy Chen]

Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.

Refactor component match logic, follow exynos drm.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
Acked-by: Mark Yao 
Tested-by: Heiko Stuebner 

---

Changes in v7:
Add Heiko Stuebner 's Tested-by.

Changes in v6:
Add Mark Yao 's Acked-by.

Changes in v5:
Fix compile error reported by Heiko Stuebner .

Changes in v4:
Use platform_driver helpers to register/unregister drivers.
Fix null pointer error reported by Heiko Stuebner .

Changes in v3:
Address Andrzej Hajda 's comments.

Changes in v2:
Address Sean Paul 's comments.

 drivers/gpu/drm/rockchip/Kconfig|  10 +-
 drivers/gpu/drm/rockchip/Makefile   |  16 +--
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   9 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |   8 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   8 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  10 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c|  10 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 138 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 ++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   8 +-
 10 files changed, 115 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0e4eb84..50c41c0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -13,7 +13,7 @@ config DRM_ROCKCHIP
  IP found on the SoC.
 
 config ROCKCHIP_ANALOGIX_DP
-   tristate "Rockchip specific extensions for Analogix DP driver"
+   bool "Rockchip specific extensions for Analogix DP driver"
depends on DRM_ROCKCHIP
select DRM_ANALOGIX_DP
help
@@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
  on RK3288 based SoC, you should selet this option.
 
 config ROCKCHIP_CDN_DP
-tristate "Rockchip cdn DP"
+bool "Rockchip cdn DP"
 depends on DRM_ROCKCHIP
depends on EXTCON
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
  option.
 
 config ROCKCHIP_DW_HDMI
-tristate "Rockchip specific extensions for Synopsys DW HDMI"
+bool "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
 select DRM_DW_HDMI
 help
@@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
  option.
 
 config ROCKCHIP_DW_MIPI_DSI
-   tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
+   bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
depends on DRM_ROCKCHIP
select DRM_MIPI_DSI
help
@@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
 option.
 
 config ROCKCHIP_INNO_HDMI
-   tristate "Rockchip specific extensions for Innosilicon HDMI"
+   bool "Rockchip specific extensions for Innosilicon HDMI"
depends on DRM_ROCKCHIP
help
  This selects support for Rockchip SoC specific extensions
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index c931e2a..fa8dc9d 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,14 +3,14 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
+   rockchip_drm_gem.o rockchip_drm_psr.o \
+   rockchip_drm_vop.o rockchip_vop_reg.o
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
-obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
-cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
-obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
-obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 
-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..91ebe5c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -507,7 +507,7 @@ static const struct of_device_id rockchip_dp_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
 

[PATCH] drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake

[Nickey Yang]

mtk_hdmi_setup_vendor_specific_infoframe will return before handle
mtk_hdmi_hw_send_info_frame.Because hdmi_vendor_infoframe_pack
returns the number of bytes packed into the binary buffer or
a negative error code on failure.
So correct it.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index c262512..b43aa29 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1062,7 +1062,7 @@ static int 
mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
}
 
err = hdmi_vendor_infoframe_pack(, buffer, sizeof(buffer));
-   if (err) {
+   if (err < 0) {
dev_err(hdmi->dev, "Failed to pack vendor infoframe: %zd\n",
err);
return err;
-- 
1.9.1


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

Re: [Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[Frank Gomez]

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov 
wrote:

> On 21 March 2017 at 18:06, Matt Turner  wrote:
> > On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov 
> wrote:
> >> On 21 March 2017 at 15:57, Matt Turner  wrote:
> >>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
>  On 20 March 2017 at 18:30, Matt Turner  wrote:
> > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> >> Seems like we ended up all over the place, so let me try afresh.
> >>
> >> Above all:
> >>  - Saying "I don't care" about your users is arrogant - let us _not_
> >> do that, please ?
> >
> > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > arbitrary restrictions caused including Mesa in its core: 10+ year
> old
> > GCC,
>  IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>  wasn't OpenBSD to blame here ;-)
> 
> > non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> > NetBSD keep Mesa as part of the core operating system, and as such
> > don't suffer from these problems.
> >
> > For better or worse, they have made their choices and they get to
> live
> > with them. We are not beholden to them.
> >
>  Overall this hunk seems misplaced. I go agree that we should not cater
>  for all their needs. At the same time, intentionally, breaking things
>  while we all can coexist is very strange.
> 
> >> Even Linux distribution maintainers have responded that "upstream
> does
> >> not care us", which is indicative that we should be more careful
> what
> >> we say.
> >
> > Citation needed.
> >
>  https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>  couple of instances where I've been contacted in private.
> 
> >> For the rest - we're dealing with two orthogonal issues here:
> >>
> >> * Multiple build systems
> >> I believe we'll all agree that I might be the person who's been in
> all
> >> the build systems the most.
> >> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that
> yet:
> >
> > No one is advocating dropping all of the existing build systems yet.
> >
> > This patch is an RFC for a smaller project to start the discussion
> about Mesa.
> >
> >>  - [currently] there is no viable solution for Android
> >
> > Acknowledged. Dylan is going to see if this is something that can be
> > solved in upstream Meson.
> >
>  I would suggest checking with Android people as well, as Meson.
>  There's some plans on moving to yet another build system - Blueprint.
> 
> >>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> >> write one from scratch, IIRC Solaris/FreeBSD and others are in
> similar
> >> boat.
> >
> > Solaris is a closed source operating system whose developers do not
> > contribute to the project. We do not need to base our decisions on
> > them.
> >
> > Mesa is not subject to ridiculous requirements (like in the case of
> > OpenBSD) in FreeBSD and NetBSD.
>  Again - not a requirement, but coexistence.
> 
> > Mesa depends on gmake in FreeBSD's
> > ports, for instance.
> >
>  That amongst others is a bug in their packaging.
> >>>
> >>> That is not even remotely the point.
> >>>
> >>> My point is that they are not subjecting themselves (and us by
> >>> extension, since you want to let them) to such ridiculous
> >>> requirements.
> >>>
> >> I will kindly ask you to keep these adjectives outside of what aims to
> >> be (?) technical discussion.
> >
> > Huh?
> >
> > Didn't you call us arrogant in this very thread? Didn't you suggest
> > we're immature?
> >
> Should I was unclear previously - I'm not trying to belittle, insult
> or otherwise offend your/anyone's contribution or input.
>
> I'm hoping to have a technical discussion, which does not have phrases
> such as "slow as mud" "i don't care", "X is ridiculous" and friends.
>
> >> And on your question - 50-100 lines worth of compatibility changes
> >> across a 6.5kloc of build system is not that unreasonable, right ?
> >
> > You're still not understanding my point.
> >
> > So I don't think any of this is true.
> >
>  I'd suggest giving it a try then - grab a non-GNU make, a release
>  tarball and let me know if you spot any issues.
> 
> >> These projects have been getting closer to upstream and "forcing"
> the
> >> extra obstacle is effectively giving them the middle finger.
> >
> > No. Requiring us to compile with a 10 year old GCC is giving a
> middle finger.
> >
>  Can we stop with the GCC thing ? Can we point to a place where we want
>  to use feature A introduced with GCC B and we don't 

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

[Brian Norris]

+ Thierry for real

On Tue, Mar 21, 2017 at 03:26:35PM -0400, Sean Paul wrote:
> On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote:
> > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> > panel.
> > 
> > Signed-off-by: Chris Zhong 
> > ---
> > 
> > Changes in v2:
> > - add some error check
> > - always use Low power mode to send commend
> > - add comments for all the sleep
> > - use DRM_DEV_ERROR instead of dev_err
> > 
> 
> Minor suggestion below. Once that's cleared up, you can add:
> Reviewed-by: Sean Paul 
> 
> Also, please add Thierry directly to your patches so he sees them.
> 
> 
> >  drivers/gpu/drm/panel/Kconfig |  11 +
> >  drivers/gpu/drm/panel/Makefile|   1 +
> >  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 
> > ++
> >  3 files changed, 356 insertions(+)
> >  create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
> > 
> 
> 
> > +static int innolux_panel_prepare(struct drm_panel *panel)
> > +{
> > +   struct innolux_panel *innolux = to_innolux_panel(panel);
> > +   int err, ret;
> > +
> > +   if (innolux->prepared)
> > +   return 0;
> > +
> > +   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> > +
> > +   err = regulator_enable(innolux->supply);
> > +   if (err < 0)
> > +   return err;
> > +
> > +   /* T2: 15ms - 1000ms */
> > +   usleep_range(15000, 16000);
> > +
> > +   gpiod_set_value_cansleep(innolux->enable_gpio, 1);
> > +
> > +   /* T4: 15ms - 1000ms */
> > +   usleep_range(15000, 16000);
> > +
> > +   err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
> > +   if (err < 0) {
> > +   DRM_DEV_ERROR(panel->dev, "failed to exit sleep mode: %d\n",
> > + err);
> > +   goto poweroff;
> > +   }
> > +
> > +   /* T6: 120ms - 1000ms*/
> > +   msleep(120);
> > +
> > +   err = mipi_dsi_dcs_set_display_on(innolux->link);
> > +   if (err < 0) {
> > +   DRM_DEV_ERROR(panel->dev, "failed to set display on: %d\n",
> > + err);
> > +   goto poweroff;
> > +   }
> > +
> > +   /* T7: 5ms */
> > +   usleep_range(5000, 6000);
> > +
> > +   innolux->prepared = true;
> > +
> > +   return 0;
> > +
> > +poweroff:
> > +   ret = regulator_disable(innolux->supply);
> > +   if (ret)
> > +   return ret;
> 
> I don't think we should be returning this error code. If we're here, it's
> because something else triggered err, and we should return that. Change this 
> to:
> 
> if (regulator_disable(innolux->supply))
> DRM_DEV_ERROR(panel->dev, "failed to disable regulator after 
> error\n");

And maybe include the error code in that message still?

ret = regulator_disable(innolux->supply);
if (ret)
DRM_DEV_ERROR(panel->dev, "failed to disable regulator after 
error (%d)\n",
  ret);

Brian

> > +
> > +   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> > +   return err;
> > +}
> 
> 
> 
> > -- 
> > 2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[CRTC:24] vblank wait timed out

[Martyn Welch]

I have an i.MX6 platform with 2 display port interfaces, one driven by the
HDMI interface, the other by LVDS, both via bridges. We are currently
experiencing the following error when we boot with the monitor connected
to the LVDS backed interface and then connect a monitor to the HDMI backed
interface after boot:

Mar 20 18:15:23 GE00409729044C kernel: [ cut here ]
Mar 20 18:15:23 GE00409729044C kernel: WARNING: CPU: 1 PID: 85 at 
/home/martyn/build-helix/tmp/work-shared/csmon/kernel-source/drivers/gpu/drm/drm_atomic_helper.c:1121
 drm_atomic_helper_wait_for_vblanks+0x264/0x274
Mar 20 18:15:23 GE00409729044C kernel: [CRTC:24] vblank wait timed out
Mar 20 18:15:23 GE00409729044C kernel: Modules linked in: bonding snd_usb_audio 
snd_hwdep snd_usbmidi_lib snd_rawmidi cp210x usbserial atmel_mxt_ts
Mar 20 18:15:23 GE00409729044C kernel: CPU: 1 PID: 85 Comm: kworker/u4:1 Not 
tainted 4.8.0 #4
Mar 20 18:15:23 GE00409729044C kernel: Hardware name: Freescale i.MX6 
Quad/DualLite (Device Tree)
Mar 20 18:15:23 GE00409729044C kernel: Workqueue: events_unbound commit_work
Mar 20 18:15:23 GE00409729044C kernel: Backtrace:
Mar 20 18:15:23 GE00409729044C kernel: [<8010c968>] (dump_backtrace) from 
[<8010cbb0>] (show_stack+0x20/0x24)
Mar 20 18:15:23 GE00409729044C kernel:  r7: r6:80d2bf98 r5:600b0013 
r4:
Mar 20 18:15:23 GE00409729044C kernel: [<8010cb90>] (show_stack) from 
[<803c0e68>] (dump_stack+0x98/0xb4)
Mar 20 18:15:23 GE00409729044C kernel: [<803c0dd0>] (dump_stack) from 
[<80122abc>] (__warn+0xe4/0x110)
Mar 20 18:15:23 GE00409729044C kernel:  r7:0009 r6:80a8d490 r5: 
r4:ee173e10
Mar 20 18:15:23 GE00409729044C kernel: [<801229d8>] (__warn) from [<80122b2c>] 
(warn_slowpath_fmt+0x44/0x4c)
Mar 20 18:15:23 GE00409729044C kernel:  r9:ee1e5418 r8: r7: 
r6: r5:ecc04f00 r4:80a8d5ec
Mar 20 18:15:23 GE00409729044C kernel: [<80122aec>] (warn_slowpath_fmt) from 
[<80486ce0>] (drm_atomic_helper_wait_for_vblanks+0x264/0x274)
Mar 20 18:15:23 GE00409729044C kernel:  r3:0018 r2:80a8d5ec
Mar 20 18:15:23 GE00409729044C kernel:  r4:edaa8200
Mar 20 18:15:23 GE00409729044C kernel: [<80486a7c>] 
(drm_atomic_helper_wait_for_vblanks) from [<804b3990>] 
(imx_drm_atomic_commit_tail+0x1b4/0x1e0)
Mar 20 18:15:23 GE00409729044C kernel:  r10:0ee80680 r9:80d76580 r8: 
r7:ee1e5000 r6:ecc04f00 r5:
Mar 20 18:15:23 GE00409729044C kernel:  r4:0004
Mar 20 18:15:23 GE00409729044C kernel: [<804b37dc>] 
(imx_drm_atomic_commit_tail) from [<80487498>] (commit_tail+0x50/0x6c)
Mar 20 18:15:23 GE00409729044C kernel:  r7:ee806800 r6:ee82b000 r5:80d3a5fc 
r4:ecc04f00
Mar 20 18:15:23 GE00409729044C kernel: [<80487448>] (commit_tail) from 
[<804874d0>] (commit_work+0x1c/0x20)
Mar 20 18:15:23 GE00409729044C kernel:  r5:eeb97280 r4:ecc04f1c
Mar 20 18:15:23 GE00409729044C kernel: [<804874b4>] (commit_work) from 
[<8013b638>] (process_one_work+0x154/0x510)
Mar 20 18:15:23 GE00409729044C kernel: [<8013b4e4>] (process_one_work) from 
[<8013ba30>] (worker_thread+0x3c/0x5cc)
Mar 20 18:15:23 GE00409729044C kernel:  r10:eeb97280 r9:ee82b000 r8:80d02100 
r7:ee82b018 r6:0088 r5:eeb97298
Mar 20 18:15:23 GE00409729044C kernel:  r4:ee82b000
Mar 20 18:15:23 GE00409729044C kernel: [<8013b9f4>] (worker_thread) from 
[<80141670>] (kthread+0xe4/0x100)
Mar 20 18:15:23 GE00409729044C kernel:  r10: r9: r8: 
r7:8013b9f4 r6:eeb97280 r5:eebae640
Mar 20 18:15:23 GE00409729044C kernel:  r4:
Mar 20 18:15:23 GE00409729044C kernel: [<8014158c>] (kthread) from [<80108278>] 
(ret_from_fork+0x14/0x3c)
Mar 20 18:15:23 GE00409729044C kernel:  r7: r6: r5:8014158c 
r4:eebae640
Mar 20 18:15:23 GE00409729044C kernel: ---[ end trace ba005811962ba6f2 ]---

We believe this may be due to the vblank interrupt for the LVDS interface
being affected when the vblank interface for the HDMI backed interface
gets enabled. Any pointers regarding how to proceed narrowing down/fixing
this would be appreciated.

We are currently running 4.8 kernel with 1.11 Weston compositor.

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

Re: [PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

[Brian Norris]

On Fri, Mar 17, 2017 at 11:54:24AM +0800, Chris Zhong wrote:
> For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
> not RK3399_GRF_SOC_CON19.

Matches the TRM for me, and otherwise it's a no-op:

Reviewed-by: Brian Norris 

> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v3: None
> Changes in v2: 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 5a18281..19b9208 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -34,7 +34,7 @@
>  #define RK3288_DSI0_SEL_VOP_LIT  BIT(6)
>  #define RK3288_DSI1_SEL_VOP_LIT  BIT(9)
>  
> -#define RK3399_GRF_SOC_CON19 0x6250
> +#define RK3399_GRF_SOC_CON20 0x6250
>  #define RK3399_DSI0_SEL_VOP_LIT  BIT(0)
>  #define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
>  
> @@ -1151,7 +1151,7 @@ static struct dw_mipi_dsi_plat_data 
> rk3288_mipi_dsi_drv_data = {
>  static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
>   .dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
>   .dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
> - .grf_switch_reg = RK3399_GRF_SOC_CON19,
> + .grf_switch_reg = RK3399_GRF_SOC_CON20,
>   .grf_dsi0_mode = RK3399_GRF_DSI_MODE,
>   .grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
>   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> -- 
> 2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GEM allocation for para-virtualized DRM driver

[Oleksandr Andrushchenko]

On 03/20/2017 08:52 PM, Rob Clark wrote:

On Mon, Mar 20, 2017 at 2:25 PM, Oleksandr Andrushchenko
 wrote:

On 03/20/2017 08:17 PM, Rob Clark wrote:

On Mon, Mar 20, 2017 at 2:01 PM, Oleksandr Andrushchenko
 wrote:

On 03/20/2017 07:38 PM, Rob Clark wrote:

On Mon, Mar 20, 2017 at 1:18 PM, Oleksandr Andrushchenko
 wrote:


On 03/18/2017 02:22 PM, Rob Clark wrote:

On Fri, Mar 17, 2017 at 1:39 PM, Oleksandr Andrushchenko
 wrote:

Hello,
I am writing a para-virtualized DRM driver for Xen hypervisor
and it now works with DRM CMA helpers, but I would also like
to make it work with non-contigous memory: virtual machine
that the driver runs in can't guarantee that CMA is actually
physically contigous (that is not a problem because of IPMMU
and other means, the only constraint I have is that I cannot mmap
with pgprot == noncached). So, I am planning to use
*drm_gem_get_pages*
+
*shmem_read_mapping_page_gfp* to allocate memory for GEM objects
(scanout buffers + dma-bufs shared with virtual GPU)

Do you think this is the right approach to take?

I guess if you had some case where you needed to "migrate" buffers
between host and guest memory, then TTM might be useful.  Otherwise
this sounds like the right approach.

Tried that today (drm_gem_get_pages), the result is interesting:

1. modetest
1.1. Runs, I can see page flips
1.2. vm_operations_struct.fault is called, I can vm_insert_page

2. kmscube (Rob, thanks for that :) + PowerVR SGX 6250
2.1. Cannot initialize EGL
2.2. vm_operations_struct.fault is NOT called

jfwiw, pages will only get faulted in when CPU accesses them..

indeed, good catch

modetest "renders" the frame on the CPU but kmscube does it on gpu.

yes, I have already learned that modetest only renders once and
then just flips

So not seeing vm_operations_struct.fault is normal.  The EGL fail is
not..


In both cases 2 dumbs are created and successfully mmaped,
in case of kmscube there are also handle_to_fd IOCTLs issued
and no DRM errors observed. No DMA-BUF mmap attempt seen

I re-checked 2) with alloc_pages + remap_pfn_range and it works
(it cannot unmap cleanly, but it could be because I didn't call
split_pages after alloc_pages), thus the setup is still good

Can it be that the buffer allocated with drm_gem_get_pages
doesn't suit PowerVR for some reason?

I've no idea what the state of things is w/ pvr as far as gbm support
(not required/used by modetest, but anything that uses the gpu on
"bare metal" needs it).  Or what the state of dmabuf-import is with
pvr.

Do you think there could be DMA related problems with
the buffer allocated with drm_gem_get_pages and DMA mapping,
use? So GPU is not able to handle those?

The only source of knowledge at the moment I have is
publicly available pvrsrvkm kernel module. But there are
other unknowns, e.g. user-space libraries, firmware which
are in binary form: thus kernel driver is mostly a bridge
between FW and libs. That being said, do you think I have to get
deeper into GPU use-case or should I switch back to alloc_pages+
remap_pfn_range? ;)

so, I suppose with pvr there is a whole host of potential pain... *but*..

if alloc_pages path actually works, then perhaps the issue is the
deferred allocation.  Ie. most drivers don't drm_gem_get_pages() until
the buffer is passed to hw or until it is faulted in.  You should make
sure it ends up getting called (if it hasn't been called already)
somewhere in gem_prime_pin.

I call drm_gem_get_pages as part of dumb creation, because I
need to pass the pages to the host OS. So, probably, this is not
because of the late allocation, but something else

hmm, well all the pvr gpu's that I've had to deal with in the past
have MMUs, so there shouldn't be any specific issue with where the
pages come from.  But I guess you have to poke around the kernel
module to see where things go wrong with dmabuf import (or if it even
gets that far)

well, if I do vm_insert_page on .mmap for the whole
buffer, then everything is ok for both GPU and CPU, so
probably I'll leave it that way.
I also removed .fault handler as it seems to be not needed
if we mmap the whole thing at once


BR,
-R


BR,
-R

Thank you!

Thank you for helping!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config

[Nickey Yang]

Vendor specific infoframe is mandatory for 4K2K resolution.
Without this, the HDMI protocol compliance fails.

Signed-off-by: Nickey Yang 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 53 
 drivers/gpu/drm/bridge/dw-hdmi.h |  4 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9a9ec27..6b29d1a 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1195,6 +1195,58 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi_writeb(hdmi, (frame.right_bar >> 8) & 0xff, HDMI_FC_AVISRB1);
 }
 
+static void hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
+struct drm_display_mode *mode)
+{
+   struct hdmi_vendor_infoframe frame;
+   u8 buffer[10];
+   ssize_t err;
+
+   err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);
+   if (err < 0)
+   /*
+* Going into that statement does not means vendor infoframe
+* fails. It just informed us that vendor infoframe is not
+* needed for the selected mode. Only 4k or stereoscopic 3D
+* mode requires vendor infoframe. So just simply return.
+*/
+   return;
+
+   err = hdmi_vendor_infoframe_pack(, buffer, sizeof(buffer));
+   if (err < 0) {
+   dev_err(hdmi->dev, "Failed to pack vendor infoframe: %zd\n",
+   err);
+   return;
+   }
+   hdmi_mask_writeb(hdmi, 0, HDMI_FC_DATAUTO0, HDMI_FC_DATAUTO0_VSD_OFFSET,
+   HDMI_FC_DATAUTO0_VSD_MASK);
+
+   /* Set the length of HDMI vendor specific InfoFrame payload */
+   hdmi_writeb(hdmi, buffer[2], HDMI_FC_VSDSIZE);
+
+   /* Set 24bit IEEE Registration Identifier */
+   hdmi_writeb(hdmi, buffer[4], HDMI_FC_VSDIEEEID0);
+   hdmi_writeb(hdmi, buffer[5], HDMI_FC_VSDIEEEID1);
+   hdmi_writeb(hdmi, buffer[6], HDMI_FC_VSDIEEEID2);
+
+   /* Set HDMI_Video_Format and HDMI_VIC/3D_Structure */
+   hdmi_writeb(hdmi, buffer[7], HDMI_FC_VSDPAYLOAD0);
+   hdmi_writeb(hdmi, buffer[8], HDMI_FC_VSDPAYLOAD1);
+
+   if (frame.s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+   hdmi_writeb(hdmi, buffer[9], HDMI_FC_VSDPAYLOAD2);
+
+   /* Packet frame interpolation */
+   hdmi_writeb(hdmi, 1, HDMI_FC_DATAUTO1);
+
+   /* Auto packets per frame and line spacing */
+   hdmi_writeb(hdmi, 0x11, HDMI_FC_DATAUTO2);
+
+   /* Configures the Frame Composer On RDRB mode */
+   hdmi_mask_writeb(hdmi, 1, HDMI_FC_DATAUTO0, HDMI_FC_DATAUTO0_VSD_OFFSET,
+   HDMI_FC_DATAUTO0_VSD_MASK);
+}
+
 static void hdmi_av_composer(struct dw_hdmi *hdmi,
 const struct drm_display_mode *mode)
 {
@@ -1446,6 +1498,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 
/* HDMI Initialization Step F - Configure AVI InfoFrame */
hdmi_config_AVI(hdmi, mode);
+   hdmi_config_vendor_specific_infoframe(hdmi, mode);
} else {
dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
}
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 325b0b8..c59f87e 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -854,6 +854,10 @@ enum {
HDMI_FC_DBGFORCE_FORCEAUDIO = 0x10,
HDMI_FC_DBGFORCE_FORCEVIDEO = 0x1,
 
+/* FC_DATAUTO0 field values */
+   HDMI_FC_DATAUTO0_VSD_MASK = 0x08,
+   HDMI_FC_DATAUTO0_VSD_OFFSET = 3,
+
 /* PHY_CONF0 field values */
HDMI_PHY_CONF0_PDZ_MASK = 0x80,
HDMI_PHY_CONF0_PDZ_OFFSET = 7,
-- 
1.9.1


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

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/i915_gem_shrinker.c

between commit:

  3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")

from the drm-intel-fixes tree and commit:

  519d52498156 ("drm/i915: i915_gem_shrink_all() needs an awake device")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_gem_shrinker.c
index d5d2b4c6ed38,006a8b908f77..
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@@ -263,7 -264,9 +264,9 @@@ unsigned long i915_gem_shrink_all(struc
I915_SHRINK_BOUND |
I915_SHRINK_UNBOUND |
I915_SHRINK_ACTIVE);
+   intel_runtime_pm_put(dev_priv);
+ 
 -  rcu_barrier(); /* wait until our RCU delayed slab frees are completed */
 +  synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */
  
return freed;
  }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/i915_gem_context.c

between commit:

  590379aef2e3 ("drm/i915: make context status notifier head be per engine")

from the drm-intel-fixes tree and commits:

  2355cf088d46 ("drm/i915: Create context desc template when context is 
created")
  949e8ab3a94b ("drm/i915: Use the size/type of address space to make 
decisions")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_gem_context.c
index e2d83b6d376b,baceca14f5e0..
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@@ -309,8 -316,9 +316,8 @@@ __create_hw_context(struct drm_i915_pri
  
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
-   ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
-GEN8_CTX_ADDRESSING_MODE_SHIFT;
+   ctx->desc_template =
+   default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
 -  ATOMIC_INIT_NOTIFIER_HEAD(>status_notifier);
  
/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not
 * present or not in use we still need a small bias as ring wraparound
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100270] power usage increase by approx 4W between kernel 4.7.8 and 4.8.5

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100270

--- Comment #7 from brett.hass...@gmail.com ---
(In reply to Alex Deucher from comment #6)
> (In reply to brett.hassall from comment #5)
> > (In reply to Emil Velikov from comment #2)
> > > If your bisection has gone right, you're looking at either
> > > c39b487f195b93235ee76384427467786f7bf29f (if you're running amdgpu) or
> > > b817634276f7f68c9d1d6d4a27117ff3c2f16956 (if you're on radeon).
> > > 
> > > lspci should tell you which one, and you should be able to revert either 
> > > one
> > > on top of 4.8.5. Once you confirm the commit causing the issue, please
> > > change the component accordingly and CC the author - Alex Deucher.
> > 
> > Following the "git checkout tags/v4.8-rc3 -b bug" I reverted
> > b817634276f7f68c9d1d6d4a27117ff3c2f16956. Power usage dropped by approx 4.5W
> > (measured after login once system had settled, wifi not connected).
> 
> So apparently your system claims to support pcie pm (d3cold), but either
> doesn't or it's disabled for some reason.

I've taken a look in the BIOS and there doesn't appear to be any settings under
Power Management related to pcie. I've also checked in /etc/default/grub, there
is only 'quiet' on the CMDLINE settings.

Booted under kernel 4.9, sudo lspci -vv for the radeon card shows:
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Under kernel 4.4 and 4.7 with the lower power consumption, sudo lspci -vv shows
"Unknown header type 7f".

Booted under kernel 4.9, sudo dmesg | grep 01:00.0 shows:
[0.515468] pci :01:00.0: [1002:6660] type 00 class 0x038000
[0.515480] pci :01:00.0: reg 0x10: [mem 0xe000-0xefff 64bit
pref]
[0.515489] pci :01:00.0: reg 0x18: [mem 0xf7c0-0xf7c3
64bit]
[0.515495] pci :01:00.0: reg 0x20: [io  0xe000-0xe0ff]
[0.515506] pci :01:00.0: reg 0x30: [mem 0xf7c4-0xf7c5 pref]
[0.515545] pci :01:00.0: supports D1 D2
[0.515545] pci :01:00.0: PME# supported from D1 D2 D3hot
[0.515566] pci :01:00.0: System wakeup disabled by ACPI
[2.950049] radeon :01:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[2.950051] radeon :01:00.0: GTT: 2048M 0x8000 -
0x
[2.952510] radeon :01:00.0: firmware: direct-loading firmware
radeon/hainan_pfp.bin
[2.952800] radeon :01:00.0: firmware: direct-loading firmware
radeon/hainan_me.bin
[2.953657] radeon :01:00.0: firmware: direct-loading firmware
radeon/hainan_ce.bin
[2.954265] radeon :01:00.0: firmware: direct-loading firmware
radeon/hainan_rlc.bin
[2.955119] radeon :01:00.0: firmware: direct-loading firmware
radeon/hainan_mc.bin
[2.955430] radeon :01:00.0: firmware: direct-loading firmware
radeon/hainan_smc.bin
[2.989489] radeon :01:00.0: WB enabled
[2.989491] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x8c00 and cpu addr 0x9e4896928c00
[2.989493] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x8c04 and cpu addr 0x9e4896928c04
[2.989494] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x8c08 and cpu addr 0x9e4896928c08
[2.989495] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x8c0c and cpu addr 0x9e4896928c0c
[2.989496] radeon :01:00.0: fence driver on ring 4 use gpu addr
0x8c10 and cpu addr 0x9e4896928c10
[2.989498] radeon :01:00.0: radeon: MSI limited to 32-bit
[2.989561] radeon :01:00.0: radeon: using MSI.
[3.229692] [drm] Initialized radeon 2.48.0 20080528 for :01:00.0 on
minor 1

There is no mention of D3cold for the radeon card. Comparing lspci and dmesg
output, the pattern seems to be D3cold+ in the device capabilities results in
"PME# supported from D0 D3hot D3cold" in dmesg.

I need the longer battery life for travelling and can cope easily without the
radeon card being used. Is there a workaround, perhaps something in the
modprobe.d, to make the radeon driver revert to old behaviour ie behave as if
there was no d3cold support on the system?

-- 
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 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=193981

--- Comment #11 from winches (dry...@gmx.fr) ---
I can try. I've seen how to do on the wiki.
I will test the kernel 4.9.1 and the 4.11rc1 tomorrow.
It may be longto do all the bisect, it took nearly 40-50 min to compile.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hey Kai,

Quoting Kai Wasserbäch (2017-03-21 11:36:31)
> I hope the rest of the Mesa project would follow such a rule. Because if 
> there's
> something I absolutely hate about all those "new" build systems, then it's 
> their
> tendency to just download stuff and build/include that. This seems to have 
> risen
> with Node and now spread into Rust and other parts of the FLOSS eco-system.

I think we have enough distro people in the project that they would revert a use
of wrap on linux :)

> CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the
> Android eco-system already
> (), which might mean it
> could be easier for the Android downstreams of Mesa? Not sure on that though.

I don't think this really helps our android problem, since mesa is part of the
core anrdoid tree for devices using mesa, it needs android.mk files (I think
someone mentioned that they're migrating to blueprint?), and that doesn't
support cmake, autotools, scons, or meson. If meson is useful I'm willing to
propose and write an android.mk or blueprint backend for meson if the meson
community wants it.

> > 2) meson much simpler than autotools, scons, or (especially) cmake
> 
> OTOH CMake gives you CTest/CDash
> (), CPack
> (), dependency
> visualisation
> () and
> many other things for (basically) free. Maybe that warrants some complexity?

Meson generates a 'ninja test' target, and has a mesontest which I assume is
similar to CTest, but I've never used mesontest or CTest tbh, so I can't comment
too much about either.

> > 3) recursive meson files, flat ninja file.
> 
> IIRC you would also get the same with CMake if you target Ninja.

That's fair.

> > 
> > I've never had to use gitattributes for anything, are you thinking for 
> > setting
> > export-ignore and export-subst?
> 
> Yep. AFAICT we have several files which aren't distributed if you do "make
> dist". Those would need to be excluded from a tarball built with git archive 
> as
> well. AFAIK that's done through having .gitattributes files in the tree.

I'll have a look at what ends up in the dist-tarball and what ends up in a
git-archive tarbal too. Thanks for pointing that out.

> Anyway, I don't want to bikeshed here, so I'll be silent as long as any 
> possible
> future build system doesn't download stuff behind my back.
> 
> Thanks for your reply!
> 
> Cheers,
> Kai

Thanks for your reply Kai, I hadn't even noticed wrap, so at the very least it's
good to see that's there, and I'll be sure to add a note to the README that we
don't use wrap on Linux, BSD and similar.

Dylan


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

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

[Sean Paul]

On Tue, Mar 21, 2017 at 01:38:31PM -0700, Brian Norris wrote:
> + Thierry for real
> 
> On Tue, Mar 21, 2017 at 03:26:35PM -0400, Sean Paul wrote:
> > On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote:
> > > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> > > panel.
> > > 
> > > Signed-off-by: Chris Zhong 
> > > ---
> > > 
> > > Changes in v2:
> > > - add some error check
> > > - always use Low power mode to send commend
> > > - add comments for all the sleep
> > > - use DRM_DEV_ERROR instead of dev_err
> > > 
> > 
> > Minor suggestion below. Once that's cleared up, you can add:
> > Reviewed-by: Sean Paul 
> > 
> > Also, please add Thierry directly to your patches so he sees them.
> > 
> > 
> > >  drivers/gpu/drm/panel/Kconfig |  11 +
> > >  drivers/gpu/drm/panel/Makefile|   1 +
> > >  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 
> > > ++
> > >  3 files changed, 356 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
> > > 
> > 
> > 
> > > +static int innolux_panel_prepare(struct drm_panel *panel)
> > > +{
> > > + struct innolux_panel *innolux = to_innolux_panel(panel);
> > > + int err, ret;
> > > +
> > > + if (innolux->prepared)
> > > + return 0;
> > > +
> > > + gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> > > +
> > > + err = regulator_enable(innolux->supply);
> > > + if (err < 0)
> > > + return err;
> > > +
> > > + /* T2: 15ms - 1000ms */
> > > + usleep_range(15000, 16000);
> > > +
> > > + gpiod_set_value_cansleep(innolux->enable_gpio, 1);
> > > +
> > > + /* T4: 15ms - 1000ms */
> > > + usleep_range(15000, 16000);
> > > +
> > > + err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
> > > + if (err < 0) {
> > > + DRM_DEV_ERROR(panel->dev, "failed to exit sleep mode: %d\n",
> > > +   err);
> > > + goto poweroff;
> > > + }
> > > +
> > > + /* T6: 120ms - 1000ms*/
> > > + msleep(120);
> > > +
> > > + err = mipi_dsi_dcs_set_display_on(innolux->link);
> > > + if (err < 0) {
> > > + DRM_DEV_ERROR(panel->dev, "failed to set display on: %d\n",
> > > +   err);
> > > + goto poweroff;
> > > + }
> > > +
> > > + /* T7: 5ms */
> > > + usleep_range(5000, 6000);
> > > +
> > > + innolux->prepared = true;
> > > +
> > > + return 0;
> > > +
> > > +poweroff:
> > > + ret = regulator_disable(innolux->supply);
> > > + if (ret)
> > > + return ret;
> > 
> > I don't think we should be returning this error code. If we're here, it's
> > because something else triggered err, and we should return that. Change 
> > this to:
> > 
> > if (regulator_disable(innolux->supply))
> > DRM_DEV_ERROR(panel->dev, "failed to disable regulator after 
> > error\n");
> 
> And maybe include the error code in that message still?
> 
>   ret = regulator_disable(innolux->supply);
>   if (ret)
>   DRM_DEV_ERROR(panel->dev, "failed to disable regulator after 
> error (%d)\n",
> ret);

Sure, but let's not have ret beside err, each function should have one or the
other. So, perhaps s/ret/regulator_err/ or similar.

Sean

> 
> Brian
> 
> > > +
> > > + gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> > > + return err;
> > > +}
> > 
> > 
> > 
> > > -- 
> > > 2.6.3

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/3] drm/panel: Pull some code out into common helpers

[Eric Anholt]

Sean Paul  writes:

> This series pulls out the power-sequencing code from panel-simple into a
> panel-common helper library. This allows drivers that cannot leverage
> panel-simple to share some code.
>
> I've converted the 2 sharp mipi drivers, and Chris Zhong's driver on the
> list can also be converted. I haven't checked any other drivers, but I
> suspect we'll see the same code blocks there too.
>
> I'm sure there's more we can pull out of the various drivers, but this
> seems like a good place to start talking about how to share common panel
> code across drivers.

I've been looking at doing another panel driver for one with a little
SPI sequence at bringup, and this series seems like it would be nice to
have for that.


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

Re: [RFC PATCH 2/3] drm/panel: sharp-lq101r1sx01: Use panel-common helpers

[Eric Anholt]

Sean Paul  writes:

> Instead of duplicating common code from panel-simple, use the panel-common 
> helpers.
>
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/panel/Kconfig   |  1 +
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 79 
> +++--
>  2 files changed, 24 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index be8590724042..98db78d22a13 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -73,6 +73,7 @@ config DRM_PANEL_SHARP_LQ101R1SX01
>   depends on OF
>   depends on DRM_MIPI_DSI
>   depends on BACKLIGHT_CLASS_DEVICE
> + select DRM_PANEL_COMMON
>   help
> Say Y here if you want to enable support for Sharp LQ101R1SX01
> TFT-LCD modules. The panel has a 2560x1600 resolution and uses
> diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
> b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> index 3cce3ca19601..fb2bf67449ab 100644
> --- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> +++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> @@ -6,11 +6,8 @@
>   * published by the Free Software Foundation.
>   */
>  
> -#include 
> -#include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> @@ -19,17 +16,17 @@
>  
>  #include 
>  
> +#include "panel-common.h"
> +
>  struct sharp_panel {
>   struct drm_panel base;
> + struct panel_common common;
> +
>   /* the datasheet refers to them as DSI-LINK1 and DSI-LINK2 */
>   struct mipi_dsi_device *link1;
>   struct mipi_dsi_device *link2;
>  
> - struct backlight_device *backlight;
> - struct regulator *supply;
> -
>   bool prepared;
> - bool enabled;
>  
>   const struct drm_display_mode *mode;
>  };
> @@ -93,17 +90,7 @@ static int sharp_panel_disable(struct drm_panel *panel)
>  {
>   struct sharp_panel *sharp = to_sharp_panel(panel);
>  
> - if (!sharp->enabled)
> - return 0;
> -
> - if (sharp->backlight) {
> - sharp->backlight->props.power = FB_BLANK_POWERDOWN;
> - backlight_update_status(sharp->backlight);
> - }
> -
> - sharp->enabled = false;
> -
> - return 0;
> + return panel_common_disable(>common, 0);
>  }
>  
>  static int sharp_panel_unprepare(struct drm_panel *panel)
> @@ -126,11 +113,13 @@ static int sharp_panel_unprepare(struct drm_panel 
> *panel)
>  
>   msleep(120);
>  
> - regulator_disable(sharp->supply);
> + err = panel_common_unprepare(>common, 0);
> + if (err < 0)
> + dev_err(panel->dev, "failed common unprepare: %d\n", err);
>  
>   sharp->prepared = false;
>  
> - return 0;
> + return err;
>  }
>  
>  static int sharp_setup_symmetrical_split(struct mipi_dsi_device *left,
> @@ -176,17 +165,15 @@ static int sharp_panel_prepare(struct drm_panel *panel)
>   if (sharp->prepared)
>   return 0;
>  
> - err = regulator_enable(sharp->supply);
> - if (err < 0)
> - return err;
> -
>   /*
>* According to the datasheet, the panel needs around 10 ms to fully
>* power up. At least another 120 ms is required before exiting sleep
>* mode to make sure the panel is ready. Throw in another 20 ms for
>* good measure.
>*/
> - msleep(150);
> + err = panel_common_prepare(>common, 150);
> + if (err < 0)
> + return err;

Aside: I like how 120 + 20 = 150, because always round up your delays :)

>  
>   err = mipi_dsi_dcs_exit_sleep_mode(sharp->link1);
>   if (err < 0) {
> @@ -252,7 +239,7 @@ static int sharp_panel_prepare(struct drm_panel *panel)
>   return 0;
>  
>  poweroff:
> - regulator_disable(sharp->supply);
> + panel_common_unprepare(>common, 0);
>   return err;
>  }
>  
> @@ -260,17 +247,7 @@ static int sharp_panel_enable(struct drm_panel *panel)
>  {
>   struct sharp_panel *sharp = to_sharp_panel(panel);
>  
> - if (sharp->enabled)
> - return 0;
> -
> - if (sharp->backlight) {
> - sharp->backlight->props.power = FB_BLANK_UNBLANK;
> - backlight_update_status(sharp->backlight);
> - }
> -
> - sharp->enabled = true;
> -
> - return 0;
> + return panel_common_enable(>common, 0);
>  }
>  
>  static const struct drm_display_mode default_mode = {
> @@ -324,23 +301,15 @@ MODULE_DEVICE_TABLE(of, sharp_of_match);
>  
>  static int sharp_panel_add(struct sharp_panel *sharp)
>  {
> - struct device_node *np;
>   int err;
>  
>   sharp->mode = _mode;
> + sharp->prepared = false;
>  
> - sharp->supply = devm_regulator_get(>link1->dev, "power");
> - if (IS_ERR(sharp->supply))
> - return PTR_ERR(sharp->supply);
> -
> - np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);
> - if (np) {
> - sharp->backlight = 

Re: [PATCH v4 2/8] drm/stm: Add STM32 LTDC driver

[Eric Anholt]

Yannick Fertre  writes:

> This controller provides output signals to interface directly a variety
> of LCD and TFT panels. These output signals are: RGB signals
> (up to 24bpp), vertical & horizontal synchronisations, data enable and
> the pixel clock.

I've got some feedback inline that hopefully helps cut some boilerplate
DRM code.  This looks like a complete driver, and some nice hardware as
far as modesetting goes.

If you're planning on going through drm-misc, I'd do another pass at
review so I could give an Ack.

> Change-Id: Ic1d6ade06ab7115c62e98dd21dc3981fb5948d1c
> Signed-off-by: Yannick Fertre 
> ---
>  drivers/gpu/drm/Kconfig  |3 +-
>  drivers/gpu/drm/Makefile |1 +
>  drivers/gpu/drm/stm/Kconfig  |   16 +
>  drivers/gpu/drm/stm/Makefile |7 +
>  drivers/gpu/drm/stm/drv.c|  232 +++
>  drivers/gpu/drm/stm/drv.h|   22 +
>  drivers/gpu/drm/stm/ltdc.c   | 1422 
> ++
>  drivers/gpu/drm/stm/ltdc.h   |   22 +
>  8 files changed, 1724 insertions(+), 1 deletion(-)
>  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 78d7fc0..dd5762a 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -203,7 +203,6 @@ config DRM_VGEM
> as used by Mesa's software renderer for enhanced performance.
> If M is selected the module will be called vgem.
>  
> -
>  source "drivers/gpu/drm/exynos/Kconfig"
>  
>  source "drivers/gpu/drm/rockchip/Kconfig"
> @@ -246,6 +245,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 59aae43..320fd86 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..8ef8a09
> --- /dev/null
> +++ b/drivers/gpu/drm/stm/Kconfig
> @@ -0,0 +1,16 @@
> +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
> + default y
> +
> + help
> +   Enable support for the on-chip display controller on
> +STMicroelectronics STM32 MCUs.

Funny indentation here?

> +   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..d5c46c5
> --- /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 STM_MAX_FB_WIDTH 2048
> +#define STM_MAX_FB_HEIGHT2048 /* 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 

Re: [PATCH v4 1/8] dt-bindings: display: add STM32 LTDC driver

[Eric Anholt]

Yannick Fertre  writes:

> Acked-by: Rob Herring 
> 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.

I think you meant "lcd" here.

> +  - 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 = < STM32F4_APB2_RESET(LTDC)>;
> + clocks = < 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


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

[Bug 100305] [BAT][IGT]basic tests in gem_ctx_basic, gem_ctx_exec, gem_ctx_params fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100305

Chris Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Chris Wilson  ---
commit 83884e97e18739e3588c6467a210838099d42073
Author: Chris Wilson 
Date:   Tue Mar 21 17:16:03 2017 +

Restore "lib: Open debugfs files for the given DRM device"

This reverts commit 25fbae15262cf570e207e62f50e7c5233e06bc67, restoring
commit 301ad44cdf1b868b1ab89096721da91fa8541fdc
Author: Tomeu Vizoso 
Date:   Thu Mar 2 10:37:11 2017 +0100

lib: Open debugfs files for the given DRM device

with fixes.

Signed-off-by: Chris Wilson 

-- 
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 12/41] drm/bridge: analogix_dp: add fast link train for eDP

[Sean Paul]

On Thu, Mar 16, 2017 at 03:14:28PM +0100, Andrzej Hajda wrote:
> On 10.03.2017 05:32, Sean Paul wrote:
> > From: zain wang 
> >
> > We would meet a short black screen when exit PSR with the full link
> > training, In this case, we should use fast link train instead of full
> > link training.
> >
> > Signed-off-by: zain wang 
> > Signed-off-by: Sean Paul 
> > ---
> >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 142 
> > -
> >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   3 +
> >  2 files changed, 114 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index 64d94a34874d..5bc151b0995b 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -10,17 +10,18 @@
> >  * option) any later version.
> >  */
> >  
> > -#include 
> > -#include 
> > -#include 
> >  #include 
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -35,6 +36,8 @@
> >  
> >  #define to_dp(nm)  container_of(nm, struct analogix_dp_device, nm)
> >  
> > +static const bool verify_fast_training;
> > +
> 
> Quite odd debug sentinel, I am not sure if it is good practice to use
> such construct.

IIRC, they originally had a #define and then used #ifdef below to gate the
verification. My concern with that was the code would rot if it wasn't compiled.



> > @@ -853,10 +933,10 @@ static void analogix_dp_commit(struct 
> > analogix_dp_device *dp)
> > DRM_ERROR("failed to disable the panel\n");
> > }
> >  
> > -   ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
> > -dp->video_info.max_link_rate);
> > +   ret = readx_poll_timeout(analogix_dp_train_link, dp, ret, !ret, 100,
> > +DP_TIMEOUT_TRAINING_US * 5);
> > if (ret) {
> > -   dev_err(dp->dev, "unable to do link train\n");
> > +   dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
> 
> And here we have ", ret=%d\n". Maybe it would be good to make it
> consistent across whole driver.

Meh. I don't think it's worth bikeshedding over commas in error messages. I'm
just happy there are error checks/messages.


> Another issue with consistency in DRM_DEV_ERROR vs dev_err.

Yeah, that's annoying.

Sean

> 
> Regards
> Andrzej
> 
> > return;
> > }
> >  
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > index e135a42cb19e..920607d7eb3e 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > @@ -20,6 +20,8 @@
> >  #define MAX_CR_LOOP 5
> >  #define MAX_EQ_LOOP 5
> >  
> > +/* Training takes 22ms if AUX channel comm fails. Use this as retry 
> > interval */
> > +#define DP_TIMEOUT_TRAINING_US 22000
> >  #define DP_TIMEOUT_PSR_LOOP_MS 300
> >  
> >  /* DP_MAX_LANE_COUNT */
> > @@ -171,6 +173,7 @@ struct analogix_dp_device {
> > int hpd_gpio;
> > boolforce_hpd;
> > boolpsr_enable;
> > +   boolfast_train_support;
> >  
> > struct mutexpanel_lock;
> > boolpanel_is_modeset;
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

[Sean Paul]

On Fri, Mar 17, 2017 at 11:54:23AM +0800, Chris Zhong wrote:
> For RK3399, the grf clk should be enabled before writing grf registers,
> otherwise the register value can not be changed.
> 
> Signed-off-by: Chris Zhong 

Minor nit below, with that:

Reviewed-by: Sean Paul 

> ---
> 
> Changes in v3:
> - add a DW_MIPI_NEEDS_GRF_CLK for RK3399
> 
> Changes in v2:
> - check the grf_clk only for RK3399
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 68f48b0..5a18281 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -252,6 +252,7 @@
>  #define THS_ZERO_PROGRAM_EN  BIT(6)
>  
>  #define DW_MIPI_NEEDS_PHY_CFG_CLKBIT(0)
> +#define DW_MIPI_NEEDS_GRF_CLKBIT(1)
>  
>  enum {
>   BANDGAP_97_07,
> @@ -294,6 +295,7 @@ struct dw_mipi_dsi {
>   struct regmap *grf_regmap;
>   void __iomem *base;
>  
> + struct clk *grf_clk;
>   struct clk *pllref_clk;
>   struct clk *pclk;
>   struct clk *phy_cfg_clk;
> @@ -982,6 +984,17 @@ static void dw_mipi_dsi_encoder_enable(struct 
> drm_encoder *encoder)
>   dw_mipi_dsi_dphy_interface_config(dsi);
>   dw_mipi_dsi_clear_err(dsi);
>  
> + /*
> +  * For the RK3399, the clk of grf must be enabled before writing grf
> +  * register. And for RK3288 or other soc, this grf_clk must be NULL,
> +  * the clk_prepare_enable return true directly.
> +  */
> + ret = clk_prepare_enable(dsi->grf_clk);
> + if (ret) {
> + dev_err(dsi->dev, "Failed to enable grf_clk\n");

nit: Print ret?

> + return;
> + }
> +
>   if (pdata->grf_dsi0_mode_reg)
>   regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
>pdata->grf_dsi0_mode);
> @@ -1006,6 +1019,8 @@ 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;
> +
> + clk_disable_unprepare(dsi->grf_clk);
>  }
>  
>  static int
> @@ -1139,7 +1154,7 @@ static struct dw_mipi_dsi_plat_data 
> rk3399_mipi_dsi_drv_data = {
>   .grf_switch_reg = RK3399_GRF_SOC_CON19,
>   .grf_dsi0_mode = RK3399_GRF_DSI_MODE,
>   .grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
> - .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
> + .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
>   .max_data_lanes = 4,
>  };
>  
> @@ -1240,6 +1255,15 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
> device *master,
>   }
>   }
>  
> + if (pdata->flags & DW_MIPI_NEEDS_GRF_CLK) {
> + dsi->grf_clk = devm_clk_get(dev, "grf");
> + if (IS_ERR(dsi->grf_clk)) {
> + ret = PTR_ERR(dsi->grf_clk);
> + dev_err(dev, "Unable to get grf_clk: %d\n", ret);
> + return ret;
> + }
> + }
> +
>   ret = clk_prepare_enable(dsi->pllref_clk);
>   if (ret) {
>   dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

[Sean Paul]

On Tue, Mar 21, 2017 at 04:16:23PM -0400, Sean Paul wrote:
> On Fri, Mar 17, 2017 at 11:54:21AM +0800, Chris Zhong wrote:
> > For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is
> > disabled, MIPI phy can not work. Let's return a error if there is no
> > phy_cfg_clk in dts property, when the pdata match RK3399.
> > 
> 
> The dt bindings say this is a required clock, I think you'll need to update 
> them
> to reflect that this is optional for certain SoCs
> 

As stated in the other patch, I didn't read the binding close enough. Sorry
about that.

Reviewed-by: Sean Paul 

Sean

> Sean
> 
> > Signed-off-by: Chris Zhong 
> > ---
> > 
> > Changes in v3:
> > - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
> > 
> > Changes in v2: None
> > 
> >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 14 --
> >  1 file changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index f84f9ae..68f48b0 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -251,6 +251,8 @@
> >  #define THS_PRE_PROGRAM_EN BIT(7)
> >  #define THS_ZERO_PROGRAM_ENBIT(6)
> >  
> > +#define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
> > +
> >  enum {
> > BANDGAP_97_07,
> > BANDGAP_98_05,
> > @@ -279,6 +281,7 @@ struct dw_mipi_dsi_plat_data {
> > u32 grf_switch_reg;
> > u32 grf_dsi0_mode;
> > u32 grf_dsi0_mode_reg;
> > +   unsigned int flags;
> > unsigned int max_data_lanes;
> >  };
> >  
> > @@ -1136,6 +1139,7 @@ static struct dw_mipi_dsi_plat_data 
> > rk3399_mipi_dsi_drv_data = {
> > .grf_switch_reg = RK3399_GRF_SOC_CON19,
> > .grf_dsi0_mode = RK3399_GRF_DSI_MODE,
> > .grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
> > +   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
> > .max_data_lanes = 4,
> >  };
> >  
> > @@ -1227,15 +1231,13 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> > struct device *master,
> > clk_disable_unprepare(dsi->pclk);
> > }
> >  
> > -   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
> > -   if (IS_ERR(dsi->phy_cfg_clk)) {
> > -   ret = PTR_ERR(dsi->phy_cfg_clk);
> > -   if (ret != -ENOENT) {
> > +   if (pdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
> > +   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
> > +   if (IS_ERR(dsi->phy_cfg_clk)) {
> > +   ret = PTR_ERR(dsi->phy_cfg_clk);
> > dev_err(dev, "Unable to get phy_cfg_clk: %d\n", ret);
> > return ret;
> > }
> > -   dsi->phy_cfg_clk = NULL;
> > -   dev_dbg(dev, "have not phy_cfg_clk\n");
> > }
> >  
> > ret = clk_prepare_enable(dsi->pllref_clk);
> > -- 
> > 2.6.3
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

[Sean Paul]

On Tue, Mar 21, 2017 at 04:17:00PM -0400, Sean Paul wrote:
> On Fri, Mar 17, 2017 at 11:54:22AM +0800, Chris Zhong wrote:
> > For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
> > add the description for this clock.
> > 
> > Signed-off-by: Chris Zhong 
> > ---
> > 
> > Changes in v3: None
> > Changes in v2: None
> > 
> >  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 
> > 2 +-
> >  1 file changed, 1 insertion(+), 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 188f6f7..7e17a60 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> > +++ 
> > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> > @@ -10,7 +10,7 @@ Required properties:
> >  - 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). For RK3399, a phy config clock
> > -  (phy_cfg) is additional required. As described in [1].
> > +  (phy_cfg) and a grf clock(grf) are additional required. As described in 
> > [1].
> 
> These are only required for rk3399, you should make that clear.
> 

I completely missed "For RK3399" on my first pass, sigh. Sorry for the reading
comprehension fail.

Minor nit if you want: s/additional// && s/. As/, as/

Either way,

Reviewed-by: Sean Paul 

Sean

> Sean
> 
> >  - 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
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm: Remove fb hsub/vsub alignment requirement

[Ben Widawsky]

On 17-03-21 20:12:15, Ville Syrjälä wrote:

From: Ville Syrjälä 

Allow framebuffers dimesions to be misaligned w.r.t. the subsampling
factors. No real reason the core should have to enforce this, and
it definitely starts to cause us issues with the i915 CCS support.
So let's just lift the restriction.

Let's start to round up when computing the color plane dimesions
so that we'll not end up with too low an estimate for the memory
requirements and whatnot.

Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 


Both 1 and 2 are:
Reviewed-by: Ben Widawsky 


---
drivers/gpu/drm/drm_framebuffer.c | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 1138f90a7d5d..69e4c1487420 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -132,7 +132,7 @@ static int fb_plane_width(int width,
if (plane == 0)
return width;

-   return width / format->hsub;
+   return DIV_ROUND_UP(width, format->hsub);
}

static int fb_plane_height(int height,
@@ -141,7 +141,7 @@ static int fb_plane_height(int height,
if (plane == 0)
return height;

-   return height / format->vsub;
+   return DIV_ROUND_UP(height, format->vsub);
}

static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
@@ -158,12 +158,12 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
return -EINVAL;
}

-   if (r->width == 0 || r->width % info->hsub) {
+   if (r->width == 0) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
}

-   if (r->height == 0 || r->height % info->vsub) {
+   if (r->height == 0) {
DRM_DEBUG_KMS("bad framebuffer height %u\n", r->height);
return -EINVAL;
}
--
2.10.2


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

[Bug 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=193981

--- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to winches from comment #9)
> hello, i have the same bug. On my sapphire r9 380 itx, the fan seem to work
> at 100% from the loading of the kernel (no problem in bios and in grub
> stage).
> T
> he bug seem to occur since the 4.9 series. 

Can you bisect?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

[Sean Paul]

On Fri, Mar 17, 2017 at 11:54:24AM +0800, Chris Zhong wrote:
> For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
> not RK3399_GRF_SOC_CON19.
> 
> Signed-off-by: Chris Zhong 

Reviewed-by: Sean Paul 

> ---
> 
> Changes in v3: None
> Changes in v2: 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 5a18281..19b9208 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -34,7 +34,7 @@
>  #define RK3288_DSI0_SEL_VOP_LIT  BIT(6)
>  #define RK3288_DSI1_SEL_VOP_LIT  BIT(9)
>  
> -#define RK3399_GRF_SOC_CON19 0x6250
> +#define RK3399_GRF_SOC_CON20 0x6250
>  #define RK3399_DSI0_SEL_VOP_LIT  BIT(0)
>  #define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
>  
> @@ -1151,7 +1151,7 @@ static struct dw_mipi_dsi_plat_data 
> rk3288_mipi_dsi_drv_data = {
>  static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
>   .dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
>   .dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
> - .grf_switch_reg = RK3399_GRF_SOC_CON19,
> + .grf_switch_reg = RK3399_GRF_SOC_CON20,
>   .grf_dsi0_mode = RK3399_GRF_DSI_MODE,
>   .grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
>   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

[Sean Paul]

On Fri, Mar 17, 2017 at 11:54:22AM +0800, Chris Zhong wrote:
> For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
> add the description for this clock.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 
> +-
>  1 file changed, 1 insertion(+), 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 188f6f7..7e17a60 100644
> --- 
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> @@ -10,7 +10,7 @@ Required properties:
>  - 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). For RK3399, a phy config clock
> -  (phy_cfg) is additional required. As described in [1].
> +  (phy_cfg) and a grf clock(grf) are additional required. As described in 
> [1].

These are only required for rk3399, you should make that clear.

Sean

>  - 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

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

[Sean Paul]

On Fri, Mar 17, 2017 at 11:54:21AM +0800, Chris Zhong wrote:
> For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is
> disabled, MIPI phy can not work. Let's return a error if there is no
> phy_cfg_clk in dts property, when the pdata match RK3399.
> 

The dt bindings say this is a required clock, I think you'll need to update them
to reflect that this is optional for certain SoCs

Sean

> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v3:
> - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index f84f9ae..68f48b0 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -251,6 +251,8 @@
>  #define THS_PRE_PROGRAM_EN   BIT(7)
>  #define THS_ZERO_PROGRAM_EN  BIT(6)
>  
> +#define DW_MIPI_NEEDS_PHY_CFG_CLKBIT(0)
> +
>  enum {
>   BANDGAP_97_07,
>   BANDGAP_98_05,
> @@ -279,6 +281,7 @@ struct dw_mipi_dsi_plat_data {
>   u32 grf_switch_reg;
>   u32 grf_dsi0_mode;
>   u32 grf_dsi0_mode_reg;
> + unsigned int flags;
>   unsigned int max_data_lanes;
>  };
>  
> @@ -1136,6 +1139,7 @@ static struct dw_mipi_dsi_plat_data 
> rk3399_mipi_dsi_drv_data = {
>   .grf_switch_reg = RK3399_GRF_SOC_CON19,
>   .grf_dsi0_mode = RK3399_GRF_DSI_MODE,
>   .grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
> + .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
>   .max_data_lanes = 4,
>  };
>  
> @@ -1227,15 +1231,13 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> struct device *master,
>   clk_disable_unprepare(dsi->pclk);
>   }
>  
> - dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
> - if (IS_ERR(dsi->phy_cfg_clk)) {
> - ret = PTR_ERR(dsi->phy_cfg_clk);
> - if (ret != -ENOENT) {
> + if (pdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
> + dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
> + if (IS_ERR(dsi->phy_cfg_clk)) {
> + ret = PTR_ERR(dsi->phy_cfg_clk);
>   dev_err(dev, "Unable to get phy_cfg_clk: %d\n", ret);
>   return ret;
>   }
> - dsi->phy_cfg_clk = NULL;
> - dev_dbg(dev, "have not phy_cfg_clk\n");
>   }
>  
>   ret = clk_prepare_enable(dsi->pllref_clk);
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/41] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

[Sean Paul]

On Thu, Mar 16, 2017 at 02:40:21PM +0100, Andrzej Hajda wrote:
> On 10.03.2017 05:32, Sean Paul wrote:
> > From: zain wang 
> >
> > There is a race between AUX CH bring-up and enabling bridge which will
> > cause link training to fail. To avoid hitting it, don't change psr state
> > while enabling the bridge.
> >
> > Cc: Tomeu Vizoso 
> > Cc: Sean Paul 
> > Signed-off-by: zain wang 
> > Signed-off-by: Caesar Wang 
> > [seanpaul fixed up the commit message a bit and renamed *_supported to 
> > *_enabled]
> > Signed-off-by: Sean Paul 
> 
> Hmm, beside resetting psr_enable in analogix_dp_bridge_disable I do not
> see functional change, or am I blind?

The patch also adds a check of psr_enable in analogix_dp_commit. This will avoid
trying to enable psr when the bridge is disabled (that's why psr_enable is
reset).

Sean

> 
> Regards
> Andrzej
> 
> > ---
> >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 ---
> >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 +-
> >  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  2 +-
> >  include/drm/bridge/analogix_dp.h   |  2 +-
> >  4 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index 8a8f05fe9da3..64d94a34874d 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -98,20 +98,20 @@ static int analogix_dp_detect_hpd(struct 
> > analogix_dp_device *dp)
> > return 0;
> >  }
> >  
> > -int analogix_dp_psr_supported(struct device *dev)
> > +int analogix_dp_psr_enabled(struct device *dev)
> >  {
> > struct analogix_dp_device *dp = dev_get_drvdata(dev);
> >  
> > -   return dp->psr_support;
> > +   return dp->psr_enable;
> >  }
> > -EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
> > +EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
> >  
> >  int analogix_dp_enable_psr(struct device *dev)
> >  {
> > struct analogix_dp_device *dp = dev_get_drvdata(dev);
> > struct edp_vsc_psr psr_vsc;
> >  
> > -   if (!dp->psr_support)
> > +   if (!dp->psr_enable)
> > return 0;
> >  
> > /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
> > @@ -134,7 +134,7 @@ int analogix_dp_disable_psr(struct device *dev)
> > struct edp_vsc_psr psr_vsc;
> > int ret;
> >  
> > -   if (!dp->psr_support)
> > +   if (!dp->psr_enable)
> > return 0;
> >  
> > /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
> > @@ -878,8 +878,8 @@ static void analogix_dp_commit(struct 
> > analogix_dp_device *dp)
> > /* Enable video */
> > analogix_dp_start_video(dp);
> >  
> > -   dp->psr_support = analogix_dp_detect_sink_psr(dp);
> > -   if (dp->psr_support)
> > +   dp->psr_enable = analogix_dp_detect_sink_psr(dp);
> > +   if (dp->psr_enable)
> > analogix_dp_enable_sink_psr(dp);
> >  }
> >  
> > @@ -1120,6 +1120,7 @@ static void analogix_dp_bridge_disable(struct 
> > drm_bridge *bridge)
> > if (ret)
> > DRM_ERROR("failed to setup the panel ret = %d\n", ret);
> >  
> > +   dp->psr_enable = false;
> > dp->dpms_mode = DRM_MODE_DPMS_OFF;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > index b039b28d8fcc..e135a42cb19e 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > @@ -170,7 +170,7 @@ struct analogix_dp_device {
> > int dpms_mode;
> > int hpd_gpio;
> > boolforce_hpd;
> > -   boolpsr_support;
> > +   boolpsr_enable;
> >  
> > struct mutexpanel_lock;
> > boolpanel_is_modeset;
> > diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> > b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > index 64e7e2c0bc58..f44756029478 100644
> > --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > @@ -83,7 +83,7 @@ static void analogix_dp_psr_set(struct drm_encoder 
> > *encoder, bool enabled)
> > int vact_end;
> > int ret;
> >  
> > -   if (!analogix_dp_psr_supported(dp->dev))
> > +   if (!analogix_dp_psr_enabled(dp->dev))
> > return;
> >  
> > dev_dbg(dp->dev, "%s PSR...\n", enabled ? "enable" : "disable");
> > diff --git a/include/drm/bridge/analogix_dp.h 
> > b/include/drm/bridge/analogix_dp.h
> > index c99d6eaef1ac..4fc0165ed3f5 100644
> > --- a/include/drm/bridge/analogix_dp.h
> > +++ b/include/drm/bridge/analogix_dp.h
> > @@ -38,7 +38,7 @@ struct analogix_dp_plat_data {
> >  struct drm_connector *);
> > 

Re: [PATCH v7] drm/rockchip: Refactor the component match logic.

[Sean Paul]

On Tue, Mar 21, 2017 at 02:42:11PM +0800, Jeffy Chen wrote:
> Currently we are adding all components from the dts, if one of their
> drivers been disabled, we would not be able to bring up others.
> 
> Refactor component match logic, follow exynos drm.
> 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Andrzej Hajda 
> Acked-by: Mark Yao 
> Tested-by: Heiko Stuebner 
> 
> ---
> 
> Changes in v7:
> Add Heiko Stuebner 's Tested-by.
> 
> Changes in v6:
> Add Mark Yao 's Acked-by.
> 
> Changes in v5:
> Fix compile error reported by Heiko Stuebner .
> 
> Changes in v4:
> Use platform_driver helpers to register/unregister drivers.
> Fix null pointer error reported by Heiko Stuebner .
> 
> Changes in v3:
> Address Andrzej Hajda 's comments.
> 
> Changes in v2:
> Address Sean Paul 's comments.
> 
>  drivers/gpu/drm/rockchip/Kconfig|  10 +-
>  drivers/gpu/drm/rockchip/Makefile   |  16 +--
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   9 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |   8 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   8 +-
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  10 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c|  10 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 138 
> +++-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 ++
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   8 +-
>  10 files changed, 115 insertions(+), 108 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0e4eb84..50c41c0 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -13,7 +13,7 @@ config DRM_ROCKCHIP
> IP found on the SoC.
>  
>  config ROCKCHIP_ANALOGIX_DP
> - tristate "Rockchip specific extensions for Analogix DP driver"
> + bool "Rockchip specific extensions for Analogix DP driver"
>   depends on DRM_ROCKCHIP
>   select DRM_ANALOGIX_DP
>   help
> @@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
> on RK3288 based SoC, you should selet this option.
>  
>  config ROCKCHIP_CDN_DP
> -tristate "Rockchip cdn DP"
> +bool "Rockchip cdn DP"
>  depends on DRM_ROCKCHIP
>   depends on EXTCON
>   select SND_SOC_HDMI_CODEC if SND_SOC
> @@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
> option.
>  
>  config ROCKCHIP_DW_HDMI
> -tristate "Rockchip specific extensions for Synopsys DW HDMI"
> +bool "Rockchip specific extensions for Synopsys DW HDMI"
>  depends on DRM_ROCKCHIP
>  select DRM_DW_HDMI
>  help
> @@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
> option.
>  
>  config ROCKCHIP_DW_MIPI_DSI
> - tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
> + bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
>   depends on DRM_ROCKCHIP
>   select DRM_MIPI_DSI
>   help
> @@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
>option.
>  
>  config ROCKCHIP_INNO_HDMI
> - tristate "Rockchip specific extensions for Innosilicon HDMI"
> + bool "Rockchip specific extensions for Innosilicon HDMI"
>   depends on DRM_ROCKCHIP
>   help
> This selects support for Rockchip SoC specific extensions
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index c931e2a..fa8dc9d 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -3,14 +3,14 @@
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
>  rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> - rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
> + rockchip_drm_gem.o rockchip_drm_psr.o \
> + rockchip_drm_vop.o rockchip_vop_reg.o
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
> -obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
> -cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
> -obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> -obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  
> -obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
> +obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> 

Re: [PATCH v3 2/3] drm/pl111: Initial drm/kms driver for pl111

[Eric Anholt]

Russell King - ARM Linux  writes:

> On Mon, Mar 20, 2017 at 04:36:14PM -0700, Eric Anholt wrote:
>> +static struct amba_driver pl111_amba_driver = {
>> +.drv = {
>> +.name = "clcd-pl11x",
>
> either:
>
>   .name = "clcd-pl111",
>
> or:
>
>   .name = "drm-clcd-pl111",
>
> otherwise the driver names will clash in sysfs - driver names must be
> unique.
>
>> +},
>> +.probe = pl111_amba_probe,
>> +.remove = pl111_amba_remove,
>> +.id_table = pl111_id_table,
>> +};
>> +#endif /* CONFIG_ARM_AMBA */
>> +
>> +module_amba_driver(pl111_amba_driver);
>> +
>> +MODULE_DESCRIPTION(DRIVER_DESC);
>> +MODULE_AUTHOR("ARM Ltd.");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:pl111_drm");
>
> Does the platform alias make sense for an OF-only driver?

Not sure, this is left over from the original submission.

If I renamed to drm-clcd-pl111 and dropped the alias, would that get
your ack?


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

Re: [PATCH] drm: zte: remove leftover 'inf' from struct zx_hdmi

[Sean Paul]

On Tue, Mar 21, 2017 at 04:59:55PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> There is a leftover 'inf' field in struct zx_hdmi from commit
> '831a8d5e0bef ("drm: zte: move struct vou_inf into zx_vou driver")'.
> Remove it.
> 
> Signed-off-by: Shawn Guo 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/zte/zx_hdmi.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
> index c47b9cbfe270..0df7366e594b 100644
> --- a/drivers/gpu/drm/zte/zx_hdmi.c
> +++ b/drivers/gpu/drm/zte/zx_hdmi.c
> @@ -50,7 +50,6 @@ struct zx_hdmi {
>   struct clk *xclk;
>   bool sink_is_hdmi;
>   bool sink_has_audio;
> - const struct vou_inf *inf;
>   struct platform_device *audio_pdev;
>  };
>  
> -- 
> 1.9.1

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: Document feature merge deadlines

[Sean Paul]

On Tue, Mar 21, 2017 at 04:52:28PM +0100, Daniel Vetter wrote:
> The discussion pretty much concluded without objections, let's
> document what we agreed on.
> 
> Cc'ing linux-doc for the new tag in Documentation/process/index.rst.
> 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Dave Airlie 
> Cc: Sean Paul 
> Cc: Jani Nikula 
> Cc: Alex Deucher 
> Cc: Lukas Wunner 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/introduction.rst | 25 +
>  Documentation/process/index.rst|  1 +
>  2 files changed, 26 insertions(+)
> 
> diff --git a/Documentation/gpu/introduction.rst 
> b/Documentation/gpu/introduction.rst
> index 1f8bd5ef5f9d..05a82bdfbca4 100644
> --- a/Documentation/gpu/introduction.rst
> +++ b/Documentation/gpu/introduction.rst
> @@ -60,3 +60,28 @@ checkpatch or sparse. We welcome such contributions.
>  
>  Anyone looking to kick it up a notch can find a list of janitorial tasks on
>  the :ref:`TODO list `.
> +
> +Contribution Process
> +
> +
> +Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the
> +main process guidelines and documentation ` for how things 
> work.
> +Here we just document some of the specialities of the GPU subsystem.
> +
> +Feature Merge Deadlines
> +---
> +
> +All feature work must be in the linux-next tree by the -rc6 release of the
> +current release cycle, otherwise they must be postponed and can't reach the 
> next
> +merge window. All patches must have landed in the drm-next tree by latest 
> -rc7,
> +but if your branch is not in linux-next then this must have happened by -rc6
> +already.
> +
> +After that point only bugfixes (like after the upstream merge window has 
> closed
> +with the -rc1 release) are allowed. No new platform enabling or new drivers 
> are
> +allowed.
> +
> +This means that there's a blackout-period of about one month where feature 
> work
> +can't be merged. The recommended way to deal with that is having a -next tree
> +that's always open, but making sure to not feed it into linux-next during the
> +blackout period. As an example, drm-misc works like that.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index 10aa6920709a..82fc399fcd33 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -3,6 +3,7 @@
>   \renewcommand\thesection*
>   \renewcommand\thesubsection*
>  
> +.. _process_index:
>  
>  Working with the kernel development community
>  =
> -- 
> 2.11.0

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=193981

winches (dry...@gmx.fr) changed:

   What|Removed |Added

 CC||dry...@gmx.fr

--- Comment #9 from winches (dry...@gmx.fr) ---
hello, i have the same bug. On my sapphire r9 380 itx, the fan seem to work at
100% from the loading of the kernel (no problem in bios and in grub stage).
T
he bug seem to occur since the 4.9 series. 
T
he archlinux usb key i use to downgrade my kernel have a 4.9.11 and i have to
remove my r9 380 in order to boot or my system hang.

The bug occur in the last kernel from the archlinux (4.10.4) too.

Maybe it's specific to this model. I have a sapphire r7 370 in this computer
with no fan problem and last week a sapphire 7870 ghz edition with no problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

[Sean Paul]

On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote:
> Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> panel.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v2:
> - add some error check
> - always use Low power mode to send commend
> - add comments for all the sleep
> - use DRM_DEV_ERROR instead of dev_err
> 

Minor suggestion below. Once that's cleared up, you can add:
Reviewed-by: Sean Paul 

Also, please add Thierry directly to your patches so he sees them.


>  drivers/gpu/drm/panel/Kconfig |  11 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 
> ++
>  3 files changed, 356 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
> 


> +static int innolux_panel_prepare(struct drm_panel *panel)
> +{
> + struct innolux_panel *innolux = to_innolux_panel(panel);
> + int err, ret;
> +
> + if (innolux->prepared)
> + return 0;
> +
> + gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> +
> + err = regulator_enable(innolux->supply);
> + if (err < 0)
> + return err;
> +
> + /* T2: 15ms - 1000ms */
> + usleep_range(15000, 16000);
> +
> + gpiod_set_value_cansleep(innolux->enable_gpio, 1);
> +
> + /* T4: 15ms - 1000ms */
> + usleep_range(15000, 16000);
> +
> + err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
> + if (err < 0) {
> + DRM_DEV_ERROR(panel->dev, "failed to exit sleep mode: %d\n",
> +   err);
> + goto poweroff;
> + }
> +
> + /* T6: 120ms - 1000ms*/
> + msleep(120);
> +
> + err = mipi_dsi_dcs_set_display_on(innolux->link);
> + if (err < 0) {
> + DRM_DEV_ERROR(panel->dev, "failed to set display on: %d\n",
> +   err);
> + goto poweroff;
> + }
> +
> + /* T7: 5ms */
> + usleep_range(5000, 6000);
> +
> + innolux->prepared = true;
> +
> + return 0;
> +
> +poweroff:
> + ret = regulator_disable(innolux->supply);
> + if (ret)
> + return ret;

I don't think we should be returning this error code. If we're here, it's
because something else triggered err, and we should return that. Change this to:

if (regulator_disable(innolux->supply))
DRM_DEV_ERROR(panel->dev, "failed to disable regulator after error\n");



Sean

> +
> + gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> + return err;
> +}



> -- 
> 2.6.3
> 
> ___
> 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: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov  wrote:
> On 21 March 2017 at 18:06, Matt Turner  wrote:
>> (1) Non-recursive automake is necessary for parallel build performance
> Fully agree
>
>> (2) Non-recursive automake is intractably unmaintainable for
>> sufficiently large projects
> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?

Not by itself.

src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.

>> (3) Mesa is a sufficiently large project
>>
> Again - fully agree.
>
>> Therefore using automake will be either bad for parallel build
>> performance, unmaintainable, or both.
>>
>> Meson aims to be a build system actually capable of replacing
>> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
>> cleaner domain specific language for writing the build rules, while
>> generating non-recursive ninja build files. It does not use libtool.
>> It supports Windows. It supports cross compilation.
>>
> Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
> alike) platforms,

Its website says "Linux, OSX, Windows, Gcc, Clang, Visual Studio and
others". I see Meson in FreeBSD's ports. It's written in python, so I
expect it will support any of the platforms we care about.

> How about Android - Android.mk or Blueprint.

We have gone over this.

> Does it have "dist", "check", "distcheck" or less commonly used

Our thinking is that by switching to a build system that doesn't
require large amounts of generated code (configure, Makefile.in, etc),
we will stop shipping the code generated by the build system in the
tarballs (which would just be created by git archive). None of that is
set in stone.

> "ctags" "cscope"  targets ?

I don't know.

>> And it has momentum: libepoxy already has a Meson build system. Others
>> in the X.Org community are experimenting with it for libinput, Wayland
>> and Weston, and the xserver.
>>
>> All of that makes Meson very compelling.
> That's the thing - I'm never said that it's _not_ a very compelling project.
> I'm saying that it's not there yet - mostly due to the list above.

Perfect. Since no one claimed it's "there yet" there is nothing to
disagree about.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 18:06, Matt Turner  wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov  
> wrote:
>> On 21 March 2017 at 15:57, Matt Turner  wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
>>> wrote:
 On 20 March 2017 at 18:30, Matt Turner  wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> wrote:
>> Seems like we ended up all over the place, so let me try afresh.
>>
>> Above all:
>>  - Saying "I don't care" about your users is arrogant - let us _not_
>> do that, please ?
>
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC,
 IIRC Brian was using old MinGW GCC, which was one of the blockers - it
 wasn't OpenBSD to blame here ;-)

> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
>
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.
>
 Overall this hunk seems misplaced. I go agree that we should not cater
 for all their needs. At the same time, intentionally, breaking things
 while we all can coexist is very strange.

>> Even Linux distribution maintainers have responded that "upstream does
>> not care us", which is indicative that we should be more careful what
>> we say.
>
> Citation needed.
>
 https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
 couple of instances where I've been contacted in private.

>> For the rest - we're dealing with two orthogonal issues here:
>>
>> * Multiple build systems
>> I believe we'll all agree that I might be the person who's been in all
>> the build systems the most.
>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>
> No one is advocating dropping all of the existing build systems yet.
>
> This patch is an RFC for a smaller project to start the discussion about 
> Mesa.
>
>>  - [currently] there is no viable solution for Android
>
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
>
 I would suggest checking with Android people as well, as Meson.
 There's some plans on moving to yet another build system - Blueprint.

>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> boat.
>
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.
>
> Mesa is not subject to ridiculous requirements (like in the case of
> OpenBSD) in FreeBSD and NetBSD.
 Again - not a requirement, but coexistence.

> Mesa depends on gmake in FreeBSD's
> ports, for instance.
>
 That amongst others is a bug in their packaging.
>>>
>>> That is not even remotely the point.
>>>
>>> My point is that they are not subjecting themselves (and us by
>>> extension, since you want to let them) to such ridiculous
>>> requirements.
>>>
>> I will kindly ask you to keep these adjectives outside of what aims to
>> be (?) technical discussion.
>
> Huh?
>
> Didn't you call us arrogant in this very thread? Didn't you suggest
> we're immature?
>
Should I was unclear previously - I'm not trying to belittle, insult
or otherwise offend your/anyone's contribution or input.

I'm hoping to have a technical discussion, which does not have phrases
such as "slow as mud" "i don't care", "X is ridiculous" and friends.

>> And on your question - 50-100 lines worth of compatibility changes
>> across a 6.5kloc of build system is not that unreasonable, right ?
>
> You're still not understanding my point.
>
> So I don't think any of this is true.
>
 I'd suggest giving it a try then - grab a non-GNU make, a release
 tarball and let me know if you spot any issues.

>> These projects have been getting closer to upstream and "forcing" the
>> extra obstacle is effectively giving them the middle finger.
>
> No. Requiring us to compile with a 10 year old GCC is giving a middle 
> finger.
>
 Can we stop with the GCC thing ? Can we point to a place where we want
 to use feature A introduced with GCC B and we don't ?
>>>
>>> Are you freaking serious?!
>>>
>>> This happens *all* the time. It happened like two days ago with commit
>>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>>> happened at least once in the previous month, and every month before
>>> that.
>>>
>> Considering none of the ANV 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> I've just a few points, since I'm not too enthused by the prospect of having 
>> to
>> deal with yet another build system with yet another slightly different 
>> syntax.
>> But ultimately this is only a "my 2 cents" e-mail, since others are way 
>> deeper
>> involved with Mesa and their opinion is what matters in the end. Anyway, here
>> goes nothing.
>>
>> This might be a dumb question but isn't Meson (through wrap files) one of the
>> build systems that download crap from all over the internet silently? Ie. 
>> making
>> a packager's/distribution's life hell? There is
>> 
>> but that seems to imply a silent fallback to downloading stuff. I would 
>> rather
>> have a configure step that fails if a dependency is not met instead of 
>> building
>> something that can't be distributed. Or is there a magic 
>> "--distribution-build"
>> flag? If there isn't I would rather see a switch to CMake (as others have
>> pointed out in this thread: many projects in the vicinity of Mesa already use
>> CMake), but I get that there's a lot of hate for CMake (even though the Meson
>> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
>> would be unlikely.
> 
> I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
> aimed at windows and osx, where bundling is the norm, and not Linux and the 
> BSDs
> where it's not. What I would expect if the windows guys wanted to use wrap is
> that we would have something like this:
> 
> if host_machine.system() != 'windows'
> dep_zlib = dependency('zlib', version : '>1.0.0')
> else
> subproj_zlib = subproject('zlib')
> dep_zlib = subproj_zlib.get_variable('zlib_dep')
> endif
> 
> Which would make the dependency a hard requirement for non-windows system 
> (i.e.
> the configure fails if zlib isn't found *except* on windows), and windows 
> could
> fall back to wraps.
> 
> I have no plans to implement wrap for mesa in the port I would do, and would 
> NAK
> any patches that used wrap on Linux or BSD. The windows devs can make their 
> own
> choice on how to handle dependencies (I have no idea what their development
> environment looks like and don't want to make that choice for them). I agree
> with you it's not the way that Linux or BSD works, we have competent package
> management solutions without the need to automatically download sources.

I hope the rest of the Mesa project would follow such a rule. Because if there's
something I absolutely hate about all those "new" build systems, then it's their
tendency to just download stuff and build/include that. This seems to have risen
with Node and now spread into Rust and other parts of the FLOSS eco-system.

> As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
> and cmake are the difference between python and perl, there may be some
> superficial similarities, but they are *not* the same. One of the things I'll
> reiterate that impressed me the most about meson is that it's syntax is 
> simple,
> not Turring-complete, and opinionated.
> 
> In fact, piglit is the best reason not not use cmake I can come up with. There
> is an (admittedly clever) hack to allow building tests for each of the API's
> supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
> each API, which means you can't put things in the tests directory that can 
> only
> be run once. Every time I try to make changes to the Cmake I spend about an 
> hour
> trying to figure out why some code I've implemented doesn't work, only to
> remember that. Build systems aren't programming languages, they shouldn't be
> interesting, they should be declarative; cmake is a full scripting language 
> with
> enough warts to make bash look cuddly.

Hm, I have written a lot of CMakeFiles.txt and so far I've always been rather
happy with them. Not sure what Piglit is doing though.

>> Dylan Baker wrote on 16.03.2017 22:25:
>>> Why bother, and why would we want this?
>>>
>>> First it's written in python, which means the potential developer base
>>> is massive. And it provides a recursive view for humans, but a
>>> non-recursive view for the system. This is the best of both worlds,
>>> humans can organize the build system in a way that makes sense, and the
>>> machine gets a non-recursive build system. It also uses ninja rather
>>> than make, and ninja is faster than make inherently.
>>
>> Well, CMake (and probably others), see
>> , can use/generate 
>> for
>> ninja too.
> 
> Sure, I think we've gone over this in the rather long thread, ninja is really
> just a "nice to have" since it's faster than make. The real advantages are:
> 1) one build system for linux and windows (reducing from 3 to 2 build systems)

[PATCH v4 5/5] drm/i915: Add render decompression support

[ville . syrjala]

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.

Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.

Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.

Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.

This patch may contain work from at least the following people:
* Vandana Kannan 
* Daniel Vetter 
* Ben Widawsky 

v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
Put the AUX register defines to the correct place
Fix up the slightly bogus rotation check
v4: Use I915_WRITE_FW() due to plane update locking changes
s/return -EINVAL/goto err/ in intel_framebuffer_init()
Eliminate a bunch hardcoded numbers in CCS code

Cc: Paulo Zanoni 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Ben Widawsky  (v1)
---
 drivers/gpu/drm/i915/i915_reg.h  |  23 
 drivers/gpu/drm/i915/intel_display.c | 241 ---
 drivers/gpu/drm/i915/intel_pm.c  |  29 -
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 279 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04c8f69fcc62..7582d630f4a1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5903,6 +5903,10 @@ enum {
 #define _PLANE_KEYMSK_2_A  0x70298
 #define _PLANE_KEYMAX_1_A  0x701a0
 #define _PLANE_KEYMAX_2_A  0x702a0
+#define _PLANE_AUX_DIST_1_A0x701c0
+#define _PLANE_AUX_DIST_2_A0x702c0
+#define _PLANE_AUX_OFFSET_1_A  0x701c4
+#define _PLANE_AUX_OFFSET_2_A  0x702c4
 #define _PLANE_COLOR_CTL_1_A   0x701CC /* GLK+ */
 #define _PLANE_COLOR_CTL_2_A   0x702CC /* GLK+ */
 #define _PLANE_COLOR_CTL_3_A   0x703CC /* GLK+ */
@@ -6009,6 +6013,24 @@ enum {
 #define PLANE_NV12_BUF_CFG(pipe, plane)\
_MMIO_PLANE(plane, _PLANE_NV12_BUF_CFG_1(pipe), 
_PLANE_NV12_BUF_CFG_2(pipe))
 
+#define _PLANE_AUX_DIST_1_B0x711c0
+#define _PLANE_AUX_DIST_2_B0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, _PLANE_AUX_DIST_1_A, _PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, _PLANE_AUX_DIST_2_A, _PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define _PLANE_AUX_OFFSET_1_B  0x711c4
+#define _PLANE_AUX_OFFSET_2_B  0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, _PLANE_AUX_OFFSET_1_A, _PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, _PLANE_AUX_OFFSET_2_A, _PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 #define _PLANE_COLOR_CTL_1_B   0x711CC
 #define _PLANE_COLOR_CTL_2_B   0x712CC
 #define _PLANE_COLOR_CTL_3_B   0x713CC
@@ -6492,6 +6514,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
 
 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
 #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 033d8d62cccb..33a9b9d79ca3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2004,11 +2004,19 @@ intel_tile_width_bytes(const struct 

[PATCH 2/5] drm: Remove fb hsub/vsub alignment requirement

[ville . syrjala]

From: Ville Syrjälä 

Allow framebuffers dimesions to be misaligned w.r.t. the subsampling
factors. No real reason the core should have to enforce this, and
it definitely starts to cause us issues with the i915 CCS support.
So let's just lift the restriction.

Let's start to round up when computing the color plane dimesions
so that we'll not end up with too low an estimate for the memory
requirements and whatnot.

Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 1138f90a7d5d..69e4c1487420 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -132,7 +132,7 @@ static int fb_plane_width(int width,
if (plane == 0)
return width;
 
-   return width / format->hsub;
+   return DIV_ROUND_UP(width, format->hsub);
 }
 
 static int fb_plane_height(int height,
@@ -141,7 +141,7 @@ static int fb_plane_height(int height,
if (plane == 0)
return height;
 
-   return height / format->vsub;
+   return DIV_ROUND_UP(height, format->vsub);
 }
 
 static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
@@ -158,12 +158,12 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
return -EINVAL;
}
 
-   if (r->width == 0 || r->width % info->hsub) {
+   if (r->width == 0) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
}
 
-   if (r->height == 0 || r->height % info->vsub) {
+   if (r->height == 0) {
DRM_DEBUG_KMS("bad framebuffer height %u\n", r->height);
return -EINVAL;
}
-- 
2.10.2

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

[PATCH v3 3/5] drm: Add mode_config .get_format_info() hook

[ville . syrjala]

From: Ville Syrjälä 

Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.

v2: Fix drm_get_format_info() kernel doc (Laurent)
Don't pass 'dev' to the new hook (Laurent)
v3: s/compresssion/compression/ (Ben)

Cc: Laurent Pinchart 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_fb_cma_helper.c  |  2 +-
 drivers/gpu/drm/drm_fourcc.c | 25 +
 drivers/gpu/drm/drm_framebuffer.c|  9 +++--
 drivers/gpu/drm/drm_modeset_helper.c |  2 +-
 include/drm/drm_fourcc.h |  6 ++
 include/drm/drm_mode_config.h| 14 ++
 6 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 74cd393a6407..50abd1faf38f 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -177,7 +177,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct 
drm_device *dev,
int ret;
int i;
 
-   info = drm_format_info(mode_cmd->pixel_format);
+   info = drm_get_format_info(dev, mode_cmd);
if (!info)
return ERR_PTR(-EINVAL);
 
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 92bf3306d4b3..9c0152df45ad 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -207,6 +207,31 @@ const struct drm_format_info *drm_format_info(u32 format)
 EXPORT_SYMBOL(drm_format_info);
 
 /**
+ * drm_get_format_info - query information for a given framebuffer 
configuration
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ *
+ * Returns:
+ * The instance of struct drm_format_info that describes the pixel format, or
+ * NULL if the format is unsupported.
+ */
+const struct drm_format_info *
+drm_get_format_info(struct drm_device *dev,
+   const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   const struct drm_format_info *info = NULL;
+
+   if (dev->mode_config.funcs->get_format_info)
+   info = dev->mode_config.funcs->get_format_info(mode_cmd);
+
+   if (!info)
+   info = drm_format_info(mode_cmd->pixel_format);
+
+   return info;
+}
+EXPORT_SYMBOL(drm_get_format_info);
+
+/**
  * drm_format_num_planes - get the number of planes for format
  * @format: pixel format (DRM_FORMAT_*)
  *
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 69e4c1487420..e8f9c13a0afd 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -144,11 +144,13 @@ static int fb_plane_height(int height,
return DIV_ROUND_UP(height, format->vsub);
 }
 
-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
 {
const struct drm_format_info *info;
int i;
 
+   /* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
@@ -158,6 +160,9 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2 
*r)
return -EINVAL;
}
 
+   /* now let the driver pick its own format info */
+   info = drm_get_format_info(dev, r);
+
if (r->width == 0) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
@@ -281,7 +286,7 @@ drm_internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
 
-   ret = framebuffer_check(r);
+   ret = framebuffer_check(dev, r);
if (ret)
return ERR_PTR(ret);
 
diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
b/drivers/gpu/drm/drm_modeset_helper.c
index cc44a9a4b004..2b33825f2f93 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -78,7 +78,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
int i;
 
fb->dev = dev;
-   fb->format = drm_format_info(mode_cmd->pixel_format);
+   fb->format = drm_get_format_info(dev, mode_cmd);
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
for (i = 0; i < 4; i++) {
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fcc08da850c8..6942e84b6edd 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,9 @@
 #include 
 #include 
 
+struct drm_device;
+struct drm_mode_fb_cmd2;
+
 /**
  * struct drm_format_info - information about a DRM format
  * @format: 4CC format identifier (DRM_FORMAT_*)
@@ 

[PATCH v4 4/5] drm/i915: Implement .get_format_info() hook for CCS

[ville . syrjala]

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.

By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.

Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.

v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout
v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)

Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Reviewed-by: Ben Widawsky  (v3)
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 43 
 include/uapi/drm/drm_fourcc.h| 20 +
 2 files changed, 63 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 010e5ddb198a..033d8d62cccb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2420,6 +2420,48 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t 
fb_modifier)
}
 }
 
+/*
+ * 1 byte of CCS actually corresponds to 16x8 pixels on the main
+ * surface, and the memory layout for the CCS tile us 64x64 bytes.
+ * But since we're pretending the CCS tile is 128 bytes wide we
+ * adjust hsub/vsub here accordingly to 8x16 so that the
+ * bytes<->x/y conversions come out correct.
+ */
+static const struct drm_format_info ccs_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
+   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
+   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 8, .vsub = 16, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+  int num_formats, u32 format)
+{
+   int i;
+
+   for (i = 0; i < num_formats; i++) {
+   if (formats[i].format == format)
+   return [i];
+   }
+
+   return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
+{
+   switch (cmd->modifier[0]) {
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+   default:
+   return NULL;
+   }
+}
+
 static int
 intel_fill_fb_info(struct drm_i915_private *dev_priv,
   struct drm_framebuffer *fb)
@@ -14530,6 +14572,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)
 
 static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+   .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 995c8f9c692f..f18c53d95833 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -252,6 +252,26 @@ extern "C" {
 #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
 
 /*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats.
+ * The main surface will be plane index 0 and must be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each CCS tile matches a 1024x512 pixel area of the main surface.
+ * To match certain aspects of the 3D hardware the CCS is
+ * considered to be made up of normal 128Bx32 Y tiles, Thus
+ * the CCS pitch must be specified in multiples of 128 bytes.
+ *
+ * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
+ * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
+ * But that fact is not relevant unless the memory is accessed

[PATCH 1/5] drm: Share the code to compute color plane dimesions

[ville . syrjala]

From: Ville Syrjälä 

framebuffer_check() has some hand rolled code to compute the color plane
dimensions based on the subsampled information. Let's share the code
between framebuffer_check() and drm_framebuffer_plane_{width,height}().

Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index e4909aef75d7..1138f90a7d5d 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -126,6 +126,24 @@ int drm_mode_addfb(struct drm_device *dev,
return 0;
 }
 
+static int fb_plane_width(int width,
+ const struct drm_format_info *format, int plane)
+{
+   if (plane == 0)
+   return width;
+
+   return width / format->hsub;
+}
+
+static int fb_plane_height(int height,
+  const struct drm_format_info *format, int plane)
+{
+   if (plane == 0)
+   return height;
+
+   return height / format->vsub;
+}
+
 static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
 {
const struct drm_format_info *info;
@@ -151,8 +169,8 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2 
*r)
}
 
for (i = 0; i < info->num_planes; i++) {
-   unsigned int width = r->width / (i != 0 ? info->hsub : 1);
-   unsigned int height = r->height / (i != 0 ? info->vsub : 1);
+   unsigned int width = fb_plane_width(r->width, info, i);
+   unsigned int height = fb_plane_height(r->height, info, i);
unsigned int cpp = info->cpp[i];
 
if (!r->handles[i]) {
@@ -816,10 +834,7 @@ int drm_framebuffer_plane_width(int width,
if (plane >= fb->format->num_planes)
return 0;
 
-   if (plane == 0)
-   return width;
-
-   return width / fb->format->hsub;
+   return fb_plane_width(width, fb->format, plane);
 }
 EXPORT_SYMBOL(drm_framebuffer_plane_width);
 
@@ -838,9 +853,6 @@ int drm_framebuffer_plane_height(int height,
if (plane >= fb->format->num_planes)
return 0;
 
-   if (plane == 0)
-   return height;
-
-   return height / fb->format->vsub;
+   return fb_plane_height(height, fb->format, plane);
 }
 EXPORT_SYMBOL(drm_framebuffer_plane_height);
-- 
2.10.2

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

[PATCH v3 0/5] drm/i915: SKL+ render decompression support

[ville . syrjala]

From: Ville Syrjälä 

Another iteration of the i915 CCS support. Main change is lifting the
fb dimensions hsub/vsub alignment restrictions from the core. Without that
userspace would have to align the fb size be a multiple of 8x16 pixels
which isn't something they are interested in doing.

Ville Syrjälä (5):
  drm: Share the code to compute color plane dimesions
  drm: Remove fb hsub/vsub alignment requirement
  drm: Add mode_config .get_format_info() hook
  drm/i915: Implement .get_format_info() hook for CCS
  drm/i915: Add render decompression support

 drivers/gpu/drm/drm_fb_cma_helper.c  |   2 +-
 drivers/gpu/drm/drm_fourcc.c |  25 +++
 drivers/gpu/drm/drm_framebuffer.c|  45 --
 drivers/gpu/drm/drm_modeset_helper.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |  23 +++
 drivers/gpu/drm/i915/intel_display.c | 284 ---
 drivers/gpu/drm/i915/intel_pm.c  |  29 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 include/drm/drm_fourcc.h |   6 +
 include/drm/drm_mode_config.h|  14 ++
 include/uapi/drm/drm_fourcc.h|  20 +++
 11 files changed, 420 insertions(+), 35 deletions(-)

-- 
2.10.2

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov  wrote:
> On 21 March 2017 at 15:57, Matt Turner  wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
>> wrote:
>>> On 20 March 2017 at 18:30, Matt Turner  wrote:
 On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
 wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
>  - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?

 Let's be honest, the OpenBSD is subjecting itself to some pretty
 arbitrary restrictions caused including Mesa in its core: 10+ year old
 GCC,
>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>>> wasn't OpenBSD to blame here ;-)
>>>
 non-GNU Make, and now no Meson. I don't believe either FreeBSD or
 NetBSD keep Mesa as part of the core operating system, and as such
 don't suffer from these problems.

 For better or worse, they have made their choices and they get to live
 with them. We are not beholden to them.

>>> Overall this hunk seems misplaced. I go agree that we should not cater
>>> for all their needs. At the same time, intentionally, breaking things
>>> while we all can coexist is very strange.
>>>
> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.

 Citation needed.

>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>>> couple of instances where I've been contacted in private.
>>>
> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:

 No one is advocating dropping all of the existing build systems yet.

 This patch is an RFC for a smaller project to start the discussion about 
 Mesa.

>  - [currently] there is no viable solution for Android

 Acknowledged. Dylan is going to see if this is something that can be
 solved in upstream Meson.

>>> I would suggest checking with Android people as well, as Meson.
>>> There's some plans on moving to yet another build system - Blueprint.
>>>
>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.

 Solaris is a closed source operating system whose developers do not
 contribute to the project. We do not need to base our decisions on
 them.

 Mesa is not subject to ridiculous requirements (like in the case of
 OpenBSD) in FreeBSD and NetBSD.
>>> Again - not a requirement, but coexistence.
>>>
 Mesa depends on gmake in FreeBSD's
 ports, for instance.

>>> That amongst others is a bug in their packaging.
>>
>> That is not even remotely the point.
>>
>> My point is that they are not subjecting themselves (and us by
>> extension, since you want to let them) to such ridiculous
>> requirements.
>>
> I will kindly ask you to keep these adjectives outside of what aims to
> be (?) technical discussion.

Huh?

Didn't you call us arrogant in this very thread? Didn't you suggest
we're immature?

> And on your question - 50-100 lines worth of compatibility changes
> across a 6.5kloc of build system is not that unreasonable, right ?

You're still not understanding my point.

 So I don't think any of this is true.

>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>>> tarball and let me know if you spot any issues.
>>>
> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.

 No. Requiring us to compile with a 10 year old GCC is giving a middle 
 finger.

>>> Can we stop with the GCC thing ? Can we point to a place where we want
>>> to use feature A introduced with GCC B and we don't ?
>>
>> Are you freaking serious?!
>>
>> This happens *all* the time. It happened like two days ago with commit
>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>> happened at least once in the previous month, and every month before
>> that.
>>
> Considering none of the ANV code is built outside of Linux, why you
> guys will restrict yourself is beyond me.

I think you're confused.

> Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
>
>>> The anonymous unions/structs for example require newer GCC and we use
>>> them extensively. If anything we have the workaround(s) for MSVC's
>>> lack of designated initializers.
>>
>> We actually have
>>
>> if test "x$USE_GNU99" = xyes; then
>> CFLAGS="$CFLAGS 

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

--- Comment #4 from Mike Lothian  ---
Yes setting amdgpu.runpm=0 fixes the issue - also reverting the commit allows
me to boot

-- 
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 100305] [BAT][IGT]basic tests in gem_ctx_basic, gem_ctx_exec, gem_ctx_params fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100305

Tomi Sarvela  changed:

   What|Removed |Added

 OS|All |Linux (All)
   Hardware|Other   |x86-64 (AMD64)

-- 
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 100305] [BAT][IGT]basic tests in gem_ctx_basic, gem_ctx_exec, gem_ctx_params fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100305

Bug ID: 100305
   Summary: [BAT][IGT]basic tests in gem_ctx_basic, gem_ctx_exec,
gem_ctx_params fail
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tomi.p.sarv...@intel.com

This problem is fallout from commit 301ad44cdf1b868b1ab89096721da91fa8541fdc
lib: Open debugfs files for the given DRM device

Error is always the same:
(gem_ctx_basic:6494) igt-debugfs-CRITICAL: Test assertion failure function
igt_drop_caches_set, file igt_debugfs.c:964:
(gem_ctx_basic:6494) igt-debugfs-CRITICAL: Failed assertion: fd >= 0
(gem_ctx_basic:6494) igt-debugfs-CRITICAL: Last errno: 2, No such file or
directory
Test gem_ctx_basic failed.

Problem in a nutshell:
tomeu> test has a fd for the render node, but wants to tweak the
i915_gem_drop_caches file for the legacy device

-- 
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: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hi Kai,

Quoting Kai Wasserbäch (2017-03-21 09:50:52)
> Hey Dylan,
> I've just a few points, since I'm not too enthused by the prospect of having 
> to
> deal with yet another build system with yet another slightly different syntax.
> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
> involved with Mesa and their opinion is what matters in the end. Anyway, here
> goes nothing.
> 
> This might be a dumb question but isn't Meson (through wrap files) one of the
> build systems that download crap from all over the internet silently? Ie. 
> making
> a packager's/distribution's life hell? There is
> 
> but that seems to imply a silent fallback to downloading stuff. I would rather
> have a configure step that fails if a dependency is not met instead of 
> building
> something that can't be distributed. Or is there a magic 
> "--distribution-build"
> flag? If there isn't I would rather see a switch to CMake (as others have
> pointed out in this thread: many projects in the vicinity of Mesa already use
> CMake), but I get that there's a lot of hate for CMake (even though the Meson
> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
> would be unlikely.

I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs
where it's not. What I would expect if the windows guys wanted to use wrap is
that we would have something like this:

if host_machine.system() != 'windows'
dep_zlib = dependency('zlib', version : '>1.0.0')
else
subproj_zlib = subproject('zlib')
dep_zlib = subproj_zlib.get_variable('zlib_dep')
endif

Which would make the dependency a hard requirement for non-windows system (i.e.
the configure fails if zlib isn't found *except* on windows), and windows could
fall back to wraps.

I have no plans to implement wrap for mesa in the port I would do, and would NAK
any patches that used wrap on Linux or BSD. The windows devs can make their own
choice on how to handle dependencies (I have no idea what their development
environment looks like and don't want to make that choice for them). I agree
with you it's not the way that Linux or BSD works, we have competent package
management solutions without the need to automatically download sources.

As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
and cmake are the difference between python and perl, there may be some
superficial similarities, but they are *not* the same. One of the things I'll
reiterate that impressed me the most about meson is that it's syntax is simple,
not Turring-complete, and opinionated.

In fact, piglit is the best reason not not use cmake I can come up with. There
is an (admittedly clever) hack to allow building tests for each of the API's
supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
each API, which means you can't put things in the tests directory that can only
be run once. Every time I try to make changes to the Cmake I spend about an hour
trying to figure out why some code I've implemented doesn't work, only to
remember that. Build systems aren't programming languages, they shouldn't be
interesting, they should be declarative; cmake is a full scripting language with
enough warts to make bash look cuddly.

> 
> Dylan Baker wrote on 16.03.2017 22:25:
> > Why bother, and why would we want this?
> > 
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently.
> 
> Well, CMake (and probably others), see
> , can use/generate 
> for
> ninja too.

Sure, I think we've gone over this in the rather long thread, ninja is really
just a "nice to have" since it's faster than make. The real advantages are:
1) one build system for linux and windows (reducing from 3 to 2 build systems)
2) meson much simpler than autotools, scons, or (especially) cmake
3) recursive meson files, flat ninja file.

> 
> > Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> > 
> > What's different about using meson?
> > 
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it 

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #3 from Mike Lothian  ---
This is on Tonga in a prime setup

-- 
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: [CRTC:24] vblank wait timed out

[Philipp Zabel]

Hi Martyn,

On Tue, 2017-03-21 at 09:50 +, Martyn Welch wrote:
> I have an i.MX6 platform with 2 display port interfaces, one driven by the
> HDMI interface, the other by LVDS, both via bridges. We are currently
> experiencing the following error when we boot with the monitor connected
> to the LVDS backed interface and then connect a monitor to the HDMI backed
> interface after boot:
> 
> Mar 20 18:15:23 GE00409729044C kernel: [ cut here ]
> Mar 20 18:15:23 GE00409729044C kernel: WARNING: CPU: 1 PID: 85 at 
> /home/martyn/build-helix/tmp/work-shared/csmon/kernel-source/drivers/gpu/drm/drm_atomic_helper.c:1121
>  drm_atomic_helper_wait_for_vblanks+0x264/0x274
> Mar 20 18:15:23 GE00409729044C kernel: [CRTC:24] vblank wait timed out
> Mar 20 18:15:23 GE00409729044C kernel: Modules linked in: bonding 
> snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi cp210x usbserial 
> atmel_mxt_ts
> Mar 20 18:15:23 GE00409729044C kernel: CPU: 1 PID: 85 Comm: kworker/u4:1 Not 
> tainted 4.8.0 #4
> Mar 20 18:15:23 GE00409729044C kernel: Hardware name: Freescale i.MX6 
> Quad/DualLite (Device Tree)
> Mar 20 18:15:23 GE00409729044C kernel: Workqueue: events_unbound commit_work
> Mar 20 18:15:23 GE00409729044C kernel: Backtrace:
> Mar 20 18:15:23 GE00409729044C kernel: [<8010c968>] (dump_backtrace) from 
> [<8010cbb0>] (show_stack+0x20/0x24)
> Mar 20 18:15:23 GE00409729044C kernel:  r7: r6:80d2bf98 r5:600b0013 
> r4:
> Mar 20 18:15:23 GE00409729044C kernel: [<8010cb90>] (show_stack) from 
> [<803c0e68>] (dump_stack+0x98/0xb4)
> Mar 20 18:15:23 GE00409729044C kernel: [<803c0dd0>] (dump_stack) from 
> [<80122abc>] (__warn+0xe4/0x110)
> Mar 20 18:15:23 GE00409729044C kernel:  r7:0009 r6:80a8d490 r5: 
> r4:ee173e10
> Mar 20 18:15:23 GE00409729044C kernel: [<801229d8>] (__warn) from 
> [<80122b2c>] (warn_slowpath_fmt+0x44/0x4c)
> Mar 20 18:15:23 GE00409729044C kernel:  r9:ee1e5418 r8: r7: 
> r6: r5:ecc04f00 r4:80a8d5ec
> Mar 20 18:15:23 GE00409729044C kernel: [<80122aec>] (warn_slowpath_fmt) from 
> [<80486ce0>] (drm_atomic_helper_wait_for_vblanks+0x264/0x274)
> Mar 20 18:15:23 GE00409729044C kernel:  r3:0018 r2:80a8d5ec
> Mar 20 18:15:23 GE00409729044C kernel:  r4:edaa8200
> Mar 20 18:15:23 GE00409729044C kernel: [<80486a7c>] 
> (drm_atomic_helper_wait_for_vblanks) from [<804b3990>] 
> (imx_drm_atomic_commit_tail+0x1b4/0x1e0)
> Mar 20 18:15:23 GE00409729044C kernel:  r10:0ee80680 r9:80d76580 r8: 
> r7:ee1e5000 r6:ecc04f00 r5:
> Mar 20 18:15:23 GE00409729044C kernel:  r4:0004
> Mar 20 18:15:23 GE00409729044C kernel: [<804b37dc>] 
> (imx_drm_atomic_commit_tail) from [<80487498>] (commit_tail+0x50/0x6c)
> Mar 20 18:15:23 GE00409729044C kernel:  r7:ee806800 r6:ee82b000 r5:80d3a5fc 
> r4:ecc04f00
> Mar 20 18:15:23 GE00409729044C kernel: [<80487448>] (commit_tail) from 
> [<804874d0>] (commit_work+0x1c/0x20)
> Mar 20 18:15:23 GE00409729044C kernel:  r5:eeb97280 r4:ecc04f1c
> Mar 20 18:15:23 GE00409729044C kernel: [<804874b4>] (commit_work) from 
> [<8013b638>] (process_one_work+0x154/0x510)
> Mar 20 18:15:23 GE00409729044C kernel: [<8013b4e4>] (process_one_work) from 
> [<8013ba30>] (worker_thread+0x3c/0x5cc)
> Mar 20 18:15:23 GE00409729044C kernel:  r10:eeb97280 r9:ee82b000 r8:80d02100 
> r7:ee82b018 r6:0088 r5:eeb97298
> Mar 20 18:15:23 GE00409729044C kernel:  r4:ee82b000
> Mar 20 18:15:23 GE00409729044C kernel: [<8013b9f4>] (worker_thread) from 
> [<80141670>] (kthread+0xe4/0x100)
> Mar 20 18:15:23 GE00409729044C kernel:  r10: r9: r8: 
> r7:8013b9f4 r6:eeb97280 r5:eebae640
> Mar 20 18:15:23 GE00409729044C kernel:  r4:
> Mar 20 18:15:23 GE00409729044C kernel: [<8014158c>] (kthread) from 
> [<80108278>] (ret_from_fork+0x14/0x3c)
> Mar 20 18:15:23 GE00409729044C kernel:  r7: r6: r5:8014158c 
> r4:eebae640
> Mar 20 18:15:23 GE00409729044C kernel: ---[ end trace ba005811962ba6f2 ]---
> 
> We believe this may be due to the vblank interrupt for the LVDS interface
> being affected when the vblank interface for the HDMI backed interface
> gets enabled. Any pointers regarding how to proceed narrowing down/fixing
> this would be appreciated.
> 
> We are currently running 4.8 kernel with 1.11 Weston compositor.
> 
> Martyn

Could you move to v4.9 or v4.10 and check if the four patches in
https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.9-ipu-dp-plane-fix
or
https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.10-ipu-dp-plane-fix-2
help?

regards
Philipp

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

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

--- Comment #2 from Alex Deucher  ---
does disabling runpm work around 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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 15:57, Matt Turner  wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
> wrote:
>> On 20 March 2017 at 18:30, Matt Turner  wrote:
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>>> wrote:
 Seems like we ended up all over the place, so let me try afresh.

 Above all:
  - Saying "I don't care" about your users is arrogant - let us _not_
 do that, please ?
>>>
>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>> GCC,
>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> wasn't OpenBSD to blame here ;-)
>>
>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>> NetBSD keep Mesa as part of the core operating system, and as such
>>> don't suffer from these problems.
>>>
>>> For better or worse, they have made their choices and they get to live
>>> with them. We are not beholden to them.
>>>
>> Overall this hunk seems misplaced. I go agree that we should not cater
>> for all their needs. At the same time, intentionally, breaking things
>> while we all can coexist is very strange.
>>
 Even Linux distribution maintainers have responded that "upstream does
 not care us", which is indicative that we should be more careful what
 we say.
>>>
>>> Citation needed.
>>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>> couple of instances where I've been contacted in private.
>>
 For the rest - we're dealing with two orthogonal issues here:

 * Multiple build systems
 I believe we'll all agree that I might be the person who's been in all
 the build systems the most.
 Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>
>>> No one is advocating dropping all of the existing build systems yet.
>>>
>>> This patch is an RFC for a smaller project to start the discussion about 
>>> Mesa.
>>>
  - [currently] there is no viable solution for Android
>>>
>>> Acknowledged. Dylan is going to see if this is something that can be
>>> solved in upstream Meson.
>>>
>> I would suggest checking with Android people as well, as Meson.
>> There's some plans on moving to yet another build system - Blueprint.
>>
  - dropping the Autotools will lead to OpenBSD and NetBSD having to
 write one from scratch, IIRC Solaris/FreeBSD and others are in similar
 boat.
>>>
>>> Solaris is a closed source operating system whose developers do not
>>> contribute to the project. We do not need to base our decisions on
>>> them.
>>>
>>> Mesa is not subject to ridiculous requirements (like in the case of
>>> OpenBSD) in FreeBSD and NetBSD.
>> Again - not a requirement, but coexistence.
>>
>>> Mesa depends on gmake in FreeBSD's
>>> ports, for instance.
>>>
>> That amongst others is a bug in their packaging.
>
> That is not even remotely the point.
>
> My point is that they are not subjecting themselves (and us by
> extension, since you want to let them) to such ridiculous
> requirements.
>
I will kindly ask you to keep these adjectives outside of what aims to
be (?) technical discussion.

And on your question - 50-100 lines worth of compatibility changes
across a 6.5kloc of build system is not that unreasonable, right ?

>>> So I don't think any of this is true.
>>>
>> I'd suggest giving it a try then - grab a non-GNU make, a release
>> tarball and let me know if you spot any issues.
>>
 These projects have been getting closer to upstream and "forcing" the
 extra obstacle is effectively giving them the middle finger.
>>>
>>> No. Requiring us to compile with a 10 year old GCC is giving a middle 
>>> finger.
>>>
>> Can we stop with the GCC thing ? Can we point to a place where we want
>> to use feature A introduced with GCC B and we don't ?
>
> Are you freaking serious?!
>
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.
>
Considering none of the ANV code is built outside of Linux, why you
guys will restrict yourself is beyond me.
Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.

>> The anonymous unions/structs for example require newer GCC and we use
>> them extensively. If anything we have the workaround(s) for MSVC's
>> lack of designated initializers.
>
> We actually have
>
> if test "x$USE_GNU99" = xyes; then
> CFLAGS="$CFLAGS -std=gnu99"
> else
> CFLAGS="$CFLAGS -std=c99"
> fi
>
> in configure.ac to work around gcc-4.4 incompatibilities.
>
5-10 lines of configure code is not that much of a burden, right ?

>> Not to mention that some/many of the restrictions are imposed by very
>> older enterprise linuxes.
>
> which eventually go out of support and those requirements disappear.
> 

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

--- Comment #1 from Alex Deucher  ---
What chip is this?

-- 
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 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

Bug ID: 100304
   Summary: [bisected] Kernel oops on startup
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@fireburn.co.uk

Created attachment 130353
  --> https://bugs.freedesktop.org/attachment.cgi?id=130353=edit
Screen shot

Bisected back to:

2d38d25554b739b50eec254205f769580751fb02 is the first bad commit
commit 2d38d25554b739b50eec254205f769580751fb02
Author: David Panariti 
Date:   Mon Mar 13 13:33:18 2017 -0400

drm/amdgpu: Switch baremetal to use KIQ for compute ring management.

KIQ is the Kernel Interface Queue for managing the MEC.  Rather than
setting
up rings via direct MMIO of ring registers, the rings are configured via
special packets sent to the KIQ.  The allows the MEC to better manage
shared
resources and certain power events.

Signed-off-by: David Panariti 
Reviewed-by: Alex Deucher 
Acked-by: Tom St Denis 
Signed-off-by: Alex Deucher 

[Bug 100270] power usage increase by approx 4W between kernel 4.7.8 and 4.8.5

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100270

--- Comment #6 from Alex Deucher  ---
(In reply to brett.hassall from comment #5)
> (In reply to Emil Velikov from comment #2)
> > If your bisection has gone right, you're looking at either
> > c39b487f195b93235ee76384427467786f7bf29f (if you're running amdgpu) or
> > b817634276f7f68c9d1d6d4a27117ff3c2f16956 (if you're on radeon).
> > 
> > lspci should tell you which one, and you should be able to revert either one
> > on top of 4.8.5. Once you confirm the commit causing the issue, please
> > change the component accordingly and CC the author - Alex Deucher.
> 
> Following the "git checkout tags/v4.8-rc3 -b bug" I reverted
> b817634276f7f68c9d1d6d4a27117ff3c2f16956. Power usage dropped by approx 4.5W
> (measured after login once system had settled, wifi not connected).

So apparently your system claims to support pcie pm (d3cold), but either
doesn't or it's disabled for some reason.

-- 
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: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kai Wasserbäch]

Hey Dylan,
I've just a few points, since I'm not too enthused by the prospect of having to
deal with yet another build system with yet another slightly different syntax.
But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
involved with Mesa and their opinion is what matters in the end. Anyway, here
goes nothing.

This might be a dumb question but isn't Meson (through wrap files) one of the
build systems that download crap from all over the internet silently? Ie. making
a packager's/distribution's life hell? There is

but that seems to imply a silent fallback to downloading stuff. I would rather
have a configure step that fails if a dependency is not met instead of building
something that can't be distributed. Or is there a magic "--distribution-build"
flag? If there isn't I would rather see a switch to CMake (as others have
pointed out in this thread: many projects in the vicinity of Mesa already use
CMake), but I get that there's a lot of hate for CMake (even though the Meson
syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
would be unlikely.

Dylan Baker wrote on 16.03.2017 22:25:
> Why bother, and why would we want this?
> 
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently.

Well, CMake (and probably others), see
, can use/generate for
ninja too.

> Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
> 
> What's different about using meson?
> 
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?

Nothing against git archive, but you then would need to maintain .gitattributes
in addition to the build system input files, correct? Right now the distribution
rules are just in the Makefile.in files, making them more visible and less
easily forgotten.

> [...]

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

[Daniel Vetter]

The trouble here is that it does multiple atomic commits under one
drm_modeset_lock_all, which breaks the behind-the-scenes acquire
context magic that function pulls off. It's much better to have one
overall atomic commit. That we still have multiple atomic commits
prevents us from adding some pretty useful debug checks to the atomic
machinery.

Hence it is really a bad idea to call the legacy
drm_crtc_force_disable_all() function. There's 2 atomic drivers using
this still, nouveau and tinydrm. To fix this, introduce a new
drm_atomic_helper_shutdown() by extracting the code from i915.

While at it improve kernel-doc and catch future offenders by
sprinkling a WARN_ON into the legacy function. We should probably move
those into the legacy modeset helpers, too ...

v2: Make it compile on arm drivers too (Noralf).

v3: Correct kerneldoc to point at _disable_all().

Reviewed-by: Maarten Lankhorst 
Acked-by: Noralf Trønnes 
Cc: Maarten Lankhorst 
Cc: Noralf Trønnes 
Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 42 +++--
 drivers/gpu/drm/drm_crtc.c  |  7 +
 drivers/gpu/drm/i915/i915_drv.c | 20 +-
 drivers/gpu/drm/nouveau/nouveau_display.c   |  8 --
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c |  4 +--
 include/drm/drm_atomic_helper.h |  1 +
 6 files changed, 57 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index b4dcb2559e09..55c1f2b6a10b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2444,7 +2444,8 @@ int __drm_atomic_helper_set_config(struct drm_mode_set 
*set,
  * that they are connected to.
  *
  * This is used for example in suspend/resume to disable all currently active
- * functions when suspending.
+ * functions when suspending. If you just want to shut down everything at e.g.
+ * driver unload, look at drm_atomic_helper_shutdown().
  *
  * Note that if callers haven't already acquired all modeset locks this might
  * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
@@ -2453,7 +2454,8 @@ int __drm_atomic_helper_set_config(struct drm_mode_set 
*set,
  * 0 on success or a negative error code on failure.
  *
  * See also:
- * drm_atomic_helper_suspend(), drm_atomic_helper_resume()
+ * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
+ * drm_atomic_helper_shutdown().
  */
 int drm_atomic_helper_disable_all(struct drm_device *dev,
  struct drm_modeset_acquire_ctx *ctx)
@@ -2518,6 +2520,42 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
 EXPORT_SYMBOL(drm_atomic_helper_disable_all);
 
 /**
+ * drm_atomic_helper_shutdown - shutdown all CRTC
+ * @dev: DRM device
+ *
+ * This shuts down all CRTC, which is useful for driver unloading. Shutdown on
+ * suspend should instead be handled with drm_atomic_helper_suspend(), since
+ * that also takes a snapshot of the modeset state to be restored on resume.
+ *
+ * This is just a convenience wrapper around drm_atomic_helper_disable_all(),
+ * and it is the atomic version of drm_crtc_force_disable_all().
+ */
+void drm_atomic_helper_shutdown(struct drm_device *dev)
+{
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
+   drm_modeset_acquire_init(, 0);
+   while (1) {
+   ret = drm_modeset_lock_all_ctx(dev, );
+   if (!ret)
+   ret = drm_atomic_helper_disable_all(dev, );
+
+   if (ret != -EDEADLK)
+   break;
+
+   drm_modeset_backoff();
+   }
+
+   if (ret)
+   DRM_ERROR("Disabling all crtc's during unload failed with 
%i\n", ret);
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+}
+EXPORT_SYMBOL(drm_atomic_helper_shutdown);
+
+/**
  * drm_atomic_helper_suspend - subsystem-level suspend helper
  * @dev: DRM device
  *
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e2974d3c92e7..660b4c8715de 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -94,6 +94,8 @@ EXPORT_SYMBOL(drm_crtc_from_index);
  * drm_crtc_force_disable - Forcibly turn off a CRTC
  * @crtc: CRTC to turn off
  *
+ * Note: This should only be used by non-atomic legacy drivers.
+ *
  * Returns:
  * Zero on success, error code on failure.
  */
@@ -103,6 +105,8 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
.crtc = crtc,
};
 
+   WARN_ON(drm_drv_uses_atomic_modeset(crtc->dev));
+
return drm_mode_set_config_internal();
 }
 EXPORT_SYMBOL(drm_crtc_force_disable);
@@ -114,6 +118,9 @@ EXPORT_SYMBOL(drm_crtc_force_disable);
  * Drivers may want to call this on unload to ensure that all displays 

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-21 07:44:55)
> On Thu, 16 Mar 2017, Dylan Baker  wrote:
> > First it's written in python, [...]
> 
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?

Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
released in 2012. It's also worth nothing that a couple of us have been working
to get mesa's python scripts python3 compatible, so in the (hopefully) near
future python2 wouldn't be required.

> How does meson handle build file backwards compatibility between meson
> versions? I don't intend to flame, but I've found for some reason many
> python projects don't seem to take this very seriously. Either having
> conditionals in build files to support building with several meson
> versions or always requiring the latest and greatest version would be
> rather annoying.

Meson makes backwards compatible changes, and the version can be queried using
`meson.version()`, which works using meson's version comparison mechanism. I
would say this about meson, it's not a 'python project', it's 'a project written
in python', and they've taken great pains to not expose python in meson, and
reserve the right to reimplement in a different language if python becomes an
issue.


> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

Dylan


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

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

I would personally rather have scons and autotools than cmake. I've had the
misfortune of using all three, and cmake is not an improvement in my opinion.

Quoting Grazvydas Ignotas (2017-03-21 08:13:31)
> It might make sense to give more attention to cmake just because many
> mesa-related projects are already using it: llvm, piglit, vulkan
> loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
> and windows, but everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
> 
> Gražvydas
> 
> On Tue, Mar 21, 2017 at 4:44 PM, Jani Nikula
>  wrote:
> > On Thu, 16 Mar 2017, Dylan Baker  wrote:
> >> First it's written in python, [...]
> >
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> >
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 10:10 PM, Jonathan Gray  wrote:
> On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> wrote:
>> > Seems like we ended up all over the place, so let me try afresh.
>> >
>> > Above all:
>> >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>
> This isn't a situation like OpenSSH where people explicitly go out of
> their way to provide support for and test multiple systems and add
> support for horrible things like PAM.  It is more along the lines of
> considering integrating patches sent by others to make code build.

I think we (and you) have been able to deal with compiler problems
reasonably well. I don't have a particular problem taking patches for
things like that. GCC is just an example of the problem.

My core point is that OpenBSD has made choices to build Mesa with
tools and versions no one else uses. If we want to add a new build
dependency not in OpenBSD's core, I don't think it's fair for
OpenBSD's choices prevent us from moving forward.

>> > Even Linux distribution maintainers have responded that "upstream does
>> > not care us", which is indicative that we should be more careful what
>> > we say.
>>
>> Citation needed.
>>
>> > For the rest - we're dealing with two orthogonal issues here:
>> >
>> > * Multiple build systems
>> > I believe we'll all agree that I might be the person who's been in all
>> > the build systems the most.
>> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about 
>> Mesa.
>>
>> >  - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
>> >  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> > boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>
> So Mesa will remove support for libglvnd then?  I don't see a lot of
> open source non-Mesa alternatives for libGL.

Huh? libglvnd is free software.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 10:00 PM, Jonathan Gray  wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> > > wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.

How can we reasonably do that? In the context of the patch you inlined
-- what would make us believe designated initializers aren't available
in some version of GCC and we should test for it? They're just a C99
feature AFAIK.

And what would we do if we check and they're not available? Presumably
you're not advocating for #ifdef'ing and having two pieces of the same
code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  wrote:
> On 20 March 2017 at 18:30, Matt Turner  wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> wrote:
>>> Seems like we ended up all over the place, so let me try afresh.
>>>
>>> Above all:
>>>  - Saying "I don't care" about your users is arrogant - let us _not_
>>> do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC,
> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> wasn't OpenBSD to blame here ;-)
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>>
> Overall this hunk seems misplaced. I go agree that we should not cater
> for all their needs. At the same time, intentionally, breaking things
> while we all can coexist is very strange.
>
>>> Even Linux distribution maintainers have responded that "upstream does
>>> not care us", which is indicative that we should be more careful what
>>> we say.
>>
>> Citation needed.
>>
> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
> couple of instances where I've been contacted in private.
>
>>> For the rest - we're dealing with two orthogonal issues here:
>>>
>>> * Multiple build systems
>>> I believe we'll all agree that I might be the person who's been in all
>>> the build systems the most.
>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about 
>> Mesa.
>>
>>>  - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
> I would suggest checking with Android people as well, as Meson.
> There's some plans on moving to yet another build system - Blueprint.
>
>>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>> boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>>
>> Mesa is not subject to ridiculous requirements (like in the case of
>> OpenBSD) in FreeBSD and NetBSD.
> Again - not a requirement, but coexistence.
>
>> Mesa depends on gmake in FreeBSD's
>> ports, for instance.
>>
> That amongst others is a bug in their packaging.

That is not even remotely the point.

My point is that they are not subjecting themselves (and us by
extension, since you want to let them) to such ridiculous
requirements.

>> So I don't think any of this is true.
>>
> I'd suggest giving it a try then - grab a non-GNU make, a release
> tarball and let me know if you spot any issues.
>
>>> These projects have been getting closer to upstream and "forcing" the
>>> extra obstacle is effectively giving them the middle finger.
>>
>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>
> Can we stop with the GCC thing ? Can we point to a place where we want
> to use feature A introduced with GCC B and we don't ?

Are you freaking serious?!

This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.

> The anonymous unions/structs for example require newer GCC and we use
> them extensively. If anything we have the workaround(s) for MSVC's
> lack of designated initializers.

We actually have

if test "x$USE_GNU99" = xyes; then
CFLAGS="$CFLAGS -std=gnu99"
else
CFLAGS="$CFLAGS -std=c99"
fi

in configure.ac to work around gcc-4.4 incompatibilities.

> Not to mention that some/many of the restrictions are imposed by very
> older enterprise linuxes.

which eventually go out of support and those requirements disappear.
Unlike OpenBSD's insistence on using the last GPLv2 GCC.

>>> * Slow build times
>>> Before we jump into "the next cool thing", let us properly utilise
>>> what we have at the moment.
>>
>> It cannot be properly utilized. There is a patch on the list *today*
>> that is attempting to workaround the *design* of libtool. It's an
>> issue that's existed... since libtool?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>
> Yes design is ..., but I'm talking about utilising all the X cores on 
> $platform.
>
>>>  - I've asked multiple times about numbers behind those "let's make
>>> the build faster" 

[PATCH] drm/doc: Document feature merge deadlines

[Daniel Vetter]

The discussion pretty much concluded without objections, let's
document what we agreed on.

Cc'ing linux-doc for the new tag in Documentation/process/index.rst.

Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: Dave Airlie 
Cc: Sean Paul 
Cc: Jani Nikula 
Cc: Alex Deucher 
Cc: Lukas Wunner 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/introduction.rst | 25 +
 Documentation/process/index.rst|  1 +
 2 files changed, 26 insertions(+)

diff --git a/Documentation/gpu/introduction.rst 
b/Documentation/gpu/introduction.rst
index 1f8bd5ef5f9d..05a82bdfbca4 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -60,3 +60,28 @@ checkpatch or sparse. We welcome such contributions.
 
 Anyone looking to kick it up a notch can find a list of janitorial tasks on
 the :ref:`TODO list `.
+
+Contribution Process
+
+
+Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the
+main process guidelines and documentation ` for how things work.
+Here we just document some of the specialities of the GPU subsystem.
+
+Feature Merge Deadlines
+---
+
+All feature work must be in the linux-next tree by the -rc6 release of the
+current release cycle, otherwise they must be postponed and can't reach the 
next
+merge window. All patches must have landed in the drm-next tree by latest -rc7,
+but if your branch is not in linux-next then this must have happened by -rc6
+already.
+
+After that point only bugfixes (like after the upstream merge window has closed
+with the -rc1 release) are allowed. No new platform enabling or new drivers are
+allowed.
+
+This means that there's a blackout-period of about one month where feature work
+can't be merged. The recommended way to deal with that is having a -next tree
+that's always open, but making sure to not feed it into linux-next during the
+blackout period. As an example, drm-misc works like that.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 10aa6920709a..82fc399fcd33 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -3,6 +3,7 @@
\renewcommand\thesection*
\renewcommand\thesubsection*
 
+.. _process_index:
 
 Working with the kernel development community
 =
-- 
2.11.0

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

Re: [PATCH] drm: add check for plane functions

[Harry Wentland]

On 2017-03-20 05:42 AM, Shirish S wrote:

On Mon, Mar 20, 2017 at 1:51 PM, Daniel Vetter  wrote:

On Mon, Mar 20, 2017 at 09:58:01AM +0530, Shirish S wrote:

First of all, thanks for your comments/insights.

On Sat, Mar 18, 2017 at 12:59 AM, Eric Anholt  wrote:

Ville Syrjälä  writes:


On Fri, Mar 17, 2017 at 05:57:52PM +0100, Daniel Vetter wrote:

On Fri, Mar 17, 2017 at 01:08:43PM +0200, Ville Syrjälä wrote:

On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote:

On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
 wrote:

On Fri, Mar 17, 2017 at 01:25:08PM +0530, Shirish S wrote:

update_plane() and disable_plane() functions
assoiciated with setting plane are called
without any check, causing kernel panic.


Why are you registering a plane without the funcs?


Basically, enabling planes and making them fully functional is
generally a 2 -step process,
so i suggest for new drivers wanting to implement/re-design  planes,
would like to tap
the flow at enabling(listing caps) and later at ensuring it works.


I don't think there's much point in exposing something that
doesn't work. And even if you do, you could always just use
stub functions.


Yes, just wire up stub functions if you want to enable planes with
multi-step patch series.


I noticed that there is a underlying assumption only for
plane->(funcs) are implemented, whereas for
other function for crtc/connector/encoder function calls there is a
sanity check(or WARN_ON) through out the framework.

I believe this check wont cause any performance/functional impact.
Please let me know if am missing anything.
And further more help developers to focus on enabling planes via
various tests without causing reboots/system hangs.


I don't particularly like adding more unconditional runtime checks
that just to protect developers from themselves. If you really
think there's value in these, then at least add the checks into
the plane init codepath so that it's a one time cost.


All the plane->funcs are guarded before being called , be it:
 late_register()
 early_unregister()
atomic_destroy_state() etc.,
only update/disable_plane() are called without checking their
existence, am just extending  the protocol.

The same approach could be used for all the other non-optional
hooks. Otherwise the same WARN_ON()s would have to be sprinkled
all over the place, and there's always the risk of missing a few
codepaths that call a specific hook.


I think for these here there's negative value - it allows developers to
create completely broken planes. Stub functions really seem like a much
better idea.


I was thinking

drm_whatever_init()
{
  if (WARN_ON(!funcs->mandatory_thing))
  return -EINVAL;
}


I think since the motive here is to
* convey user space that it does not have permissions to
update/disable available plane due to implementation issues.
* Keeping system alive/usable after non-permitted call.
Adding  a WARN_ON() trace showing something is missing at boot/insmod
time, wont solve the purpose.

This  development phase here could be setting-up infra for adding a
plane available on hardware,populate its capabilities
and to know how user space reads it and tweak it before moving to
configuring registers.

To add to what @Eric Anholt mentioned, without this patch developer
comes to know about
the mandatory functions required in a real tough way of panic and
system freezes,
just because the core framework invokes a NULL function pointer
without checking.
(Am re-stressing here, that only update/disable planes are exceptions
rest all have required checks.)


Eric acked Ville's idea, not your patch.



rather than putting the WARN_ON()s around each call of
funcs->mandatory_thing().


There are similar checks around every
"[crtc/encoder]->funcs->[hooked_up_function specific to vendor]",
including  plane functions called in drm_plane.c & other places like:
 drivers/gpu/drm/drm_crtc_helper.c:1074: if
(plane->funcs->atomic_duplicate_state)
 drivers/gpu/drm/drm_mode_config.c:176:  if (plane->funcs->reset)
 drivers/gpu/drm/drm_plane.c:162:if
(plane->funcs->late_register)
 drivers/gpu/drm/drm_plane.c:242:if (plane->state &&
plane->funcs->atomic_destroy_state)
and so on...
For consistency sake lets have this check.


Those are different functions. They are in transitional helpers, where
we explicitly assume not all the atomic bits are ready yet.

Different use-case, different semantics.


That will fail gracefully (which I guess is what people are after here),
and gives the developer a clear message what's missing.


Having this in our init functions for funcs and helpers would have saved
me tons of time in vc4 and clcd.

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

Re: [PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

[Maarten Lankhorst]

Op 21-03-17 om 16:26 schreef Daniel Vetter:
> The trouble here is that it does multiple atomic commits under one
> drm_modeset_lock_all, which breaks the behind-the-scenes acquire
> context magic that function pulls off. It's much better to have one
> overall atomic commit. That we still have multiple atomic commits
> prevents us from adding some pretty useful debug checks to the atomic
> machinery.
>
> Hence it is really a bad idea to call the legacy
> drm_crtc_force_disable_all() function. There's 2 atomic drivers using
> this still, nouveau and tinydrm. To fix this, introduce a new
> drm_atomic_helper_shutdown() by extracting the code from i915.
>
> While at it improve kernel-doc and catch future offenders by
> sprinkling a WARN_ON into the legacy function. We should probably move
> those into the legacy modeset helpers, too ...
>
> v2: Make it compile on arm drivers too (Noralf).
>
> Acked-by: Noralf Trønnes 
> Cc: Maarten Lankhorst 
> Cc: Noralf Trønnes 
> Cc: Ben Skeggs 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 42 
> +++--
>  drivers/gpu/drm/drm_crtc.c  |  7 +
>  drivers/gpu/drm/i915/i915_drv.c | 20 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c   |  8 --
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c |  4 +--
>  include/drm/drm_atomic_helper.h |  1 +
>  6 files changed, 57 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index b4dcb2559e09..5f401519d03c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2444,7 +2444,8 @@ int __drm_atomic_helper_set_config(struct drm_mode_set 
> *set,
>   * that they are connected to.
>   *
>   * This is used for example in suspend/resume to disable all currently active
> - * functions when suspending.
> + * functions when suspending. If you just want to shut down everything at 
> e.g.
> + * driver unload, look at drm_atomic_helper_shutdown().
>   *
>   * Note that if callers haven't already acquired all modeset locks this might
>   * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
> @@ -2453,7 +2454,8 @@ int __drm_atomic_helper_set_config(struct drm_mode_set 
> *set,
>   * 0 on success or a negative error code on failure.
>   *
>   * See also:
> - * drm_atomic_helper_suspend(), drm_atomic_helper_resume()
> + * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
> + * drm_atomic_helper_shutdown().
>   */
>  int drm_atomic_helper_disable_all(struct drm_device *dev,
> struct drm_modeset_acquire_ctx *ctx)
> @@ -2518,6 +2520,42 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>  EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>  
>  /**
> + * drm_atomic_helper_shutdown - shutdown all CRTC
> + * @dev: DRM device
> + *
> + * This shuts down all CRTC, which is useful for driver unloading. Shutdown 
> on
> + * suspend should instead be handled with drm_atomic_helper_suspend(), since
> + * that also takes a snapshot of the modeset state to be restored on resume.
> + *
> + * This is just a convenience wrapper around drm_atomic_helper_disable_all(),
> + * and it is the atomic version of drm_crtc_force_disable().
> + */
> +void drm_atomic_helper_shutdown(struct drm_device *dev)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> +
> + drm_modeset_acquire_init(, 0);
> + while (1) {
> + ret = drm_modeset_lock_all_ctx(dev, );
> + if (!ret)
> + ret = drm_atomic_helper_disable_all(dev, );
> +
> + if (ret != -EDEADLK)
> + break;
> +
> + drm_modeset_backoff();
> + }
> +
> + if (ret)
> + DRM_ERROR("Disabling all crtc's during unload failed with 
> %i\n", ret);
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_shutdown);
Reviewed-by: Maarten Lankhorst 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 11/13] drm/meson: Convert existing documentation to actual kerneldoc

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_canvas.c  |  4 +++-
 drivers/gpu/drm/meson/meson_drv.c |  5 +++--
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 25 +
 drivers/gpu/drm/meson/meson_vclk.c| 22 +++---
 drivers/gpu/drm/meson/meson_venc.c| 25 -
 drivers/gpu/drm/meson/meson_viu.c |  6 +-
 drivers/gpu/drm/meson/meson_vpp.c |  8 ++--
 7 files changed, 65 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_canvas.c 
b/drivers/gpu/drm/meson/meson_canvas.c
index 4109e36..08f6073 100644
--- a/drivers/gpu/drm/meson/meson_canvas.c
+++ b/drivers/gpu/drm/meson/meson_canvas.c
@@ -24,7 +24,9 @@
 #include "meson_canvas.h"
 #include "meson_registers.h"
 
-/*
+/**
+ * DOC: Canvas
+ *
  * CANVAS is a memory zone where physical memory frames information
  * are stored for the VIU to scanout.
  */
diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index a2e9f56..75382f5 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -52,13 +52,14 @@
 #define DRIVER_NAME "meson"
 #define DRIVER_DESC "Amlogic Meson DRM driver"
 
-/*
- * Video Processing Unit
+/**
+ * DOC: Video Processing Unit
  *
  * VPU Handles the Global Video Processing, it includes management of the
  * clocks gates, blocks reset lines and power domains.
  *
  * What is missing :
+ *
  * - Full reset of entire video processing HW blocks
  * - Scaling and setup of the VPU clock
  * - Bus clock gates
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 8851dcb..7b86eb7 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -42,18 +42,25 @@
 #define DRIVER_NAME "meson-dw-hdmi"
 #define DRIVER_DESC "Amlogic Meson HDMI-TX DRM driver"
 
-/*
+/**
+ * DOC: HDMI Output
+ *
  * HDMI Output is composed of :
+ *
  * - A Synopsys DesignWare HDMI Controller IP
  * - A TOP control block controlling the Clocks and PHY
  * - A custom HDMI PHY in order convert video to TMDS signal
- *  ___
- * |HDMI TOP   |<= HPD
- * |___|
- * |  ||
- * |  Synopsys HDMI   |   HDMI PHY |=> TMDS
- * |Controller||
- * |___|<=> DDC
+ *
+ * .. code::
+ *
+ *___
+ *   |HDMI TOP   |<= HPD
+ *   |___|
+ *   |  ||
+ *   |  Synopsys HDMI   |   HDMI PHY |=> TMDS
+ *   |Controller||
+ *   |___|<=> DDC
+ *
  *
  * The HDMI TOP block only supports HPD sensing.
  * The Synopsys HDMI Controller interrupt is routed
@@ -78,6 +85,7 @@
  * audio source interfaces.
  *
  * We handle the following features :
+ *
  * - HPD Rise & Fall interrupt
  * - HDMI Controller Interrupt
  * - HDMI PHY Init for 480i to 1080p60
@@ -85,6 +93,7 @@
  * - VENC Mode setup for 480i to 1080p60
  *
  * What is missing :
+ *
  * - PHY, Clock and Mode setup for 2k && 4k modes
  * - SDDC Scrambling mode for HDMI 2.0a
  * - HDCP Setup
diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index 3731479..4767704 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -23,21 +23,29 @@
 #include "meson_drv.h"
 #include "meson_vclk.h"
 
-/*
+/**
+ * DOC: Video Clocks
+ *
  * VCLK is the "Pixel Clock" frequency generator from a dedicated PLL.
  * We handle the following encodings :
+ *
  * - CVBS 27MHz generator via the VCLK2 to the VENCI and VDAC blocks
  * - HDMI Pixel Clocks generation
+ *
  * What is missing :
+ *
  * - Genenate Pixel clocks for 2K/4K 10bit formats
  *
  * Clock generator scheme :
- *  __   __
- * |  | | |  | |--ENCI
- * | HDMI PLL |-| PLL_DIV |--- VCLK--| |--ENCL
- * |__| |_| \| MUX |--ENCP
- *   --VCLK2-| |--VDAC
- *   |_|--HDMI-TX
+ *
+ * .. code::
+ *
+ *__   __
+ *   |  | | |  | |--ENCI
+ *   | HDMI PLL |-| PLL_DIV |--- VCLK--| |--ENCL
+ *   |__| |_| \| MUX |--ENCP
+ * --VCLK2-| |--VDAC
+ * |_|--HDMI-TX
  *
  * Final clocks can take input for either VCLK or VCLK2, but
  * VCLK is the preferred path for HDMI clocking and VCLK2 is the
diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index 31dc275..9509017 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -26,26 +26,33 @@
 #include "meson_vclk.h"
 #include 

[PATCH v2 13/13] MAINTAINERS: update files for Amlogic DRM Driver

[Neil Armstrong]

This patch adds the dw-hdmi bindings and RST kerneldoc to maintained files.

Signed-off-by: Neil Armstrong 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e88154f..3df68c73 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4256,6 +4256,8 @@ W:http://linux-meson.com/
 S: Supported
 F: drivers/gpu/drm/meson/
 F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+F: Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
+F: Documentation/gpu/meson.rst
 T: git git://anongit.freedesktop.org/drm/drm-meson
 T: git git://anongit.freedesktop.org/drm/drm-misc
 
-- 
1.9.1

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

[PATCH v2 02/13] drm/meson: Add missing HDMI register

[Neil Armstrong]

Add missing VPU HDMI register.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_registers.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 6adf9c1..2847381 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -1319,6 +1319,7 @@
 #define VPU_MISC_CTRL 0x2740
 #define VPU_ISP_GCLK_CTRL0 0x2741
 #define VPU_ISP_GCLK_CTRL1 0x2742
+#define VPU_HDMI_FMT_CTRL 0x2743
 #define VPU_VDIN_ASYNC_HOLD_CTRL 0x2743
 #define VPU_VDISP_ASYNC_HOLD_CTRL 0x2744
 #define VPU_VPUARB2_ASYNC_HOLD_CTRL 0x2745
-- 
1.9.1

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

[PATCH v2 08/13] ARM64: dts: meson-gx: Add shared CMA dma memory pool

[Neil Armstrong]

The HDMI modes needs more CMA memory to be reserved at boot-time.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 5d995f7..94c6f95 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -71,6 +71,14 @@
reg = <0x0 0x1000 0x0 0x20>;
no-map;
};
+
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x0 0xbc0>;
+   alignment = <0x0 0x40>;
+   linux,cma-default;
+   };
};
 
cpus {
-- 
1.9.1

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

[PATCH v2 10/13] dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension

[Neil Armstrong]

This binding describes the Amlogic Meson specific extension to the
Synopsys Designware HDMI Controller.

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 .../bindings/display/amlogic,meson-dw-hdmi.txt | 111 +
 1 file changed, 111 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt

diff --git 
a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt 
b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
new file mode 100644
index 000..7f040ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
@@ -0,0 +1,111 @@
+Amlogic specific extensions to the Synopsys Designware HDMI Controller
+==
+
+The Amlogic Meson Synopsys Designware Integration is composed of :
+- A Synopsys DesignWare HDMI Controller IP
+- A TOP control block controlling the Clocks and PHY
+- A custom HDMI PHY in order to convert video to TMDS signal
+ ___
+|HDMI TOP   |<= HPD
+|___|
+|  ||
+|  Synopsys HDMI   |   HDMI PHY |=> TMDS
+|Controller||
+|___|<=> DDC
+
+The HDMI TOP block only supports HPD sensing.
+The Synopsys HDMI Controller interrupt is routed through the
+TOP Block interrupt.
+Communication to the TOP Block and the Synopsys HDMI Controller is done
+via a pair of dedicated addr+read/write registers.
+The HDMI PHY is configured by registers in the HHI register block.
+
+Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux
+selects either the ENCI encoder for the 576i or 480i formats or the ENCP
+encoder for all the other formats including interlaced HD formats.
+
+The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
+DVI timings for the HDMI controller.
+
+Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
+HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
+audio source interfaces.
+
+Required properties:
+- compatible: value should be different for each SoC family as :
+   - GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi"
+   - GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi"
+   - GXM (S912) : "amlogic,meson-gxm-dw-hdmi"
+   followed by the common "amlogic,meson-gx-dw-hdmi"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The HDMI interrupt number
+- clocks, clock-names : must have the phandles to the HDMI iahb and isfr 
clocks,
+  and the Amlogic Meson venci clocks as described in
+  Documentation/devicetree/bindings/clock/clock-bindings.txt,
+  the clocks are soc specific, the clock-names should be "iahb", "isfr", 
"venci"
+- resets, resets-names: must have the phandles to the HDMI apb, glue and phy
+  resets as described in :
+  Documentation/devicetree/bindings/reset/reset.txt,
+  the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
+
+Required nodes:
+
+The connections to the HDMI ports are modeled using the OF graph
+bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+The following table lists for each supported model the port number
+corresponding to each HDMI output and input.
+
+   Port 0  Port 1
+-
+ S905 (GXBB)   VENC Input  TMDS Output
+ S905X (GXL)   VENC Input  TMDS Output
+ S905D (GXL)   VENC Input  TMDS Output
+ S912 (GXM)VENC Input  TMDS Output
+
+Example:
+
+hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+};
+
+hdmi_tx: hdmi-tx@c883a000 {
+   compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
+   reg = <0x0 0xc883a000 0x0 0x1c>;
+   interrupts = ;
+   resets = < RESET_HDMITX_CAPB3>,
+< RESET_HDMI_SYSTEM_RESET>,
+< RESET_HDMI_TX>;
+   reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
+   clocks = < CLKID_HDMI_PCLK>,
+< CLKID_CLK81>,
+< CLKID_GCLK_VENCI_INT0>;
+   clock-names = "isfr", "iahb", "venci";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* VPU VENC Input */
+   hdmi_tx_venc_port: port@0 {
+   reg = <0>;
+
+   hdmi_tx_in: endpoint {
+   remote-endpoint = <_tx_out>;
+   };
+   };
+
+   /* TMDS Output */
+   hdmi_tx_tmds_port: port@1 {
+   reg = <1>;
+
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+};
-- 
1.9.1

___

[PATCH v2 05/13] drm/meson: add support for HDMI clock support

[Neil Armstrong]

This patchs adds support for the supported HDMI modes clocks frequencies.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_vclk.c  | 624 +++-
 drivers/gpu/drm/meson/meson_vclk.h  |   6 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c |   9 +-
 3 files changed, 623 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index 252cfd4..3731479 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -27,9 +27,26 @@
  * VCLK is the "Pixel Clock" frequency generator from a dedicated PLL.
  * We handle the following encodings :
  * - CVBS 27MHz generator via the VCLK2 to the VENCI and VDAC blocks
- *
- * What is missing :
  * - HDMI Pixel Clocks generation
+ * What is missing :
+ * - Genenate Pixel clocks for 2K/4K 10bit formats
+ *
+ * Clock generator scheme :
+ *  __   __
+ * |  | | |  | |--ENCI
+ * | HDMI PLL |-| PLL_DIV |--- VCLK--| |--ENCL
+ * |__| |_| \| MUX |--ENCP
+ *   --VCLK2-| |--VDAC
+ *   |_|--HDMI-TX
+ *
+ * Final clocks can take input for either VCLK or VCLK2, but
+ * VCLK is the preferred path for HDMI clocking and VCLK2 is the
+ * preferred path for CVBS VDAC clocking.
+ *
+ * VCLK and VCLK2 have fixed divided clocks paths for /1, /2, /4, /6 or /12.
+ *
+ * The PLL_DIV can achieve an additional fractional dividing like
+ * 1.5, 3.5, 3.75... to generate special 2K and 4K 10bit clocks.
  */
 
 /* HHI Registers */
@@ -50,11 +67,34 @@
 #define VCLK2_SOFT_RESET   BIT(15)
 #define VCLK2_DIV1_EN  BIT(0)
 #define HHI_VID_CLK_DIV0x164 /* 0x59 offset in data sheet */
+#define VCLK_DIV_MASK  0xff
+#define VCLK_DIV_ENBIT(16)
+#define VCLK_DIV_RESET BIT(17)
+#define CTS_ENCP_SEL_MASK  (0xf << 24)
+#define CTS_ENCP_SEL_SHIFT 24
 #define CTS_ENCI_SEL_MASK  (0xf << 28)
 #define CTS_ENCI_SEL_SHIFT 28
+#define HHI_VID_CLK_CNTL   0x17c /* 0x5f offset in data sheet */
+#define VCLK_ENBIT(19)
+#define VCLK_SEL_MASK  (0x7 << 16)
+#define VCLK_SEL_SHIFT 16
+#define VCLK_SOFT_RESETBIT(15)
+#define VCLK_DIV1_EN   BIT(0)
+#define VCLK_DIV2_EN   BIT(1)
+#define VCLK_DIV4_EN   BIT(2)
+#define VCLK_DIV6_EN   BIT(3)
+#define VCLK_DIV12_EN  BIT(4)
 #define HHI_VID_CLK_CNTL2  0x194 /* 0x65 offset in data sheet */
 #define CTS_ENCI_ENBIT(0)
+#define CTS_ENCP_ENBIT(2)
 #define CTS_VDAC_ENBIT(4)
+#define HDMI_TX_PIXEL_EN   BIT(5)
+#define HHI_HDMI_CLK_CNTL  0x1cc /* 0x73 offset in data sheet */
+#define HDMI_TX_PIXEL_SEL_MASK (0xf << 16)
+#define HDMI_TX_PIXEL_SEL_SHIFT16
+#define CTS_HDMI_SYS_SEL_MASK  (0x7 << 9)
+#define CTS_HDMI_SYS_DIV_MASK  (0x7f)
+#define CTS_HDMI_SYS_ENBIT(8)
 
 #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
 #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
@@ -69,6 +109,126 @@
 #define HDMI_PLL_RESET BIT(28)
 #define HDMI_PLL_LOCK  BIT(31)
 
+/* VID PLL Dividers */
+enum {
+   VID_PLL_DIV_1 = 0,
+   VID_PLL_DIV_2,
+   VID_PLL_DIV_2p5,
+   VID_PLL_DIV_3,
+   VID_PLL_DIV_3p5,
+   VID_PLL_DIV_3p75,
+   VID_PLL_DIV_4,
+   VID_PLL_DIV_5,
+   VID_PLL_DIV_6,
+   VID_PLL_DIV_6p25,
+   VID_PLL_DIV_7,
+   VID_PLL_DIV_7p5,
+   VID_PLL_DIV_12,
+   VID_PLL_DIV_14,
+   VID_PLL_DIV_15,
+};
+
+void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
+{
+   unsigned int shift_val = 0;
+   unsigned int shift_sel = 0;
+
+   /* Disable vid_pll output clock */
+   regmap_update_bits(priv->hhi, HHI_VID_PLL_CLK_DIV, VID_PLL_EN, 0);
+   regmap_update_bits(priv->hhi, HHI_VID_PLL_CLK_DIV, VID_PLL_PRESET, 0);
+
+   switch (div) {
+   case VID_PLL_DIV_2:
+   shift_val = 0x0aaa;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_2p5:
+   shift_val = 0x5294;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_3:
+   shift_val = 0x0db6;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_3p5:
+   shift_val = 0x36cc;
+   shift_sel = 1;
+   break;
+   case VID_PLL_DIV_3p75:
+   shift_val = 0x;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_4:
+   shift_val = 0x0ccc;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_5:
+   shift_val = 0x739c;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_6:
+   shift_val = 0x0e38;
+   

[PATCH v2 12/13] drm/meson: Add RST to bring together kerneldoc

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 Documentation/gpu/index.rst |  1 +
 Documentation/gpu/meson.rst | 61 +
 2 files changed, 62 insertions(+)
 create mode 100644 Documentation/gpu/meson.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index e998ee0..7eceb97 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -11,6 +11,7 @@ Linux GPU Driver Developer's Guide
drm-kms-helpers
drm-uapi
i915
+   meson
tinydrm
vc4
vga-switcheroo
diff --git a/Documentation/gpu/meson.rst b/Documentation/gpu/meson.rst
new file mode 100644
index 000..479f6f5
--- /dev/null
+++ b/Documentation/gpu/meson.rst
@@ -0,0 +1,61 @@
+=
+drm/meson AmLogic Meson Video Processing Unit
+=
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_drv.c
+   :doc: Video Processing Unit
+
+Video Processing Unit
+=
+
+The Amlogic Meson Display controller is composed of several components
+that are going to be documented below:
+
+.. code::
+
+  DMC|---VPU (Video Processing 
Unit)|--HHI--|
+ | vd1   ___ __ |  
 |
+  D  |---|  |||   |||   HDMI PLL   
 |
+  D  | vd2   | VIU  || Video Post |   | Video Encoders |<---|-VCLK 
 |
+  R  |---|  || Processing |   |||  
 |
+ | osd2  |  |||---| Enci 
--||-VDAC--|
+  R  |---| CSC  || Scalers|   | Encp 
--||HDMI-TX|
+  A  | osd1  |  || Blenders   |   | Encl 
--||---|
+  M  |---|__|||   |||  
 |
+  
___|__|___|
+
+Video Input Unit
+
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_viu.c
+   :doc: Video Input Unit
+
+Video Post Processing
+=
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_vpp.c
+   :doc: Video Post Processing
+
+Video Encoder
+=
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
+   :doc: Video Encoder
+
+Video Canvas Management
+===
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
+   :doc: Canvas
+
+Video Clocks
+
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_vclk.c
+   :doc: Video Clocks
+
+HDMI Video Output
+=
+
+.. kernel-doc:: drivers/gpu/drm/meson/meson_dw_hdmi.c
+   :doc: HDMI Output
-- 
1.9.1

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

[PATCH v2 07/13] drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY

[Neil Armstrong]

The Amlogic Meson GXBB/GXL/GXM SoCs embeds a Synopsys DesignWare HDMI TX
Controller with a custom Bridge + PHY around the Controller.

This driver makes uses of all the custom PHY plat data callbacks and enables
the compatible HDMI modes to be configured as a drm_encoder instance.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/Kconfig |   6 +
 drivers/gpu/drm/meson/Makefile|   1 +
 drivers/gpu/drm/meson/meson_drv.h |   3 +
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 910 ++
 drivers/gpu/drm/meson/meson_dw_hdmi.h | 146 ++
 5 files changed, 1066 insertions(+)
 create mode 100644 drivers/gpu/drm/meson/meson_dw_hdmi.c
 create mode 100644 drivers/gpu/drm/meson/meson_dw_hdmi.h

diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 99719af..3ce51d8 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -7,3 +7,9 @@ config DRM_MESON
select DRM_GEM_CMA_HELPER
select VIDEOMODE_HELPERS
select REGMAP_MMIO
+
+config DRM_MESON_DW_HDMI
+   tristate "HDMI Synopsys Controller support for Amlogic Meson Display"
+   depends on DRM_MESON
+   default y if DRM_MESON
+   select DRM_DW_HDMI
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 92cf845..c5c4cc3 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -2,3 +2,4 @@ meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o 
meson_venc_cvbs.o
 meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o
 
 obj-$(CONFIG_DRM_MESON) += meson-drm.o
+obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 6195327..5e8b392 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -47,6 +47,9 @@ struct meson_drm {
 
struct {
unsigned int current_mode;
+   bool hdmi_repeat;
+   bool venc_repeat;
+   bool hdmi_use_enci;
} venc;
 };
 
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
new file mode 100644
index 000..8851dcb
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -0,0 +1,910 @@
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong 
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "meson_drv.h"
+#include "meson_venc.h"
+#include "meson_vclk.h"
+#include "meson_dw_hdmi.h"
+#include "meson_registers.h"
+
+#define DRIVER_NAME "meson-dw-hdmi"
+#define DRIVER_DESC "Amlogic Meson HDMI-TX DRM driver"
+
+/*
+ * HDMI Output is composed of :
+ * - A Synopsys DesignWare HDMI Controller IP
+ * - A TOP control block controlling the Clocks and PHY
+ * - A custom HDMI PHY in order convert video to TMDS signal
+ *  ___
+ * |HDMI TOP   |<= HPD
+ * |___|
+ * |  ||
+ * |  Synopsys HDMI   |   HDMI PHY |=> TMDS
+ * |Controller||
+ * |___|<=> DDC
+ *
+ * The HDMI TOP block only supports HPD sensing.
+ * The Synopsys HDMI Controller interrupt is routed
+ * through the TOP Block interrupt.
+ * Communication to the TOP Block and the Synopsys
+ * HDMI Controller is done a pair of addr+read/write
+ * registers.
+ * The HDMI PHY is configured by registers in the
+ * HHI register block.
+ *
+ * Pixel data arrives in 4:4:4 format from the VENC
+ * block and the VPU HDMI mux selects either the ENCI
+ * encoder for the 576i or 480i formats or the ENCP
+ * encoder for all the other formats including
+ * interlaced HD formats.
+ * The VENC uses a DVI encoder on top of the ENCI
+ * or ENCP encoders to generate DVI timings for the
+ * HDMI controller.
+ *
+ * GXBB, GXL and GXM embeds the Synopsys DesignWare
+ * HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
+ * audio source interfaces.
+ *
+ * We handle the following features :
+ * - HPD Rise & Fall interrupt
+ * - HDMI 

[PATCH v2 01/13] drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable sync for vsync commit

[Neil Armstrong]

Clean the crtc_enable by using the proper crtc_state instead of the state
of the primary plane state data.

Also fix the dependency to commit the plane changes even if enable is called
after the flush.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 0fe49ec..c986eb0 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -82,11 +82,18 @@ static void meson_crtc_disable_vblank(struct drm_crtc *crtc)
 static void meson_crtc_enable(struct drm_crtc *crtc)
 {
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
-   struct drm_plane *plane = meson_crtc->priv->primary_plane;
+   struct drm_crtc_state *crtc_state = crtc->state;
struct meson_drm *priv = meson_crtc->priv;
 
+   DRM_DEBUG_DRIVER("\n");
+
+   if (!crtc_state) {
+   DRM_ERROR("Invalid crtc_state\n");
+   return;
+   }
+
/* Enable VPP Postblend */
-   writel(plane->state->crtc_w,
+   writel(crtc_state->mode.hdisplay,
   priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
 
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
@@ -101,6 +108,7 @@ static void meson_crtc_disable(struct drm_crtc *crtc)
struct meson_drm *priv = meson_crtc->priv;
 
priv->viu.osd1_enabled = false;
+   priv->viu.osd1_commit = false;
 
/* Disable VPP Postblend */
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
@@ -137,8 +145,7 @@ static void meson_crtc_atomic_flush(struct drm_crtc *crtc,
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
 
-   if (priv->viu.osd1_enabled)
-   priv->viu.osd1_commit = true;
+   priv->viu.osd1_commit = true;
 }
 
 static const struct drm_crtc_helper_funcs meson_crtc_helper_funcs = {
-- 
1.9.1

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

[PATCH v2 06/13] drm/meson: Add support for HDMI venc modes and settings

[Neil Armstrong]

This patch adds support for the supported HDMI Venc modes and add the VPP mux
value to switch to ENCP encoder.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc.c | 1245 +++-
 drivers/gpu/drm/meson/meson_venc.h |7 +
 drivers/gpu/drm/meson/meson_vpp.h  |2 +
 3 files changed, 1249 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index f7c87017..31dc275 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -30,12 +30,37 @@
  * VENC Handle the pixels encoding to the output formats.
  * We handle the following encodings :
  * - CVBS Encoding via the ENCI encoder and VDAC digital to analog converter
- *
- * What is missing :
  * - TMDS/HDMI Encoding via ENCI_DIV and ENCP
  * - Setup of more clock rates for HDMI modes
+ *
+ * What is missing :
  * - LCD Panel encoding via ENCL
  * - TV Panel encoding via ENCT
+ *
+ * VENC paths :
+ *_   _   
+ * vd1---| |-| | | VENC /-|VDAC
+ * vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
+ * osd1--| |-| | | \  | X--HDMI-TX
+ * osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
+ *   |  | |
+ *   |  \--ENCL---|LVDS
+ *   ||
+ *
+ * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC
+ * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI.
+ * The ENCP is designed for Progressive encoding but can also generate
+ * 1080i interlaced pixels, and was initialy desined to encode pixels for
+ * VDAC to output RGB ou YUV analog outputs.
+ * It's output is only used through the ENCP_DVI encoder for HDMI.
+ * The ENCL LVDS encoder is not implemented.
+ *
+ * The ENCI and ENCP encoders needs specially defined parameters for each
+ * supported mode and thus cannot be determined from standard video timings.
+ *
+ * The ENCI end ENCP DVI encoders are more generic and can generate any timings
+ * from the pixel data generated by ENCI or ENCP, so can use the standard video
+ * timings are source for HW parameters.
  */
 
 /* HHI Registers */
@@ -91,6 +116,1219 @@ struct meson_cvbs_enci_mode meson_cvbs_enci_ntsc = {
.analog_sync_adj = 0x9c00,
 };
 
+union meson_hdmi_venc_mode {
+   struct {
+   unsigned int mode_tag;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_even;
+   unsigned int vso_odd;
+   unsigned int macv_max_amp;
+   unsigned int video_prog_mode;
+   unsigned int video_mode;
+   unsigned int sch_adjust;
+   unsigned int yc_delay;
+   unsigned int pixel_start;
+   unsigned int pixel_end;
+   unsigned int top_field_line_start;
+   unsigned int top_field_line_end;
+   unsigned int bottom_field_line_start;
+   unsigned int bottom_field_line_end;
+   } enci;
+   struct {
+   unsigned int dvi_settings;
+   unsigned int video_mode;
+   unsigned int video_mode_adv;
+   unsigned int video_prog_mode;
+   bool video_prog_mode_present;
+   unsigned int video_sync_mode;
+   bool video_sync_mode_present;
+   unsigned int video_yc_dly;
+   bool video_yc_dly_present;
+   unsigned int video_rgb_ctrl;
+   bool video_rgb_ctrl_present;
+   unsigned int video_filt_ctrl;
+   bool video_filt_ctrl_present;
+   unsigned int video_ofld_voav_ofst;
+   bool video_ofld_voav_ofst_present;
+   unsigned int yfp1_htime;
+   unsigned int yfp2_htime;
+   unsigned int max_pxcnt;
+   unsigned int hspuls_begin;
+   unsigned int hspuls_end;
+   unsigned int hspuls_switch;
+   unsigned int vspuls_begin;
+   unsigned int vspuls_end;
+   unsigned int vspuls_bline;
+   unsigned int vspuls_eline;
+   unsigned int eqpuls_begin;
+   bool eqpuls_begin_present;
+   unsigned int eqpuls_end;
+   bool eqpuls_end_present;
+   unsigned int eqpuls_bline;
+   bool eqpuls_bline_present;
+   unsigned int eqpuls_eline;
+   bool eqpuls_eline_present;
+   unsigned int havon_begin;
+   unsigned int havon_end;
+   unsigned int vavon_bline;
+   unsigned int vavon_eline;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_begin;
+   unsigned int vso_end;
+   unsigned int vso_bline;
+

[PATCH v2 03/13] drm/meson: Add support for components

[Neil Armstrong]

This patch adds support for optional components connected through the
Device Tree endpoints scheme.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.c | 113 +-
 1 file changed, 99 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index bc562a0..a2e9f56 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -150,9 +151,9 @@ static bool meson_vpu_has_available_connectors(struct 
device *dev)
.max_register   = 0x1000,
 };
 
-static int meson_drv_probe(struct platform_device *pdev)
+static int meson_drv_bind(struct device *dev)
 {
-   struct device *dev = >dev;
+   struct platform_device *pdev = to_platform_device(dev);
struct meson_drm *priv;
struct drm_device *drm;
struct resource *res;
@@ -215,6 +216,15 @@ static int meson_drv_probe(struct platform_device *pdev)
 
drm_vblank_init(drm, 1);
drm_mode_config_init(drm);
+   drm->mode_config.max_width = 3840;
+   drm->mode_config.max_height = 2160;
+   drm->mode_config.funcs = _mode_config_funcs;
+
+   /* Hardware Initialization */
+
+   meson_venc_init(priv);
+   meson_vpp_init(priv);
+   meson_viu_init(priv);
 
/* Encoder Initialization */
 
@@ -222,11 +232,11 @@ static int meson_drv_probe(struct platform_device *pdev)
if (ret)
goto free_drm;
 
-   /* Hardware Initialization */
-
-   meson_venc_init(priv);
-   meson_vpp_init(priv);
-   meson_viu_init(priv);
+   ret = component_bind_all(drm->dev, drm);
+   if (ret) {
+   dev_err(drm->dev, "Couldn't bind all components\n");
+   goto free_drm;
+   }
 
ret = meson_plane_create(priv);
if (ret)
@@ -241,9 +251,6 @@ static int meson_drv_probe(struct platform_device *pdev)
goto free_drm;
 
drm_mode_config_reset(drm);
-   drm->mode_config.max_width = 8192;
-   drm->mode_config.max_height = 8192;
-   drm->mode_config.funcs = _mode_config_funcs;
 
priv->fbdev = drm_fbdev_cma_init(drm, 32,
 drm->mode_config.num_connector);
@@ -268,9 +275,9 @@ static int meson_drv_probe(struct platform_device *pdev)
return ret;
 }
 
-static int meson_drv_remove(struct platform_device *pdev)
+static void meson_drv_unbind(struct device *dev)
 {
-   struct drm_device *drm = dev_get_drvdata(>dev);
+   struct drm_device *drm = dev_get_drvdata(dev);
struct meson_drm *priv = drm->dev_private;
 
drm_dev_unregister(drm);
@@ -280,9 +287,88 @@ static int meson_drv_remove(struct platform_device *pdev)
drm_vblank_cleanup(drm);
drm_dev_unref(drm);
 
-   return 0;
 }
 
+static const struct component_master_ops meson_drv_master_ops = {
+   .bind   = meson_drv_bind,
+   .unbind = meson_drv_unbind,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+   DRM_DEBUG_DRIVER("Comparing of node %s with %s\n",
+of_node_full_name(dev->of_node),
+of_node_full_name(data));
+
+   return dev->of_node == data;
+}
+
+/* Possible connectors nodes to ignore */
+static const struct of_device_id connectors_match[] = {
+   { .compatible = "composite-video-connector" },
+   { .compatible = "svideo-connector" },
+   { .compatible = "hdmi-connector" },
+   { .compatible = "dvi-connector" },
+   {}
+};
+
+static int meson_probe_remote(struct platform_device *pdev,
+ struct component_match **match,
+ struct device_node *parent,
+ struct device_node *remote)
+{
+   struct device_node *ep, *remote_node;
+   int count = 1;
+
+   /* If node is a connector, return and do not add to match table */
+   if (of_match_node(connectors_match, remote))
+   return 1;
+
+   component_match_add(>dev, match, compare_of, remote);
+
+   for_each_endpoint_of_node(remote, ep) {
+   remote_node = of_graph_get_remote_port_parent(ep);
+   if (!remote_node ||
+   remote_node == parent || /* Ignore parent endpoint */
+   !of_device_is_available(remote_node))
+   continue;
+
+   count += meson_probe_remote(pdev, match, remote, remote_node);
+
+   of_node_put(remote_node);
+   }
+
+   return count;
+}
+
+static int meson_drv_probe(struct platform_device *pdev)
+{
+   struct component_match *match = NULL;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *ep, *remote;
+   int count = 0;
+
+   for_each_endpoint_of_node(np, ep) {
+   remote = 

[PATCH v2 04/13] drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available

[Neil Armstrong]

Since this is managed now by the components code, if CVBS is not available
and HDMI neither, the drm driver won't bind anyway.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c 
b/drivers/gpu/drm/meson/meson_venc_cvbs.c
index a2bcc70..a96fcb4 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
@@ -248,7 +248,7 @@ int meson_venc_cvbs_create(struct meson_drm *priv)
 
if (!meson_venc_cvbs_connector_is_available(priv)) {
dev_info(drm->dev, "CVBS Output connector not available\n");
-   return -ENODEV;
+   return 0;
}
 
meson_venc_cvbs = devm_kzalloc(priv->dev, sizeof(*meson_venc_cvbs),
-- 
1.9.1

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

[PATCH v2 00/13] drm/meson: Initial support for HDMI Output

[Neil Armstrong]

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.

This patchset depends on Laurent Pinchart patchset merged in drm-misc-next
and my v4 patchset at [1] to permit PHY control from outside the dw-hdmi driver.

The Synopsys DesignWare HDMI TX Controller is integrated like :
 ___
|HDMI TOP   |<= HPD
|___|
|  ||
HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
|Controller||
|___|<=> DDC

And uses the following paths for Pixels Encoding :
   _   _   
vd1---| |-| | | VENC /-|VDAC
vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
osd1--| |-| | | \  | X--HDMI-TX
osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
  |  | |
  |  \--ENCL---|LVDS
  ||

The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
ENCP-DVI encoders. Those DVI encoders will format the pixels for the
Synopsys DesignWare HDMI TX Controller.

In order to support display modes, the ENCI and ENCP encoders needs very
specific parameters for *each* display modes, so usage of the CEA VIC
identifier is necessary. But the DVI timings are generated from the
drm_mode structure in a generic way.

To simplify the first push, only the main CEA modes are supported up to
1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
in order to support the Clock Doubling necessary for these modes.

Support for more traditional modes like the EDID fallback modes is planned
but will need tome additionnal handling along the CEA modes.
Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
for now only the HDMI 1.4 modes are currently available in the drm_edid
implementation.

This patchset does :
 - Fixes the CRTC handling
 - Fixes the registers definitions
 - Adds support for device components registration along of-graph
 - Adds support for HDMI clocks
 - Adds support for HDMI VENC video modes
 - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
 - Adds CMA node to reserve enougth memory for 1080p display
 - Adds the HDMI controller et connector modes on selected boards
 - Adds a proper dt-bindings for the HDMI controller et connector
 - Add RST documentation for Meson DRM driver
 - Updates the MAINTAINERS file to track the new files

Changes since v1 patchset at [2] :
 - Add the meson drm documentation from [3] to this patchset
 - Update with new bus formats and HPD callbacks
 - Drop all the of_machine_is_compatible

[1] 
http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com
[2] 
http://lkml.kernel.org/r/1488469207-523-1-git-send-email-narmstr...@baylibre.com
[3] 
http://lkml.kernel.org/r/1488536068-9407-1-git-send-email-narmstr...@baylibre.com

Neil Armstrong (13):
  drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
sync for vsync commit
  drm/meson: Add missing HDMI register
  drm/meson: Add support for components
  drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
  drm/meson: add support for HDMI clock support
  drm/meson: Add support for HDMI venc modes and settings
  drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
  ARM64: dts: meson-gx: Add shared CMA dma memory pool
  ARM64: dts: meson-gx: Add support for HDMI output
  dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
  drm/meson: Convert existing documentation to actual kerneldoc
  drm/meson: Add RST to bring together kerneldoc
  MAINTAINERS: update files for Amlogic DRM Driver

 .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
 Documentation/gpu/index.rst|1 +
 Documentation/gpu/meson.rst|   61 +
 MAINTAINERS|2 +
 .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
 .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
 .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts|   23 +
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
 .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |3 +
 drivers/gpu/drm/meson/Kconfig  |6 +
 drivers/gpu/drm/meson/Makefile |1 +
 drivers/gpu/drm/meson/meson_canvas.c   |4 +-
 drivers/gpu/drm/meson/meson_crtc.c |   15 +-
 drivers/gpu/drm/meson/meson_drv.c  |  118 +-
 

Re: [RFC libdrm 0/2] Replace the build system with meson

[Ilia Mirkin]

On Tue, Mar 21, 2017 at 11:13 AM, Grazvydas Ignotas  wrote:
> everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.

Or they could be contributing to mesa because it's the last project
with a sane build system.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Neil Armstrong]

Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 +-
 include/drm/bridge/dw_hdmi.h  |  63 ++
 2 files changed, 294 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f82750a..fcb0a27 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -30,18 +30,15 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
 #define DDC_SEGMENT_ADDR   0x30
 #define HDMI_EDID_LEN  512
 
-#define RGB0
-#define YCBCR444   1
-#define YCBCR422_16BITS2
-#define YCBCR422_8BITS 3
-#define XVYCC444   4
-
 enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -95,10 +92,10 @@ struct hdmi_vmode {
 };
 
 struct hdmi_data_info {
-   unsigned int enc_in_format;
-   unsigned int enc_out_format;
-   unsigned int enc_color_depth;
-   unsigned int colorimetry;
+   unsigned int enc_in_bus_format;
+   unsigned int enc_out_bus_format;
+   unsigned int enc_in_encoding;
+   unsigned int enc_out_encoding;
unsigned int pix_repet_factor;
unsigned int hdcp_enable;
struct hdmi_vmode video_mode;
@@ -567,6 +564,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
 
+static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_UYYVYY8_1X24:
+   case MEDIA_BUS_FMT_UYYVYY10_1X30:
+   case MEDIA_BUS_FMT_UYYVYY12_1X36:
+   case MEDIA_BUS_FMT_UYYVYY16_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYYVYY8_1X24:
+   return 8;
+
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_UYYVYY10_1X30:
+   return 10;
+
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   case MEDIA_BUS_FMT_UYYVYY12_1X36:
+   return 12;
+
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   case MEDIA_BUS_FMT_UYYVYY16_1X48:
+   return 16;
+
+   default:
+   return 0;
+   }
+}
+
 /*
  * this submodule is responsible for the video data synchronization.
  * for example, for RGB 4:4:4 input, the data map is defined as
@@ -579,37 +662,49 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
int color_format = 0;
u8 val;
 
-   if (hdmi->hdmi_data.enc_in_format == RGB) {
-   if (hdmi->hdmi_data.enc_color_depth == 8)
-   color_format = 0x01;
-   else if (hdmi->hdmi_data.enc_color_depth == 10)
-   color_format = 0x03;
-   else if (hdmi->hdmi_data.enc_color_depth == 12)
-   color_format = 0x05;
-   else if (hdmi->hdmi_data.enc_color_depth == 16)
-   color_format = 0x07;
-   else
-   return;
-   } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) {
-   if (hdmi->hdmi_data.enc_color_depth == 8)
-   color_format = 0x09;
-   else if (hdmi->hdmi_data.enc_color_depth == 10)
-   color_format = 0x0B;
-  

[PATCH v4 1/6] drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

[Neil Armstrong]

From: Laurent Pinchart 

In preparation for adding PHY operations to handle RX SENSE and HPD,
group all the PHY interrupt setup code in a single location and extract
it to a separate function.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 50 ++-
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index af93f7a..f82750a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1559,7 +1559,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 }
 
 /* Wait until we are registered to enable interrupts */
-static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
+static void dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
 {
hdmi_writeb(hdmi, HDMI_PHY_I2CM_INT_ADDR_DONE_POL,
HDMI_PHY_I2CM_INT_ADDR);
@@ -1567,15 +1567,6 @@ static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, HDMI_PHY_I2CM_CTLINT_ADDR_NAC_POL |
HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_POL,
HDMI_PHY_I2CM_CTLINT_ADDR);
-
-   /* enable cable hot plug irq */
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
-   return 0;
 }
 
 static void initialize_hdmi_ih_mutes(struct dw_hdmi *hdmi)
@@ -1693,6 +1684,26 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
 }
 
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
+{
+   /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+
+   /* Enable cable hot plug irq. */
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+   /* Clear and unmute interrupts. */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+   HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -2204,29 +2215,14 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
hdmi->ddc = NULL;
}
 
-   /*
-* Configure registers related to HDMI interrupt
-* generation before registering IRQ.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = _hdmi_bridge_funcs;
 #ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
 #endif
 
-   ret = dw_hdmi_fb_registered(hdmi);
-   if (ret)
-   goto err_iahb;
-
-   /* Unmute interrupts */
-   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
-   HDMI_IH_MUTE_PHY_STAT0);
+   dw_hdmi_fb_registered(hdmi);
+   dw_hdmi_phy_setup_hpd(hdmi);
 
memset(, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
-- 
1.9.1

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

[PATCH v4 0/6] drm: bridge: dw-hdmi: Add support for Custom PHYs

[Neil Armstrong]

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.

Thanks to Laurent Pinchart's changes, the HW report the following :
 Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)

The following differs from common PHY integration as managed in the current
driver :
 - Amlogic PHY is not configured through the internal I2C link
 - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the 
controller
 - Amlogic PHY do not export HPD ands RxSense signals to the controller

And finally, concerning the controller integration :
 - the Controller registers are not flat memory-mapped, and uses an
addr+read/write register pair to write all registers.
 - Inputs only YUV444 pixel data

Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged
in drm-misc-next branch.

This is why the following patchset implements :
 - Configure the Input format from the plat_data
 - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver

To implement the input format handling, the Synopsys HDMIT TX Controller input
V4L bus formats are used and missing formats + documentation are added.

This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is
also tested on the RK3288 ACT8846 EVB Board.

Changes since v3 at [4] :
 - Fix 4:2:0 bus formats naming
 - Add separate 36bit and 48bit tables for bus formats documentation
 - Added 4:2:0 bus config in hdmi_video_sample
 - Moved dw_hdmi documentation in a "bridge" subdir
 - Rebase on drm-misc-next at 62c58af32c93

Changes since v2 at [3] :
 - Rebase on laurent patch "Extract PHY interrupt setup to a function"
 - Reduce phy operations
 - Switch the V4L bus formats and encodings instead of custom enum

Changes since v1 at [2] :
 - Drop patches submitted by laurent

Changes since RFC at [1] :
 - Regmap fixup for 4bytes register access, tested on RK3288 SoC
 - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops
 - Move HDMI link data into shared header
 - Move Pixel Encoding enum to shared header

[1] 
http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com
[2] 
http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com
[3] 
http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
[4] 
http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com

Laurent Pinchart (1):
  drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

Neil Armstrong (5):
  media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX
Controller
  documentation: media: Add documentation for new RGB and YUV bus
formats
  drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
  drm: bridge: dw-hdmi: Add Documentation on supported input formats
  drm: bridge: dw-hdmi: Move HPD handling to PHY operations

 Documentation/gpu/bridge/dw-hdmi.rst|  15 +
 Documentation/gpu/index.rst |   1 +
 Documentation/media/uapi/v4l/subdev-formats.rst | 871 +++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 469 -
 include/drm/bridge/dw_hdmi.h|  68 ++
 include/uapi/linux/media-bus-format.h   |  13 +-
 6 files changed, 1266 insertions(+), 171 deletions(-)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

-- 
1.9.1

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