date:20151208

[PATCH 1/2] drm: make drm_dev_set_unique() not use a format string

2015-12-08 Thread Emil Velikov

On 8 December 2015 at 22:12, Nicolas Iooss  
wrote:
> drm_dev_set_unique() uses a format string to define the unique name of a
> device.  This feature is not used as currently all the calls to this
> function either use "%s" as a format string or directly use
> dev_name().
>
> Even though this second kind of call does not introduce security
> problems, because there cannot be "%" characters in dev_name() results,
> gcc issues a warning when building with -Wformat-security flag
> ("warning: format string is not a string literal (potentially
> insecure)").  This warning is useful to find real bugs like the one
> fixed by commit 3958b79266b1 ("configfs: fix kernel infoleak through
> user-controlled format string").  False positives which do not bring
> an extra value make the work of finding real bugs harder.
>
> Therefore remove the format-string feature from drm_dev_set_unique().
>
> Signed-off-by: Nicolas Iooss 
> ---
>  drivers/gpu/drm/drm_drv.c   | 11 +++
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 +-
>  include/drm/drmP.h  |  2 +-
>  4 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7dd6728dd092..20eaa0aae205 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -797,7 +797,7 @@ EXPORT_SYMBOL(drm_dev_unregister);
>  /**
>   * drm_dev_set_unique - Set the unique name of a DRM device
>   * @dev: device of which to set the unique name
> - * @fmt: format string for unique name
> + * @name: unique name
>   *
>   * Sets the unique name of a DRM device using the specified format string and
>   * a variable list of arguments. Drivers can use this at driver probe time if
You might want to also update the above hunk :-)

-Emil

[PATCH 2/2] drm: use dev_name as default unique name in drm_dev_alloc()

2015-12-08 Thread Nicolas Iooss

The following code pattern exists in some DRM drivers:

ddev = drm_dev_alloc(&driver, parent_dev);
drm_dev_set_unique(ddev, dev_name(parent_dev));

(Sometimes dev_name(ddev->dev) is used, which is the same.)

As suggested in
http://lists.freedesktop.org/archives/dri-devel/2015-December/096441.html,
the unique name of a new DRM device can be set as dev_name(parent_dev)
when parent_dev is not NULL (vgem is a special case).

Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 
 drivers/gpu/drm/drm_drv.c| 9 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 1 -
 drivers/gpu/drm/nouveau/nouveau_drm.c| 4 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  | 4 
 drivers/gpu/drm/tegra/drm.c  | 1 -
 drivers/gpu/drm/vc4/vc4_drv.c| 2 --
 7 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 244df0a440b7..fba4f72e7ae1 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -733,10 +733,6 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device 
*pdev)
if (!ddev)
return -ENOMEM;

-   ret = drm_dev_set_unique(ddev, dev_name(ddev->dev));
-   if (ret)
-   goto err_unref;
-
ret = atmel_hlcdc_dc_load(ddev);
if (ret)
goto err_unref;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 20eaa0aae205..df749a6156e0 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -633,8 +633,17 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
}
}

+   if (parent) {
+   ret = drm_dev_set_unique(dev, dev_name(parent));
+   if (ret)
+   goto err_setunique;
+   }
+
return dev;

+err_setunique:
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_destroy(dev);
 err_ctxbitmap:
drm_legacy_ctxbitmap_cleanup(dev);
drm_ht_remove(&dev->map_hash);
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 1930234ba5f1..fca97d3fc846 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -363,7 +363,6 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
fsl_dev->np = dev->of_node;
drm->dev_private = fsl_dev;
dev_set_drvdata(dev, fsl_dev);
-   drm_dev_set_unique(drm, dev_name(dev));

ret = drm_dev_register(drm, 0);
if (ret < 0)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2d23f95f17ce..b3a563c44bcd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1046,10 +1046,6 @@ nouveau_platform_device_create(const struct 
nvkm_device_tegra_func *func,
goto err_free;
}

-   err = drm_dev_set_unique(drm, dev_name(&pdev->dev));
-   if (err < 0)
-   goto err_free;
-
drm->platformdev = pdev;
platform_set_drvdata(pdev, drm);

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 215d6c44af55..afbb7407c44f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,10 +450,6 @@ static int rockchip_drm_bind(struct device *dev)
if (!drm)
return -ENOMEM;

-   ret = drm_dev_set_unique(drm, dev_name(dev));
-   if (ret)
-   goto err_free;
-
ret = drm_dev_register(drm, 0);
if (ret)
goto err_free;
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 159ef515cab1..12e2d3ccbc9d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -991,7 +991,6 @@ static int host1x_drm_probe(struct host1x_device *dev)
if (!drm)
return -ENOMEM;

-   drm_dev_set_unique(drm, dev_name(&dev->dev));
dev_set_drvdata(&dev->dev, drm);

err = drm_dev_register(drm, 0);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index d5db9e0f3b73..647772305e8f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -168,8 +168,6 @@ static int vc4_drm_bind(struct device *dev)
vc4->dev = drm;
drm->dev_private = vc4;

-   drm_dev_set_unique(drm, dev_name(dev));
-
drm_mode_config_init(drm);
if (ret)
goto unref;
-- 
2.6.3

[PATCH 1/2] drm: make drm_dev_set_unique() not use a format string

2015-12-08 Thread Nicolas Iooss

drm_dev_set_unique() uses a format string to define the unique name of a
device.  This feature is not used as currently all the calls to this
function either use "%s" as a format string or directly use
dev_name().

Even though this second kind of call does not introduce security
problems, because there cannot be "%" characters in dev_name() results,
gcc issues a warning when building with -Wformat-security flag
("warning: format string is not a string literal (potentially
insecure)").  This warning is useful to find real bugs like the one
fixed by commit 3958b79266b1 ("configfs: fix kernel infoleak through
user-controlled format string").  False positives which do not bring
an extra value make the work of finding real bugs harder.

Therefore remove the format-string feature from drm_dev_set_unique().

Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/drm_drv.c   | 11 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 +-
 include/drm/drmP.h  |  2 +-
 4 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7dd6728dd092..20eaa0aae205 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -797,7 +797,7 @@ EXPORT_SYMBOL(drm_dev_unregister);
 /**
  * drm_dev_set_unique - Set the unique name of a DRM device
  * @dev: device of which to set the unique name
- * @fmt: format string for unique name
+ * @name: unique name
  *
  * Sets the unique name of a DRM device using the specified format string and
  * a variable list of arguments. Drivers can use this at driver probe time if
@@ -805,15 +805,10 @@ EXPORT_SYMBOL(drm_dev_unregister);
  *
  * Return: 0 on success or a negative error code on failure.
  */
-int drm_dev_set_unique(struct drm_device *dev, const char *fmt, ...)
+int drm_dev_set_unique(struct drm_device *dev, const char *name)
 {
-   va_list ap;
-
kfree(dev->unique);
-
-   va_start(ap, fmt);
-   dev->unique = kvasprintf(GFP_KERNEL, fmt, ap);
-   va_end(ap);
+   dev->unique = kstrdup(name, GFP_KERNEL);

return dev->unique ? 0 : -ENOMEM;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 1d3ee5179ab8..2d23f95f17ce 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1046,7 +1046,7 @@ nouveau_platform_device_create(const struct 
nvkm_device_tegra_func *func,
goto err_free;
}

-   err = drm_dev_set_unique(drm, "%s", dev_name(&pdev->dev));
+   err = drm_dev_set_unique(drm, dev_name(&pdev->dev));
if (err < 0)
goto err_free;

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f22e1e1ee64a..215d6c44af55 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,7 +450,7 @@ static int rockchip_drm_bind(struct device *dev)
if (!drm)
return -ENOMEM;

-   ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
+   ret = drm_dev_set_unique(drm, dev_name(dev));
if (ret)
goto err_free;

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 0a271ca1f7c7..f14c25a6bbf2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1059,7 +1059,7 @@ void drm_dev_ref(struct drm_device *dev);
 void drm_dev_unref(struct drm_device *dev);
 int drm_dev_register(struct drm_device *dev, unsigned long flags);
 void drm_dev_unregister(struct drm_device *dev);
-int drm_dev_set_unique(struct drm_device *dev, const char *fmt, ...);
+int drm_dev_set_unique(struct drm_device *dev, const char *name);

 struct drm_minor *drm_minor_acquire(unsigned int minor_id);
 void drm_minor_release(struct drm_minor *minor);
-- 
2.6.3

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #9 from Nicolai HÃ¤hnle  ---
Created attachment 120426
  --> https://bugs.freedesktop.org/attachment.cgi?id=120426&action=edit
dmesg.faults

Sample extractions of the first four reported VM faults across different runs.

Note how something always wants to access page 0x092D80FA, and later accesses
look like they could originate from something being very confused about the
memory layout of textures, e.g. 0x00126AAC and 0x001A6A8C differing only in two
bits.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/31e149ca/attachment.html>

[PATCH v10.1 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

2015-12-08 Thread Rob Herring

On Wed, Dec 09, 2015 at 10:10:39AM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
> 
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
> 
> Signed-off-by: Yakir Yang 
> Tested-by: Javier Martinez Canillas 

Acked-by: Rob Herring 

> ---
> Changes in v10.1:
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> 
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>   hpd when hpd detect failed.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt|  4 ++-
>  .../bindings/display/exynos/exynos_dp.txt  |  1 +
>  .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 
> ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
>  6 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> index 7659a7a..4f2ba8c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
>   from general PHY binding: Should be "dp".
>  
>  Optional properties for dp-controller:
> + -force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.
>   -hpd-gpios:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug detection
> @@ -31,7 +34,6 @@ Optional properties for dp-controller:
>   * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>   * 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>  
> -
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> ---
>  
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 9905081..8800164 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>   -phys (required)
>   -phy-names (required)
>   -hpd-gpios (optional)
> + -analogix,need-force-hpd (optional)
>   -video interfaces (optional)
>  
>  Deprecated properties for DisplayPort:
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> index dae86c4..187a708e 100644
> --- 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>  - phys (required)
>  - phy-names (required)
>  - hpd-gpios (optional)
> +- force-hpd (optional)
>  
> ---
>  
>  Example:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a11504b..00aee44 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct 
> analogix_dp_device *dp)
>  {
>   int timeout_loop = 0;
>  
> - while (analogix_dp_get_plug_in_status(dp) != 0) {
> + while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
> + if (analogix_dp_get_plug_in_status(dp) == 0)
> + return 0;
> +
>   timeout_loop++;
> - if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
> - dev_err(dp->dev, "failed to get hpd plug status\n");
> - return -ETIMEDOUT;
> - }
>   usleep_range(10, 11);
>   }
>  
> + /*
> +  * Some edp screen do not have hpd signal, so we can't just
> +  * return failed when hpd plug in detect failed, DT property
> +  * "need-force-hpd" would indicate whether driver need this.
> +  */
> + if (!dp->force_hpd)
> + return -ETIMEDOUT;
> +
> + /*
> +  * The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
> +  * will n

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #8 from Nicolai HÃ¤hnle  ---
Created attachment 120425
  --> https://bugs.freedesktop.org/attachment.cgi?id=120425&action=edit
llvm-26ddca1.mesa-caf12bebd.run009.shader.frag

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/a7e49590/attachment.html>

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Nicolai HÃ¤hnle  ---
Created attachment 120424
  --> https://bugs.freedesktop.org/attachment.cgi?id=120424&action=edit
llvm-26ddca1.mesa-caf12bebd.run009.shader.vert

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/de66a6b9/attachment.html>

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Nicolai HÃ¤hnle  ---
Created attachment 120423
  --> https://bugs.freedesktop.org/attachment.cgi?id=120423&action=edit
llvm-c0a189c.mesa-caf12bebd.run008.shader.16f00d

Fragment shader

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/103923e7/attachment.html>

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Nicolai HÃ¤hnle  ---
Created attachment 120422
  --> https://bugs.freedesktop.org/attachment.cgi?id=120422&action=edit
llvm-c0a189c.mesa-caf12bebd.run008.shader.113a9b

This is the vertex shader

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/30a39b32/attachment.html>

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

Nicolai HÃ¤hnle  changed:

   What|Removed |Added

 Attachment #120421|check_vm dump   |llvm-c0a189c.mesa-caf12bebd
description||.run008.check_vm-dump

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/6422a6f2/attachment-0001.html>

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Nicolai HÃ¤hnle  ---
Created attachment 120421
  --> https://bugs.freedesktop.org/attachment.cgi?id=120421&action=edit
check_vm dump

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/5112d445/attachment.html>

[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Nicolai HÃ¤hnle  ---
Time to document some information I've gathered.

I can now confirm that Mesa has nothing to do with it. Something must have gone
wrong with my builds initially, sorry for having caused confusion.

I captured an apitrace for better reproducibility[0] and ran it with shader
dumps enabled and flushing after each draw call in the "interesting" region.

I am going to attach the R600_DEBUG=check_vm dump which I've cross-referenced
with R600_DEBUG=vm to obtain the shaders that were active during the draw call
(file names with prefix llvm-c0a189c.mesa-caf12bebd). I then matched the
shaders to those dumped by a run with a good version of LLVM (commit just
before the bad one, file names with prefix llvm-26ddca1.mesa-caf12bebd).

Clearly, the LLVM changes caused some significant re-ordering of the
instruction schedule, and that somehow, surprisingly, seems to be responsible
for the VM faults.

Another aspect to note is that the shaders are compiled before draw call
174000, while the VM faults happen shortly after draw call 178000. This seems
to suggest that the shaders alone only cause VM faults in conjunction with some
other state. However, the VM faults have always happened in exactly the same
point so far, so it does appear to be deterministic.

[0] The demo always causes VM faults, so I'm not going to upload the giant
trace; however, the timing varies between runs, so it's cleaner to reproduce
using a trace.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/55a7322c/attachment.html>

[PATCH] drm/i915: constify intel_dvo_dev_ops structures

2015-12-08 Thread Julia Lawall

The intel_dvo_dev_ops structures are never modified, so declare them as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/i915/dvo.h|   12 ++--
 drivers/gpu/drm/i915/dvo_ch7017.c |2 +-
 drivers/gpu/drm/i915/dvo_ch7xxx.c |2 +-
 drivers/gpu/drm/i915/dvo_ivch.c   |2 +-
 drivers/gpu/drm/i915/dvo_ns2501.c |2 +-
 drivers/gpu/drm/i915/dvo_sil164.c |2 +-
 drivers/gpu/drm/i915/dvo_tfp410.c |2 +-
 7 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h
index 13dea42..5e6a301 100644
--- a/drivers/gpu/drm/i915/dvo.h
+++ b/drivers/gpu/drm/i915/dvo.h
@@ -129,11 +129,11 @@ struct intel_dvo_dev_ops {
void (*dump_regs)(struct intel_dvo_device *dvo);
 };

-extern struct intel_dvo_dev_ops sil164_ops;
-extern struct intel_dvo_dev_ops ch7xxx_ops;
-extern struct intel_dvo_dev_ops ivch_ops;
-extern struct intel_dvo_dev_ops tfp410_ops;
-extern struct intel_dvo_dev_ops ch7017_ops;
-extern struct intel_dvo_dev_ops ns2501_ops;
+extern const struct intel_dvo_dev_ops sil164_ops;
+extern const struct intel_dvo_dev_ops ch7xxx_ops;
+extern const struct intel_dvo_dev_ops ivch_ops;
+extern const struct intel_dvo_dev_ops tfp410_ops;
+extern const struct intel_dvo_dev_ops ch7017_ops;
+extern const struct intel_dvo_dev_ops ns2501_ops;

 #endif /* _INTEL_DVO_H */
diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
b/drivers/gpu/drm/i915/dvo_ch7017.c
index cbb2202..b3c7c19 100644
--- a/drivers/gpu/drm/i915/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/dvo_ch7017.c
@@ -402,7 +402,7 @@ static void ch7017_destroy(struct intel_dvo_device *dvo)
}
 }

-struct intel_dvo_dev_ops ch7017_ops = {
+const struct intel_dvo_dev_ops ch7017_ops = {
.init = ch7017_init,
.detect = ch7017_detect,
.mode_valid = ch7017_mode_valid,
diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c 
b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index 4b4acc1..44b3159 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -356,7 +356,7 @@ static void ch7xxx_destroy(struct intel_dvo_device *dvo)
}
 }

-struct intel_dvo_dev_ops ch7xxx_ops = {
+const struct intel_dvo_dev_ops ch7xxx_ops = {
.init = ch7xxx_init,
.detect = ch7xxx_detect,
.mode_valid = ch7xxx_mode_valid,
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
index ff9f1b0..4950b82 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -490,7 +490,7 @@ static void ivch_destroy(struct intel_dvo_device *dvo)
}
 }

-struct intel_dvo_dev_ops ivch_ops = {
+const struct intel_dvo_dev_ops ivch_ops = {
.init = ivch_init,
.dpms = ivch_dpms,
.get_hw_state = ivch_get_hw_state,
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 063859f..2379c33 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -698,7 +698,7 @@ static void ns2501_destroy(struct intel_dvo_device *dvo)
}
 }

-struct intel_dvo_dev_ops ns2501_ops = {
+const struct intel_dvo_dev_ops ns2501_ops = {
.init = ns2501_init,
.detect = ns2501_detect,
.mode_valid = ns2501_mode_valid,
diff --git a/drivers/gpu/drm/i915/dvo_sil164.c 
b/drivers/gpu/drm/i915/dvo_sil164.c
index 26f13eb..1c1a067 100644
--- a/drivers/gpu/drm/i915/dvo_sil164.c
+++ b/drivers/gpu/drm/i915/dvo_sil164.c
@@ -267,7 +267,7 @@ static void sil164_destroy(struct intel_dvo_device *dvo)
}
 }

-struct intel_dvo_dev_ops sil164_ops = {
+const struct intel_dvo_dev_ops sil164_ops = {
.init = sil164_init,
.detect = sil164_detect,
.mode_valid = sil164_mode_valid,
diff --git a/drivers/gpu/drm/i915/dvo_tfp410.c 
b/drivers/gpu/drm/i915/dvo_tfp410.c
index 6f1a0a6..31e181d 100644
--- a/drivers/gpu/drm/i915/dvo_tfp410.c
+++ b/drivers/gpu/drm/i915/dvo_tfp410.c
@@ -306,7 +306,7 @@ static void tfp410_destroy(struct intel_dvo_device *dvo)
}
 }

-struct intel_dvo_dev_ops tfp410_ops = {
+const struct intel_dvo_dev_ops tfp410_ops = {
.init = tfp410_init,
.detect = tfp410_detect,
.mode_valid = tfp410_mode_valid,

[PATCH 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings

2015-12-08 Thread Rob Herring

On Tue, Dec 08, 2015 at 02:49:05PM +0100, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
> via I2C bus.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../bindings/video/bridge/sil-sii8620.txt  | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt 
> b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
> new file mode 100644
> index 000..29f3f35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
> @@ -0,0 +1,34 @@
> +Silicon Image SiI8620 bridge bindings

Bridging what to what?

> +
> +Required properties:
> + - compatible: "sil,sii8620"
> + - reg: i2c address of the bridge
> + - cvcc10-supply: Digital Core Supply Voltage (1.0V)
> + - iovcc18-supply: I/O Supply Voltage (1.8V)
> + - int-gpios: gpio specifier of INT pin

Assuming INT means interrupt, this should use interrupts property.

> + - reset-gpios: gpio specifier of RESET pin
> + - clocks, clock-names: specification and name of "xtal" clock
> + - video interfaces: Device node can contain video interface port
> + node for HDMI encoder according to [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + sii8620 at 39 {
> + reg = <0x39>;
> + compatible = "sil,sii8620";
> + cvcc10-supply = <&ldo36_reg>;
> + iovcc18-supply = <&ldo34_reg>;
> + int-gpio = <&gpf0 2 0>;
> + reset-gpio = <&gpv7 0 0>;
> + clocks = <&pmu_system_controller 0>;
> + clock-names = "xtal";

> + assigned-clocks = <&pmu_system_controller 0>;
> + assigned-clock-parents = <&xxti>;

These aren't listed in the doc.

> +
> + port {
> + mhl_to_hdmi: endpoint {
> + remote-endpoint = <&hdmi_to_mhl>;
> + };
> + };

I'd like to see this have a port to a connector node, too. Possibly
that can come later.

Rob

[PATCH i915 v8 0/2] PRIME Synchronization

2015-12-08 Thread Alex Goins

Any more feedback on this?

Thanks,
Alex

On Thu, 26 Nov 2015, Alex Goins wrote:

> Hello all,
> 
> For a while now, I've been working to fix tearing with PRIME. This is the
> same as the eighth version of the DRM component for PRIME synchronization,
> 
> In this version, use_mmio_flip() tests against
> !reservation_object_test_signaled_rcu(test_all=FALSE) instead of directly
> checking for an exclusive fence with obj->base.dma_buf->resv->fence_excl.
> 
> Repeat of overview below:
> 
> v1 was a more complicated patch set that added an additional fenced
> interface to page flipping. To avoid adding additional interfaces on top of
> a legacy path, v2 scrapped those patches and changed i915 page flipping
> paths to wait on fences attached to DMA-BUF-backed fbs. Subsequent versions
> involve incremental changes outlined in the patch descriptions.
> 
> I have two patches, one that implements fencing for i915's legacy mmio_flip
> path, and one for atomic modesetting for futureproofing. Currently the
> mmio_flip path is the one ultimately used by the X patches, due to the lack
> of asynchronous atomic modesetting support in i915.
> 
> With my synchronization patches to X, it is possible to export two shared
> buffers per crtc instead of just one. The sink driver uses the legacy
> drmModePageFlip() to flip between the buffers, as the rest of the driver
> has yet to be ported to atomics. In the pageflip/vblank event handler, the
> sink driver requests a present from the source using the new X ABI function
> pScreen->PresentTrackedFlippingPixmap(). If the call returns successfully,
> it uses drmModePageFlip() to flip to the updated buffer, otherwise it waits
> until the next vblank and tries again.
> 
> When the source driver presents on a given buffer, it first attaches a
> fence.  The source driver is responsible for either using software
> signaling or hardware semaphore-backed fences to ensure the fence is
> signaled when the present is finished. If the sink's DRM driver implements
> fencing in the flipping path, it will guarantee that that flip won't occur
> until the present has finished.
> 
> This means that DRM drivers that don't implement fencing in their flipping
> paths won't be able to guarantee 100% tear-free PRIME with my X patches.
> However, the good news is that even without fencing, tearing is rare.
> Generally presenting finishes before the next vblank, so there is no need
> to wait on the fence. The X patches are a drastic improvement with or
> without fencing, but the fencing is nonetheless important to guarantee
> tear-free under all conditions.
> 
> To give some greater context, I've uploaded my branches for DRM and the X
> server to Github. I'll move forward with upstreaming the X changes if and
> when these DRM patches go in.
> 
> DRM Tree:https://github.com/GoinsWithTheWind/drm-prime-sync
> X Tree:  https://github.com/GoinsWithTheWind/xserver-prime-sync
> 
> (branch agoins-prime-v8)
> 
> Thanks, Alex @ NVIDIA Linux Driver Team
> 
> Alex Goins (2):
>   i915: wait for fence in mmio_flip_work_func
>   i915: wait for fence in prepare_plane_fb
> 
>  drivers/gpu/drm/i915/intel_display.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> -- 
> 1.9.1
> 
>

[PATCH 14/14] drm/i915: Add debug prints for encoder modeset hooks

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

To get a better idea where exactly some error occurred during modeset,
put in some debug prints to tell us when the variuous encoder hooks are
getting called.

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 58 +---
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f302d4af3c05..4904207a7c32 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4866,6 +4866,15 @@ static void intel_crtc_disable_planes(struct drm_crtc 
*crtc, unsigned plane_mask
intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_ALL_MASK(pipe));
 }

+#define intel_call_encoder_func(encoder, func) \
+do { \
+   if (!(encoder)->func) \
+   break; \
+   DRM_DEBUG_KMS("%s " #func " start\n", (encoder)->base.name); \
+   (encoder)->func(encoder); \
+   DRM_DEBUG_KMS("%s " #func " end\n", (encoder)->base.name); \
+} while (0)
+
 static void ironlake_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
@@ -4900,8 +4909,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);

for_each_encoder_on_crtc(dev, crtc, encoder)
-   if (encoder->pre_enable)
-   encoder->pre_enable(encoder);
+   intel_call_encoder_func(encoder, pre_enable);

if (intel_crtc->config->has_pch_encoder) {
/* Note: FDI PLL enabling _must_ be done before we enable the
@@ -4931,7 +4939,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);

for_each_encoder_on_crtc(dev, crtc, encoder)
-   encoder->enable(encoder);
+   intel_call_encoder_func(encoder, enable);

if (HAS_PCH_CPT(dev))
cpt_verify_modeset(dev, intel_crtc->pipe);
@@ -4996,10 +5004,8 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
else
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);

-   for_each_encoder_on_crtc(dev, crtc, encoder) {
-   if (encoder->pre_enable)
-   encoder->pre_enable(encoder);
-   }
+   for_each_encoder_on_crtc(dev, crtc, encoder)
+   intel_call_encoder_func(encoder, pre_enable);

if (intel_crtc->config->has_pch_encoder)
dev_priv->display.fdi_link_train(crtc);
@@ -5035,7 +5041,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);

for_each_encoder_on_crtc(dev, crtc, encoder) {
-   encoder->enable(encoder);
+   intel_call_encoder_func(encoder, enable);
intel_opregion_notify_encoder(encoder, true);
}

@@ -5085,7 +5091,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);

for_each_encoder_on_crtc(dev, crtc, encoder)
-   encoder->disable(encoder);
+   intel_call_encoder_func(encoder, disable);

drm_crtc_vblank_off(crtc);
assert_vblank_disabled(crtc);
@@ -5108,8 +5114,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
}

for_each_encoder_on_crtc(dev, crtc, encoder)
-   if (encoder->post_disable)
-   encoder->post_disable(encoder);
+   intel_call_encoder_func(encoder, post_disable);

if (intel_crtc->config->has_pch_encoder) {
ironlake_disable_pch_transcoder(dev_priv, pipe);
@@ -5154,7 +5159,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)

for_each_encoder_on_crtc(dev, crtc, encoder) {
intel_opregion_notify_encoder(encoder, false);
-   encoder->disable(encoder);
+   intel_call_encoder_func(encoder, disable);
}

drm_crtc_vblank_off(crtc);
@@ -5177,8 +5182,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
intel_ddi_disable_pipe_clock(intel_crtc);

for_each_encoder_on_crtc(dev, crtc, encoder)
-   if (encoder->post_disable)
-   encoder->post_disable(encoder);
+   intel_call_encoder_func(encoder, post_disable);

if (intel_crtc->config->has_pch_encoder) {
lpt_disable_pch_transcoder(dev_priv);
@@ -6200,8 +6204,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);

for_each_encoder_on_crtc(dev, crtc, encoder)
-   if (encoder->pre_pll_enable)
-   encoder->pre_pll_enable(encoder);
+   intel_call_encoder_func(encoder, pre_pll_enable);

if (!intel_crtc->config->has_dsi_encoder) {
if (IS_CHERRYVIEW(dev)) {
@@ -6214,8 +6217,7 @@ stat

[PATCH 13/14] drm/i915: Give encoders useful names

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Rather than let the core generate usless encoder names, let's pass in
something that actually identifies the piece of hardware we're dealing
with.

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_crt.c|  2 +-
 drivers/gpu/drm/i915/intel_ddi.c|  2 +-
 drivers/gpu/drm/i915/intel_dp.c |  2 +-
 drivers/gpu/drm/i915/intel_dp_mst.c |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c| 15 ++-
 drivers/gpu/drm/i915/intel_dvo.c| 18 --
 drivers/gpu/drm/i915/intel_hdmi.c   |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_tv.c |  2 +-
 10 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 9c89df1af036..2c5fbd06b470 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -824,7 +824,7 @@ void intel_crt_init(struct drm_device *dev)
   &intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);

drm_encoder_init(dev, &crt->base.base, &intel_crt_enc_funcs,
-DRM_MODE_ENCODER_DAC, NULL);
+DRM_MODE_ENCODER_DAC, "CRT");

intel_connector_attach_encoder(intel_connector, &crt->base);

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b0b1a4838cea..39c1e7149c05 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3290,7 +3290,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
encoder = &intel_encoder->base;

drm_encoder_init(dev, encoder, &intel_ddi_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));

intel_encoder->compute_config = intel_ddi_compute_config;
intel_encoder->enable = intel_enable_ddi;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0f0573aa1b0d..b0c5944a6f45 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5989,7 +5989,7 @@ intel_dp_init(struct drm_device *dev,
encoder = &intel_encoder->base;

drm_encoder_init(dev, &intel_encoder->base, &intel_dp_enc_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+DRM_MODE_ENCODER_TMDS, "DP %c", port_name(port));

intel_encoder->compute_config = intel_dp_compute_config;
intel_encoder->disable = intel_disable_dp;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index e8d369d0a713..032882c2d693 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -536,7 +536,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port 
*intel_dig_port, enum
intel_mst->primary = intel_dig_port;

drm_encoder_init(dev, &intel_encoder->base, &intel_dp_mst_enc_funcs,
-DRM_MODE_ENCODER_DPMST, NULL);
+DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));

intel_encoder->type = INTEL_OUTPUT_DP_MST;
intel_encoder->crtc_mask = 0x7;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index fff9a66c32a1..9b064a15a8e2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -,6 +,19 @@ static const struct drm_connector_funcs 
intel_dsi_connector_funcs = {
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
 };

+static char intel_dsi_port_name(const struct drm_i915_private *dev_priv)
+{
+   switch (dev_priv->vbt.dsi.port) {
+   case DVO_PORT_MIPIA:
+   return 'A';
+   case DVO_PORT_MIPIC:
+   return 'C';
+   default:
+   MISSING_CASE(dev_priv->vbt.dsi.port);
+   return '?';
+   }
+}
+
 void intel_dsi_init(struct drm_device *dev)
 {
struct intel_dsi *intel_dsi;
@@ -1153,7 +1166,7 @@ void intel_dsi_init(struct drm_device *dev)
connector = &intel_connector->base;

drm_encoder_init(dev, encoder, &intel_dsi_funcs, DRM_MODE_ENCODER_DSI,
-NULL);
+"MIPI %c", intel_dsi_port_name(dev_priv));

intel_encoder->compute_config = intel_dsi_compute_config;
intel_encoder->pre_enable = intel_dsi_pre_enable;
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 286baec979c8..a456f2eb68b6 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -406,6 +406,18 @@ intel_dvo_get_current_mode(struct drm_connector *connector)
return mode;
 }

+static char intel_dvo_port_name(i915_reg_t dvo_reg)
+{
+   if (i915_mmio_reg_equal(dvo_reg, DVOA))
+   return 'A';
+   else if (i915_mmio_reg_equal(dvo_reg, DVOB))
+   return 'B';
+   else i

[PATCH v3 12/14] drm/i915: Give meaningful names to all the planes

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Let's name our planes in a way that makes sense wrt. the spec:
- skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc.
- g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc.
- pre-g4x -> "plane A", "cursor B" etc.

v2: Rebase on top of the fixed/cleaned error paths
Use a local 'name' variable to make things easier
v3: Pass the name as a function argument to drm_universal_plane_init() (Jani)
v3: Pass the printf style string to drm_universal_plane_init()

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 25 -
 drivers/gpu/drm/i915/intel_sprite.c  | 16 
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b96fb1b77a70..f302d4af3c05 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14023,10 +14023,24 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
num_formats = ARRAY_SIZE(i8xx_primary_formats);
}

-   ret = drm_universal_plane_init(dev, &primary->base, 0,
-  &intel_plane_funcs,
-  intel_primary_formats, num_formats,
-  DRM_PLANE_TYPE_PRIMARY, NULL);
+   if (INTEL_INFO(dev)->gen >= 9)
+   ret = drm_universal_plane_init(dev, &primary->base, 0,
+  &intel_plane_funcs,
+  intel_primary_formats, 
num_formats,
+  DRM_PLANE_TYPE_PRIMARY,
+  "plane 1%c", pipe_name(pipe));
+   else if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
+   ret = drm_universal_plane_init(dev, &primary->base, 0,
+  &intel_plane_funcs,
+  intel_primary_formats, 
num_formats,
+  DRM_PLANE_TYPE_PRIMARY,
+  "primary %c", pipe_name(pipe));
+   else
+   ret = drm_universal_plane_init(dev, &primary->base, 0,
+  &intel_plane_funcs,
+  intel_primary_formats, 
num_formats,
+  DRM_PLANE_TYPE_PRIMARY,
+  "plane %c", 
plane_name(primary->plane));
if (ret)
goto fail;

@@ -14172,7 +14186,8 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
   &intel_plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
-  DRM_PLANE_TYPE_CURSOR, NULL);
+  DRM_PLANE_TYPE_CURSOR,
+  "cursor %c", pipe_name(pipe));
if (ret)
goto fail;

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index e89896336673..199c69d7b89d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1125,10 +1125,18 @@ intel_plane_init(struct drm_device *dev, enum pipe 
pipe, int plane)

possible_crtcs = (1 << pipe);

-   ret = drm_universal_plane_init(dev, &intel_plane->base, possible_crtcs,
-  &intel_plane_funcs,
-  plane_formats, num_plane_formats,
-  DRM_PLANE_TYPE_OVERLAY, NULL);
+   if (INTEL_INFO(dev)->gen >= 9)
+   ret = drm_universal_plane_init(dev, &intel_plane->base, 
possible_crtcs,
+  &intel_plane_funcs,
+  plane_formats, num_plane_formats,
+  DRM_PLANE_TYPE_OVERLAY,
+  "plane %d%c", plane + 2, 
pipe_name(pipe));
+   else
+   ret = drm_universal_plane_init(dev, &intel_plane->base, 
possible_crtcs,
+  &intel_plane_funcs,
+  plane_formats, num_plane_formats,
+  DRM_PLANE_TYPE_OVERLAY,
+  "sprite %c", sprite_name(pipe, 
plane));
if (ret)
goto fail;

-- 
2.4.10

[PATCH 11/14] drm/i915: Don't leak primary/cursor planes on crtc init failure

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Call intel_plane_destroy() instead of drm_plane_cleanup() so that we
also free the plane struct itself when bailing out of the crtc init.

And make intel_plane_destroy() NULL tolerant to avoid having to check
for it in the caller.

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8f1e8d73416e..b96fb1b77a70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13960,9 +13960,11 @@ static void intel_finish_crtc_commit(struct drm_crtc 
*crtc,
  */
 void intel_plane_destroy(struct drm_plane *plane)
 {
-   struct intel_plane *intel_plane = to_intel_plane(plane);
+   if (!plane)
+   return;
+
drm_plane_cleanup(plane);
-   kfree(intel_plane);
+   kfree(to_intel_plane(plane));
 }

 const struct drm_plane_funcs intel_plane_funcs = {
@@ -14295,10 +14297,8 @@ static void intel_crtc_init(struct drm_device *dev, 
int pipe)
return;

 fail:
-   if (primary)
-   drm_plane_cleanup(primary);
-   if (cursor)
-   drm_plane_cleanup(cursor);
+   intel_plane_destroy(primary);
+   intel_plane_destroy(cursor);
kfree(crtc_state);
kfree(intel_crtc);
 }
-- 
2.4.10

[PATCH v3 10/14] drm/i915: Fix plane init failure paths

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Deal with errors from drm_universal_plane_init() in primary and cursor
plane init paths (sprites were already covered). Also make the code
neater by using goto for error handling.

v2: Rebased due to drm_universal_plane_init() 'name' parameter
v3: Another rebase due to s/""/NULL/

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 64 ++--
 drivers/gpu/drm/i915/intel_sprite.c  | 34 +++
 2 files changed, 60 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9b604b117d3f..8f1e8d73416e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13980,20 +13980,19 @@ const struct drm_plane_funcs intel_plane_funcs = {
 static struct drm_plane *intel_primary_plane_create(struct drm_device *dev,
int pipe)
 {
-   struct intel_plane *primary;
-   struct intel_plane_state *state;
+   struct intel_plane *primary = NULL;
+   struct intel_plane_state *state = NULL;
const uint32_t *intel_primary_formats;
unsigned int num_formats;
+   int ret;

primary = kzalloc(sizeof(*primary), GFP_KERNEL);
-   if (primary == NULL)
-   return NULL;
+   if (!primary)
+   goto fail;

state = intel_create_plane_state(&primary->base);
-   if (!state) {
-   kfree(primary);
-   return NULL;
-   }
+   if (!state)
+   goto fail;
primary->base.state = &state->base;

primary->can_scale = false;
@@ -14022,10 +14021,12 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
num_formats = ARRAY_SIZE(i8xx_primary_formats);
}

-   drm_universal_plane_init(dev, &primary->base, 0,
-&intel_plane_funcs,
-intel_primary_formats, num_formats,
-DRM_PLANE_TYPE_PRIMARY, NULL);
+   ret = drm_universal_plane_init(dev, &primary->base, 0,
+  &intel_plane_funcs,
+  intel_primary_formats, num_formats,
+  DRM_PLANE_TYPE_PRIMARY, NULL);
+   if (ret)
+   goto fail;

if (INTEL_INFO(dev)->gen >= 4)
intel_create_rotation_property(dev, primary);
@@ -14033,6 +14034,12 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
drm_plane_helper_add(&primary->base, &intel_plane_helper_funcs);

return &primary->base;
+
+fail:
+   kfree(state);
+   kfree(primary);
+
+   return NULL;
 }

 void intel_create_rotation_property(struct drm_device *dev, struct intel_plane 
*plane)
@@ -14137,18 +14144,17 @@ update:
 static struct drm_plane *intel_cursor_plane_create(struct drm_device *dev,
   int pipe)
 {
-   struct intel_plane *cursor;
-   struct intel_plane_state *state;
+   struct intel_plane *cursor = NULL;
+   struct intel_plane_state *state = NULL;
+   int ret;

cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
-   if (cursor == NULL)
-   return NULL;
+   if (!cursor)
+   goto fail;

state = intel_create_plane_state(&cursor->base);
-   if (!state) {
-   kfree(cursor);
-   return NULL;
-   }
+   if (!state)
+   goto fail;
cursor->base.state = &state->base;

cursor->can_scale = false;
@@ -14160,11 +14166,13 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
cursor->commit_plane = intel_commit_cursor_plane;
cursor->disable_plane = intel_disable_cursor_plane;

-   drm_universal_plane_init(dev, &cursor->base, 0,
-&intel_plane_funcs,
-intel_cursor_formats,
-ARRAY_SIZE(intel_cursor_formats),
-DRM_PLANE_TYPE_CURSOR, NULL);
+   ret = drm_universal_plane_init(dev, &cursor->base, 0,
+  &intel_plane_funcs,
+  intel_cursor_formats,
+  ARRAY_SIZE(intel_cursor_formats),
+  DRM_PLANE_TYPE_CURSOR, NULL);
+   if (ret)
+   goto fail;

if (INTEL_INFO(dev)->gen >= 4) {
if (!dev->mode_config.rotation_property)
@@ -14184,6 +14192,12 @@ static struct drm_plane 
*intel_cursor_plane_create(struct drm_device *dev,
drm_plane_helper_add(&cursor->base, &intel_plane_helper_funcs);

return &cursor->base;
+
+fail:
+   kfree(state);
+   kfree(cursor);
+
+   return NULL;
 }

 static void skl_init_scalers(struct d

[PATCH v4 09/14] drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

v2: Fix intel_crtc leak on failure to allocate the name
Use a local 'name' variable to make things easier
v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani)
v4: Pass the printf style format string to drm_crtc_init_with_planes()

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8ea4ae72e939..9b604b117d3f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10862,7 +10862,6 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
}

drm_crtc_cleanup(crtc);
-
kfree(intel_crtc);
 }

@@ -14206,15 +14205,15 @@ static void skl_init_scalers(struct drm_device *dev, 
struct intel_crtc *intel_cr
 static void intel_crtc_init(struct drm_device *dev, int pipe)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc;
+   struct intel_crtc *intel_crtc = NULL;
struct intel_crtc_state *crtc_state = NULL;
struct drm_plane *primary = NULL;
struct drm_plane *cursor = NULL;
int i, ret;

intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
-   if (intel_crtc == NULL)
-   return;
+   if (!intel_crtc)
+   goto fail;

crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
if (!crtc_state)
@@ -14242,7 +14241,8 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
goto fail;

ret = drm_crtc_init_with_planes(dev, &intel_crtc->base, primary,
-   cursor, &intel_crtc_funcs, NULL);
+   cursor, &intel_crtc_funcs,
+   "pipe %c", pipe_name(pipe));
if (ret)
goto fail;

-- 
2.4.10

[PATCH 08/14] drm/i915: Use plane->name in debug prints

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 38 +---
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 39ee629cb403..8ea4ae72e939 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4472,9 +4472,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,

bool force_detach = !fb || !plane_state->visible;

-   DRM_DEBUG_KMS("Updating scaler for [PLANE:%d] scaler_user index 
%u.%u\n",
- intel_plane->base.base.id, intel_crtc->pipe,
- drm_plane_index(&intel_plane->base));
+   DRM_DEBUG_KMS("Updating scaler for [PLANE:%d:%s] scaler_user index 
%u.%u\n",
+ intel_plane->base.base.id, intel_plane->base.name,
+ intel_crtc->pipe, drm_plane_index(&intel_plane->base));

ret = skl_update_scaler(crtc_state, force_detach,
drm_plane_index(&intel_plane->base),
@@ -4490,8 +4490,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,

/* check colorkey */
if (plane_state->ckey.flags != I915_SET_COLORKEY_NONE) {
-   DRM_DEBUG_KMS("[PLANE:%d] scaling with color key not allowed",
- intel_plane->base.base.id);
+   DRM_DEBUG_KMS("[PLANE:%d:%s] scaling with color key not 
allowed",
+ intel_plane->base.base.id,
+ intel_plane->base.name);
return -EINVAL;
}

@@ -4510,8 +4511,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_VYUY:
break;
default:
-   DRM_DEBUG_KMS("[PLANE:%d] FB:%d unsupported scaling format 
0x%x\n",
-   intel_plane->base.base.id, fb->base.id, 
fb->pixel_format);
+   DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
+ intel_plane->base.base.id, intel_plane->base.name,
+ fb->base.id, fb->pixel_format);
return -EINVAL;
}

@@ -11836,13 +11838,15 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
turn_off = was_visible && (!visible || mode_changed);
turn_on = visible && (!was_visible || mode_changed);

-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] has [PLANE:%i] with fb %i\n",
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] has [PLANE:%d:%s] with fb %i\n",
 intel_crtc->base.base.id,
 intel_crtc->base.name,
-plane->base.id, fb ? fb->base.id : -1);
+plane->base.id, plane->name,
+fb ? fb->base.id : -1);

-   DRM_DEBUG_ATOMIC("[PLANE:%i] visible %i -> %i, off %i, on %i, ms %i\n",
-plane->base.id, was_visible, visible,
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] visible %i -> %i, off %i, on %i, ms 
%i\n",
+plane->base.id, plane->name,
+was_visible, visible,
 turn_off, turn_on, mode_changed);

if (turn_on || turn_off) {
@@ -12238,18 +12242,20 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
state = to_intel_plane_state(plane->state);
fb = state->base.fb;
if (!fb) {
-   DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d "
-   "disabled, scaler_id = %d\n",
+   DRM_DEBUG_KMS("%s [PLANE:%d:%s] plane: %u.%u idx: %d "
+ "disabled, scaler_id = %d\n",
plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" 
: "STANDARD",
-   plane->base.id, intel_plane->pipe,
+   plane->base.id, plane->name,
+   intel_plane->pipe,
(crtc->base.primary == plane) ? 0 : 
intel_plane->plane + 1,
drm_plane_index(plane), state->scaler_id);
continue;
}

-   DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d enabled",
+   DRM_DEBUG_KMS("%s [PLANE:%d:%s] plane: %u.%u idx: %d enabled",
plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" : 
"STANDARD",
-   plane->base.id, intel_plane->pipe,
+   plane->base.id, plane->name,
+   intel_plane->pipe,
crtc->base.primary == plane ? 0 : intel_plane->plane + 
1,
drm_plane_index(plane));
DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = 0x%x",
-- 
2.4.10

[PATCH 07/14] drm/i915: Use crtc->name in debug messages

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/i915/intel_display.c | 55 
 drivers/gpu/drm/i915/intel_fbdev.c   |  5 ++--
 2 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ee21f458c2b2..39ee629cb403 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4257,8 +4257,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
i = (enum intel_dpll_id) crtc->pipe;
pll = &dev_priv->shared_dplls[i];

-   DRM_DEBUG_KMS("CRTC:%d using pre-allocated %s\n",
- crtc->base.base.id, pll->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] using pre-allocated %s\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name);

WARN_ON(shared_dpll[i].crtc_mask);

@@ -4278,8 +4279,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
/* 1:1 mapping between ports and PLLs */
i = (enum intel_dpll_id)intel_dig_port->port;
pll = &dev_priv->shared_dplls[i];
-   DRM_DEBUG_KMS("CRTC:%d using pre-allocated %s\n",
-   crtc->base.base.id, pll->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] using pre-allocated %s\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name);
WARN_ON(shared_dpll[i].crtc_mask);

goto found;
@@ -4297,9 +4299,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
if (memcmp(&crtc_state->dpll_hw_state,
   &shared_dpll[i].hw_state,
   sizeof(crtc_state->dpll_hw_state)) == 0) {
-   DRM_DEBUG_KMS("CRTC:%d sharing existing %s (crtc mask 
0x%08x, ative %d)\n",
- crtc->base.base.id, pll->name,
- shared_dpll[i].crtc_mask,
+   DRM_DEBUG_KMS("[CRTC:%d:%s] sharing existing %s (crtc 
mask 0x%08x, ative %d)\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name, shared_dpll[i].crtc_mask,
  pll->active);
goto found;
}
@@ -4309,8 +4311,9 @@ struct intel_shared_dpll *intel_get_shared_dpll(struct 
intel_crtc *crtc,
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
pll = &dev_priv->shared_dplls[i];
if (shared_dpll[i].crtc_mask == 0) {
-   DRM_DEBUG_KMS("CRTC:%d allocated %s\n",
- crtc->base.base.id, pll->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] allocated %s\n",
+ crtc->base.base.id, crtc->base.name,
+ pll->name);
goto found;
}
}
@@ -4437,8 +4440,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
struct intel_crtc *intel_crtc = to_intel_crtc(state->base.crtc);
const struct drm_display_mode *adjusted_mode = 
&state->base.adjusted_mode;

-   DRM_DEBUG_KMS("Updating scaler for [CRTC:%i] scaler_user index %u.%u\n",
- intel_crtc->base.base.id, intel_crtc->pipe, 
SKL_CRTC_INDEX);
+   DRM_DEBUG_KMS("Updating scaler for [CRTC:%d:%s] scaler_user index 
%u.%u\n",
+ intel_crtc->base.base.id, intel_crtc->base.name,
+ intel_crtc->pipe, SKL_CRTC_INDEX);

return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
&state->scaler_state.scaler_id, DRM_ROTATE_0,
@@ -11800,13 +11804,13 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_plane_state *old_plane_state =
to_intel_plane_state(plane->state);
-   int idx = intel_crtc->base.base.id, ret;
int i = drm_plane_index(plane);
bool mode_changed = needs_modeset(crtc_state);
bool was_crtc_enabled = crtc->state->active;
bool is_crtc_enabled = crtc_state->active;
bool turn_off, turn_on, visible, was_visible;
struct drm_framebuffer *fb = plane_state->fb;
+   int ret;

if (crtc_state && INTEL_INFO(dev)->gen >= 9 &&
plane->type != DRM_PLANE_TYPE_CURSOR) {
@@ -11832,7 +11836,9 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
turn_off = was_visible && (!visible || mode_changed);
turn_on = visible && (!was_visible || mode_changed);

-   DRM_DEBUG_ATOMIC("[CRTC:%i] has [PLANE:%i] with fb %i\n", idx,
+   DRM_DEBUG_ATOM

[PATCH v3 06/14] drm: Add plane->name and use it in debug prints

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Show a sensible name for the plane in debug mesages. The driver
may supply its own name, otherwise the core genrates the name
("plane-0", "plane-1" etc.).

v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/drm_atomic.c| 12 ++--
 drivers/gpu/drm/drm_atomic_helper.c |  4 ++--
 drivers/gpu/drm/drm_crtc.c  | 30 ++
 include/drm/drm_crtc.h  |  2 ++
 4 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index feb66895e48c..6a21e5c378c1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -549,8 +549,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
state->planes[index] = plane;
plane_state->state = state;

-   DRM_DEBUG_ATOMIC("Added [PLANE:%d] %p state to %p\n",
-plane->base.id, plane_state, state);
+   DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
+plane->base.id, plane->name, plane_state, state);

if (plane_state->crtc) {
struct drm_crtc_state *crtc_state;
@@ -770,8 +770,8 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
}

if (plane_switching_crtc(state->state, plane, state)) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d] switching CRTC directly\n",
-plane->base.id);
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
+plane->base.id, plane->name);
return -EINVAL;
}

@@ -1248,8 +1248,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
for_each_plane_in_state(state, plane, plane_state, i) {
ret = drm_atomic_plane_check(plane, plane_state);
if (ret) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d] atomic core check 
failed\n",
-plane->base.id);
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic core check 
failed\n",
+plane->base.id, plane->name);
return ret;
}
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 6ba3fe5639e4..63f925b75357 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -545,8 +545,8 @@ drm_atomic_helper_check_planes(struct drm_device *dev,

ret = funcs->atomic_check(plane, plane_state);
if (ret) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d] atomic driver check 
failed\n",
-plane->base.id);
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic driver check 
failed\n",
+plane->base.id, plane->name);
return ret;
}
}
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ae2c6c5d48e9..9fe085b2efbf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1181,6 +1181,18 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 }
 EXPORT_SYMBOL(drm_encoder_cleanup);

+static unsigned int drm_num_planes(struct drm_device *dev)
+{
+   unsigned int num = 0;
+   struct drm_plane *tmp;
+
+   drm_for_each_plane(tmp, dev) {
+   num++;
+   }
+
+   return num;
+}
+
 /**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
@@ -1224,6 +1236,22 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
return -ENOMEM;
}

+   if (name) {
+   va_list ap;
+
+   va_start(ap, name);
+   plane->name = kvasprintf(GFP_KERNEL, name, ap);
+   va_end(ap);
+   } else {
+   plane->name = kasprintf(GFP_KERNEL, "plane-%d",
+   drm_num_planes(dev));
+   }
+   if (!plane->name) {
+   kfree(plane->format_types);
+   drm_mode_object_put(dev, &plane->base);
+   return -ENOMEM;
+   }
+
memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;
@@ -1314,6 +1342,8 @@ void drm_plane_cleanup(struct drm_plane *plane)
if (plane->state && plane->funcs->atomic_destroy_state)
plane->funcs->atomic_destroy_state(plane, plane->state);

+   kfree(plane->name);
+
memset(plane, 0, sizeof(*plane));
 }
 EXPORT_SYMBOL(drm_plane_cleanup);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 083b5d42c578..49885a2aef34 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h

[PATCH v3 05/14] drm: Add crtc->name and use it in debug messages

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Show a sensible name for the crtc in debug mesages. The driver may
supply its own name, otherwise the core genrates the name
("crtc-0", "crtc-1" etc.).

v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/drm_atomic.c| 41 ++-
 drivers/gpu/drm/drm_atomic_helper.c | 56 +++--
 drivers/gpu/drm/drm_crtc.c  | 34 --
 drivers/gpu/drm/drm_crtc_helper.c   | 24 
 include/drm/drm_crtc.h  |  2 ++
 5 files changed, 97 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 07ab75e22b2b..feb66895e48c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -288,8 +288,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
state->crtcs[index] = crtc;
crtc_state->state = state;

-   DRM_DEBUG_ATOMIC("Added [CRTC:%d] %p state to %p\n",
-crtc->base.id, crtc_state, state);
+   DRM_DEBUG_ATOMIC("Added [CRTC:%d:%s] %p state to %p\n",
+crtc->base.id, crtc->name, crtc_state, state);

return crtc_state;
 }
@@ -486,8 +486,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 */

if (state->active && !state->enable) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] active without enabled\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}

@@ -496,15 +496,15 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 * be able to trigger. */
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(state->enable && !state->mode_blob)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] enabled without mode blob\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}

if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(!state->enable && state->mode_blob)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] disabled with mode blob\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}

@@ -1004,8 +1004,8 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state 
*plane_state,
}

if (crtc)
-   DRM_DEBUG_ATOMIC("Link plane state %p to [CRTC:%d]\n",
-plane_state, crtc->base.id);
+   DRM_DEBUG_ATOMIC("Link plane state %p to [CRTC:%d:%s]\n",
+plane_state, crtc->base.id, crtc->name);
else
DRM_DEBUG_ATOMIC("Link plane state %p to [NOCRTC]\n",
 plane_state);
@@ -1072,8 +1072,8 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
conn_state->crtc = crtc;

if (crtc)
-   DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d]\n",
-conn_state, crtc->base.id);
+   DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d:%s]\n",
+conn_state, crtc->base.id, crtc->name);
else
DRM_DEBUG_ATOMIC("Link connector state %p to [NOCRTC]\n",
 conn_state);
@@ -1112,8 +1112,8 @@ drm_atomic_add_affected_connectors(struct 
drm_atomic_state *state,
if (ret)
return ret;

-   DRM_DEBUG_ATOMIC("Adding all current connectors for [CRTC:%d] to %p\n",
-crtc->base.id, state);
+   DRM_DEBUG_ATOMIC("Adding all current connectors for [CRTC:%d:%s] to 
%p\n",
+crtc->base.id, crtc->name, state);

/*
 * Changed connectors are already in @state, so only need to look at the
@@ -1193,8 +1193,9 @@ drm_atomic_connectors_for_crtc(struct drm_atomic_state 
*state,
num_connected_connectors++;
}

-   DRM_DEBUG_ATOMIC("State %p has %i connectors for [CRTC:%d]\n",
-state, num_connected_connectors, crtc->base.id);
+   DRM_DEBUG_ATOMIC("State %p has %i connectors for [CRTC:%d:%s]\n",
+state, num_connected_connectors,
+crtc->base.id, crtc->name);

return num_connected_connectors;
 }
@@ -1256,8 +1257,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
for_each_crtc_in_state(state, crtc, crtc_state, i) {
ret

[PATCH 04/14] drm: Use driver specified encoder name

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Use the encoder name passed by the driver if non-NULL, otherwise fall
back to the old style name.

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/drm_crtc.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3efff5dfe4f6..4bdfa5d31a6c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1101,9 +1101,17 @@ int drm_encoder_init(struct drm_device *dev,
encoder->dev = dev;
encoder->encoder_type = encoder_type;
encoder->funcs = funcs;
-   encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
- drm_encoder_enum_list[encoder_type].name,
- encoder->base.id);
+   if (name) {
+   va_list ap;
+
+   va_start(ap, name);
+   encoder->name = kvasprintf(GFP_KERNEL, name, ap);
+   va_end(ap);
+   } else {
+   encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
+ 
drm_encoder_enum_list[encoder_type].name,
+ encoder->base.id);
+   }
if (!encoder->name) {
ret = -ENOMEM;
goto out_put;
-- 
2.4.10

[PATCH 03/14] drm: Pass 'name' to drm_encoder_init()

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.

@@
identifier dev, encoder, funcs;
@@
 int drm_encoder_init(struct drm_device *dev,
  struct drm_encoder *encoder,
  const struct drm_encoder_funcs *funcs,
  int encoder_type
+ ,const char *name, int DOTDOTDOT
  )
{ ... }

@@
identifier dev, encoder, funcs;
@@
 int drm_encoder_init(struct drm_device *dev,
  struct drm_encoder *encoder,
  const struct drm_encoder_funcs *funcs,
  int encoder_type
+ ,const char *name, int DOTDOTDOT
  );

@@
expression E1, E2, E3, E4;
@@
 drm_encoder_init(E1, E2, E3, E4
+ ,NULL
  )

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   | 14 +--
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   | 14 +--
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 14 +--
 drivers/gpu/drm/ast/ast_mode.c   |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  2 +-
 drivers/gpu/drm/bochs/bochs_kms.c|  2 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c |  2 +-
 drivers/gpu/drm/drm_crtc.c   |  3 ++-
 drivers/gpu/drm/exynos/exynos_dp_core.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c|  2 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c   |  2 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c|  3 ++-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c  |  2 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c  |  2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c   |  2 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c   |  2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c   |  2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c  |  2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c  |  3 ++-
 drivers/gpu/drm/i2c/tda998x_drv.c|  2 +-
 drivers/gpu/drm/i915/intel_crt.c |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/intel_dp_mst.c  |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c |  3 ++-
 drivers/gpu/drm/i915/intel_dvo.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
 drivers/gpu/drm/i915/intel_lvds.c|  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c|  3 ++-
 drivers/gpu/drm/i915/intel_tv.c  |  2 +-
 drivers/gpu/drm/imx/dw_hdmi-imx.c|  2 +-
 drivers/gpu/drm/imx/imx-ldb.c|  2 +-
 drivers/gpu/drm/imx/imx-tve.c|  2 +-
 drivers/gpu/drm/imx/parallel-display.c   |  2 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/dac.c   |  3 ++-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c|  3 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c|  3 ++-
 drivers/gpu/drm/nouveau/nv50_display.c   |  6 ++---
 drivers/gpu/drm/omapdrm/omap_encoder.c   |  2 +-
 drivers/gpu/drm/qxl/qxl_display.c|  2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c   | 30 
 drivers/gpu/drm/radeon/radeon_dp_mst.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c  | 15 
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c|  2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c  |  2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c|  2 +-
 drivers/gpu/drm/sti/sti_tvout.c  |  7 +++---
 drivers/gpu/drm/tegra/dsi.c  |  2 +-
 drivers/gpu/drm/tegra/hdmi.c |  2 +-
 drivers/gpu/drm/tegra/rgb.c  |  2 +-
 drivers/gpu/drm/tegra/sor.c  |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  2 +-
 drivers/gpu/drm/udl/udl_encoder.c|  3 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.c   |  2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c

[PATCH v2 02/14] drm: Pass 'name' to drm_universal_plane_init()

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Done with coccinelle for the most part. It choked on
msm/mdp/mdp5/mdp5_plane.c like so:
"BAD:!  enum drm_plane_type type;"
No idea how to deal with that, so I just fixed that up
by hand.

Also it thinks '...' is part of the semantic patch, so I put an
'int DOTDOTDOT' placeholder in its place and got rid of it with
sed afterwards.

I didn't convert drm_plane_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.

@@
typedef uint32_t;
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
  const uint32_t *formats,
  unsigned int format_count,
  enum drm_plane_type type
+ ,const char *name, int DOTDOTDOT
  )
{ ... }

@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
  const uint32_t *formats,
  unsigned int format_count,
  enum drm_plane_type type
+ ,const char *name, int DOTDOTDOT
  );

@@
expression E1, E2, E3, E4, E5, E6, E7;
@@
 drm_universal_plane_init(E1, E2, E3, E4, E5, E6, E7
+ ,NULL
  )

v2: Split crtc and plane changes apart
Pass NUL for no-name instead of ""
Leave drm_plane_init() alone

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/armada/armada_crtc.c| 2 +-
 drivers/gpu/drm/armada/armada_overlay.c | 2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
 drivers/gpu/drm/drm_crtc.c  | 6 --
 drivers/gpu/drm/drm_plane_helper.c  | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c   | 2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +-
 drivers/gpu/drm/i915/intel_display.c| 4 ++--
 drivers/gpu/drm/i915/intel_sprite.c | 2 +-
 drivers/gpu/drm/imx/ipuv3-plane.c   | 3 ++-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   | 3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c| 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 drivers/gpu/drm/sti/sti_cursor.c| 2 +-
 drivers/gpu/drm/sti/sti_gdp.c   | 2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
 drivers/gpu/drm/tegra/dc.c  | 9 ++---
 drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  | 2 +-
 include/drm/drm_crtc.h  | 3 ++-
 22 files changed, 36 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index c3f3a7031bb1..9bdc28cf927e 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1216,7 +1216,7 @@ static int armada_drm_crtc_create(struct drm_device *drm, 
struct device *dev,
   &armada_primary_plane_funcs,
   armada_primary_formats,
   ARRAY_SIZE(armada_primary_formats),
-  DRM_PLANE_TYPE_PRIMARY);
+  DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
kfree(primary);
return ret;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 5c22b380f8f3..148e8a42b2c6 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -460,7 +460,7 @@ int armada_overlay_plane_create(struct drm_device *dev, 
unsigned long crtcs)
   &armada_ovl_plane_funcs,
   armada_ovl_formats,
   ARRAY_SIZE(armada_ovl_formats),
-  DRM_PLANE_TYPE_OVERLAY);
+  DRM_PLANE_TYPE_OVERLAY, NULL);
if (ret) {
kfree(dplane);
return ret;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index d0299aed517e..1ffe9c329c46 100644
--- a/drivers/gpu/

[PATCH v2 01/14] drm: Pass 'name' to drm_crtc_init_with_planes()

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.

I didn't convert drm_crtc_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.

@@
identifier dev, crtc, primary, cursor, funcs;
@@
 int drm_crtc_init_with_planes(struct drm_device *dev,
   struct drm_crtc *crtc,
   struct drm_plane *primary, struct drm_plane 
*cursor,
   const struct drm_crtc_funcs *funcs
+  ,const char *name, int DOTDOTDOT
   )
{ ... }

@@
identifier dev, crtc, primary, cursor, funcs;
@@
 int drm_crtc_init_with_planes(struct drm_device *dev,
   struct drm_crtc *crtc,
   struct drm_plane *primary, struct drm_plane 
*cursor,
   const struct drm_crtc_funcs *funcs
+  ,const char *name, int DOTDOTDOT
   );

@@
expression E1, E2, E3, E4, E5;
@@
 drm_crtc_init_with_planes(E1, E2, E3, E4, E5
+  ,NULL
   )

v2: Split crtc and plane changes apart
Pass NULL for no-name instead of ""
Leave drm_crtc_init() alone

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/armada/armada_crtc.c   | 2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 drivers/gpu/drm/drm_crtc.c | 4 +++-
 drivers/gpu/drm/drm_plane_helper.c | 3 ++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 2 +-
 drivers/gpu/drm/i915/intel_display.c   | 2 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   | 3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   | 3 ++-
 drivers/gpu/drm/omapdrm/omap_crtc.c| 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 2 +-
 drivers/gpu/drm/sti/sti_crtc.c | 2 +-
 drivers/gpu/drm/tegra/dc.c | 2 +-
 drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c   | 2 +-
 include/drm/drm_crtc.h | 3 ++-
 18 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index cebcab560626..c3f3a7031bb1 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1223,7 +1223,7 @@ static int armada_drm_crtc_create(struct drm_device *drm, 
struct device *dev,
}

ret = drm_crtc_init_with_planes(drm, &dcrtc->crtc, &primary->base, NULL,
-   &armada_crtc_funcs);
+   &armada_crtc_funcs, NULL);
if (ret)
goto err_crtc_init;

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9f6e234e7029..468a14f266a7 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -344,7 +344,7 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
ret = drm_crtc_init_with_planes(dev, &crtc->base,
&planes->primary->base,
planes->cursor ? &planes->cursor->base : NULL,
-   &atmel_hlcdc_crtc_funcs);
+   &atmel_hlcdc_crtc_funcs, NULL);
if (ret < 0)
goto fail;

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 99e7efebedda..62306d336d0d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -657,6 +657,7 @@ DEFINE_WW_CLASS(crtc_ww_class);
  * @primary: Primary plane for CRTC
  * @cursor: Cursor plane for CRTC
  * @funcs: callbacks for the new CRTC
+ * @name: printf style format string for the CRTC name
  *
  * Inits a new object created as base part of a driver crtc object.
  *
@@ -666,7 +667,8 @@ DEFINE_WW_CLASS(crtc_ww_class);
 int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_plane *primary,
  struct drm_plane *cursor,
- const struct drm_crtc_funcs *funcs)
+ const struct drm_crtc_funcs *funcs,
+ const char *name, ...)
 {
struct drm_mode_config *config = &dev->mode_config;
int ret;
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 8455e996dd9c..f5a4273e71b5 100644
--- a/drivers/gpu/drm/drm

[PATCH v4 00/14] drm: Give crtcs and planes actual names (v4)

2015-12-08 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

I've done some more modeset log staring recently and again got
fed up with the noise. So here's another attempt at making the
logs make some sense.

This time I pass a printf style format string to the init functions, so
that callers don't have to worry about any snprintf buffers or memory
allocation.

Also if the caller passes in NULL, the core will fill out some kind of
default value ("crtc-%d", "plane-%d", etc.).

I also made it possible for drivers to supply the name for encoders.
Eg. "HDMI B" tells me much more on intel hardware than "TMDS-".

Previous attempts:
http://lists.freedesktop.org/archives/dri-devel/2015-November/094331.html
http://lists.freedesktop.org/archives/dri-devel/2015-November/094359.html
http://lists.freedesktop.org/archives/dri-devel/2015-November/094425.html

Entire series available here:
git://github.com/vsyrjala/linux.git crtc_plane_name_4

Ville SyrjÃ¤lÃ¤ (14):
  drm: Pass 'name' to drm_crtc_init_with_planes()
  drm: Pass 'name' to drm_universal_plane_init()
  drm: Pass 'name' to drm_encoder_init()
  drm: Use driver specified encoder name
  drm: Add crtc->name and use it in debug messages
  drm: Add plane->name and use it in debug prints
  drm/i915: Use crtc->name in debug messages
  drm/i915: Use plane->name in debug prints
  drm/i915: Set crtc->name to "pipe A", "pipe B", etc.
  drm/i915: Fix plane init failure paths
  drm/i915: Don't leak primary/cursor planes on crtc init failure
  drm/i915: Give meaningful names to all the planes
  drm/i915: Give encoders useful names
  drm/i915: Add debug prints for encoder modeset hooks

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  14 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  14 +-
 drivers/gpu/drm/armada/armada_crtc.c |   4 +-
 drivers/gpu/drm/armada/armada_overlay.c  |   2 +-
 drivers/gpu/drm/ast/ast_mode.c   |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  |   2 +-
 drivers/gpu/drm/bochs/bochs_kms.c|   2 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c |   2 +-
 drivers/gpu/drm/drm_atomic.c |  53 ++---
 drivers/gpu/drm/drm_atomic_helper.c  |  60 +++---
 drivers/gpu/drm/drm_crtc.c   |  91 -
 drivers/gpu/drm/drm_crtc_helper.c|  24 ++-
 drivers/gpu/drm/drm_plane_helper.c   |   5 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c  |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c |   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c   |   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c  |   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c|   2 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c   |   2 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c|   3 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c  |   2 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c  |   2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c   |   2 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c   |   2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c   |   2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c  |   2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c  |   3 +-
 drivers/gpu/drm/i2c/tda998x_drv.c|   2 +-
 drivers/gpu/drm/i915/intel_crt.c |   2 +-
 drivers/gpu/drm/i915/intel_ddi.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c | 250 +--
 drivers/gpu/drm/i915/intel_dp.c  |   2 +-
 drivers/gpu/drm/i915/intel_dp_mst.c  |   2 +-
 drivers/gpu/drm/i915/intel_dsi.c |  16 +-
 drivers/gpu/drm/i915/intel_dvo.c |  18 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |   5 +-
 drivers/gpu/drm/i915/intel_hdmi.c|   2 +-
 drivers/gpu/drm/i915/intel_lvds.c|   2 +-
 drivers/gpu/drm/i915/intel_sdvo.c|   3 +-
 drivers/gpu/drm/i915/intel_sprite.c  |  50 +++--
 drivers/gpu/drm/i915/intel_tv.c  |   2 +-
 drivers/gpu/drm/imx/dw_hdmi-imx.c|   2 +-
 drivers/gpu/drm/imx/imx-drm-core.c   |   2 +-
 drivers/gpu/drm/imx/imx-ldb.c|   2 +-
 drivers/gpu/drm/imx/imx-tve.c|   2 +-
 drivers/gpu/drm/imx/ipuv3-plane.c|   3 +-
 drivers/gpu/drm/imx/parallel-display.c   |   2 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c

Implementing Miracast?

2015-12-08 Thread Martin Peres

On 08/12/15 13:59, David Herrmann wrote:
> Hi
>
> On Fri, Dec 4, 2015 at 9:07 AM, Daniel Vetter  wrote:
>> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>>> You are right Ilia, this is indeed what Jaakko and I had in mind, but they
>>> did not re-use the fuse/cuse framework to do the serialization of the
>>> ioctls.
>>>
>>> Not sure what we can do against allowing proprietary drivers to use this
>>> feature though :s To be fair, nothing prevents any vendor to do this shim
>>> themselves and nvidia definitely did it, and directly called their
>>> closed-source driver.
>>>
>>> Any proposition on how to handle this case? I guess we could limit that to
>>> screens only, no rendering. That would block any serious GPU manufacturer
>>> from using this code even if any sane person would never write a driver in
>>> the userspace...
>> Hm for virtual devices like this I figured there's no point exporting the
>> full kms api to userspace, but instead we'd just need a simple kms driver
>> with just 1 crtc and 1 connector per drm_device. Plus a special device
>> node (v4l is probably inappropriate since it doesn't do damage) where the
>> miracast userspace can receive events with just the following information:
>> - virtual screen size
>> - fd to the underlying shmem node for the current fb. Or maybe a dma-buf
>>(but then we'd need the dma-buf mmap stuff to land first).
>> - damage tracking
>>
>> If we want fancy, we could allow userspace to reply (through an ioctl)
>> when it's done reading the previous image, which the kernel could then
>> forward as vblank complete events.
>>
>> Connector configuration could be done by forcing the outputs (we'll send
>> out uevents nowadays for that), so the only thing we need is some configfs
>> to instantiate new copies of this.
>>
>> At least for miracst (as opposed to full-blown hw drivers in userspace) I
>> don't think we need to export everything.
> I looked into all this when working on WFD, but I cannot recommend
> going down that road. First of all, you still need heavy modifications
> for gnome-shell, kwin, and friends, as neither of them supports
> seamless drm-device hotplugging.

That would still be needed for USB GPUs though. Seems like metacity had 
no probs
in 2011, but no idea how heavily patched it was:
https://www.youtube.com/watch?v=g54y80blzRU

Airlied?

> Hence, providing more devices than
> the main GPU just confuses them. Secondly, you really don't win much
> by re-using DRM for all that. On the contrary, you get very heavy
> overhead, need to feed all this through limited ioctl interfaces, and
> fake DRM crtcs/encoders/connectors, when all you really have is an
> mpeg stream.
The overhead is just at init time, is that really relevant? The only 
added cost
could then be the page flip ioctl which is not really relevant again 
since it is only up
to 60 times per second in usual monitors.

> I wouldn't mind if anyone writes a virtual DRM interface, it'd be
> really great for automated testing. However, if you want your
> wifi-display (or whatever else) integrated into desktop environments,
> then I recommend teaching those environments to accept gstreamer sinks
> as outputs.

That is a fair proposal but that requires a lot more work for 
compositors than
waiting for drm udev events and reusing all the existing infrastructure 
for DRM
to drive the new type of display.

I guess there are benefits to being able to output to a gstreamer 
backend, but
the drm driver we propose could do just that without having to ask for a 
lot of
new code, especially code that is already necessary for handling USB GPUs.
Moreover, the gstreamer backend would not be registered as a screen by X 
which
means that games may not be able to set themselves fullscreen on this 
screen only.

I am open to the idea of having compositors render to a gstreamer 
backend, but
I never worked with gstreamer myself so I have no clue about how suited 
it is for
output management (resolution, refresh rate) and there is the added 
difficulty of
the X model not working well with this approach. We will have a look at 
this though.

Martin

[PATCH] drm/omap: fix fbdev pix format to support all platforms

2015-12-08 Thread Tomi Valkeinen

omap_fbdev always creates a framebuffer with ARGB pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
OMAP2 none of the overlays support ARGB888.

This patch changes the omap_fbdev's fb to XRGB, which is supported
by all platforms.

Signed-off-by: Tomi Valkeinen 

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..24f92bea39c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
dma_addr_t paddr;
int ret;

-   /* only doing ARGB32 since this is what is needed to alpha-blend
-* with video overlays:
-*/
sizes->surface_bpp = 32;
-   sizes->surface_depth = 32;
+   sizes->surface_depth = 24;

DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
sizes->surface_height, sizes->surface_bpp,

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:

Implementing Miracast?

2015-12-08 Thread David Herrmann

Hi

On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres  wrote:
> On 08/12/15 13:59, David Herrmann wrote:
>> I looked into all this when working on WFD, but I cannot recommend
>> going down that road. First of all, you still need heavy modifications
>> for gnome-shell, kwin, and friends, as neither of them supports
>> seamless drm-device hotplugging.
>
>
> That would still be needed for USB GPUs though. Seems like metacity had no
> probs
> in 2011, but no idea how heavily patched it was:
> https://www.youtube.com/watch?v=g54y80blzRU
>
> Airlied?

Yes, Xorg has offload-sinks. But if you target Xorg, then you can just
as well implement user-space sinks in Xorg, and you're done. But given
that you talk about "compositors" here, I assume you're targeting
wayland compositors. Otherwise, there is really nothing to implement
in Gnome and friends to make external displays work. Supporting it in
Xorg would be enough.

Long story short: offload-sinks like UDL only work properly if you use
Xorg (if my information is outdated, please correct me, but I haven't
seen any multi-display-controller-support in clutter or kwin or even
weston).

>> Hence, providing more devices than
>> the main GPU just confuses them. Secondly, you really don't win much
>> by re-using DRM for all that. On the contrary, you get very heavy
>> overhead, need to feed all this through limited ioctl interfaces, and
>> fake DRM crtcs/encoders/connectors, when all you really have is an
>> mpeg stream.
>
> The overhead is just at init time, is that really relevant? The only added
> cost
> could then be the page flip ioctl which is not really relevant again since
> it is only up
> to 60 times per second in usual monitors.

This is not so much about overhead, but API constraints. Putting stuff
into the kernel just places arbitrary constraints on your
implementation, when you don't have any real gain.

>> I wouldn't mind if anyone writes a virtual DRM interface, it'd be
>> really great for automated testing. However, if you want your
>> wifi-display (or whatever else) integrated into desktop environments,
>> then I recommend teaching those environments to accept gstreamer sinks
>> as outputs.
>
>
> That is a fair proposal but that requires a lot more work for compositors
> than
> waiting for drm udev events and reusing all the existing infrastructure for
> DRM
> to drive the new type of display.

This is not true. Again, I haven't seen any multi-display-support in
any major compositors but Xorg (and even for Xorg I'm not entirely
sure they support _fully_ independent display drivers, but airlied
should know more).

> I guess there are benefits to being able to output to a gstreamer backend,
> but
> the drm driver we propose could do just that without having to ask for a lot
> of
> new code, especially code that is already necessary for handling USB GPUs.
> Moreover, the gstreamer backend would not be registered as a screen by X
> which
> means that games may not be able to set themselves fullscreen on this screen
> only.
>
> I am open to the idea of having compositors render to a gstreamer backend,
> but
> I never worked with gstreamer myself so I have no clue about how suited it
> is for
> output management (resolution, refresh rate) and there is the added
> difficulty of
> the X model not working well with this approach. We will have a look at this
> though.

As I said earlier, I'm not opposed to a virtual DRM driver. I'm just
saying that you should not expect it to work out-of-the-box in any
major compositor. I spent a significant amount of time hacking on it,
and my recommendation is to instead do all that in user-space. It'll
be less work.

Thanks
David

[PATCH 02/12] drm/etnaviv: add devicetree bindings

2015-12-08 Thread Michel Dänzer

On 07.12.2015 17:41, Michel DÃ¤nzer wrote:
> On 05.12.2015 19:12, Daniel Vetter wrote:
>> On Fri, Dec 04, 2015 at 05:43:33PM -0500, Ilia Mirkin wrote:
>>> On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
>>>  wrote:
 On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>  wrote:
>> Moreover, DRI3 is not yet available for Gallium, so if we're talking
>> about Xorg, then functional DRI2 is a requirement, and that _needs_
>> to have a single device for the rendering instances.  Xorg has no way
>> to pass multiple render nodes to client over DRI2.
>
> Just to correct... DRI3 has been available on gallium [at least in the
> context of st/mesa] basically since DRI3 was introduced. Not sure what
> issue you're fighting with, but it's definitely not a gallium
> limitation... could be something related to platform devices.

 Well, my statement is based on the fact that there's nothing in
 src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
 implemented differently, I don't know.
> 
> The DRI state tracker code in src/gallium/state_trackers/dri/ supports
> DRI1-3. There's almost no explicit mention of DRI3 in it because DRI3
> and DRI2 work mostly the same as far as this code is concerned.

Also note that there's no requirement for the renderer device node to be
opened via the DRI3 protocol. E.g. the DRI_PRIME implementation for DRI3
in Mesa opens the renderer device itself, creates a shared scanout image
from it, gets a dma-buf file descriptor for that, creates a pixmap from
that via DRI3 and presents that pixmap via Present.


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH v3 00/15] ASoC: hdac_hdmi: Add DP & notification support

2015-12-08 Thread Subhransu S. Prusty

On Mon, Dec 07, 2015 at 08:12:00PM +, Mark Brown wrote:
> On Tue, Dec 08, 2015 at 02:47:58AM +0530, Subhransu S. Prusty wrote:
> > This patch series adds DP audio and hotplug notification support.
> 
> Not related to the code but there seems to be something wrong with the
> time configuration on your system which is causing all your patches to
> be submitted quite a few hours in the future which confuses time based
> mailbox sorting - might be worth looking at that.

Sorry about that. Will fix it.



--

[PATCH v5 2/4] drm: Add support for ARM's HDLCD controller.

2015-12-08 Thread Liviu Dudau

On Tue, Dec 08, 2015 at 04:25:27PM +, Robin Murphy wrote:
> Hi Liviu,
> 
> On 07/12/15 12:11, Liviu Dudau wrote:
> >The HDLCD controller is a display controller that supports resolutions
> >up to 4096x4096 pixels. It is present on various development boards
> >produced by ARM Ltd and emulated by the latest Fast Models from the
> >company.
> >
> > Cc: David Airlie 
> > Cc: Robin Murphy 
> 
> I've given this a spin on my Juno, and the first thing of note is this:
> 
> hdlcd 7ff6.hdlcd: master bind failed: -517
> hdlcd 7ff5.hdlcd: master bind failed: -517
> scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.9.0 version
> [drm] found ARM HDLCD version r0p0
> tda998x 0-0070: Falling back to first CRTC
> usb 1-1: new high-speed USB device number 2 using ehci-platform
> tda998x 0-0070: found TDA19988
> hdlcd 7ff6.hdlcd: bound 0-0070 (ops tda998x_ops)
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> [ cut here ]
> WARNING: at drivers/gpu/drm/drm_atomic_helper.c:682
> Modules linked in:
> 
> CPU: 2 PID: 98 Comm: kworker/u12:3 Tainted: GW   4.4.0-rc2+ #846
> Hardware name: ARM Juno development board (r1) (DT)
> Workqueue: deferwq deferred_probe_work_func
> task: fe007ecb3700 ti: fe09409c8000 task.ti: fe09409c8000
> PC is at drm_atomic_helper_update_legacy_modeset_state+0x1e8/0x1f0
> LR is at drm_atomic_helper_commit_modeset_disables+0x1a8/0x388
> pc : [] lr : [] pstate: 2045
> sp : fe09409cb560
> x29: fe09409cb560 x28: fe0940bf2800
> x27: fe094007 x26: 0001
> x25: febe4b50 x24: fe7ae820
> x23: febe4b50 x22: fe0940bd1000
> x21: fe0940bd1000 x20: 
> x19: fe0940968000 x18: fe0940c8091c
> x17: 0007 x16: 0001
> x15: fe0940c8016f x14: 003c
> x13:  x12: 04c904b4
> x11: 04b104c9 x10: 04b004b0
> x9 : 06f4 x8 : 06a40654
> x7 : 06f40640 x6 : fe0940966480
> x5 : fe0940968200 x4 : 0001
> x3 : fe0940966a80 x2 : 
> x1 : fe0940bd0900 x0 : fe0940bd0960
> 
> ---[ end trace bdb6af69b29bf7ea ]---
> Call trace:
> []
> drm_atomic_helper_update_legacy_modeset_state+0x1e8/0x1f0
> [] drm_atomic_helper_commit_modeset_disables+0x1a8/0x388
> [] drm_atomic_helper_commit+0xd8/0x140
> [] hdlcd_atomic_commit+0x10/0x18
> [] drm_atomic_commit+0x40/0x70
> [] restore_fbdev_mode+0x270/0x2b0
> [] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x90
> [] drm_fb_helper_set_par+0x2c/0x60
> [] fbcon_init+0x4d0/0x520
> [] visual_init+0xac/0x108
> [] do_bind_con_driver+0x1d4/0x3e8
> [] do_take_over_console+0x174/0x1e8
> [] do_fbcon_takeover+0x74/0x100
> [] fbcon_event_notify+0x77c/0x7d8
> [] notifier_call_chain+0x50/0x90
> [] __blocking_notifier_call_chain+0x4c/0x90
> [] blocking_notifier_call_chain+0x14/0x20
> [] fb_notifier_call_chain+0x1c/0x28
> [] register_framebuffer+0x1c0/0x2b8
> [] drm_fb_helper_initial_config+0x284/0x3e8
> [] drm_fbdev_cma_init+0x94/0x148
> [] hdlcd_drm_bind+0x1d4/0x418
> [] try_to_bring_up_master.part.2+0xc8/0x110
> [] component_add+0x90/0x108
> [] tda998x_probe+0x18/0x20
> [] i2c_device_probe+0x164/0x228
> [] driver_probe_device+0x1ec/0x2f0
> [] __device_attach_driver+0x90/0xd8
> [] bus_for_each_drv+0x58/0x98
> [] __device_attach+0xc4/0x148
> [] device_initial_probe+0x10/0x18
> [] bus_probe_device+0x94/0xa0
> [] deferred_probe_work_func+0x70/0xa8
> [] process_one_work+0x138/0x378
> [] worker_thread+0x124/0x498
> [] kthread+0xdc/0xf0
> [] ret_from_fork+0x10/0x50
> Console: switching to colour frame buffer device 150x100
> 
> which for reference, is the first one in that function:
> 
>   ...
>   /* clear out existing links and update dpms */
>   for_each_connector_in_state(old_state, connector, old_conn_state, i) {
>   if (connector->encoder) {
>   WARN_ON(!connector->encoder->crtc);
>   ...
> 
> That's on 4.4-rc2 with this series plus the 3 tda998x patches from Russell's
> patch system applied. Is there something else I'm missing or does this need
> looking at (could it be related to that initial probe deferral)?

Yeah, you also need Thierry Reding's patch to not set the connector->encoder in
drivers.

http://lists.freedesktop.org/archives/dri-devel/2015-November/094576.html



> 
> >Signed-off-by: Liviu Dudau 
> >Acked-by: Daniel Vetter 
> >---
> >  drivers/gpu/drm/Kconfig  |   2 +
> >  drivers/gpu/drm/Makefile |   1 +
> >  drivers/gpu/drm/arm/Kconfig  |  29 ++
> >  drivers/gpu/drm/arm/Makefile |   2 +
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 329 ++
> >  drivers/gpu/drm/arm/hdlcd_drv.c  | 580 
> > +++
> >  drivers/gpu/drm/arm/hdlcd_drv.h  |  42 +++
> >  drivers/gpu/drm/arm/hdlcd_regs.h |  87 ++
> >  8 files changed, 10

[PATCH] drm/sti: use u32 to store DMA addresses

2015-12-08 Thread Arnd Bergmann

The STi drm driver correctly warns about invalid format strings
when built with 64-bit dma_addr_t:

sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
sti_hqvdp.c:605:119: warning: format '%x' expects argument of type 'unsigned 
int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' 
[-Wformat=]
sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
sti_hqvdp.c:931:118: warning: format '%x' expects argument of type 'unsigned 
int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' 
[-Wformat=]

This could be changed to using the %pad format string, but that
does not work when printing an rvalue, so instead I'm changing
the type in the sti_hqvdp structure to u32, which is what gets
written into the registers anyway.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index ea0690bc77d5..9d698e582011 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -349,7 +349,7 @@ struct sti_hqvdp {
unsigned int curr_field_count;
unsigned int last_field_count;
void *hqvdp_cmd;
-   dma_addr_t hqvdp_cmd_paddr;
+   u32 hqvdp_cmd_paddr;
struct sti_vtg *vtg;
bool xp70_initialized;
 };
@@ -372,8 +372,8 @@ static const uint32_t hqvdp_supported_formats[] = {
  */
 static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
 {
-   int curr_cmd, next_cmd;
-   dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
+   u32 curr_cmd, next_cmd;
+   u32 cmd = hqvdp->hqvdp_cmd_paddr;
int i;

curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
@@ -400,8 +400,8 @@ static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
  */
 static int sti_hqvdp_get_curr_cmd(struct sti_hqvdp *hqvdp)
 {
-   int curr_cmd;
-   dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
+   u32 curr_cmd;
+   u32 cmd = hqvdp->hqvdp_cmd_paddr;
unsigned int i;

curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
@@ -612,19 +612,21 @@ int sti_hqvdp_vtg_cb(struct notifier_block *nb, unsigned 
long evt, void *data)
 static void sti_hqvdp_init(struct sti_hqvdp *hqvdp)
 {
int size;
+   dma_addr_t dma_addr;

hqvdp->vtg_nb.notifier_call = sti_hqvdp_vtg_cb;

/* Allocate memory for the VDP commands */
size = NB_VDP_CMD * sizeof(struct sti_hqvdp_cmd);
hqvdp->hqvdp_cmd = dma_alloc_writecombine(hqvdp->dev, size,
-&hqvdp->hqvdp_cmd_paddr,
+&dma_addr,
 GFP_KERNEL | GFP_DMA);
if (!hqvdp->hqvdp_cmd) {
DRM_ERROR("Failed to allocate memory for VDP cmd\n");
return;
}

+   hqvdp->hqvdp_cmd_paddr = (u32)dma_addr;
memset(hqvdp->hqvdp_cmd, 0, size);
 }

-- 
2.1.0.rc2

[PATCH v10 0/17] Add Analogix Core Display Port Driver

2015-12-08 Thread Heiko Stübner

Hi Yakir,

Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM

[...]

> Changes in v10:
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
> (Heiko) - Fix the wrong macro value of
> GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4) -> BIT(20)
> - Remove the surplus "plat_data" check. (Heiko)
> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> +   switch (dp->plat_data->dev_type) {
> - Revert parts of Gustavo Padovan's changes in commit:
>   drm/exynos: do not start enabling DP at bind() phase
>   Add dp phy poweron function in bind time.

The hotplug issue is still present, but I think I found the cause. When
the first detect call happens, the display simply is still off. I just did
some very basic tracing [0] and it seems the display simply is not enabled
when it is supposed to get detected.

And it seems injecting a drm_panel_prepare early for _testing_ [1] really
did make the hotplug work on both my jerry and minnie.

So I guess we should somehow make sure the panel is actually powered when
detection is running. Although I'm not sure yet, how that should look like.


Intuition suggests, making drm_panel calls nestable (similar to
clk_prepare/unprepare, etc) and simply wrapping the detection code
in a prepare-unprepare calls, but I'm not sure if Thierry might have other
ideas ;-)


Also my "log" below suggests some sort of mismatch between
prepare/unprepare calls, as there are a lot more of the prepare-side.


And the locking issue also seems to be still there [2].


Heiko


[0]
[2.797383] analogix_dp_reset
[2.800709] analogix_dp_init_hpd
[2.803960] analogix_dp_init_video
[2.807653] rockchip-drm display-subsystem: bound ff97.dp (ops 
rockchip_dp_component_ops)
[2.817176] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.823799] [drm] No driver support for vblank timestamp query.
[2.829947] analogix_dp_detect
[2.833015] analogix_dp_get_plug_in_status: hpd status 0
...
[2.893425] analogix_dp_get_plug_in_status: hpd status 0
[2.893456] rockchip-dp ff97.dp: failed to get hpd plug status, try to 
force hpd
[2.893458] analogix_dp_force_hpd
[2.893464] analogix_dp_get_plug_in_status: hpd status 112
[2.893470] panel_simple_prepare
[2.952183] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[2.961727] panel_simple_get_modes
[3.432154] analogix_dp_detect
[3.432158] analogix_dp_get_plug_in_status: hpd status 120
[3.432160] panel_simple_prepare
[3.433731] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.443268] panel_simple_get_modes
[3.444668] panel_simple_prepare
[3.444755] analogix_dp_reset
[3.445078] analogix_dp_init_hpd
[3.445096] panel_simple_disable
[3.455349] analogix_dp_init_video
[3.558323] rockchip-dp ff97.dp: Timeout of video streamclk ok
[3.558326] rockchip-dp ff97.dp: unable to config video
[3.558328] panel_simple_enable
[3.573915] analogix_dp_detect
[3.573919] analogix_dp_get_plug_in_status: hpd status 72
[3.573921] panel_simple_prepare


[1]
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3990951..0c2dca5 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -399,6 +399,8 @@ static int rockchip_dp_probe(struct platform_device *pdev)

dp->plat_data.panel = panel;

+drm_panel_prepare(dp->plat_data.panel);
+
/*
 * We just use the drvdata until driver run into component
 * add function, and then we would set drvdata to null, so


[2]
[   11.971277] panel_simple_get_modes
[  OK  ] Started LSB: X display manager for KDE.
[  OK  ] Started LSB: Speech Dispatcher.
[   12.007120] panel_simple_disable
[   12.012323] 
[   12.013820] ==
[   12.019993] [ INFO: possible circular locking dependency detected ]
[   12.026250] 4.4.0-rc3+ #2755 Not tainted
[   12.030165] ---
[  12.036417] Xorg/793 is trying to acquire lock:
[   12.040855]  ((&dp->hotplug_work)){+.+...}[   12.040870] 
[   12.040870] but task is already holding lock:
[   12.040871]  (crtc_ww_class_mutex){+.+.+.}, at: [] 
drm_modeset_lock+0x84/0x104
[   12.040881] 
[   12.040881] which lock already depends on the new lock.
[   12.040881] 
[   12.040882] 
[   12.040882] the existing dependency chain (in reverse order) is:
[   12.040883] 
[   12.040883] -> #2 (crtc_ww_class_mut

[PATCH v5 2/4] drm: Add support for ARM's HDLCD controller.

2015-12-08 Thread Robin Murphy

Hi Liviu,

On 07/12/15 12:11, Liviu Dudau wrote:
> The HDLCD controller is a display controller that supports resolutions
> up to 4096x4096 pixels. It is present on various development boards
> produced by ARM Ltd and emulated by the latest Fast Models from the
> company.
 >
 > Cc: David Airlie 
 > Cc: Robin Murphy 

I've given this a spin on my Juno, and the first thing of note is this:

hdlcd 7ff6.hdlcd: master bind failed: -517
hdlcd 7ff5.hdlcd: master bind failed: -517
scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.9.0 version
[drm] found ARM HDLCD version r0p0
tda998x 0-0070: Falling back to first CRTC
usb 1-1: new high-speed USB device number 2 using ehci-platform
tda998x 0-0070: found TDA19988
hdlcd 7ff6.hdlcd: bound 0-0070 (ops tda998x_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[ cut here ]
WARNING: at drivers/gpu/drm/drm_atomic_helper.c:682
Modules linked in:

CPU: 2 PID: 98 Comm: kworker/u12:3 Tainted: GW   4.4.0-rc2+ #846
Hardware name: ARM Juno development board (r1) (DT)
Workqueue: deferwq deferred_probe_work_func
task: fe007ecb3700 ti: fe09409c8000 task.ti: fe09409c8000
PC is at drm_atomic_helper_update_legacy_modeset_state+0x1e8/0x1f0
LR is at drm_atomic_helper_commit_modeset_disables+0x1a8/0x388
pc : [] lr : [] pstate: 2045
sp : fe09409cb560
x29: fe09409cb560 x28: fe0940bf2800
x27: fe094007 x26: 0001
x25: febe4b50 x24: fe7ae820
x23: febe4b50 x22: fe0940bd1000
x21: fe0940bd1000 x20: 
x19: fe0940968000 x18: fe0940c8091c
x17: 0007 x16: 0001
x15: fe0940c8016f x14: 003c
x13:  x12: 04c904b4
x11: 04b104c9 x10: 04b004b0
x9 : 06f4 x8 : 06a40654
x7 : 06f40640 x6 : fe0940966480
x5 : fe0940968200 x4 : 0001
x3 : fe0940966a80 x2 : 
x1 : fe0940bd0900 x0 : fe0940bd0960

---[ end trace bdb6af69b29bf7ea ]---
Call trace:
[] 
drm_atomic_helper_update_legacy_modeset_state+0x1e8/0x1f0
[] drm_atomic_helper_commit_modeset_disables+0x1a8/0x388
[] drm_atomic_helper_commit+0xd8/0x140
[] hdlcd_atomic_commit+0x10/0x18
[] drm_atomic_commit+0x40/0x70
[] restore_fbdev_mode+0x270/0x2b0
[] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x90
[] drm_fb_helper_set_par+0x2c/0x60
[] fbcon_init+0x4d0/0x520
[] visual_init+0xac/0x108
[] do_bind_con_driver+0x1d4/0x3e8
[] do_take_over_console+0x174/0x1e8
[] do_fbcon_takeover+0x74/0x100
[] fbcon_event_notify+0x77c/0x7d8
[] notifier_call_chain+0x50/0x90
[] __blocking_notifier_call_chain+0x4c/0x90
[] blocking_notifier_call_chain+0x14/0x20
[] fb_notifier_call_chain+0x1c/0x28
[] register_framebuffer+0x1c0/0x2b8
[] drm_fb_helper_initial_config+0x284/0x3e8
[] drm_fbdev_cma_init+0x94/0x148
[] hdlcd_drm_bind+0x1d4/0x418
[] try_to_bring_up_master.part.2+0xc8/0x110
[] component_add+0x90/0x108
[] tda998x_probe+0x18/0x20
[] i2c_device_probe+0x164/0x228
[] driver_probe_device+0x1ec/0x2f0
[] __device_attach_driver+0x90/0xd8
[] bus_for_each_drv+0x58/0x98
[] __device_attach+0xc4/0x148
[] device_initial_probe+0x10/0x18
[] bus_probe_device+0x94/0xa0
[] deferred_probe_work_func+0x70/0xa8
[] process_one_work+0x138/0x378
[] worker_thread+0x124/0x498
[] kthread+0xdc/0xf0
[] ret_from_fork+0x10/0x50
Console: switching to colour frame buffer device 150x100

which for reference, is the first one in that function:

...
/* clear out existing links and update dpms */
for_each_connector_in_state(old_state, connector, old_conn_state, i) {
if (connector->encoder) {
WARN_ON(!connector->encoder->crtc);
...

That's on 4.4-rc2 with this series plus the 3 tda998x patches from 
Russell's patch system applied. Is there something else I'm missing or 
does this need looking at (could it be related to that initial probe 
deferral)?

> Signed-off-by: Liviu Dudau 
> Acked-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/Kconfig  |   2 +
>   drivers/gpu/drm/Makefile |   1 +
>   drivers/gpu/drm/arm/Kconfig  |  29 ++
>   drivers/gpu/drm/arm/Makefile |   2 +
>   drivers/gpu/drm/arm/hdlcd_crtc.c | 329 ++
>   drivers/gpu/drm/arm/hdlcd_drv.c  | 580 
> +++
>   drivers/gpu/drm/arm/hdlcd_drv.h  |  42 +++
>   drivers/gpu/drm/arm/hdlcd_regs.h |  87 ++
>   8 files changed, 1072 insertions(+)
>   create mode 100644 drivers/gpu/drm/arm/Kconfig
>   create mode 100644 drivers/gpu/drm/arm/Makefile
>   create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c
>   create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c
>   create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h
>   create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h

[...]

> +static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> +{
> + unsigned int bt

[PATCH v3 10/15] drm/edid: Add API to help find connection type

2015-12-08 Thread Jani Nikula

On Mon, 07 Dec 2015, "Subhransu S. Prusty"  
wrote:
> To fill the audio infoframe it is required to identify the
> connection type as DP or HDMI. This patch adds an API which
> parses ELD and returns the display type of connected.
>
> Signed-off-by: Subhransu S. Prusty 
> Signed-off-by: Vinod Koul 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Daniel Vetter 

Reviewed-by: Jani Nikula 


> ---
>  include/drm/drm_edid.h | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 2af9769..8c537a0 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -403,6 +403,18 @@ static inline int drm_eld_size(const uint8_t *eld)
>   return DRM_ELD_HEADER_BLOCK_SIZE + eld[DRM_ELD_BASELINE_ELD_LEN] * 4;
>  }
>  
> +/**
> + * drm_eld_get_conn_type - Get device type hdmi/dp connected
> + * @eld: pointer to an eld memory structure
> + *
> + * The caller need to use %DRM_ELD_CONN_TYPE_HDMI or %DRM_ELD_CONN_TYPE_DP to
> + * identify the display type connected.
> + */
> +static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
> +{
> + return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
> +}
> +
>  struct edid *drm_do_get_edid(struct drm_connector *connector,
>   int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
> size_t len),

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/5] [RFC] drm: Documentation style guide

2015-12-08 Thread Laurent Pinchart

Hello,

On Tuesday 08 December 2015 10:59:05 Pierre Moreau wrote:
> On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> > Every time I type or review docs this seems a bit different. Try to
> > document the common style so we can try to unify at least new docs.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> > 
> >  Documentation/DocBook/gpu.tmpl | 37 +
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/Documentation/DocBook/gpu.tmpl
> > b/Documentation/DocBook/gpu.tmpl index 86e5b12a49ba..5698c93dae8b 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -124,6 +124,43 @@
> >  
> >[Insert diagram of typical DRM stack here]
> >  
> > +  
> > +Style Guidelines
> > +
> > +  For consistency these documentations use American English.
> > Abbreviations
> > +  are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC,
> > and so
> > +  on. To aid in reading documentations make full use of the markup
> > +  characters kerneldoc provides: @parameter for function paramters,
> > @member
>
> paramters -> parameters
> 
> > +  for structure members, &structure to refernce structures and
> 
> refernce -> reference
> 
> > +  function() for functions. These all get automatically hyperlinked
> > if
> > +  kerneldoc for the referencec objects exists When referencing
> > entries in
>
> referencec -> referenced, missing '.' after exists
> 
> > +  function vtables please use - > does
>
> Isn't "with" too much here? "Note that kerneldoc does not [â¦]"?
> 
> > +  not support referncing struct members directly, so please add a
> > reference
>
> referncing -> referencing
> 
> > +  to the vtable struct somewhere in the same paragraph or at least
> > section.
> > +
> > +
> > +  Except in special situations (to separate locked from unlocked
> > variants)
> > +  locking requirements for functions aren't documented in the
> > kerneldoc.
> > +  Instead locking should be check at runtime using e.g.
> > +  WARN_ON(!mutex_is_locked(...));. Since it's much
> > easier to
> > +  ignore documentation than runtime noise this provides more value.
> > And on
> > +  top of that runtime checks do need to be updated when the locking
> > rules
> > +  change, increasing the changes that they're correct. Within the

s/changes/chances/

> > +  documentation the locking rules should be explained in the relevant
> > +  structures: Either in the comment for the lock explaining what it
> > +  protects, or data fields need a note about which lock protects
> > them, or
> > +  both.
> > +
> > +
> > +  Functions which have a non-void return value should
> > have a
> > +  section called "Returns" explaining the expected return values in
> > +  different cases an their meanings. Currently there's no consensus

s/an/and/

Apart from that,

Acked-by: Laurent Pinchart 

> > whether
> > +  that section name should be all upper-case or not, and whether it
> > should
> > +  end in a colon or not. Go with the file-local style. Other common
> > section
> > +  names are "Notes" with information for dangerous or tricky corner
> > cases,
> > +  and "FIXME" where the interface could be cleaned up.
> 
> Why not define (and use) a single style for naming all sections? Old
> documentation might not use it, but it should be doable to upgrade those old
> documents.
> 
> > +
> > +  
> > 
> >
> >

-- 
Regards,

Laurent Pinchart

AMD guys: commit messages?

2015-12-08 Thread Christian König

On 08.12.2015 15:04, Ilia Mirkin wrote:
> On Tue, Dec 8, 2015 at 8:43 AM, Ernst SjÃ¶strand  wrote:
>> Hello list!
>>
>> I lurk here and try to follow Mesa/DRI and most specifically Radeon
>> driver development, report bugs, test new stuff and help get the bugs
>> closed and so on...
>>
>> However I see that the commit messages for AMD/Radeon are often very
>> unhelpful. They don't state the motivation behind the commits. Is this
>> a optimization, a nice-to-have cleanup or does this actually fix
>> something? What does this fix?
>> Are there tests or bugreports related?
>>
>> Improving this could make it easier for new developers to start
>> contributing in the long run also!
>>
>> Examples:
>>
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750
>>
>> This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
>> "Patch fix is not clearly described. For example, a commit message of
>> only a single line, no description of the bug, no mention of bugzilla,
>> etc."
> So... what's the appropriate amount? Have every commit describe, in
> detail, how the GPU works, how the driver works, and what little bit
> of interaction is being changed? I'm not an AMD developer (I do hack
> on nouveau though), but I basically get what all 3 of the above are
> doing. The reason why you're having trouble is probably because you
> don't know what the ingredients are -- what's a mip level, what's a
> ring index, what's fence, what's a winsys, what's a "emit vertex", all
> in the context of the relevant drivers. If you know what all these
> things are, the above commits become much clearer. But having to
> describe each of those things every time would ... not fly :)

Yeah, exactly.

I work for AMD but mostly on the kernel side and I wasn't involved in 
any of those patches, nor with the surrounding source code.

But I do get just by reading the subject lines what all of those are about.

So it's more about knowing the driver and the hardware a bit to 
understand what's going on here.

While it often could be a bit more, describing everything in the commit 
message is way to much.

Regards,
Christian.

>
> You can usually tell a cleanup/hypothetical fix apart from a real fix
> by seeing if it (a) references a bugzilla, (b) mentions a commit it
> fixes, or (c) cc'd to stable.
>
>-ilia
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

AMD guys: commit messages?

2015-12-08 Thread Emil Velikov

On 8 December 2015 at 14:22, Christian KÃ¶nig  
wrote:
> On 08.12.2015 15:04, Ilia Mirkin wrote:
>>
>> On Tue, Dec 8, 2015 at 8:43 AM, Ernst SjÃ¶strand  wrote:
>>>
>>> Hello list!
>>>
>>> I lurk here and try to follow Mesa/DRI and most specifically Radeon
>>> driver development, report bugs, test new stuff and help get the bugs
>>> closed and so on...
>>>
>>> However I see that the commit messages for AMD/Radeon are often very
>>> unhelpful. They don't state the motivation behind the commits. Is this
>>> a optimization, a nice-to-have cleanup or does this actually fix
>>> something? What does this fix?
>>> Are there tests or bugreports related?
>>>
>>> Improving this could make it easier for new developers to start
>>> contributing in the long run also!
>>>
>>> Examples:
>>>
>>>
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
>>>
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
>>>
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750
>>>
>>> This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
>>> "Patch fix is not clearly described. For example, a commit message of
>>> only a single line, no description of the bug, no mention of bugzilla,
>>> etc."
>>
>> So... what's the appropriate amount? Have every commit describe, in
>> detail, how the GPU works, how the driver works, and what little bit
>> of interaction is being changed? I'm not an AMD developer (I do hack
>> on nouveau though), but I basically get what all 3 of the above are
>> doing. The reason why you're having trouble is probably because you
>> don't know what the ingredients are -- what's a mip level, what's a
>> ring index, what's fence, what's a winsys, what's a "emit vertex", all
>> in the context of the relevant drivers. If you know what all these
>> things are, the above commits become much clearer. But having to
>> describe each of those things every time would ... not fly :)
>
>
> Yeah, exactly.
>
> I work for AMD but mostly on the kernel side and I wasn't involved in any of
> those patches, nor with the surrounding source code.
>
> But I do get just by reading the subject lines what all of those are about.
>
> So it's more about knowing the driver and the hardware a bit to understand
> what's going on here.
>
> While it often could be a bit more, describing everything in the commit
> message is way to much.
>
I might be biased yet it seems that the patches coming from AMD people
have the briefest of commit messages in whole of mesa. If this is a
bugfix one could mention the commit which introduces the issue (broken
from day 1, etc), if it's been tested one could mention the hardware
in question and etc.
For example in the case of "radeonsi: avoid stale state pointers" one
could mention if this fixes app X, and/or what are the possible side
effects.

That said I'm also guilty of keeping things brief on the odd occasion,
yet feel free to point out when things look funky.

Thanks
Emil

[git pull] vmwgfx-fixes-4.4

2015-12-08 Thread Thomas Hellstrom

Dave,
A couple of fixes for vmwgfx. A WARN() fix by Dan Carpenter,
a TTM read/write lock imbalance causing occasional hangs with Wayland and
an implementation of cursor_set2 to fix incorrectly offset Wayland cursors.

The following changes since commit 2f1371614a5d49428846b90673a89036518dffad:

  Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2015-11-26 12:42:15 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-fixes-4.4-151208

for you to fetch changes up to 8fbf9d92a7bc4cadd3a0139698cf17031dfcdfca:

  drm/vmwgfx: Implement the cursor_set2 callback v2 (2015-12-08 12:55:46 +0100)


Pull request of 2015-12-08


Dan Carpenter (1):
  drm/vmwgfx: fix a warning message

Thomas Hellstrom (2):
  drm/ttm: Fixed a read/write lock imbalance
  drm/vmwgfx: Implement the cursor_set2 callback v2

 drivers/gpu/drm/ttm/ttm_lock.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 64 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  7 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  2 +-
 9 files changed, 63 insertions(+), 20 deletions(-)

AMD guys: commit messages?

2015-12-08 Thread Emil Velikov

Hi Ernst,

On 8 December 2015 at 13:43, Ernst SjÃ¶strand  wrote:
> Hello list!
>
> I lurk here and try to follow Mesa/DRI and most specifically Radeon
> driver development, report bugs, test new stuff and help get the bugs
> closed and so on...
>
> However I see that the commit messages for AMD/Radeon are often very
> unhelpful. They don't state the motivation behind the commits. Is this
> a optimization, a nice-to-have cleanup or does this actually fix
> something? What does this fix?
> Are there tests or bugreports related?
>
> Improving this could make it easier for new developers to start
> contributing in the long run also!
>
> Examples:
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750
>
> This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
> "Patch fix is not clearly described. For example, a commit message of
> only a single line, no description of the bug, no mention of bugzilla,
> etc."
>
I'm glad that I'm not the only person noticing these. I've asked a few
times for people to write commit messages, mostly to get a summary of
what the patch does, as opposed to why it does it. I'm seriously
considering about not dropping fixes for [mesa] stable if they're so
terse.

I hope this situation improves, because as you've noticed a-is it make
things actually harder for anyone now working on the relevant code on
daily basis. And I doubt AMD wants to alienate "outsiders" from
working on their driver(s).

Thanks
Emil

P.S. Fwiw mesa-dev might have been better suited for this.

[PATCH 3/3] drm/bridge: add Silicon Image SiI8620 driver

2015-12-08 Thread Andrzej Hajda

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/Kconfig   |7 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/sil-sii8620.c | 1567 ++
 drivers/gpu/drm/bridge/sil-sii8620.h | 1517 
 4 files changed, 3092 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..1f13ced 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,11 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_SIL_SII8620
+   tristate "Silicon Image SII8620 HDMI/MHL bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Silicon Image SII8620 HDMI/MHL bridge chip driver.
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..9ec29d5 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
new file mode 100644
index 000..70014b7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -0,0 +1,1567 @@
+/*
+ * Driver for Silicon Image SiI8620 Mobile HD Transmitter
+ *
+ * Copyright (C) 2015, Samsung Electronics Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sil-sii8620.h"
+
+#define VAL_RX_HDMI_CTRL2_DEFVAL   VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+
+enum sii8620_mode {
+   CM_DISCONNECTED,
+   CM_DISCOVERY,
+   CM_MHL1,
+   CM_MHL3,
+   CM_ECBUS_S
+};
+
+enum sii8620_sink_type {
+   SINK_NONE,
+   SINK_HDMI,
+   SINK_DVI
+};
+
+enum sii8620_mt_state {
+   MT_STATE_READY,
+   MT_STATE_BUSY,
+   MT_STATE_DONE
+};
+
+struct sii8620 {
+   struct drm_bridge bridge;
+   struct device *dev;
+   struct clk *clk_xtal;
+   struct gpio_desc *gpio_reset;
+   struct gpio_desc *gpio_int;
+   int irq;
+   struct regulator_bulk_data supplies[2];
+   struct mutex lock; /* context lock, protects fields below */
+   int error;
+   enum sii8620_mode mode;
+   enum sii8620_sink_type sink_type;
+   u8 cbus_status;
+   u8 stat[MHL_DST_SIZE];
+   u8 xstat[MHL_XDS_SIZE];
+   u8 devcap[MHL_DCAP_SIZE];
+   u8 xdevcap[MHL_XDC_SIZE];
+   u8 avif[19];
+   struct edid *edid;
+   unsigned int gen2_write_burst:1;
+   enum sii8620_mt_state mt_state;
+   struct list_head mt_queue;
+};
+
+struct sii8620_mt_msg;
+
+typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
+ struct sii8620_mt_msg *msg);
+
+struct sii8620_mt_msg {
+   struct list_head node;
+   u8 reg[4];
+   u8 ret;
+   sii8620_mt_msg_cb send;
+   sii8620_mt_msg_cb recv;
+};
+
+static const u8 sii8620_i2c_page[] = {
+   0x39, /* Main System */
+   0x3d, /* TDM and HSIC */
+   0x49, /* TMDS Receiver, MHL EDID */
+   0x4d, /* eMSC, HDCP, HSIC */
+   0x5d, /* MHL Spec */
+   0x64, /* MHL CBUS */
+   0x59, /* Hardware TPI (Transmitter Programming Interface) */
+   0x61, /* eCBUS-S, eCBUS-D */
+};
+
+static void sii8620_fetch_edid(struct sii8620 *ctx);
+static void sii8620_set_upstream_edid(struct sii8620 *ctx);
+static void sii8620_enable_hpd(struct sii8620 *ctx);
+static void sii8620_mhl_disconnected(struct sii8620 *ctx);
+
+static int sii8620_clear_error(struct sii8620 *ctx)
+{
+   int ret = ctx->error;
+
+   ctx->error = 0;
+   return ret;
+}
+
+static void sii8620_read_buf(struct sii8620 *ctx, u16 addr, u8 *buf, int len)
+{
+   struct device *dev = ctx->dev;
+   struct i2c_client *client = to_i2c_client(dev);
+   u8 data = addr;
+   struct i2c_msg msg[] = {
+   {
+   .addr = sii8620_i2c_page[addr >> 8],
+   .flags = client->flags,
+

[PATCH 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings

2015-12-08 Thread Andrzej Hajda

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
via I2C bus.

Signed-off-by: Andrzej Hajda 
---
 .../bindings/video/bridge/sil-sii8620.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
new file mode 100644
index 000..29f3f35
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI8620 bridge bindings
+
+Required properties:
+   - compatible: "sil,sii8620"
+   - reg: i2c address of the bridge
+   - cvcc10-supply: Digital Core Supply Voltage (1.0V)
+   - iovcc18-supply: I/O Supply Voltage (1.8V)
+   - int-gpios: gpio specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin
+   - clocks, clock-names: specification and name of "xtal" clock
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii8620 at 39 {
+   reg = <0x39>;
+   compatible = "sil,sii8620";
+   cvcc10-supply = <&ldo36_reg>;
+   iovcc18-supply = <&ldo34_reg>;
+   int-gpio = <&gpf0 2 0>;
+   reset-gpio = <&gpv7 0 0>;
+   clocks = <&pmu_system_controller 0>;
+   clock-names = "xtal";
+   assigned-clocks = <&pmu_system_controller 0>;
+   assigned-clock-parents = <&xxti>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH 1/3] video: add header file for Mobile High-Definition Link (MHL) interface

2015-12-08 Thread Andrzej Hajda

This header adds definitions specific to MHL protocol.

Signed-off-by: Andrzej Hajda 
---
 include/linux/mhl.h | 292 
 1 file changed, 292 insertions(+)
 create mode 100644 include/linux/mhl.h

diff --git a/include/linux/mhl.h b/include/linux/mhl.h
new file mode 100644
index 000..6917508
--- /dev/null
+++ b/include/linux/mhl.h
@@ -0,0 +1,292 @@
+/*
+ * Defines for Mobile High-Definition Link (MHL) interface
+ *
+ * Copyright (C) 2015, Samsung Electronics, Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * Based on MHL driver for Android devices.
+ * Copyright (C) 2013-2014 Silicon Image, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef LINUX_MHL_H
+#define LINUX_MHL_H
+
+/* Device Capabilities Registers */
+enum {
+   MHL_DCAP_DEV_STATE,
+   MHL_DCAP_MHL_VERSION,
+   MHL_DCAP_CAT,
+   MHL_DCAP_ADOPTER_ID_H,
+   MHL_DCAP_ADOPTER_ID_L,
+   MHL_DCAP_VID_LINK_MODE,
+   MHL_DCAP_AUD_LINK_MODE,
+   MHL_DCAP_VIDEO_TYPE,
+   MHL_DCAP_LOG_DEV_MAP,
+   MHL_DCAP_BANDWIDTH,
+   MHL_DCAP_FEATURE_FLAG,
+   MHL_DCAP_DEVICE_ID_H,
+   MHL_DCAP_DEVICE_ID_L,
+   MHL_DCAP_SCRATCHPAD_SIZE,
+   MHL_DCAP_INT_STAT_SIZE,
+   MHL_DCAP_RESERVED,
+   MHL_DCAP_SIZE
+};
+
+#define MHL_DCAP_CAT_SINK  0x01
+#define MHL_DCAP_CAT_SOURCE0x02
+#define MHL_DCAP_CAT_POWER 0x10
+#define MHL_DCAP_CAT_PLIM(x)   ((x) << 5)
+
+#define MHL_DCAP_VID_LINK_RGB444   0x01
+#define MHL_DCAP_VID_LINK_YCBCR444 0x02
+#define MHL_DCAP_VID_LINK_YCBCR422 0x04
+#define MHL_DCAP_VID_LINK_PPIXEL   0x08
+#define MHL_DCAP_VID_LINK_ISLANDS  0x10
+#define MHL_DCAP_VID_LINK_VGA  0x20
+#define MHL_DCAP_VID_LINK_16BPP0x40
+
+#define MHL_DCAP_AUD_LINK_2CH  0x01
+#define MHL_DCAP_AUD_LINK_8CH  0x02
+
+#define MHL_DCAP_VT_GRAPHICS   0x00
+#define MHL_DCAP_VT_PHOTO  0x02
+#define MHL_DCAP_VT_CINEMA 0x04
+#define MHL_DCAP_VT_GAMES  0x08
+#define MHL_DCAP_SUPP_VT   0x80
+
+#define MHL_DCAP_LD_DISPLAY0x01
+#define MHL_DCAP_LD_VIDEO  0x02
+#define MHL_DCAP_LD_AUDIO  0x04
+#define MHL_DCAP_LD_MEDIA  0x08
+#define MHL_DCAP_LD_TUNER  0x10
+#define MHL_DCAP_LD_RECORD 0x20
+#define MHL_DCAP_LD_SPEAKER0x40
+#define MHL_DCAP_LD_GUI0x80
+#define MHL_DCAP_LD_ALL0xFF
+
+#define MHL_DCAP_FEATURE_RCP_SUPPORT   0x01
+#define MHL_DCAP_FEATURE_RAP_SUPPORT   0x02
+#define MHL_DCAP_FEATURE_SP_SUPPORT0x04
+#define MHL_DCAP_FEATURE_UCP_SEND_SUPPOR   0x08
+#define MHL_DCAP_FEATURE_UCP_RECV_SUPPORT  0x10
+#define MHL_DCAP_FEATURE_RBP_SUPPORT   0x40
+
+/* Extended Device Capabilities Registers */
+enum {
+   MHL_XDC_ECBUS_SPEEDS,
+   MHL_XDC_TMDS_SPEEDS,
+   MHL_XDC_ECBUS_ROLES,
+   MHL_XDC_LOG_DEV_MAPX,
+   MHL_XDC_SIZE
+};
+
+#define MHL_XDC_ECBUS_S_0750x01
+#define MHL_XDC_ECBUS_S_8BIT   0x02
+#define MHL_XDC_ECBUS_S_12BIT  0x04
+#define MHL_XDC_ECBUS_D_1500x10
+#define MHL_XDC_ECBUS_D_8BIT   0x20
+
+#define MHL_XDC_TMDS_000   0x00
+#define MHL_XDC_TMDS_150   0x01
+#define MHL_XDC_TMDS_300   0x02
+#define MHL_XDC_TMDS_600   0x04
+
+/* MHL_XDC_ECBUS_ROLES flags */
+#define MHL_XDC_DEV_HOST   0x01
+#define MHL_XDC_DEV_DEVICE 0x02
+#define MHL_XDC_DEV_CHARGER0x04
+#define MHL_XDC_HID_HOST   0x08
+#define MHL_XDC_HID_DEVICE 0x10
+
+/* MHL_XDC_LOG_DEV_MAPX flags */
+#define MHL_XDC_LD_PHONE   0x01
+
+/* Device Status Registers */
+enum {
+   MHL_DST_CONNECTED_RDY,
+   MHL_DST_LINK_MODE,
+   MHL_DST_VERSION,
+   MHL_DST_SIZE
+};
+
+/* Offset of DEVSTAT registers */
+#define MHL_DST_OFFSET 0x30
+#define MHL_DST_REG(name) (MHL_DST_OFFSET + MHL_DST_##name)
+
+#define MHL_DST_CONN_DCAP_RDY  0x01
+#define MHL_DST_CONN_XDEVCAPP_SUPP 0x02
+#define MHL_DST_CONN_POW_STAT  0x04
+#define MHL_DST_CONN_PLIM_STAT_MASK0x38
+
+#define MHL_DST_LM_CLK_MODE_MASK   0x07
+#define MHL_DST_LM_CLK_MODE_PACKED_PIXEL   0x02
+#define MHL_DST_LM_CLK_MODE_NORMAL 0x03
+#define MHL_DST_LM_PATH_EN_M

[PATCH 0/3] drm/bridge: add Silicon Image SiI8620 driver

2015-12-08 Thread Andrzej Hajda

Hi,

This patchset adds MHL bridge driver for Silicon Image SiI8620 chip.
The chip is quite powerful, supports MHL versions up to 3.0. It is present
in multiple mobile devices.

I have put common MHL definitions into include/linux/mhl.h header file,
similarily to include/linux/hdmi.h.

The patchset is based on latest exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (3):
  video: add header file for Mobile High-Definition Link (MHL) interface
  dt-bindings: add Silicon Image SiI8620 bridge bindings
  drm/bridge: add Silicon Image SiI8620 driver

 .../bindings/video/bridge/sil-sii8620.txt  |   34 +
 drivers/gpu/drm/bridge/Kconfig |7 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/sil-sii8620.c   | 1567 
 drivers/gpu/drm/bridge/sil-sii8620.h   | 1517 +++
 include/linux/mhl.h|  292 
 6 files changed, 3418 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h
 create mode 100644 include/linux/mhl.h

-- 
1.9.1

AMD guys: commit messages?

2015-12-08 Thread Ernst Sjöstrand

Hello list!

I lurk here and try to follow Mesa/DRI and most specifically Radeon
driver development, report bugs, test new stuff and help get the bugs
closed and so on...

However I see that the commit messages for AMD/Radeon are often very
unhelpful. They don't state the motivation behind the commits. Is this
a optimization, a nice-to-have cleanup or does this actually fix
something? What does this fix?
Are there tests or bugreports related?

Improving this could make it easier for new developers to start
contributing in the long run also!

Examples:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750

This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
"Patch fix is not clearly described. For example, a commit message of
only a single line, no description of the bug, no mention of bugzilla,
etc."

Regards!
//Ernst

Implementing Miracast?

2015-12-08 Thread David Herrmann

Hi

On Fri, Dec 4, 2015 at 9:07 AM, Daniel Vetter  wrote:
> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>> You are right Ilia, this is indeed what Jaakko and I had in mind, but they
>> did not re-use the fuse/cuse framework to do the serialization of the
>> ioctls.
>>
>> Not sure what we can do against allowing proprietary drivers to use this
>> feature though :s To be fair, nothing prevents any vendor to do this shim
>> themselves and nvidia definitely did it, and directly called their
>> closed-source driver.
>>
>> Any proposition on how to handle this case? I guess we could limit that to
>> screens only, no rendering. That would block any serious GPU manufacturer
>> from using this code even if any sane person would never write a driver in
>> the userspace...
>
> Hm for virtual devices like this I figured there's no point exporting the
> full kms api to userspace, but instead we'd just need a simple kms driver
> with just 1 crtc and 1 connector per drm_device. Plus a special device
> node (v4l is probably inappropriate since it doesn't do damage) where the
> miracast userspace can receive events with just the following information:
> - virtual screen size
> - fd to the underlying shmem node for the current fb. Or maybe a dma-buf
>   (but then we'd need the dma-buf mmap stuff to land first).
> - damage tracking
>
> If we want fancy, we could allow userspace to reply (through an ioctl)
> when it's done reading the previous image, which the kernel could then
> forward as vblank complete events.
>
> Connector configuration could be done by forcing the outputs (we'll send
> out uevents nowadays for that), so the only thing we need is some configfs
> to instantiate new copies of this.
>
> At least for miracst (as opposed to full-blown hw drivers in userspace) I
> don't think we need to export everything.

I looked into all this when working on WFD, but I cannot recommend
going down that road. First of all, you still need heavy modifications
for gnome-shell, kwin, and friends, as neither of them supports
seamless drm-device hotplugging. Hence, providing more devices than
the main GPU just confuses them. Secondly, you really don't win much
by re-using DRM for all that. On the contrary, you get very heavy
overhead, need to feed all this through limited ioctl interfaces, and
fake DRM crtcs/encoders/connectors, when all you really have is an
mpeg stream.

I wouldn't mind if anyone writes a virtual DRM interface, it'd be
really great for automated testing. However, if you want your
wifi-display (or whatever else) integrated into desktop environments,
then I recommend teaching those environments to accept gstreamer sinks
as outputs.

Thanks
David

[PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks

2015-12-08 Thread Thomas Hellstrom

Reviewed-by: Thomas Hellstrom 

On 12/04/2015 09:45 AM, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Thomas Hellstrom 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 16 
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  4 
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  4 
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  4 
>  4 files changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index e38db35132ed..d50596153679 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1331,14 +1331,6 @@ static int vmw_du_update_layout(struct vmw_private 
> *dev_priv, unsigned num,
>   return 0;
>  }
>  
> -void vmw_du_crtc_save(struct drm_crtc *crtc)
> -{
> -}
> -
> -void vmw_du_crtc_restore(struct drm_crtc *crtc)
> -{
> -}
> -
>  void vmw_du_crtc_gamma_set(struct drm_crtc *crtc,
>  u16 *r, u16 *g, u16 *b,
>  uint32_t start, uint32_t size)
> @@ -1360,14 +1352,6 @@ int vmw_du_connector_dpms(struct drm_connector 
> *connector, int mode)
>   return 0;
>  }
>  
> -void vmw_du_connector_save(struct drm_connector *connector)
> -{
> -}
> -
> -void vmw_du_connector_restore(struct drm_connector *connector)
> -{
> -}
> -
>  enum drm_connector_status
>  vmw_du_connector_detect(struct drm_connector *connector, bool force)
>  {
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> index bb63e4d795fa..c1c09b338cc1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> @@ -295,8 +295,6 @@ static int vmw_ldu_crtc_set_config(struct drm_mode_set 
> *set)
>  }
>  
>  static struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
> - .save = vmw_du_crtc_save,
> - .restore = vmw_du_crtc_restore,
>   .cursor_set = vmw_du_crtc_cursor_set,
>   .cursor_move = vmw_du_crtc_cursor_move,
>   .gamma_set = vmw_du_crtc_gamma_set,
> @@ -329,8 +327,6 @@ static void vmw_ldu_connector_destroy(struct 
> drm_connector *connector)
>  
>  static struct drm_connector_funcs vmw_legacy_connector_funcs = {
>   .dpms = vmw_du_connector_dpms,
> - .save = vmw_du_connector_save,
> - .restore = vmw_du_connector_restore,
>   .detect = vmw_du_connector_detect,
>   .fill_modes = vmw_du_connector_fill_modes,
>   .set_property = vmw_du_connector_set_property,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index b96d1ab610c5..26dfed6b0c48 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -531,8 +531,6 @@ out_no_fence:
>  }
>  
>  static struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
> - .save = vmw_du_crtc_save,
> - .restore = vmw_du_crtc_restore,
>   .cursor_set = vmw_du_crtc_cursor_set,
>   .cursor_move = vmw_du_crtc_cursor_move,
>   .gamma_set = vmw_du_crtc_gamma_set,
> @@ -565,8 +563,6 @@ static void vmw_sou_connector_destroy(struct 
> drm_connector *connector)
>  
>  static struct drm_connector_funcs vmw_sou_connector_funcs = {
>   .dpms = vmw_du_connector_dpms,
> - .save = vmw_du_connector_save,
> - .restore = vmw_du_connector_restore,
>   .detect = vmw_du_connector_detect,
>   .fill_modes = vmw_du_connector_fill_modes,
>   .set_property = vmw_du_connector_set_property,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> index b1fc1c02792d..05375a8cc129 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> @@ -1041,8 +1041,6 @@ out_finish:
>   *  Screen Target CRTC dispatch table
>   */
>  static struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
> - .save = vmw_du_crtc_save,
> - .restore = vmw_du_crtc_restore,
>   .cursor_set = vmw_du_crtc_cursor_set,
>   .cursor_move = vmw_du_crtc_cursor_move,
>   .gamma_set = vmw_du_crtc_gamma_set,
> @@ -1101,8 +1099,6 @@ static void vmw_stdu_connector_destroy(struct 
> drm_connector *connector)
>  
>  static struct drm_connector_funcs vmw_stdu_connector_funcs = {
>   .dpms = vmw_du_connector_dpms,
> - .save = vmw_du_connector_save,
> - .restore = vmw_du_connector_restore,
>   .detect = vmw_du_connector_detect,
>   .fill_modes = vmw_du_connector_fill_modes,
>   .set_property = vmw_du_connector_set_property,

[Intel-gfx] i915 Skylake crash on 4.4-rc3

2015-12-08 Thread Jani Nikula

On Tue, 08 Dec 2015, Daniel Vetter  wrote:
> On Tue, Dec 08, 2015 at 09:53:05AM +, Tvrtko Ursulin wrote:
>> 
>> Hi,
>> 
>> On 07/12/15 19:25, Andy Lutomirski wrote:
>> >[53834.386369] traps: gnome-session-b[2308] general protection
>> >ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
>> >libc-2.22.so[7f10efba1000+1b7000]
>> >[53834.687584] [ cut here ]
>> >[53834.687607] WARNING: CPU: 0 PID: 23730 at
>> >drivers/gpu/drm/i915/i915_gem_context.c:144
>> >i915_gem_context_free+0x196/0x1c0 [i915]()
>> >[53834.687609] WARN_ON(!list_empty(&ppgtt->base.active_list))
>> 
>> It is a false positive, or a wrong warning in other words, the removal of
>> which is already in the queue.
>
> Well it's in the wrong queue. Please check that next time around before
> replying.
>
> Jani, can you please pick up 408952d43b27a54437244c56c0e0d8efa5607926 for
> -fixes?

Done.

-- 
Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

2015-12-08 Thread Daniel Stone

Hi,

On 8 December 2015 at 08:49, Daniel Vetter  wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
> to implement, but userspace has a track recording proofing that it's
> way too easy to accidentally abuse and cause havoc. We want to make
> sure userspace doesn't get away with that.
>
> v2: Somehow thought we do reject events already, but that code only
> existed in my imagination ... Also suggestions from Thierry.

What a beautifully-coloured shed.

Reviewed-by: Daniel Stone 

Cheers,
Daniel

[PATCH 2/3] radeon: Fix VCE ring test for Big-Endian systems

2015-12-08 Thread Michel Dänzer

On 08.12.2015 02:49, Oded Gabbay wrote:
> On Mon, Dec 7, 2015 at 9:51 AM, Michel DÃ¤nzer  wrote:
>> On 05.12.2015 06:09, Oded Gabbay wrote:
>>>
>>> @@ -765,7 +765,7 @@ int radeon_vce_ring_test(struct radeon_device *rdev, 
>>> struct radeon_ring *ring)
>>> ring->idx, r);
>>>   return r;
>>>   }
>>> - radeon_ring_write(ring, VCE_CMD_END);
>>> + radeon_ring_write(ring, cpu_to_le32(VCE_CMD_END));
>>>   radeon_ring_unlock_commit(rdev, ring, false);
>>>
>>>   for (i = 0; i < rdev->usec_timeout; i++) {
>>>
>>
>> A new helper function such as
>>
>> static inline void radeon_ring_write_le(struct radeon_ring *ring, uint32_t v)
>> {
>> radeon_ring_write(ring, cpu_to_le32(v));
>> }
>>
>> might be nice for this.
> 
> IMHO, I don't think this gives any benefit.
> You would just need to replace every:
> 
> radeon_ring_write(ring, cpu_to_le32(SOME_DEFINE));
> 
> with
> 
> radeon_ring_write_le(ring, SOME_DEFINE);
> 
> So no reduce in code size. Also, if you change it in my code, I think
> you need to change it in the entire driver for consistency.
> 
> What's even more important, is that when I look at the above, it seems
> to me this change even makes the code *less* clear as you now need to
> go into radeon_ring_write_le  to actually understand how the value is
> written.

Sprinkling cpu_to_le32 all over the place just seems a bit ugly to me,
but I don't feel strongly about it. I.e. I'm fine with the patch as is,
it was just a suggestion.


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 3/9] drm/vc4: Add create and map BO ioctls.

2015-12-08 Thread Michel Dänzer

On 08.12.2015 10:16, Eric Anholt wrote:
> Emil Velikov  writes:
> 
>> Hi Eric,
>>
>> A couple of suggestions/requests on the UAPI header side
>>
>> On 1 December 2015 at 20:35, Eric Anholt  wrote:
>>
>>> --- /dev/null
>>> +++ b/include/uapi/drm/vc4_drm.h
>>
>>> +#include 
>>> +
>> Can we make this a "drm.h" ?
> 
> Nope.
> 
> include/uapi/drm/vc4_drm.h:27:17: fatal error: drm.h: No such file or 
> directory

What happened to include/uapi/drm/drm.h in that tree?


> and none of the drivers do, either.

daenzer at kaveri|11:55:31> grep '#include "drm.h"' include/uapi/drm/*
include/uapi/drm/amdgpu_drm.h:#include "drm.h"
include/uapi/drm/radeon_drm.h:#include "drm.h"

Patches to convert the rest are pending.


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

linux-next: build failure after merge of the drm-misc tree

2015-12-08 Thread Stephen Rothwell

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/i2c/tda998x_drv.c:1354:2: error: unknown field 'save' specified 
in initializer
  .save = tda998x_encoder_save,
  ^
drivers/gpu/drm/i2c/tda998x_drv.c:1354:10: warning: initialization from 
incompatible pointer type [-Wincompatible-pointer-types]
  .save = tda998x_encoder_save,
  ^
drivers/gpu/drm/i2c/tda998x_drv.c:1354:10: note: (near initialization for 
'tda998x_encoder_helper_funcs.mode_fixup')
drivers/gpu/drm/i2c/tda998x_drv.c:1355:2: error: unknown field 'restore' 
specified in initializer
  .restore = tda998x_encoder_restore,
  ^

Caused by commit

  79f13ad5d8e0 ("drm: Move encoder->save/restore into nouveau")

I have used the drm-misc tree from next-20151207 for today.

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

[PATCH 1/5] [RFC] drm: Documentation style guide

2015-12-08 Thread Daniel Vetter

On Tue, Dec 08, 2015 at 10:59:05AM +0100, Pierre Moreau wrote:
> On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> > +
> > +  Functions which have a non-void return value should 
> > have a
> > +  section called "Returns" explaining the expected return values in
> > +  different cases an their meanings. Currently there's no consensus 
> > whether
> > +  that section name should be all upper-case or not, and whether it 
> > should
> > +  end in a colon or not. Go with the file-local style. Other common 
> > section
> > +  names are "Notes" with information for dangerous or tricky corner 
> > cases,
> > +  and "FIXME" where the interface could be cleaned up.
> 
> Why not define (and use) a single style for naming all sections? Old
> documentation might not use it, but it should be doable to upgrade those old
> documents.

There is a massive pile of these docs, and there is a slight difference in
how vfunc table section headings and function reference section headings
are rendered. Given that I figured I'll start modestly.

But if you feel like making this consistent I'd definitely take a patch to
do so. Same really for any of the other style guideline issues. Well,
after we have some acks on this, and any large-scale style change should
first do the RFC patch for this section for discussion to avoid the risk
of wasting lots of time.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-08 Thread Inki Dae

2015ë 12ì 08ì¼ 10:47ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
> On 08.12.2015 10:33, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote:
>>> On 07.12.2015 21:52, Inki Dae wrote:
 From: Javier Martinez Canillas 

 The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
 since it uses a phandle to describe the connection between the DP port and
 the display panel but uses the OF graph ports and endpoints to describe the
 connection betwen the DP port, a bridge chip and the panel.

 The Exynos DP driver and the DT binding have been changed to allow also to
 describe the DP port to panel connection using ports / endpoints (OF graph)
 so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
 the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.

 Signed-off-by: Javier Martinez Canillas 
 Tested-by: Javier Martinez Canillas 
 Reviewed-by: Inki Dae 
 ---
  arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

>>>
>>> Looks sensible:
>>> Reviewed-by: Krzysztof Kozlowski 
>>>
>>> Dependencies are not mentioned, does it depend on patch 1?
>>>
>>
>> Yes, it depends on patch 1/4 so it should be merged through the Exynos DRM
>> tree to maintain bisectability. Inki's patch maintains the DT ABI backward
>> compatibility though so another option is to wait until the DRM change hit
>> mainline and then pick $SUBJECT.
> 
> Thanks. We could also use a tag with DRM changes for samsung-soc but
> since I already flushed my queue for v4.5 I think it would be an
> overkill. From my point of view it can safely go through exynos-drm tree.

I will pick it up to exynos-drm tree. :)

Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
>

[PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

2015-12-08 Thread Daniel Vetter

On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
> On 8 December 2015 at 08:49, Daniel Vetter  wrote:
> > In my quest to remove all the drm_encoder_helper_funcs->save/restore
> > hooks I somehow missed that this driver has a dummy set too - I
> > thought all the i2c drivers only set up the slave_encoder save/restore
> > hooks, which I've left. Remove them.
> >
> There was an identical patch from Rodrigo a couple of days ago

couple = less than 1 ;-) But thanks for pointing out, merged that patch
instead.
-Daniel

> 
> http://lists.freedesktop.org/archives/dri-devel/2015-December/096492.html
> 
> -Emil

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/i2c/tda998x: Remove unused save/restore drm encoder helpers.

2015-12-08 Thread Daniel Vetter

On Mon, Dec 07, 2015 at 10:35:06AM -0800, Rodrigo Vivi wrote:
> save/restore have been removed from drm_encoder_helper_funcs by
> 'commit 79f13ad5d8e0 ("drm: Move encoder->save/restore into nouveau")'
> 
> But this module was still defining it with empty content causing
> compilation fails:
> 
> drivers/gpu/drm/i2c/tda998x_drv.c:1354:10: warning: initialization from
> incompatible pointer type [-Wincompatible-pointer-types]
>   .save = tda998x_encoder_save,
> 
> drivers/gpu/drm/i2c/tda998x_drv.c:1355:2: error: unknown field 'restore'
> specified in initializer
>   .restore = tda998x_encoder_restore,
> 
> Cc: Reinette Chatre 
> Signed-off-by: Rodrigo Vivi 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 896b6aa..79cb920 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -855,18 +855,6 @@ static void tda998x_encoder_dpms(struct drm_encoder 
> *encoder, int mode)
>   priv->dpms = mode;
>  }
>  
> -static void
> -tda998x_encoder_save(struct drm_encoder *encoder)
> -{
> - DBG("");
> -}
> -
> -static void
> -tda998x_encoder_restore(struct drm_encoder *encoder)
> -{
> - DBG("");
> -}
> -
>  static bool
>  tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
> const struct drm_display_mode *mode,
> @@ -1351,8 +1339,6 @@ static void tda998x_encoder_commit(struct drm_encoder 
> *encoder)
>  
>  static const struct drm_encoder_helper_funcs tda998x_encoder_helper_funcs = {
>   .dpms = tda998x_encoder_dpms,
> - .save = tda998x_encoder_save,
> - .restore = tda998x_encoder_restore,
>   .mode_fixup = tda998x_encoder_mode_fixup,
>   .prepare = tda998x_encoder_prepare,
>   .commit = tda998x_encoder_commit,
> -- 
> 2.4.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-08 Thread Inki Dae



2015ë 12ì 08ì¼ 09:48ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
> On 08.12.2015 00:36, Inki Dae wrote:
>> Hi Javier,
>>
>> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas > osg.samsung.com>:
>>> Hello Inki,
>>>
>>> On 12/07/2015 09:52 AM, Inki Dae wrote:
 From: Javier Martinez Canillas 

>>>
>>> Thanks a lot for posting this patch.
>>>
 The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
 since it uses a phandle to describe the connection between the DP port and
 the display panel but uses the OF graph ports and endpoints to describe the
 connection betwen the DP port, a bridge chip and the panel.

 The Exynos DP driver and the DT binding have been changed to allow also to
 describe the DP port to panel connection using ports / endpoints (OF graph)
 so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
 the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.

 Signed-off-by: Javier Martinez Canillas 
 Tested-by: Javier Martinez Canillas 
>>>
>>> This tag was not in my original patch, it's true that I tested
>>> it but will someone believe me? ;)
>>
>> Oops. I confused you spread Reviewed-by and Tested-by here and there.
>> Don't worry about that. Will remove it if you don't give me Tested-by.
>> :)
> 
> Actually authorship (the "From") in this case means Tested-by. Author
> always tests the patch so it would look weird if we start adding
> tested-by to our own patches, right?
> 
> Dear Inki,
> However the patch misses your SoB. You touched and sent it so please
> extend the SoB chain-of-blame.

Right. Missed.

Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>

[Intel-gfx] i915 Skylake crash on 4.4-rc3

2015-12-08 Thread Daniel Vetter

On Tue, Dec 08, 2015 at 09:53:05AM +, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 07/12/15 19:25, Andy Lutomirski wrote:
> >[53834.386369] traps: gnome-session-b[2308] general protection
> >ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
> >libc-2.22.so[7f10efba1000+1b7000]
> >[53834.687584] [ cut here ]
> >[53834.687607] WARNING: CPU: 0 PID: 23730 at
> >drivers/gpu/drm/i915/i915_gem_context.c:144
> >i915_gem_context_free+0x196/0x1c0 [i915]()
> >[53834.687609] WARN_ON(!list_empty(&ppgtt->base.active_list))
> 
> It is a false positive, or a wrong warning in other words, the removal of
> which is already in the queue.

Well it's in the wrong queue. Please check that next time around before
replying.

Jani, can you please pick up 408952d43b27a54437244c56c0e0d8efa5607926 for
-fixes?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/5] [RFC] drm: Documentation style guide

2015-12-08 Thread Pierre Moreau

Hello Daniel,

Just some typo comments below.

On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> Every time I type or review docs this seems a bit different. Try to
> document the common style so we can try to unify at least new docs.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/gpu.tmpl | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 86e5b12a49ba..5698c93dae8b 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -124,6 +124,43 @@
>  
>[Insert diagram of typical DRM stack here]
>  
> +  
> +Style Guidelines
> +
> +  For consistency these documentations use American English. 
> Abbreviations
> +  are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and 
> so
> +  on. To aid in reading documentations make full use of the markup
> +  characters kerneldoc provides: @parameter for function paramters, 
> @member

paramters -> parameters

> +  for structure members, &structure to refernce structures and

refernce -> reference

> +  function() for functions. These all get automatically hyperlinked if
> +  kerneldoc for the referencec objects exists When referencing entries in

referencec -> referenced, missing '.' after exists

> +  function vtables please use - +  not support referncing struct members directly, so please add a 
> reference

referncing -> referencing

> +  to the vtable struct somewhere in the same paragraph or at least 
> section.
> +
> +
> +  Except in special situations (to separate locked from unlocked 
> variants)
> +  locking requirements for functions aren't documented in the kerneldoc.
> +  Instead locking should be check at runtime using e.g.
> +  WARN_ON(!mutex_is_locked(...));. Since it's much easier to
> +  ignore documentation than runtime noise this provides more value. And 
> on
> +  top of that runtime checks do need to be updated when the locking rules
> +  change, increasing the changes that they're correct. Within the
> +  documentation the locking rules should be explained in the relevant
> +  structures: Either in the comment for the lock explaining what it
> +  protects, or data fields need a note about which lock protects them, or
> +  both.
> +
> +
> +  Functions which have a non-void return value should have a
> +  section called "Returns" explaining the expected return values in
> +  different cases an their meanings. Currently there's no consensus 
> whether
> +  that section name should be all upper-case or not, and whether it 
> should
> +  end in a colon or not. Go with the file-local style. Other common 
> section
> +  names are "Notes" with information for dangerous or tricky corner 
> cases,
> +  and "FIXME" where the interface could be cleaned up.

Why not define (and use) a single style for naming all sections? Old
documentation might not use it, but it should be doable to upgrade those old
documents.

Pierre


> +
> +  
>
>  
>
> -- 
> 2.5.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-08 Thread Krzysztof Kozlowski

On 08.12.2015 10:33, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote:
>> On 07.12.2015 21:52, Inki Dae wrote:
>>> From: Javier Martinez Canillas 
>>>
>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
>>> since it uses a phandle to describe the connection between the DP port and
>>> the display panel but uses the OF graph ports and endpoints to describe the
>>> connection betwen the DP port, a bridge chip and the panel.
>>>
>>> The Exynos DP driver and the DT binding have been changed to allow also to
>>> describe the DP port to panel connection using ports / endpoints (OF graph)
>>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
>>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>> Tested-by: Javier Martinez Canillas 
>>> Reviewed-by: Inki Dae 
>>> ---
>>>  arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
>>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>
>> Looks sensible:
>> Reviewed-by: Krzysztof Kozlowski 
>>
>> Dependencies are not mentioned, does it depend on patch 1?
>>
> 
> Yes, it depends on patch 1/4 so it should be merged through the Exynos DRM
> tree to maintain bisectability. Inki's patch maintains the DT ABI backward
> compatibility though so another option is to wait until the DRM change hit
> mainline and then pick $SUBJECT.

Thanks. We could also use a tag with DRM changes for samsung-soc but
since I already flushed my queue for v4.5 I think it would be an
overkill. From my point of view it can safely go through exynos-drm tree.

Best regards,
Krzysztof

[PATCH v2 9/9] drm/vc4: Add an interface for capturing the GPU state after a hang.

2015-12-08 Thread Eric Anholt

This can be parsed with vc4-gpu-tools tools for trying to figure out
what was going on.

Signed-off-by: Eric Anholt 
---

v2: Use __u32-style types.

 drivers/gpu/drm/vc4/vc4_drv.c |   2 +
 drivers/gpu/drm/vc4/vc4_drv.h |   4 +
 drivers/gpu/drm/vc4/vc4_gem.c | 185 ++
 include/uapi/drm/vc4_drm.h|  45 ++
 4 files changed, 236 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 2cfee59..97226b6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -80,6 +80,8 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 0),
DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0),
DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 0),
+   DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
+ DRM_ROOT_ONLY),
 };

 static struct drm_driver vc4_drm_driver = {
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index f9927d8..080865e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -19,6 +19,8 @@ struct vc4_dev {

struct drm_fbdev_cma *fbdev;

+   struct vc4_hang_state *hang_state;
+
/* The kernel-space BO cache.  Tracks buffers that have been
 * unreferenced by all other users (refcounts of 0!) but not
 * yet freed, so we can do cheap allocations.
@@ -361,6 +363,8 @@ int vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
*data,
   struct drm_file *file_priv);
 int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
+int vc4_get_hang_state_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
 int vc4_mmap(struct file *filp, struct vm_area_struct *vma);
 int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
 void *vc4_prime_vmap(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 5fb0556..39f29e7 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -40,6 +40,186 @@ vc4_queue_hangcheck(struct drm_device *dev)
  round_jiffies_up(jiffies + msecs_to_jiffies(100)));
 }

+struct vc4_hang_state {
+   struct drm_vc4_get_hang_state user_state;
+
+   u32 bo_count;
+   struct drm_gem_object **bo;
+};
+
+static void
+vc4_free_hang_state(struct drm_device *dev, struct vc4_hang_state *state)
+{
+   unsigned int i;
+
+   mutex_lock(&dev->struct_mutex);
+   for (i = 0; i < state->user_state.bo_count; i++)
+   drm_gem_object_unreference(state->bo[i]);
+   mutex_unlock(&dev->struct_mutex);
+
+   kfree(state);
+}
+
+int
+vc4_get_hang_state_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct drm_vc4_get_hang_state *get_state = data;
+   struct drm_vc4_get_hang_state_bo *bo_state;
+   struct vc4_hang_state *kernel_state;
+   struct drm_vc4_get_hang_state *state;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   unsigned long irqflags;
+   u32 i;
+   int ret;
+
+   spin_lock_irqsave(&vc4->job_lock, irqflags);
+   kernel_state = vc4->hang_state;
+   if (!kernel_state) {
+   spin_unlock_irqrestore(&vc4->job_lock, irqflags);
+   return -ENOENT;
+   }
+   state = &kernel_state->user_state;
+
+   /* If the user's array isn't big enough, just return the
+* required array size.
+*/
+   if (get_state->bo_count < state->bo_count) {
+   get_state->bo_count = state->bo_count;
+   spin_unlock_irqrestore(&vc4->job_lock, irqflags);
+   return 0;
+   }
+
+   vc4->hang_state = NULL;
+   spin_unlock_irqrestore(&vc4->job_lock, irqflags);
+
+   /* Save the user's BO pointer, so we don't stomp it with the memcpy. */
+   state->bo = get_state->bo;
+   memcpy(get_state, state, sizeof(*state));
+
+   bo_state = kcalloc(state->bo_count, sizeof(*bo_state), GFP_KERNEL);
+   if (!bo_state) {
+   ret = -ENOMEM;
+   goto err_free;
+   }
+
+   for (i = 0; i < state->bo_count; i++) {
+   struct vc4_bo *vc4_bo = to_vc4_bo(kernel_state->bo[i]);
+   u32 handle;
+
+   ret = drm_gem_handle_create(file_priv, kernel_state->bo[i],
+   &handle);
+
+   if (ret) {
+   state->bo_count = i - 1;
+   goto err;
+   }
+   bo_state[i].handle = handle;
+   bo_state[i].paddr = vc4_bo->base.paddr;
+   bo_state[i].size = vc4_bo->base.base.size;
+   }
+
+   ret = copy_to_user((void __user *)(uintptr_t)get_state->bo,
+

[PATCH v2 8/9] drm/vc4: Add support for async pageflips.

2015-12-08 Thread Eric Anholt

An async pageflip stores the modeset to be done and executes it once
the BOs are ready to be displayed.  This gets us about 3x performance
in full screen rendering with pageflipping.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c  |  99 +-
 drivers/gpu/drm/vc4/vc4_drv.h   |  16 +
 drivers/gpu/drm/vc4/vc4_gem.c   |  40 +++
 drivers/gpu/drm/vc4/vc4_kms.c   | 149 +++-
 drivers/gpu/drm/vc4/vc4_plane.c |  40 +++
 5 files changed, 342 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 7a9f476..a319332 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -35,6 +35,7 @@
 #include "drm_atomic_helper.h"
 #include "drm_crtc_helper.h"
 #include "linux/clk.h"
+#include "drm_fb_cma_helper.h"
 #include "linux/component.h"
 #include "linux/of_device.h"
 #include "vc4_drv.h"
@@ -475,10 +476,106 @@ static irqreturn_t vc4_crtc_irq_handler(int irq, void 
*data)
return ret;
 }

+struct vc4_async_flip_state {
+   struct drm_crtc *crtc;
+   struct drm_framebuffer *fb;
+   struct drm_pending_vblank_event *event;
+
+   struct vc4_seqno_cb cb;
+};
+
+/* Called when the V3D execution for the BO being flipped to is done, so that
+ * we can actually update the plane's address to point to it.
+ */
+static void
+vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
+{
+   struct vc4_async_flip_state *flip_state =
+   container_of(cb, struct vc4_async_flip_state, cb);
+   struct drm_crtc *crtc = flip_state->crtc;
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct drm_plane *plane = crtc->primary;
+
+   vc4_plane_async_set_fb(plane, flip_state->fb);
+   if (flip_state->event) {
+   unsigned long flags;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+   drm_crtc_send_vblank_event(crtc, flip_state->event);
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+   }
+
+   drm_framebuffer_unreference(flip_state->fb);
+   kfree(flip_state);
+
+   up(&vc4->async_modeset);
+}
+
+/* Implements async (non-vblank-synced) page flips.
+ *
+ * The page flip ioctl needs to return immediately, so we grab the
+ * modeset semaphore on the pipe, and queue the address update for
+ * when V3D is done with the BO being flipped to.
+ */
+static int vc4_async_page_flip(struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  struct drm_pending_vblank_event *event,
+  uint32_t flags)
+{
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct drm_plane *plane = crtc->primary;
+   int ret = 0;
+   struct vc4_async_flip_state *flip_state;
+   struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
+   struct vc4_bo *bo = to_vc4_bo(&cma_bo->base);
+
+   flip_state = kzalloc(sizeof(*flip_state), GFP_KERNEL);
+   if (!flip_state)
+   return -ENOMEM;
+
+   drm_framebuffer_reference(fb);
+   flip_state->fb = fb;
+   flip_state->crtc = crtc;
+   flip_state->event = event;
+
+   /* Make sure all other async modesetes have landed. */
+   ret = down_interruptible(&vc4->async_modeset);
+   if (ret) {
+   kfree(flip_state);
+   return ret;
+   }
+
+   /* Immediately update the plane's legacy fb pointer, so that later
+* modeset prep sees the state that will be present when the semaphore
+* is released.
+*/
+   drm_atomic_set_fb_for_plane(plane->state, fb);
+   plane->fb = fb;
+
+   vc4_queue_seqno_cb(dev, &flip_state->cb, bo->seqno,
+  vc4_async_page_flip_complete);
+
+   /* Driver takes ownership of state on successful async commit. */
+   return 0;
+}
+
+static int vc4_page_flip(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+struct drm_pending_vblank_event *event,
+uint32_t flags)
+{
+   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
+   return vc4_async_page_flip(crtc, fb, event, flags);
+   else
+   return drm_atomic_helper_page_flip(crtc, fb, event, flags);
+}
+
 static const struct drm_crtc_funcs vc4_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = vc4_crtc_destroy,
-   .page_flip = drm_atomic_helper_page_flip,
+   .page_flip = vc4_page_flip,
.set_property = NULL,
.cursor_set = NULL, /* handled by drm_mode_cursor_universal */
.cursor_move = NULL, /* handled by drm_mode_cursor_universal */
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 0bc8c57..f9927d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/g

[PATCH v2 7/9] drm/vc4: Add support for drawing 3D frames.

2015-12-08 Thread Eric Anholt

The user submission is basically a pointer to a command list and a
pointer to uniforms.  We copy those in to the kernel, validate and
relocate them, and store the result in a GPU BO which we queue for
execution.

Signed-off-by: Eric Anholt 
---

v2: Drop support for NV shader recs (not necessary for GL), simplify
vc4_use_bo(), improve bin flush/semaphore checks, use __u32 style
types.

 drivers/gpu/drm/vc4/Makefile   |   7 +
 drivers/gpu/drm/vc4/vc4_drv.c  |  15 +-
 drivers/gpu/drm/vc4/vc4_drv.h  | 182 +++
 drivers/gpu/drm/vc4/vc4_gem.c  | 642 +++
 drivers/gpu/drm/vc4/vc4_irq.c  | 210 
 drivers/gpu/drm/vc4/vc4_packet.h   | 399 +++
 drivers/gpu/drm/vc4/vc4_render_cl.c| 634 +++
 drivers/gpu/drm/vc4/vc4_trace.h|  63 +++
 drivers/gpu/drm/vc4/vc4_trace_points.c |  14 +
 drivers/gpu/drm/vc4/vc4_v3d.c  |  37 ++
 drivers/gpu/drm/vc4/vc4_validate.c | 900 +
 include/uapi/drm/vc4_drm.h | 141 ++
 12 files changed, 3243 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/vc4/vc4_gem.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_irq.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_packet.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_render_cl.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_trace.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_trace_points.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_validate.c

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index e87a6f2..4c6a99f 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -8,12 +8,19 @@ vc4-y := \
vc4_crtc.o \
vc4_drv.o \
vc4_kms.o \
+   vc4_gem.o \
vc4_hdmi.o \
vc4_hvs.o \
+   vc4_irq.o \
vc4_plane.o \
+   vc4_render_cl.o \
+   vc4_trace_points.o \
vc4_v3d.o \
+   vc4_validate.o \
vc4_validate_shaders.o

 vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o

 obj-$(CONFIG_DRM_VC4)  += vc4.o
+
+CFLAGS_vc4_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index db58d74..2cfee59 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -74,6 +74,9 @@ static const struct file_operations vc4_drm_fops = {
 };

 static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
+   DRM_IOCTL_DEF_DRV(VC4_SUBMIT_CL, vc4_submit_cl_ioctl, 0),
+   DRM_IOCTL_DEF_DRV(VC4_WAIT_SEQNO, vc4_wait_seqno_ioctl, 0),
+   DRM_IOCTL_DEF_DRV(VC4_WAIT_BO, vc4_wait_bo_ioctl, 0),
DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 0),
DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0),
DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 0),
@@ -83,10 +86,16 @@ static struct drm_driver vc4_drm_driver = {
.driver_features = (DRIVER_MODESET |
DRIVER_ATOMIC |
DRIVER_GEM |
+   DRIVER_HAVE_IRQ |
DRIVER_PRIME),
.lastclose = vc4_lastclose,
.preclose = vc4_drm_preclose,

+   .irq_handler = vc4_irq,
+   .irq_preinstall = vc4_irq_preinstall,
+   .irq_postinstall = vc4_irq_postinstall,
+   .irq_uninstall = vc4_irq_uninstall,
+
.enable_vblank = vc4_enable_vblank,
.disable_vblank = vc4_disable_vblank,
.get_vblank_counter = drm_vblank_count,
@@ -181,9 +190,11 @@ static int vc4_drm_bind(struct device *dev)
if (ret)
goto unref;

+   vc4_gem_init(drm);
+
ret = component_bind_all(dev, drm);
if (ret)
-   goto unref;
+   goto gem_destroy;

ret = drm_dev_register(drm, 0);
if (ret < 0)
@@ -207,6 +218,8 @@ unregister:
drm_dev_unregister(drm);
 unbind_all:
component_unbind_all(dev, drm);
+gem_destroy:
+   vc4_gem_destroy(drm);
 unref:
drm_dev_unref(drm);
vc4_bo_cache_destroy(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 8945463..0bc8c57 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -49,6 +49,48 @@ struct vc4_dev {

/* Protects bo_cache and the BO stats. */
struct mutex bo_lock;
+
+   /* Sequence number for the last job queued in job_list.
+* Starts at 0 (no jobs emitted).
+*/
+   uint64_t emit_seqno;
+
+   /* Sequence number for the last completed job on the GPU.
+* Starts at 0 (no jobs completed).
+*/
+   uint64_t finished_seqno;
+
+   /* List of all struct vc4_exec_info for jobs to be executed.
+* The first job in the list is the one currently programmed
+* into ct0ca/ct1ca for execution.
+*/
+   struct list_head job_list;
+   /* List of the finished vc4_exec_infos waiting to be freed by
+* job_done_work.
+

[PATCH v2 6/9] drm/vc4: Bind and initialize the V3D engine.

2015-12-08 Thread Eric Anholt

This is the component of the GPU that does 3D rendering.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/Makefile  |   1 +
 drivers/gpu/drm/vc4/vc4_debugfs.c |   2 +
 drivers/gpu/drm/vc4/vc4_drv.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h |  13 +++
 drivers/gpu/drm/vc4/vc4_v3d.c | 225 ++
 5 files changed, 242 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/vc4_v3d.c

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index eb776a6..e87a6f2 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -11,6 +11,7 @@ vc4-y := \
vc4_hdmi.o \
vc4_hvs.o \
vc4_plane.o \
+   vc4_v3d.o \
vc4_validate_shaders.o

 vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c 
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index 6bcf96e..d76ad10 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -22,6 +22,8 @@ static const struct drm_info_list vc4_debugfs_list[] = {
{"crtc0_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)0},
{"crtc1_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)1},
{"crtc2_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)2},
+   {"v3d_ident", vc4_v3d_debugfs_ident, 0},
+   {"v3d_regs", vc4_v3d_debugfs_regs, 0},
 };

 #define VC4_DEBUGFS_ENTRIES ARRAY_SIZE(vc4_debugfs_list)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index da4be9c..db58d74 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -236,6 +236,7 @@ static struct platform_driver *const component_drivers[] = {
&vc4_hdmi_driver,
&vc4_crtc_driver,
&vc4_hvs_driver,
+   &vc4_v3d_driver,
 };

 static int vc4_platform_drm_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index bd77d55..8945463 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,7 @@ struct vc4_dev {
struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
struct vc4_crtc *crtc[3];
+   struct vc4_v3d *v3d;

struct drm_fbdev_cma *fbdev;

@@ -82,6 +83,11 @@ to_vc4_bo(struct drm_gem_object *bo)
return (struct vc4_bo *)bo;
 }

+struct vc4_v3d {
+   struct platform_device *pdev;
+   void __iomem *regs;
+};
+
 struct vc4_hvs {
struct platform_device *pdev;
void __iomem *regs;
@@ -119,6 +125,8 @@ to_vc4_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_encoder, base);
 }

+#define V3D_READ(offset) readl(vc4->v3d->regs + offset)
+#define V3D_WRITE(offset, val) writel(val, vc4->v3d->regs + offset)
 #define HVS_READ(offset) readl(vc4->hvs->regs + offset)
 #define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)

@@ -241,6 +249,11 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
 u32 vc4_plane_write_dlist(struct drm_plane *plane, u32 __iomem *dlist);
 u32 vc4_plane_dlist_size(struct drm_plane_state *state);

+/* vc4_v3d.c */
+extern struct platform_driver vc4_v3d_driver;
+int vc4_v3d_debugfs_ident(struct seq_file *m, void *unused);
+int vc4_v3d_debugfs_regs(struct seq_file *m, void *unused);
+
 /* vc4_validate_shader.c */
 struct vc4_validated_shader_info *
 vc4_validate_shader(struct drm_gem_cma_object *shader_obj);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
new file mode 100644
index 000..040ad0d
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -0,0 +1,225 @@
+/*
+ * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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 "linux/component.h"
+#include "vc4_drv.h"
+#include "vc4_regs.h"
+
+#ifdef CONFIG_DEBUG_FS
+#define REGDEF(reg) { reg, #reg }
+static const struct {
+   uint32_t reg;
+   const char *name;
+} vc4_reg_defs[] = {
+   REGDEF(V3D_IDENT0),
+   REGDEF(V3D_IDENT1),
+   REGDEF(V3D_IDENT2),
+   REGDEF(V3D_SCRATCH),
+   REGDEF(V3D_L2CACTL),
+   REGDEF(V3D_SLCACTL),
+   REGDEF(V3D_INTCTL),
+   REGDEF(V3D_INTENA),
+   REGDEF(V3D_INTDIS),
+   REGDEF(V3D_CT0CS),
+   REGDEF(V3D_CT1CS),
+   REGDEF(V3D_CT0EA),
+   REGDEF(V3D_CT1EA),
+   REGDEF(V3D_CT0CA),
+   REGDEF(V3D_CT1CA),
+   REGDEF(V3D_CT0

[PATCH v2 5/9] drm/vc4: Fix a typo in a V3D debug register.

2015-12-08 Thread Eric Anholt

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 9e4e904..4e52a0a 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -154,7 +154,7 @@
 #define V3D_PCTRS14  0x006f4
 #define V3D_PCTR15   0x006f8
 #define V3D_PCTRS15  0x006fc
-#define V3D_BGE  0x00f00
+#define V3D_DBGE 0x00f00
 #define V3D_FDBGO0x00f04
 #define V3D_FDBGB0x00f08
 #define V3D_FDBGR0x00f0c
-- 
2.6.2

[PATCH v2 4/9] drm/vc4: Add an API for creating GPU shaders in GEM BOs.

2015-12-08 Thread Eric Anholt

Since we have no MMU, the kernel needs to validate that the submitted
shader code won't make any accesses to memory that the user doesn't
control, which involves banning some operations (general purpose DMA
writes), and tracking where we need to write out pointers for other
operations (texture sampling).  Once it's validated, we return a GEM
BO containing the shader, which doesn't allow mapping for write or
exporting to other subsystems.

Signed-off-by: Eric Anholt 
---

v2: Use __u32-style types.

 drivers/gpu/drm/vc4/Makefile   |   3 +-
 drivers/gpu/drm/vc4/vc4_bo.c   | 140 
 drivers/gpu/drm/vc4/vc4_drv.c  |   9 +-
 drivers/gpu/drm/vc4/vc4_drv.h  |  50 +++
 drivers/gpu/drm/vc4/vc4_qpu_defines.h  | 264 +++
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 513 +
 include/uapi/drm/vc4_drm.h |  25 ++
 7 files changed, 999 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/vc4/vc4_qpu_defines.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_validate_shaders.c

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index 32b4f9c..eb776a6 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -10,7 +10,8 @@ vc4-y := \
vc4_kms.o \
vc4_hdmi.o \
vc4_hvs.o \
-   vc4_plane.o
+   vc4_plane.o \
+   vc4_validate_shaders.o

 vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 06cba26..18dfe3e 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -79,6 +79,12 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
struct drm_gem_object *obj = &bo->base.base;
struct vc4_dev *vc4 = to_vc4_dev(obj->dev);

+   if (bo->validated_shader) {
+   kfree(bo->validated_shader->texture_samples);
+   kfree(bo->validated_shader);
+   bo->validated_shader = NULL;
+   }
+
vc4->bo_stats.num_allocated--;
vc4->bo_stats.size_allocated -= obj->size;
drm_gem_cma_free_object(obj);
@@ -315,6 +321,12 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
goto out;
}

+   if (bo->validated_shader) {
+   kfree(bo->validated_shader->texture_samples);
+   kfree(bo->validated_shader);
+   bo->validated_shader = NULL;
+   }
+
bo->free_time = jiffies;
list_add(&bo->size_head, cache_list);
list_add(&bo->unref_head, &vc4->bo_cache.time_list);
@@ -347,6 +359,78 @@ static void vc4_bo_cache_time_timer(unsigned long data)
schedule_work(&vc4->bo_cache.time_work);
 }

+struct dma_buf *
+vc4_prime_export(struct drm_device *dev, struct drm_gem_object *obj, int flags)
+{
+   struct vc4_bo *bo = to_vc4_bo(obj);
+
+   if (bo->validated_shader) {
+   DRM_ERROR("Attempting to export shader BO\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   return drm_gem_prime_export(dev, obj, flags);
+}
+
+int vc4_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+   struct drm_gem_object *gem_obj;
+   struct vc4_bo *bo;
+   int ret;
+
+   ret = drm_gem_mmap(filp, vma);
+   if (ret)
+   return ret;
+
+   gem_obj = vma->vm_private_data;
+   bo = to_vc4_bo(gem_obj);
+
+   if (bo->validated_shader && (vma->vm_flags & VM_WRITE)) {
+   DRM_ERROR("mmaping of shader BOs for writing not allowed.\n");
+   return -EINVAL;
+   }
+
+   /*
+* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
+* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
+* the whole buffer.
+*/
+   vma->vm_flags &= ~VM_PFNMAP;
+   vma->vm_pgoff = 0;
+
+   ret = dma_mmap_writecombine(bo->base.base.dev->dev, vma,
+   bo->base.vaddr, bo->base.paddr,
+   vma->vm_end - vma->vm_start);
+   if (ret)
+   drm_gem_vm_close(vma);
+
+   return ret;
+}
+
+int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
+{
+   struct vc4_bo *bo = to_vc4_bo(obj);
+
+   if (bo->validated_shader && (vma->vm_flags & VM_WRITE)) {
+   DRM_ERROR("mmaping of shader BOs for writing not allowed.\n");
+   return -EINVAL;
+   }
+
+   return drm_gem_cma_prime_mmap(obj, vma);
+}
+
+void *vc4_prime_vmap(struct drm_gem_object *obj)
+{
+   struct vc4_bo *bo = to_vc4_bo(obj);
+
+   if (bo->validated_shader) {
+   DRM_ERROR("mmaping of shader BOs not allowed.\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   return drm_gem_cma_prime_vmap(obj);
+}
+
 int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
@@ -387,6 +471,62 @@ int vc4_mmap_bo_ioctl(struct drm_device *de

[PATCH v2 3/9] drm/vc4: Add create and map BO ioctls.

2015-12-08 Thread Eric Anholt

While there exist dumb APIs for creating and mapping BOs, one of the
rules is that drivers doing 3D acceleration have to provide their own
APIs for buffer allocation (besides, the pitch/height parameters of
the dumb alloc don't really make sense for a lot of 3D allocations).

Signed-off-by: Eric Anholt 
---

v2: Use __u32-style types, use "drm.h" instead of .

 drivers/gpu/drm/vc4/vc4_bo.c  | 41 ++
 drivers/gpu/drm/vc4/vc4_drv.c |  3 ++
 drivers/gpu/drm/vc4/vc4_drv.h |  4 +++
 include/uapi/drm/Kbuild   |  1 +
 include/uapi/drm/vc4_drm.h| 68 +++
 5 files changed, 117 insertions(+)
 create mode 100644 include/uapi/drm/vc4_drm.h

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 18faa5b..06cba26 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -19,6 +19,7 @@
  */

 #include "vc4_drv.h"
+#include "uapi/drm/vc4_drm.h"

 static void vc4_bo_stats_dump(struct vc4_dev *vc4)
 {
@@ -346,6 +347,46 @@ static void vc4_bo_cache_time_timer(unsigned long data)
schedule_work(&vc4->bo_cache.time_work);
 }

+int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_vc4_create_bo *args = data;
+   struct vc4_bo *bo = NULL;
+   int ret;
+
+   /*
+* We can't allocate from the BO cache, because the BOs don't
+* get zeroed, and that might leak data between users.
+*/
+   bo = vc4_bo_create(dev, args->size, false);
+   if (!bo)
+   return -ENOMEM;
+
+   ret = drm_gem_handle_create(file_priv, &bo->base.base, &args->handle);
+   drm_gem_object_unreference_unlocked(&bo->base.base);
+
+   return ret;
+}
+
+int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_vc4_mmap_bo *args = data;
+   struct drm_gem_object *gem_obj;
+
+   gem_obj = drm_gem_object_lookup(dev, file_priv, args->handle);
+   if (!gem_obj) {
+   DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
+   return -EINVAL;
+   }
+
+   /* The mmap offset was set up at BO allocation time. */
+   args->offset = drm_vma_node_offset_addr(&gem_obj->vma_node);
+
+   drm_gem_object_unreference_unlocked(gem_obj);
+   return 0;
+}
+
 void vc4_bo_cache_init(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index da041fa..5fa4688 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -16,6 +16,7 @@
 #include 
 #include "drm_fb_cma_helper.h"

+#include "uapi/drm/vc4_drm.h"
 #include "vc4_drv.h"
 #include "vc4_regs.h"

@@ -73,6 +74,8 @@ static const struct file_operations vc4_drm_fops = {
 };

 static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
+   DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 0),
+   DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0),
 };

 static struct drm_driver vc4_drm_driver = {
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 39a1ff5..fddb0a0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -155,6 +155,10 @@ int vc4_dumb_create(struct drm_file *file_priv,
struct drm_mode_create_dumb *args);
 struct dma_buf *vc4_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj, int flags);
+int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv);
+int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
 void vc4_bo_cache_init(struct drm_device *dev);
 void vc4_bo_cache_destroy(struct drm_device *dev);
 int vc4_bo_stats_debugfs(struct seq_file *m, void *arg);
diff --git a/include/uapi/drm/Kbuild b/include/uapi/drm/Kbuild
index 38d4370..974fcd5 100644
--- a/include/uapi/drm/Kbuild
+++ b/include/uapi/drm/Kbuild
@@ -17,4 +17,5 @@ header-y += tegra_drm.h
 header-y += via_drm.h
 header-y += vmwgfx_drm.h
 header-y += msm_drm.h
+header-y += vc4_drm.h
 header-y += virtgpu_drm.h
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
new file mode 100644
index 000..219d34c
--- /dev/null
+++ b/include/uapi/drm/vc4_drm.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright Â© 2014-2015 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission

[PATCH v2 2/9] drm/vc4: Add a BO cache.

2015-12-08 Thread Eric Anholt

We need to allocate new BOs in the kernel as part of each frame, but
the CMA allocator is way too slow for that.  As an optimization, keep
track of recently-freed BOs and reuse them, with a 1 second timeout to
fully free them back to the system.

This improves 3D performance by about 15%.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c  | 336 +-
 drivers/gpu/drm/vc4/vc4_debugfs.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.c |   6 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  49 +-
 4 files changed, 384 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index ab9f510..18faa5b 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -12,19 +12,229 @@
  * access to system memory with no MMU in between.  To support it, we
  * use the GEM CMA helper functions to allocate contiguous ranges of
  * physical memory for our BOs.
+ *
+ * Since the CMA allocator is very slow, we keep a cache of recently
+ * freed BOs around so that the kernel's allocation of objects for 3D
+ * rendering can return quickly.
  */

 #include "vc4_drv.h"

-struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
+static void vc4_bo_stats_dump(struct vc4_dev *vc4)
+{
+   DRM_INFO("num bos allocated: %d\n",
+vc4->bo_stats.num_allocated);
+   DRM_INFO("size bos allocated: %dkb\n",
+vc4->bo_stats.size_allocated / 1024);
+   DRM_INFO("num bos used: %d\n",
+vc4->bo_stats.num_allocated - vc4->bo_stats.num_cached);
+   DRM_INFO("size bos used: %dkb\n",
+(vc4->bo_stats.size_allocated -
+ vc4->bo_stats.size_cached) / 1024);
+   DRM_INFO("num bos cached: %d\n",
+vc4->bo_stats.num_cached);
+   DRM_INFO("size bos cached: %dkb\n",
+vc4->bo_stats.size_cached / 1024);
+}
+
+#ifdef CONFIG_DEBUG_FS
+int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_bo_stats stats;
+
+   /* Take a snapshot of the current stats with the lock held. */
+   mutex_lock(&vc4->bo_lock);
+   stats = vc4->bo_stats;
+   mutex_unlock(&vc4->bo_lock);
+
+   seq_printf(m, "num bos allocated: %d\n",
+  stats.num_allocated);
+   seq_printf(m, "size bos allocated: %dkb\n",
+  stats.size_allocated / 1024);
+   seq_printf(m, "num bos used: %d\n",
+  stats.num_allocated - stats.num_cached);
+   seq_printf(m, "size bos used: %dkb\n",
+  (stats.size_allocated - stats.size_cached) / 1024);
+   seq_printf(m, "num bos cached: %d\n",
+  stats.num_cached);
+   seq_printf(m, "size bos cached: %dkb\n",
+  stats.size_cached / 1024);
+
+   return 0;
+}
+#endif
+
+static uint32_t bo_page_index(size_t size)
+{
+   return (size / PAGE_SIZE) - 1;
+}
+
+/* Must be called with bo_lock held. */
+static void vc4_bo_destroy(struct vc4_bo *bo)
 {
+   struct drm_gem_object *obj = &bo->base.base;
+   struct vc4_dev *vc4 = to_vc4_dev(obj->dev);
+
+   vc4->bo_stats.num_allocated--;
+   vc4->bo_stats.size_allocated -= obj->size;
+   drm_gem_cma_free_object(obj);
+}
+
+/* Must be called with bo_lock held. */
+static void vc4_bo_remove_from_cache(struct vc4_bo *bo)
+{
+   struct drm_gem_object *obj = &bo->base.base;
+   struct vc4_dev *vc4 = to_vc4_dev(obj->dev);
+
+   vc4->bo_stats.num_cached--;
+   vc4->bo_stats.size_cached -= obj->size;
+
+   list_del(&bo->unref_head);
+   list_del(&bo->size_head);
+}
+
+static struct list_head *vc4_get_cache_list_for_size(struct drm_device *dev,
+size_t size)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   uint32_t page_index = bo_page_index(size);
+
+   if (vc4->bo_cache.size_list_size <= page_index) {
+   uint32_t new_size = max(vc4->bo_cache.size_list_size * 2,
+   page_index + 1);
+   struct list_head *new_list;
+   uint32_t i;
+
+   new_list = kmalloc_array(new_size, sizeof(struct list_head),
+GFP_KERNEL);
+   if (!new_list)
+   return NULL;
+
+   /* Rebase the old cached BO lists to their new list
+* head locations.
+*/
+   for (i = 0; i < vc4->bo_cache.size_list_size; i++) {
+   struct list_head *old_list =
+   &vc4->bo_cache.size_list[i];
+
+   if (list_empty(old_list))
+   INIT_LIST_HEAD(&new_list[i]);
+   else
+

[PATCH v2 1/9] drm: Create a driver hook for allocating GEM object structs.

2015-12-08 Thread Eric Anholt

The CMA helpers had no way for a driver to extend the struct with its
own fields.  Since the CMA helpers are mostly "Allocate a
drm_gem_cma_object, then fill in a few fields", it's hard to write as
pure helpers without passing in a driver callback for the allocate
step.

Signed-off-by: Eric Anholt 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 10 ++
 include/drm/drmP.h   |  7 +++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index e109b49..0f7b00ba 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -59,11 +59,13 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
struct drm_gem_object *gem_obj;
int ret;

-   cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
-   if (!cma_obj)
+   if (drm->driver->gem_create_object)
+   gem_obj = drm->driver->gem_create_object(drm, size);
+   else
+   gem_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
+   if (!gem_obj)
return ERR_PTR(-ENOMEM);
-
-   gem_obj = &cma_obj->base;
+   cma_obj = container_of(gem_obj, struct drm_gem_cma_object, base);

ret = drm_gem_object_init(drm, gem_obj, size);
if (ret)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 0b921ae..22ff162 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -580,6 +580,13 @@ struct drm_driver {
int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);

+   /**
+* Hook for allocating the GEM object struct, for use by core
+* helpers.
+*/
+   struct drm_gem_object *(*gem_create_object)(struct drm_device *dev,
+   size_t size);
+
/* prime: */
/* export handle -> fd (see drm_gem_prime_handle_to_fd() helper) */
int (*prime_handle_to_fd)(struct drm_device *dev, struct drm_file 
*file_priv,
-- 
2.6.2

[PATCH v2 0/9] VC4 3D rendering support.

2015-12-08 Thread Eric Anholt

Updated version of the patch series for Emil's comments about
vc4_drm.h.  I also pulled in some improvements to the validation code
which I'd written in Mesa and failed to propagate to this branch.

The series can be found at:

https://github.com/anholt/linux/tree/vc4-kms-v3d-squash-2

and a version for booting and testing can be found at:

https://github.com/anholt/linux/tree/vc4-kms-v3d-squash-2-boot

Eric Anholt (9):
  drm: Create a driver hook for allocating GEM object structs.
  drm/vc4: Add a BO cache.
  drm/vc4: Add create and map BO ioctls.
  drm/vc4: Add an API for creating GPU shaders in GEM BOs.
  drm/vc4: Fix a typo in a V3D debug register.
  drm/vc4: Bind and initialize the V3D engine.
  drm/vc4: Add support for drawing 3D frames.
  drm/vc4: Add support for async pageflips.
  drm/vc4: Add an interface for capturing the GPU state after a hang.

 drivers/gpu/drm/drm_gem_cma_helper.c   |  10 +-
 drivers/gpu/drm/vc4/Makefile   |  11 +-
 drivers/gpu/drm/vc4/vc4_bo.c   | 517 -
 drivers/gpu/drm/vc4/vc4_crtc.c |  99 +++-
 drivers/gpu/drm/vc4/vc4_debugfs.c  |   3 +
 drivers/gpu/drm/vc4/vc4_drv.c  |  36 +-
 drivers/gpu/drm/vc4/vc4_drv.h  | 318 +-
 drivers/gpu/drm/vc4/vc4_gem.c  | 867 +++
 drivers/gpu/drm/vc4/vc4_irq.c  | 210 +++
 drivers/gpu/drm/vc4/vc4_kms.c  | 149 -
 drivers/gpu/drm/vc4/vc4_packet.h   | 399 +
 drivers/gpu/drm/vc4/vc4_plane.c|  40 ++
 drivers/gpu/drm/vc4/vc4_qpu_defines.h  | 264 +
 drivers/gpu/drm/vc4/vc4_regs.h |   2 +-
 drivers/gpu/drm/vc4/vc4_render_cl.c| 634 
 drivers/gpu/drm/vc4/vc4_trace.h|  63 ++
 drivers/gpu/drm/vc4/vc4_trace_points.c |  14 +
 drivers/gpu/drm/vc4/vc4_v3d.c  | 262 +
 drivers/gpu/drm/vc4/vc4_validate.c | 900 +
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 513 
 include/drm/drmP.h |   7 +
 include/uapi/drm/Kbuild|   1 +
 include/uapi/drm/vc4_drm.h | 279 +
 23 files changed, 5577 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/vc4/vc4_gem.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_irq.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_packet.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_qpu_defines.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_render_cl.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_trace.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_trace_points.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_v3d.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_validate.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_validate_shaders.c
 create mode 100644 include/uapi/drm/vc4_drm.h

-- 
2.6.2

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

2015-12-08 Thread Tomi Valkeinen



On 08/12/15 10:19, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote:
>>
>> On 25/08/15 16:45, Daniel Vetter wrote:
>>> When the usual fbcon legacy options are enabled we have
>>> ->register_framebuffer
>>>   ->fb notifier chain calls into fbcon
>>> ->fbcon sets up console on new fbi
>>>   ->fbi->set_par
>>> ->drm_fb_helper_set_par exercises full kms api
>>>
>>> And because of locking inversion hilarity all of register_framebuffer
>>> is done with the console lock held. Which means that the first time on
>>> driver load we exercise _all_ the kms code (all probe paths and
>>> modeset paths for everything connected) is under the console lock.
>>> That means if anything goes belly-up in that big pile of code nothing
>>> ever reaches logfiles (and the machine is dead).
>>>
>>> Usual tactic to debug that is to temporarily remove those console_lock
>>> calls to be able to capture backtraces. I'm fed up writing this patch
>>> and recompiling kernels. Hence this patch here to add an unsafe,
>>> kernel-taining option to do this at runtime.
>>
>> I think this was never merged. This was part 4 of 4, were there
>> dependencies or...? Should I apply this for 4.5?
> 
> Patches 1-3 have all already landed in drm, and patch 4 is free standing.
> Would be great if you can pull it in.

Ok, I'll apply for 4.5.

>> But then... I think my issues with console lock have been later at
>> runtime, not at register. Maybe we need a module option to disable the
>> console lock altogether. I wonder how much havoc that might create, though.
> 
> Hm, where in fbdev do you hold the console_lock outside of
> registering/unregistering an fbdev (because of fbcon)? There's of course
> general trouble with console_lock deadlocks and fun like that, but ime
> that all got a lot more manageable since I added lockdep annotations to
> console_lock.

I don't know... I just have a vague recollection that I was having
trouble with the lock with... crashes during blanking, perhaps. I really
can't remember, so possibly things are better now, or I just remember wrong.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/a1acfb5b/attachment.sig>

[PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

2015-12-08 Thread Russell King - ARM Linux

On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
> > On 8 December 2015 at 08:49, Daniel Vetter  
> > wrote:
> > > In my quest to remove all the drm_encoder_helper_funcs->save/restore
> > > hooks I somehow missed that this driver has a dummy set too - I
> > > thought all the i2c drivers only set up the slave_encoder save/restore
> > > hooks, which I've left. Remove them.
> > >
> > There was an identical patch from Rodrigo a couple of days ago
> 
> couple = less than 1 ;-) But thanks for pointing out, merged that patch
> instead.

I'd be nice if Rodrigo's patch was copied to me.  I've some patches
outstanding (the atomic mode set) which I need to send to David, but
this change should not conflict.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Intel-gfx] i915 Skylake crash on 4.4-rc3

2015-12-08 Thread Tvrtko Ursulin


Hi,

On 07/12/15 19:25, Andy Lutomirski wrote:
> [53834.386369] traps: gnome-session-b[2308] general protection
> ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
> libc-2.22.so[7f10efba1000+1b7000]
> [53834.687584] [ cut here ]
> [53834.687607] WARNING: CPU: 0 PID: 23730 at
> drivers/gpu/drm/i915/i915_gem_context.c:144
> i915_gem_context_free+0x196/0x1c0 [i915]()
> [53834.687609] WARN_ON(!list_empty(&ppgtt->base.active_list))

It is a false positive, or a wrong warning in other words, the removal 
of which is already in the queue.

Regards,

Tvrtko

[PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

2015-12-08 Thread Daniel Vetter

In my quest to remove all the drm_encoder_helper_funcs->save/restore
hooks I somehow missed that this driver has a dummy set too - I
thought all the i2c drivers only set up the slave_encoder save/restore
hooks, which I've left. Remove them.

Reported-by: Stephen Rothwell 
Cc: Stephen Rothwell 
Cc: Thierry Reding 
Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 896b6aaf8c4d..79cb9208530e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -855,18 +855,6 @@ static void tda998x_encoder_dpms(struct drm_encoder 
*encoder, int mode)
priv->dpms = mode;
 }

-static void
-tda998x_encoder_save(struct drm_encoder *encoder)
-{
-   DBG("");
-}
-
-static void
-tda998x_encoder_restore(struct drm_encoder *encoder)
-{
-   DBG("");
-}
-
 static bool
 tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
  const struct drm_display_mode *mode,
@@ -1351,8 +1339,6 @@ static void tda998x_encoder_commit(struct drm_encoder 
*encoder)

 static const struct drm_encoder_helper_funcs tda998x_encoder_helper_funcs = {
.dpms = tda998x_encoder_dpms,
-   .save = tda998x_encoder_save,
-   .restore = tda998x_encoder_restore,
.mode_fixup = tda998x_encoder_mode_fixup,
.prepare = tda998x_encoder_prepare,
.commit = tda998x_encoder_commit,
-- 
2.5.1

[PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

2015-12-08 Thread Daniel Vetter

We want this for consistency with existing page_flip semantics.

Since this spurred quite a discussion on IRC also document why we
reject even generation when the pipe is off: It's not that it's hard
to implement, but userspace has a track recording proofing that it's
way too easy to accidentally abuse and cause havoc. We want to make
sure userspace doesn't get away with that.

v2: Somehow thought we do reject events already, but that code only
existed in my imagination ... Also suggestions from Thierry.

Cc: Daniel Stone 
Cc: Ville SyrjÃ¤lÃ¤ 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c| 16 
 drivers/gpu/drm/drm_atomic_helper.c |  9 +
 include/drm/drm_crtc.h  |  3 ++-
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 07ab75e22b2b..029377513b1d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -508,6 +508,22 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return -EINVAL;
}

+   /*
+* Reject event generation for when a CRTC is off and stays off.
+* It wouldn't be hard to implement this, but userspace has a track
+* record of happily burning through 100% cpu (or worse, crash) when the
+* display pipe is suspended. To avoid all that fun just reject updates
+* that ask for events since likely that indicates a bug in the
+* compositor's drawing loop. This is consistent with the vblank IOCTL
+* and legacy page_flip IOCTL which also reject service on a disabled
+* pipe.
+*/
+   if (state->event && !state->active && !crtc->state->active) {
+   DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event but off\n",
+crtc->base.id);
+   return -EINVAL;
+   }
+
return 0;
 }

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 76c124b2a775..9eb367cad790 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2282,6 +2282,15 @@ retry:
goto fail;
drm_atomic_set_fb_for_plane(plane_state, fb);

+   /* Make sure we don't accidentally do a full modeset. */
+   state->allow_modeset = false;
+   if (!crtc_state->active) {
+   DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
+crtc->base.id);
+   ret = -EINVAL;
+   goto fail;
+   }
+
ret = drm_atomic_async_commit(state);
if (ret != 0)
goto fail;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6fe14a773def..6da847a6cb2f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -548,7 +548,8 @@ struct drm_crtc_funcs {
 * ->page_flip() operation is already pending the callback should return
 * -EBUSY. Pageflips on a disabled CRTC (either by setting a NULL mode
 * or just runtime disabled through DPMS respectively the new atomic
-* "ACTIVE" state) should result in an -EINVAL error code.
+* "ACTIVE" state) should result in an -EINVAL error code. Note that
+* drm_atomic_helper_page_flip() checks this already for atomic drivers.
 */
int (*page_flip)(struct drm_crtc *crtc,
 struct drm_framebuffer *fb,
-- 
2.5.1

[PATCH 3/5] drm: Move more framebuffer doc from docbook to kerneldoc

2015-12-08 Thread Daniel Vetter

I missed a few paragraphs in the docbook that need to be pulled into
the fbdev vfunc docs.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl | 72 +-
 include/drm/drm_crtc.h | 18 ++-
 2 files changed, 18 insertions(+), 72 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 5698c93dae8b..0c02ba0d0750 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -986,10 +986,7 @@ int max_width, max_height;
 !Idrivers/gpu/drm/drm_atomic.c
 
 
-  Frame Buffer Creation
-  struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
-struct drm_file *file_priv,
-struct drm_mode_fb_cmd2 
*mode_cmd);
+  Frame Buffer Abstraction
   
 Frame buffers are abstract memory objects that provide a source of
 pixels to scanout to a CRTC. Applications explicitly request the
@@ -1008,73 +1005,6 @@ int max_width, max_height;
and so expects TTM handles in the create ioctl and not GEM handles.
   
   
-Drivers must first validate the requested frame buffer parameters 
passed
-through the mode_cmd argument. In particular this is where invalid
-sizes, pixel formats or pitches can be caught.
-  
-  
-If the parameters are deemed valid, drivers then create, initialize and
-return an instance of struct drm_framebuffer.
-If desired the instance can be embedded in a larger driver-specific
-   structure. Drivers must fill its width,
-   height, pitches,
-offsets, depth,
-bits_per_pixel and
-pixel_format fields from the values passed
-through the drm_mode_fb_cmd2 argument. They
-should call the drm_helper_mode_fill_fb_struct
-helper function to do so.
-  
-
-  
-   The initialization of the new framebuffer instance is finalized with a
-   call to drm_framebuffer_init which takes a pointer
-   to DRM frame buffer operations (struct
-   drm_framebuffer_funcs). Note that this function
-   publishes the framebuffer and so from this point on it can be accessed
-   concurrently from other threads. Hence it must be the last step in the
-   driver's framebuffer initialization sequence. Frame buffer operations
-   are
-
-  
-int (*create_handle)(struct drm_framebuffer *fb,
-struct drm_file *file_priv, unsigned int 
*handle);
-
-  Create a handle to the frame buffer underlying memory object. If
-  the frame buffer uses a multi-plane format, the handle will
-  reference the memory object associated with the first plane.
-
-
-  Drivers call drm_gem_handle_create to create
-  the handle.
-
-  
-  
-void (*destroy)(struct drm_framebuffer 
*framebuffer);
-
-  Destroy the frame buffer object and frees all associated
-  resources. Drivers must call
-  drm_framebuffer_cleanup to free resources
-  allocated by the DRM core for the frame buffer object, and must
-  make sure to unreference all memory objects associated with the
-  frame buffer. Handles created by the
-  create_handle operation are released by
-  the DRM core.
-
-  
-  
-int (*dirty)(struct drm_framebuffer *framebuffer,
-struct drm_file *file_priv, unsigned flags, unsigned color,
-struct drm_clip_rect *clips, unsigned num_clips);
-
-  This optional operation notifies the driver that a region of the
-  frame buffer has changed in response to a DRM_IOCTL_MODE_DIRTYFB
-  ioctl call.
-
-  
-
-  
-  
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
drm_framebuffer_referenceand drop them
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4f587a5bc88f..6fe14a773def 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -172,7 +172,9 @@ struct drm_framebuffer_funcs {
 * Clean up framebuffer resources, specifically also unreference the
 * backing storage. The core guarantees to call this function for every
 * framebuffer successfully created by ->fb_create() in
-* &drm_mode_config_funcs.
+* &drm_mode_config_funcs. Drivers must also call
+* drm_framebuffer_cleanup() to release DRM core resources for this
+* framebuffer.
 */
void (*destroy)(struct drm_framebuffer *framebuffer);

@@ -187,6 +189,9 @@ struct drm_framebuffer_funcs {
 * copying the c

[PATCH 2/5] drm/atomic-helper: Drop unneeded argument from check_pending_encoder

2015-12-08 Thread Daniel Vetter

Just a remnant from an old iteration of this patch that I've forgotten
to remove: We only need the encoder to figure out whether it has been
reassigned in this update already or not to figure out whether there's
a conflict or not.

Reported-by: Thierry Reding 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 110f3db8dd05..76c124b2a775 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -88,8 +88,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,

 static bool
 check_pending_encoder_assignment(struct drm_atomic_state *state,
-struct drm_encoder *new_encoder,
-struct drm_connector *new_connector)
+struct drm_encoder *new_encoder)
 {
struct drm_connector *connector;
struct drm_connector_state *conn_state;
@@ -256,7 +255,7 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
return 0;
}

-   if (!check_pending_encoder_assignment(state, new_encoder, connector)) {
+   if (!check_pending_encoder_assignment(state, new_encoder)) {
DRM_DEBUG_ATOMIC("Encoder for [CONNECTOR:%d:%s] already 
assigned\n",
 connector->base.id,
 connector->name);
-- 
2.5.1

[PATCH 1/5] [RFC] drm: Documentation style guide

2015-12-08 Thread Daniel Vetter

Every time I type or review docs this seems a bit different. Try to
document the common style so we can try to unify at least new docs.

Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl | 37 +
 1 file changed, 37 insertions(+)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 86e5b12a49ba..5698c93dae8b 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -124,6 +124,43 @@
 
   [Insert diagram of typical DRM stack here]
 
+  
+Style Guidelines
+
+  For consistency these documentations use American English. Abbreviations
+  are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so
+  on. To aid in reading documentations make full use of the markup
+  characters kerneldoc provides: @parameter for function paramters, @member
+  for structure members, &structure to refernce structures and
+  function() for functions. These all get automatically hyperlinked if
+  kerneldoc for the referencec objects exists When referencing entries in
+  function vtables please use -

[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-08 Thread Krzysztof Kozlowski

On 08.12.2015 00:36, Inki Dae wrote:
> Hi Javier,
> 
> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas  osg.samsung.com>:
>> Hello Inki,
>>
>> On 12/07/2015 09:52 AM, Inki Dae wrote:
>>> From: Javier Martinez Canillas 
>>>
>>
>> Thanks a lot for posting this patch.
>>
>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
>>> since it uses a phandle to describe the connection between the DP port and
>>> the display panel but uses the OF graph ports and endpoints to describe the
>>> connection betwen the DP port, a bridge chip and the panel.
>>>
>>> The Exynos DP driver and the DT binding have been changed to allow also to
>>> describe the DP port to panel connection using ports / endpoints (OF graph)
>>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
>>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>> Tested-by: Javier Martinez Canillas 
>>
>> This tag was not in my original patch, it's true that I tested
>> it but will someone believe me? ;)
> 
> Oops. I confused you spread Reviewed-by and Tested-by here and there.
> Don't worry about that. Will remove it if you don't give me Tested-by.
> :)

Actually authorship (the "From") in this case means Tested-by. Author
always tests the patch so it would look weird if we start adding
tested-by to our own patches, right?

Dear Inki,
However the patch misses your SoB. You touched and sent it so please
extend the SoB chain-of-blame.

Best regards,
Krzysztof

[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-08 Thread Krzysztof Kozlowski

On 07.12.2015 21:52, Inki Dae wrote:
> From: Javier Martinez Canillas 
> 
> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
> since it uses a phandle to describe the connection between the DP port and
> the display panel but uses the OF graph ports and endpoints to describe the
> connection betwen the DP port, a bridge chip and the panel.
> 
> The Exynos DP driver and the DT binding have been changed to allow also to
> describe the DP port to panel connection using ports / endpoints (OF graph)
> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
> 
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Javier Martinez Canillas 
> Reviewed-by: Inki Dae 
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 

Looks sensible:
Reviewed-by: Krzysztof Kozlowski 

Dependencies are not mentioned, does it depend on patch 1?

Best regards,
Krzysztof

[PATCH 8/9] drm/atomic: Remove drm_atomic_connectors_for_crtc.

2015-12-08 Thread Maarten Lankhorst

Op 07-12-15 om 11:34 schreef Thierry Reding:
> On Tue, Nov 24, 2015 at 10:34:35AM +0100, Maarten Lankhorst wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index cee31d43cd1c..fb79c54b2aed 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -420,8 +420,6 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>   * crtc only changed its mode but has the same set of connectors.
>>   */
>>  for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -int num_connectors;
>> -
>>  /*
>>   * We must set ->active_changed after walking connectors for
>>   * otherwise an update that only changes active would result in
>> @@ -449,10 +447,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  if (ret != 0)
>>  return ret;
>>  
>> -num_connectors = drm_atomic_connectors_for_crtc(state,
>> -crtc);
>> -
>> -if (crtc_state->enable != !!num_connectors) {
>> +if (crtc_state->enable != !!crtc_state->connector_mask) {
> I have difficulty to doubly negate in my head, so something like this
> would be a lot clearer in my opinion:
Maybe if enable == !connector_mask?

>   bool enable = crtc_state->connector_mask != 0;
>
>   ...
>
>   if (crtc_state->enable != enable)
>   ...
>
> Or perhaps even:
>
>   bool disable = crtc_state->connector_mask == 0;
>
>   ...
>
>   if (crtc_state->enable == disable)
>   ...
>
>>  DRM_DEBUG_ATOMIC("[CRTC:%d] enabled/connectors 
>> mismatch\n",
>>   crtc->base.id);
>>  
>> @@ -1668,7 +1663,7 @@ static int update_output_state(struct drm_atomic_state 
>> *state,
>>  if (crtc == set->crtc)
>>  continue;
>>  
>> -if (!drm_atomic_connectors_for_crtc(state, crtc)) {
>> +if (!crtc_state->connector_mask) {
> Similarly I think it would be more natural to say:
>
>   if (crtc->state->connector_mask == 0)
>
> here.
>
> Anyway, this is mostly about personal taste, and the change looks
> correct to me (after checking twice that I got the double negation
> right), so:
>
> Reviewed-by: Thierry Reding

[PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

2015-12-08 Thread Emil Velikov

On 8 December 2015 at 08:49, Daniel Vetter  wrote:
> In my quest to remove all the drm_encoder_helper_funcs->save/restore
> hooks I somehow missed that this driver has a dummy set too - I
> thought all the i2c drivers only set up the slave_encoder save/restore
> hooks, which I've left. Remove them.
>
There was an identical patch from Rodrigo a couple of days ago

http://lists.freedesktop.org/archives/dri-devel/2015-December/096492.html

-Emil

[PATCH v2 3/4] dt-bindings: exynos-dp: update ports node binding for panel

2015-12-08 Thread Rob Herring

On Mon, Dec 07, 2015 at 09:52:37PM +0900, Inki Dae wrote:
> This patch updates a ports node binding for panel.
> 
> With this, dp node can have a ports node which describes
> a remote endpoint node that can be connected to panel or bridge
> node.
> 
> Changelog v2:
> - remove unnecessary properties and numbering.
> - update description about eDP device.
> 
> Signed-off-by: Inki Dae 
> Reviewed-by: Javier Martinez Canillas 

Acked-by: Rob Herring 

> ---
>  .../bindings/display/exynos/exynos_dp.txt  | 41 
> +++---
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..22efeba 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -1,3 +1,20 @@
> +Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
> +
> +DisplayPort is industry standard to accommodate the growing board adoption
> +of digital display technology within the PC and CE industries.
> +It consolidates the internal and external connection methods to reduce device
> +complexity and cost. It also supports necessary features for important cross
> +industry applications and provides performance scalability to enable the next
> +generation of displays that feature higher color depths, refresh rates, and
> +display resolutions.
> +
> +eDP (embedded display port) device is compliant with Embedded DisplayPort
> +standard as follows,
> +- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
> +- DisplayPort standard 1.3 for Exynos5422s and Exynos5800.
> +
> +eDP resides between FIMD and panel or FIMD and bridge such as LVDS.
> +
>  The Exynos display port interface should be configured based on
>  the type of panel connected to it.
>  
> @@ -66,8 +83,15 @@ Optional properties for dp-controller:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug
>   detection
> - -video interfaces: Device node can contain video interface port
> - nodes according to [1].
> +Video interfaces:
> +  Device node can contain video interface port nodes according to [1].
> +  The following are properties specific to those nodes:
> +
> +  endpoint node connected to bridge or panel node:
> +   - remote-endpoint: specifies the endpoint in panel or bridge node.
> +   This node is required in all kinds of exynos dp
> +   to represent the connection between dp and bridge
> +   or dp and panel.
>  
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> @@ -111,9 +135,18 @@ Board Specific portion:
>   };
>  
>   ports {
> - port at 0 {
> + port {
>   dp_out: endpoint {
> - remote-endpoint = <&bridge_in>;
> + remote-endpoint = <&dp_in>;
> + };
> + };
> + };
> +
> + panel {
> + ...
> + port {
> + dp_in: endpoint {
> + remote-endpoint = <&dp_out>;
>   };
>   };
>   };
> -- 
> 1.9.1
>

[Intel-gfx] [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe

2015-12-08 Thread Daniel Vetter

On Mon, Dec 07, 2015 at 03:33:00PM +, Daniel Stone wrote:
> Hi,
> 
> On 4 December 2015 at 08:46, Daniel Vetter  wrote:
> > +   /*
> > +* Reject event generation for when a CRTC is off and stays off. It
> > +* wouldn't be hard to implement this, but userspace has a track 
> > record
> > +* of happily burning through 100% cpu (or worse, crash) when the
> > +* display pipe is suspended. To avoid all that fun just reject 
> > updates
> > +* that ask for events since likely that indicates a bug in the
> > +* compositors drawing loop. This is consistent with the vblank 
> > ioctl
> > +* which also rejects service on a disabled pipe.
> > +*/
> 
> Sorry to keep whingeing, but this isn't actually related to event
> generation. To the best of my knowledge, this change does a few
> things. Firstly, comments the check above (enforcing that (flags &
> ALLOW_MODESET) == {crtcs}->allow_modeset), which is good. But the
> comment is incorrect, because whether or not an event is requested is
> wholly unrelated. Secondly, it disables allow_modeset on pageflip,
> which shouldn't be changing DPMS stage (good!). Thirdly, it enforces
> something like the above statement on pageflips, except again it has
> no regard to events: it just enforces the no-DPMS-on-flip rule, for
> which event generation is a subset.

Well the comment is completely misplace, I wanted to put it next to the
check for event generation, not here.

> If you fix the above comment to more accurately note that this just
> enforces that you need the ALLOW_MODESET flag to change active, mode
> or connector routing, and (as Thierry asked), add a comment below to
> note that we enforce existing no-DPMS-on-flip semantics in the helper,
> then you're welcome to my R-b. But please don't mention events in the
> new comment. :)

Hm, I didn't really want to type a comment for ALLOW_MODESET - imo it's
pretty clear what it does and why it's useful. I'll try again at making
something coheren here ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3] staging/android: add TODO to de-stage android sync framework

2015-12-08 Thread Daniel Vetter

On Mon, Dec 07, 2015 at 04:28:45PM -0200, Gustavo Padovan wrote:
> Hi,
> 
> any comments/update on this? Thanks

My ack from the previous version still stands.
-Daniel

> 
>   Gustavo
> 
> 2015-11-26 Gustavo Padovan :
> 
> > From: Gustavo Padovan 
> > 
> >  - remove CONFIG_SW_SYNC_USER, it is used only for testing/debugging and
> >should not be upstreamed.
> >  - port CONFIG_SW_SYNC_USER tests interfaces to use debugfs somehow
> >  - port libsync tests to kselftest
> >  - clean up and ABI check for security issues
> >  - move the sync framework to drivers/base/dma-buf
> > 
> > Cc: Arve HjÃ¸nnevÃ¥g 
> > Cc: Riley Andrews 
> > Cc: Daniel Vetter 
> > Cc: Rob Clark 
> > Cc: Greg Hackmann 
> > Cc: John Harrison 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/staging/android/TODO | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..64d8c87 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> > @@ -25,5 +25,13 @@ ion/
> > exposes existing cma regions and doesn't reserve unecessarily memory 
> > when
> > booting a system which doesn't use ion.
> >  
> > +sync framework:
> > + - remove CONFIG_SW_SYNC_USER, it is used only for testing/debugging and
> > + should not be upstreamed.
> > + - port CONFIG_SW_SYNC_USER tests interfaces to use debugfs somehow
> > + - port libsync tests to kselftest
> > + - clean up and ABI check for security issues
> > + - move it to drivers/base/dma-buf
> > +
> >  Please send patches to Greg Kroah-Hartman  and Cc:
> >  Arve HjÃ¸nnevÃ¥g  and Riley Andrews  > android.com>
> > -- 
> > 2.1.0
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 4/4] fbdev: Debug knob to register without holding console_lock

2015-12-08 Thread Daniel Vetter

On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote:
> 
> On 25/08/15 16:45, Daniel Vetter wrote:
> > When the usual fbcon legacy options are enabled we have
> > ->register_framebuffer
> >   ->fb notifier chain calls into fbcon
> > ->fbcon sets up console on new fbi
> >   ->fbi->set_par
> > ->drm_fb_helper_set_par exercises full kms api
> > 
> > And because of locking inversion hilarity all of register_framebuffer
> > is done with the console lock held. Which means that the first time on
> > driver load we exercise _all_ the kms code (all probe paths and
> > modeset paths for everything connected) is under the console lock.
> > That means if anything goes belly-up in that big pile of code nothing
> > ever reaches logfiles (and the machine is dead).
> > 
> > Usual tactic to debug that is to temporarily remove those console_lock
> > calls to be able to capture backtraces. I'm fed up writing this patch
> > and recompiling kernels. Hence this patch here to add an unsafe,
> > kernel-taining option to do this at runtime.
> 
> I think this was never merged. This was part 4 of 4, were there
> dependencies or...? Should I apply this for 4.5?

Patches 1-3 have all already landed in drm, and patch 4 is free standing.
Would be great if you can pull it in.

> But then... I think my issues with console lock have been later at
> runtime, not at register. Maybe we need a module option to disable the
> console lock altogether. I wonder how much havoc that might create, though.

Hm, where in fbdev do you hold the console_lock outside of
registering/unregistering an fbdev (because of fbcon)? There's of course
general trouble with console_lock deadlocks and fun like that, but ime
that all got a lot more manageable since I added lockdep annotations to
console_lock.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/3] drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state.

2015-12-08 Thread Maarten Lankhorst

Op 07-12-15 om 11:02 schreef Thierry Reding:
> On Tue, Nov 24, 2015 at 02:35:34PM +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/tegra/dsi.c | 9 +++--
>>  1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
>> index f0a138ef68ce..33ad50487f2e 100644
>> --- a/drivers/gpu/drm/tegra/dsi.c
>> +++ b/drivers/gpu/drm/tegra/dsi.c
>> @@ -745,14 +745,11 @@ static void tegra_dsi_soft_reset(struct tegra_dsi *dsi)
>>  
>>  static void tegra_dsi_connector_reset(struct drm_connector *connector)
>>  {
>> -struct tegra_dsi_state *state;
>> +struct tegra_dsi_state *state =
>> +kzalloc(sizeof(*state), GFP_KERNEL);
> I think this could use a check just for safety. It's unlikely to ever
> happen, but just in case, better allow to fail gracefully than crash.

I didn't bother because drm_atomic_helper_connector_reset has the same kind of 
failure.

~Maarten

[PATCH v10 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

2015-12-08 Thread Rob Herring

On Mon, Dec 07, 2015 at 02:40:42PM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
> 
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.

I can see this being common. Just make it "force-hpd".

Rob

> 
> Signed-off-by: Yakir Yang 
> Tested-by: Javier Martinez Canillas 
> ---
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>   hpd when hpd detect failed.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt|  4 ++-
>  .../bindings/display/exynos/exynos_dp.txt  |  1 +
>  .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 
> +++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
>  6 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> index 7659a7a..74f0e80 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
>   from general PHY binding: Should be "dp".
>  
>  Optional properties for dp-controller:
> + -analogix,need-force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.
>   -hpd-gpios:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug detection
> @@ -31,7 +34,6 @@ Optional properties for dp-controller:
>   * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>   * 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>  
> -
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> ---
>  
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 9905081..8800164 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>   -phys (required)
>   -phy-names (required)
>   -hpd-gpios (optional)
> + -analogix,need-force-hpd (optional)
>   -video interfaces (optional)
>  
>  Deprecated properties for DisplayPort:
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> index dae86c4..1f1e594 100644
> --- 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP 
> binding document:
>  - phys (required)
>  - phy-names (required)
>  - hpd-gpios (optional)
> +- analogix,need-force-hpd (optional)
>  
> ---
>  
>  Example:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a11504b..94968e4 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct 
> analogix_dp_device *dp)
>  {
>   int timeout_loop = 0;
>  
> - while (analogix_dp_get_plug_in_status(dp) != 0) {
> + while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
> + if (analogix_dp_get_plug_in_status(dp) == 0)
> + return 0;
> +
>   timeout_loop++;
> - if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
> - dev_err(dp->dev, "failed to get hpd plug status\n");
> - return -ETIMEDOUT;
> - }
>   usleep_range(10, 11);
>   }
>  
> + /*
> +  * Some edp screen do not have hpd signal, so we can't just
> +  * return failed when hpd plug in detect failed, DT property
> +  * "need-force-hpd" would indicate whether driver need this.
> +  */
> + if (!dp->need_force_hpd)
> + return -ETIMEDOUT;
> +
> + /*
> +  * The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
> +  * will n

[PATCH v10 10/17] dt-bindings: add document for rockchip dp phy

2015-12-08 Thread Rob Herring

On Mon, Dec 07, 2015 at 02:39:50PM +0800, Yakir Yang wrote:
> Add dt binding documentation for rockchip display port PHY.
> 
> Signed-off-by: Yakir Yang 
> Reviewed-by: Heiko Stuebner 

One possible typo below, otherwise:

Acked-by: Rob Herring 

> ---
> Changes in v10: None
> Changes in v9: None
> Changes in v8:
> - Remove the specific address in the example node name. (Heiko)
> 
> Changes in v7:
> - Simplify the commit message. (Kishon)
> 
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
>   elemets in document. (Rob & Heiko)
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..00902cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,22 @@
> +Rockchip Soc Seroes Display Port PHY
   ^
Is this supposed to be SerDes?

> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +  - "rockchip.rk3288-dp-phy"
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "24m"
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: edp-phy {
> + compatible = "rockchip,rk3288-dp-phy";
> + rockchip,grf = <&grf>;
> + clocks = <&cru SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +};
> -- 
> 1.9.1
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

AMD guys: commit messages?

2015-12-08 Thread Ilia Mirkin

On Tue, Dec 8, 2015 at 8:43 AM, Ernst SjÃ¶strand  wrote:
> Hello list!
>
> I lurk here and try to follow Mesa/DRI and most specifically Radeon
> driver development, report bugs, test new stuff and help get the bugs
> closed and so on...
>
> However I see that the commit messages for AMD/Radeon are often very
> unhelpful. They don't state the motivation behind the commits. Is this
> a optimization, a nice-to-have cleanup or does this actually fix
> something? What does this fix?
> Are there tests or bugreports related?
>
> Improving this could make it easier for new developers to start
> contributing in the long run also!
>
> Examples:
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750
>
> This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
> "Patch fix is not clearly described. For example, a commit message of
> only a single line, no description of the bug, no mention of bugzilla,
> etc."

So... what's the appropriate amount? Have every commit describe, in
detail, how the GPU works, how the driver works, and what little bit
of interaction is being changed? I'm not an AMD developer (I do hack
on nouveau though), but I basically get what all 3 of the above are
doing. The reason why you're having trouble is probably because you
don't know what the ingredients are -- what's a mip level, what's a
ring index, what's fence, what's a winsys, what's a "emit vertex", all
in the context of the relevant drivers. If you know what all these
things are, the above commits become much clearer. But having to
describe each of those things every time would ... not fly :)

You can usually tell a cleanup/hypothetical fix apart from a real fix
by seeing if it (a) references a bugzilla, (b) mentions a commit it
fixes, or (c) cc'd to stable.

  -ilia

[PATCH v10 08/17] dt-bindings: add document for rockchip variant of analogix_dp

2015-12-08 Thread Rob Herring

On Mon, Dec 07, 2015 at 02:39:34PM +0800, Yakir Yang wrote:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
> 
> Signed-off-by: Yakir Yang 
> Reviewed-by: Heiko Stuebner 

I already acked the previous v10 you sent.

Acked-by: Rob Herring 

> ---
> Changes in v10: None
> Changes in v9:
> - Document more details for 'ports' property.
> 
> Changes in v8:
> - Modify the commit subject name. (Heiko)
> 
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  .../display/rockchip/analogix_dp-rockchip.txt  | 91 
> ++
>  1 file changed, 91 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> new file mode 100644
> index 000..dae86c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -0,0 +1,91 @@
> +Rockchip RK3288 specific extensions to the Analogix Display Port
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-edp";
> +
> +- reg: physical base address of the controller and length
> +
> +- clocks: from common clock binding: handle to dp clock.
> +   of memory mapped region.
> +
> +- clock-names: from common clock binding:
> +Required elements: "dp" "pclk"
> +
> +- resets: Must contain an entry for each entry in reset-names.
> +   See ../reset/reset.txt for details.
> +
> +- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
> +- pinctrl-0: pin-control mode. should be <&edp_hpd>
> +
> +- reset-names: Must include the name "dp"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +
> +- ports: there are 2 port nodes with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +Port 0: contained 2 endpoints, connecting to the ouput of vop.
> +Port 1: contained 1 endpoint, connecting to the input of panel.
> +
> +For the below properties, please refer to Analogix DP binding document:
> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +- phys (required)
> +- phy-names (required)
> +- hpd-gpios (optional)
> +---
> +
> +Example:
> + dp-controller: dp at ff97 {
> + compatible = "rockchip,rk3288-dp";
> + reg = <0xff97 0x4000>;
> + interrupts = ;
> + clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
> + clock-names = "dp", "pclk";
> + phys = <&dp_phy>;
> + phy-names = "dp";
> +
> + rockchip,grf = <&grf>;
> + resets = <&cru 111>;
> + reset-names = "dp";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&edp_hpd>;
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_in: port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_in_vopb: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vopb_out_edp>;
> + };
> + edp_in_vopl: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&vopl_out_edp>;
> + };
> + };
> +
> + edp_out: port at 1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + edp_out_panel: endpoint {
> + reg = <0>;
> + remote-endpoint = <&panel_in_edp>
> + };
> + };
> + };
> + };
> +
> + pinctrl {
> + edp {
> + edp_hpd: edp-hpd {
> + rockchip,pins = <7 11 RK_FUNC_2 
> &pcfg_pull_none>;
> + };
> + };
> + };
> -- 
> 1.9.1
> 
>

[Bug 93101] GPU Fault almost burned the CPU

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Christian KÃ¶nig  ---
(In reply to Thomas DEBESSE from comment #6)
> Hi, thank you for your answer, does this mean there is no fix possible to
> prevent the driver to burn the cpu in case of hang?

No, not really.

We should of course try to fix the hang and that's why I think we should keep
this bug open, but driver bugs like this can always happen and not only in
radeon but other kernel drivers as well.

As I said that's why dedicated hardware independent of the main CPU is usually
used for things like this.

IIRC there is also a rather big warning in the fancontrol manual about this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/61e7b59c/attachment.html>

[PATCH v10 05/17] dt-bindings: add document for analogix display port driver

2015-12-08 Thread Rob Herring

On Mon, Dec 07, 2015 at 02:39:07PM +0800, Yakir Yang wrote:
> Analogix dp driver is split from exynos dp driver, so we just
> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
> 
> Beside update some exynos dtsi file with the latest change
> according to the devicetree binding documents.
> 
> Signed-off-by: Yakir Yang 
> Tested-by: Javier Martinez Canillas 

Acked-by: Rob Herring 

> ---
> Changes in v10: None
> Changes in v9: None
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> 
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Split all DTS changes, and provide backward compatibility. Mark old
>   properties as deprecated but still support them. (Krzysztof)
> - Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
> - Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
> "analogix,color-space" & "analogix,color-depth"   &
> "analogix,link-rate"   & "analogix,lane-count"&
> "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
> "vsync-active-high"& "hsync-active-high"  & "interlaces"
> 
> Changes in v3:
> - Add devicetree binding documents. (Heiko)
> - Remove sync pol & colorimetry properies from the new analogix dp driver
>   devicetree binding. (Thierry)
> - Update the exist exynos dtsi file with the latest DP DT properies.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt| 50 +
>  .../bindings/display/exynos/exynos_dp.txt  | 65 
> --
>  2 files changed, 72 insertions(+), 43 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> new file mode 100644
> index 000..7659a7a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -0,0 +1,50 @@
> +Analogix Display Port bridge bindings
> +
> +Required properties for dp-controller:
> + -compatible:
> + platform specific such as:
> +  * "samsung,exynos5-dp"
> +  * "rockchip,rk3288-dp"
> + -reg:
> + physical base address of the controller and length
> + of memory mapped region.
> + -interrupts:
> + interrupt combiner values.
> + -clocks:
> + from common clock binding: handle to dp clock.
> + -clock-names:
> + from common clock binding: Shall be "dp".
> + -interrupt-parent:
> + phandle to Interrupt combiner node.
> + -phys:
> + from general PHY binding: the phandle for the PHY device.
> + -phy-names:
> + from general PHY binding: Should be "dp".
> +
> +Optional properties for dp-controller:
> + -hpd-gpios:
> + Hotplug detect GPIO.
> + Indicates which GPIO should be used for hotplug detection
> + -port@[X]: SoC specific port nodes with endpoint definitions as defined
> + in Documentation/devicetree/bindings/media/video-interfaces.txt,
> + please refer to the SoC specific binding document:
> + * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> + * 
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> +
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +---
> +
> +Example:
> +
> + dp-controller {
> + compatible = "samsung,exynos5-dp";
> + reg = <0x145b 0x1>;
> + interrupts = <10 3>;
> + interrupt-parent = <&combiner>;
> + clocks = <&clock 342>;
> + clock-names = "dp";
> +
> + phys = <&dp_phy>;
> + phy-names = "dp";
> + };
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..9905081 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -31,45 +31,31 @@ Required properties for dp-controller:
>   from general PHY binding: the phandle for the PHY device.
>   -phy-names:
>   from general PHY binding: Should be "dp".
> - -samsung,color-space:
> - input video data format.
> - COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> - -samsung,dynamic-range:
> - dynamic range for input video data.
> - VESA = 0, CEA = 1
> - -samsung,ycbcr-coeff:
> - YCbCr co-efficients for input video.
> - COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> - -samsung,colo

[PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

2015-12-08 Thread Ilia Mirkin

On Tue, Dec 8, 2015 at 3:49 AM, Daniel Vetter  wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard

event generation?

> to implement, but userspace has a track recording proofing that it's

has a track record which proves that it's

> way too easy to accidentally abuse and cause havoc. We want to make
> sure userspace doesn't get away with that.
>
> v2: Somehow thought we do reject events already, but that code only
> existed in my imagination ... Also suggestions from Thierry.
>
> Cc: Daniel Stone 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c| 16 
>  drivers/gpu/drm/drm_atomic_helper.c |  9 +
>  include/drm/drm_crtc.h  |  3 ++-
>  3 files changed, 27 insertions(+), 1 deletion(-)

[Bug 93292] "Thea: The Awakening" world map textures not rendered (blue background)

2015-12-08 Thread bugzilla-dae...@freedesktop.org

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

Bug ID: 93292
Summary: "Thea: The Awakening" world map textures not rendered
(blue background)
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
Assignee: dri-devel at lists.freedesktop.org
Reporter: glogow at fbihome.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 120410
--> https://bugs.freedesktop.org/attachment.cgi?id=120410&action=edit
Thea with interface only world map

The problematic game can be downloaded from the link in the first message in
the following steam thread or via the steam beta channel (DRM free, free for
Linux):
https://steamcommunity.com/app/378720/discussions/0/490125737485986607?fp=2#p1

Someone else with older AMD hardware reported the same problem in the linked
communty thread. My hardware is:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV710/M92 [Mobility Radeon HD 4530/4570/545v]

When starting the actual gameplay, only the interface is rendered but not the
games world map, basically rendering the game unplayable (see attached image).

I'm on Ubuntu Trusty 14.04, 3.13 kernel. This happens with stock Mesa from the
Ubuntu release and with the git release from the oibaf PPA:
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

The apitrace is too large to upload for me (1.5 GB), but doesn't show a
particular error, except for an early glClear without a context; even the
trimmed one is 1,25GB. xz compressed is still 620MB.

The game renders correctly when started with "LIBGL_ALWAYS_SOFTWARE=1". I
confirmed this by also rendering the apitrace in software. imirkin told me on
IRC, that this actually is a bug in the r600 driver.

I've compiled Mesa git packages with "--enable-debug" and can test a patch, if
needed. I'm jmux on freenode and will be lingering around in the channel for
some time and normally can be found in the libreoffice-dev channel.

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/5da402ce/attachment.html>

1 2 >

1 - 100 of 115 matches

Mail list logo