[Bug 55420] [Wine] fails to compile GLSL shader in Falcon BMS 4.32u3

[bugzilla-dae...@freedesktop.org]

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

Ian Romanick  changed:

   What|Removed |Added

   Assignee|idr at freedesktop.org |dri-devel at 
lists.freedesktop
   ||.org
 CC||maraeo at gmail.com
  Component|glsl-compiler   |Drivers/Gallium/r600

--- Comment #1 from Ian Romanick  ---
This seems like an issue in the r600 back-end.  The glsl-compiler component is
the common front-end code.  Perhaps Marek can comment...

-- 
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/20130830/3a5ef62a/attachment-0001.html>

[Bug 68708] Intel+Radeon Hybrid laptop hang on boot while being on the battery

[bugzilla-dae...@freedesktop.org]

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #84931|0   |1
is obsolete||

--- Comment #4 from Alex Deucher  ---
Created attachment 84933
  --> https://bugs.freedesktop.org/attachment.cgi?id=84933=edit
possible fix

Functionally the same as the previous one, but cleaner.

-- 
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/20130830/ae13670c/attachment.html>

[Bug 68708] Intel+Radeon Hybrid laptop hang on boot while being on the battery

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Alex Deucher  ---
Created attachment 84931
  --> https://bugs.freedesktop.org/attachment.cgi?id=84931=edit
possible fix

Does this patch fix the issue?

-- 
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/20130830/7772f8ee/attachment.html>

[PATCH 1/1] drm/exynos: Fix build error with exynos_drm_connector.c

[Inki Dae]

> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Friday, August 30, 2013 6:11 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; sachin.kamat at linaro.org; patches at 
> linaro.org;
> Andrzej Hajda
> Subject: [PATCH 1/1] drm/exynos: Fix build error with
> exynos_drm_connector.c
> 
> exynos_drm_connector.c now uses videomode helper API. Hence select
> VIDEOMODE_HELPERS at DRM_EXYNOS level itself instead of at
> DRM_EXYNOS_FIMD to avoid the following compilation error when FIMD
> is not selected (introduced by commit cf796235a6 "drm/exynos: fimd:
> replace struct fb_videomode with videomode"):
> drivers/built-in.o: In function `exynos_drm_connector_get_modes':
> drivers/gpu/drm/exynos/exynos_drm_connector.c:86:
> undefined reference to `drm_display_mode_from_videomode'

Applied.

Thanks,
Inki Dae

> 
> Signed-off-by: Sachin Kamat 
> Cc: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig
> b/drivers/gpu/drm/exynos/Kconfig
> index 80a251a..4752f22 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -6,6 +6,7 @@ config DRM_EXYNOS
>   select FB_CFB_COPYAREA
>   select FB_CFB_IMAGEBLIT
>   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> + select VIDEOMODE_HELPERS
>   help
> Choose this option if you have a Samsung SoC EXYNOS chipset.
> If M is selected the module will be called exynosdrm.
> @@ -26,7 +27,6 @@ config DRM_EXYNOS_FIMD
>   bool "Exynos DRM FIMD"
>   depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
>   select FB_MODE_HELPERS
> - select VIDEOMODE_HELPERS
>   help
> Choose this option if you want to use Exynos FIMD for DRM.
> 
> --
> 1.7.9.5

[PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

[Inki Dae]

One more thing, you would need to check if other driver can be probed in
probe context. With your patch, exynos_hdmiphy_driver_register() is called
in hdmi_probe() via hdmi_get_phy_device(), and then
platform_driver_reigster() is called via the
exynos_hdmiphy_driver_register(). I remember that was failed.

Thanks,
Inki Dae

> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Inki Dae
> Sent: Friday, August 30, 2013 5:33 PM
> To: 'Rahul Sharma'; linux-samsung-soc at vger.kernel.org; dri-
> devel at lists.freedesktop.org
> Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; joshi at samsung.com;
> s.nawrocki at samsung.com
> Subject: RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
> 
> Hi Rahul.
> 
> Thanks for your patch set.
> 
> I had just quick review to all patch series. And I think we could fully
> hide
> hdmiphy interfaces,
> exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
> driver.
> That may be prototyped like below,
> 
> at exynos_hdmi.h
> 
> /* Define hdmiphy callbacks. */
> struct exynos_hdmiphy_ops {
>   void (*enable)(struct device *dev);
>   void (*disable)(struct device *dev);
>   int (*check_mode)(struct device *dev, struct drm_display_mode
> *mode);
>   int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
>   int (*apply)(struct device *dev);
> };
> 
> 
> at exynos_hdmi.c
> 
> /*
>   * Add a new structure for hdmi driver data.
>   * type could be HDMI_TYPE13 or HDMI_TYPE14.
>   * i2c_hdmiphy could be true or false: true means that current hdmi
> device
> uses i2c
>   * based hdmiphy device, otherwise platform device based one.
>   */
> struct hdmi_drv_data {
>   unsigned int type;
>   unsigned int i2c_hdmiphy;
> };
> 
> ...
> 
> /* Add new members to hdmi context. */
> struct hdmi_context {
>   ...
>   struct hdmi_drv_data *drv_data;
>   struct hdmiphy_ops *ops;
>   ...
> };
> 
> 
> /* Add hdmi device data according Exynos SoC. */
> static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
>   .type = HDMI_TYPE14,
>   .i2c_hdmiphy = true
> };
> 
> static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
>   .type = HDMI_TYPE14,
>   .i2c_hdmiphy = false
> };
> 
> 
> static struct of_device_id hdmi_match_types[] = {
>   {
>   .compatible = "samsung,exynos4212-hdmi",
>   .data   = (void *)_hdmi_drv_data,
>   }, {
>   ...
> 
>   .compatible = "samsung,exynos5420-hdmi",
>   .data   = (void *)_hdmi_drv_data,
>   }, {
>   }
> };
> 
> /* the below example function shows how hdmiphy interfaces can be hided
> from
> hdmi driver. */
> static void hdmi_mode_set(...)
> {
>   ...
>   hdata->ops->set_mode(hdata->hdmiphy_dev, mode);
> }
> 
> static int hdmi_get_phy_device(struct hdmi_context *hdata)
> {
>   struct hdmi_drv_data *data = hdata->drv_data;
> 
>   ...
>   /* Register hdmiphy driver according to i2c_hdmiphy value. */
>   ret = exynos_hdmiphy_driver_register(data->i2c_hdmiphy);
>   ...
>   /* Get hdmiphy driver ops according to i2c_hdmiphy value. */
>   hdata->ops = exynos_hdmiphy_get_ops(data->i2c_hdmiphy);
>   ...
> }
> 
> 
> at exynos_hdmiphy.c
> 
> /* Define hdmiphy ops respectively. */
> struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
>   .enable = exynos_hdmiphy_i2c_enable,
>   .disable = exynos_hdmiphy_i2c_disable,
>   ...
> };
> 
> struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
>   .enable = exynos_hdmiphy_platdev_enable,
>   .disable = exynos_hdmiphy_platdev_disable,
>   ...
> };
> 
> struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
> {
>   /* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
>   if (i2c_hdmiphy)
>   return _i2c_ops;
> 
>   return _platdev_ops;
> }
> 
> int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
> {
>   ...
>   /* Register hdmiphy driver appropriately according to i2c_hdmiphy.
> */
>   if (i2c_hdmiphy) {
>   ret = i2c_add_driver(_i2c_driver);
>   ...
>   } else {
>   ret = platform_driver_register(_platform_driver);
>   ...
>   }
> 
>   return ret;
> }
> 
> Thanks,
> Inki Dae
> 
> > -Original Message-
> > From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> > Sent: Friday, August 30, 2013 3:59 PM
> > To: linux-samsung-soc at vger.kernel.org; dri-devel at lists.freedesktop.org
> > Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at 
> > samsung.com;
> > seanpaul at chromium.org; l.stach at pengutronix.de; tomasz.figa at 
> > gmail.com;
> > s.nawrocki at samsung.com; joshi at samsung.com; r.sh.open at gmail.com; 
> > Rahul
> > Sharma
> > Subject: [PATCH 0/7] drm/exynos: move hdmiphy 

[PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

[Inki Dae]

Hi Rahul.

Thanks for your patch set.

I had just quick review to all patch series. And I think we could fully hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,

at exynos_hdmi.h

/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
int (*apply)(struct device *dev);
};


at exynos_hdmi.c

/*
  * Add a new structure for hdmi driver data.
  * type could be HDMI_TYPE13 or HDMI_TYPE14.
  * i2c_hdmiphy could be true or false: true means that current hdmi device
uses i2c
  * based hdmiphy device, otherwise platform device based one.
  */
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};

...

/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};


/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};

static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};


static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos4212-hdmi",
.data   = (void *)_hdmi_drv_data,
}, {
...

.compatible = "samsung,exynos5420-hdmi",
.data   = (void *)_hdmi_drv_data,
}, {
}
};

/* the below example function shows how hdmiphy interfaces can be hided from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata->ops->set_mode(hdata->hdmiphy_dev, mode);
}

static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata->drv_data;

...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data->i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata->ops = exynos_hdmiphy_get_ops(data->i2c_hdmiphy);
...
}


at exynos_hdmiphy.c

/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};

struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};

struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
if (i2c_hdmiphy)
return _i2c_ops;

return _platdev_ops;
}

int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
...
/* Register hdmiphy driver appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy) {
ret = i2c_add_driver(_i2c_driver);
...
} else {
ret = platform_driver_register(_platform_driver);
...
}

return ret; 
}

Thanks,
Inki Dae

> -Original Message-
> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> Sent: Friday, August 30, 2013 3:59 PM
> To: linux-samsung-soc at vger.kernel.org; dri-devel at lists.freedesktop.org
> Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at 
> samsung.com;
> seanpaul at chromium.org; l.stach at pengutronix.de; tomasz.figa at gmail.com;
> s.nawrocki at samsung.com; joshi at samsung.com; r.sh.open at gmail.com; Rahul
> Sharma
> Subject: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
> 
> Currently, exynos hdmiphy operations and configs are kept
> inside the hdmi driver. Hdmiphy related code is tightly
> coupled with hdmi IP driver.
> 
> This series also removes hdmiphy dummy clock for hdmiphy
> and replace it with Phy PMU Control from the hdmiphy driver.
> 
> At the end, support for exynos5420 hdmiphy is added to the
> hdmiphy driver which is a platform device.
> 
> Drm related paches are based on exynos-drm-next branch at
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> Arch patches are dependent on
> http://www.mail-archive.com/linux-samsung-
> soc at vger.kernel.org/msg22195.html
> 
> Rahul Sharma (7):
>   drm/exynos: move hdmiphy related code to hdmiphy driver
>   drm/exynos: remove dummy hdmiphy clock
>   drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
>   drm/exynos: add support for exynos5420 hdmiphy
>   exynos/drm: fix ddc i2c device probe failure
>   ARM: dts: update hdmiphy dt node for exynos5250
>   ARM: dts: update hdmiphy dt node for 

[RFC 3/3] drm/tegra: Implement panel support

[Thierry Reding]

Use the DRM panel framework to attach a panel to an output.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/Kconfig  |  1 +
 drivers/gpu/host1x/drm/drm.h|  1 +
 drivers/gpu/host1x/drm/output.c | 28 ++--
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
index 69853a4..01b036d 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/host1x/drm/Kconfig
@@ -2,6 +2,7 @@ config DRM_TEGRA
bool "NVIDIA Tegra DRM"
depends on DRM
select DRM_KMS_HELPER
+   select DRM_PANEL
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 02ce020..a30276c 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -195,6 +195,7 @@ struct tegra_output {
const struct tegra_output_ops *ops;
enum tegra_output_type type;

+   struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
unsigned int hpd_irq;
diff --git a/drivers/gpu/host1x/drm/output.c b/drivers/gpu/host1x/drm/output.c
index 137ae81..2ce03c1 100644
--- a/drivers/gpu/host1x/drm/output.c
+++ b/drivers/gpu/host1x/drm/output.c
@@ -11,6 +11,7 @@
 #include 
 #include 

+#include 
 #include "drm.h"

 static int tegra_connector_get_modes(struct drm_connector *connector)
@@ -19,6 +20,9 @@ static int tegra_connector_get_modes(struct drm_connector 
*connector)
struct edid *edid = NULL;
int err = 0;

+   if (output->panel)
+   return output->panel->funcs->get_modes(output->panel);
+
if (output->edid)
edid = kmemdup(output->edid, sizeof(*edid), GFP_KERNEL);
else if (output->ddc)
@@ -74,6 +78,9 @@ tegra_connector_detect(struct drm_connector *connector, bool 
force)
else
status = connector_status_connected;
} else {
+   if (output->panel)
+   status = connector_status_connected;
+
if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS)
status = connector_status_connected;
}
@@ -105,6 +112,11 @@ static const struct drm_encoder_funcs encoder_funcs = {

 static void tegra_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
+   struct tegra_output *output = encoder_to_output(encoder);
+   struct drm_panel *panel = output->panel;
+
+   if (panel && panel->funcs && panel->funcs->dpms)
+   panel->funcs->dpms(panel, mode);
 }

 static bool tegra_encoder_mode_fixup(struct drm_encoder *encoder,
@@ -153,14 +165,23 @@ static irqreturn_t hpd_irq(int irq, void *data)

 int tegra_output_parse_dt(struct tegra_output *output)
 {
+   struct device_node *ddc, *panel;
enum of_gpio_flags flags;
-   struct device_node *ddc;
size_t size;
int err;

if (!output->of_node)
output->of_node = output->dev->of_node;

+   panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
+   if (panel) {
+   output->panel = of_drm_find_panel(panel);
+   if (!output->panel)
+   return -EPROBE_DEFER;
+
+   of_node_put(panel);
+   }
+
output->edid = of_get_property(output->of_node, "nvidia,edid", );

ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
@@ -175,7 +196,7 @@ int tegra_output_parse_dt(struct tegra_output *output)
of_node_put(ddc);
}

-   if (!output->edid && !output->ddc)
+   if (!output->panel && !output->edid && !output->ddc)
return -ENODEV;

output->hpd_gpio = of_get_named_gpio_flags(output->of_node,
@@ -242,6 +263,9 @@ int tegra_output_init(struct drm_device *drm, struct 
tegra_output *output)
   connector);
drm_connector_helper_add(>connector, _helper_funcs);

+   if (output->panel)
+   drm_panel_attach(output->panel, >connector);
+
drm_encoder_init(drm, >encoder, _funcs, encoder);
drm_encoder_helper_add(>encoder, _helper_funcs);

-- 
1.8.4

[RFC 2/3] drm/panel: Add simple panel support

[Thierry Reding]

Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.

Support is added for three panels: An AU Optronics 10.1" WSVGA, a
Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD
panel.

Signed-off-by: Thierry Reding 
---
 .../devicetree/bindings/panel/panel-simple.txt |  25 ++
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/panel/Kconfig  |  13 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-simple.c   | 335 +
 5 files changed, 375 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/panel-simple.txt
 create mode 100644 drivers/gpu/drm/panel/Makefile
 create mode 100644 drivers/gpu/drm/panel/panel-simple.c

diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt 
b/Documentation/devicetree/bindings/panel/panel-simple.txt
new file mode 100644
index 000..dfd4b76
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panel-simple.txt
@@ -0,0 +1,25 @@
+Simple display panel
+
+Required properties:
+- compatible: should be one of:
+  - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+  - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+  - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel
+
+Optional properties:
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- power-supply: regulator to provide the supply voltage
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   panel: panel {
+   compatible = "cptt,claa101wb01";
+   ddc-i2c-bus = <>;
+
+   power-supply = <_pnl_reg>;
+   enable-gpios = < 90 0>;
+
+   backlight = <>;
+   };
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9b009c7..764a5ec 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_DRM_TILCDC)  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_MSM) += msm/
 obj-y  += i2c/
+obj-y  += panel/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 2ddd5bd..843087b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -2,3 +2,16 @@ menuconfig DRM_PANEL
bool "DRM panel support"
help
  Panel registration and lookup framework.
+
+if DRM_PANEL
+
+config DRM_PANEL_SIMPLE
+   bool "support for simple panels"
+   depends on OF
+   help
+ DRM panel driver for dumb panels that need at most a regulator and
+ a GPIO to be powered up. Optionally a backlight can be attached so
+ that it can be automatically turned off when the panel goes into a
+ low power state.
+
+endif
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
new file mode 100644
index 000..af9dfa2
--- /dev/null
+++ b/drivers/gpu/drm/panel/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
new file mode 100644
index 000..e38cd6f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int num_modes;

[RFC 1/3] drm: Add panel support

[Thierry Reding]

Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.

The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.

Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/Kconfig   |  2 +
 drivers/gpu/drm/Makefile  |  1 +
 drivers/gpu/drm/drm_panel.c   | 96 +++
 drivers/gpu/drm/panel/Kconfig |  4 ++
 include/drm/drm_panel.h   | 65 +
 5 files changed, 168 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 drivers/gpu/drm/panel/Kconfig
 create mode 100644 include/drm/drm_panel.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..b4d8402 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source "drivers/gpu/drm/tilcdc/Kconfig"
 source "drivers/gpu/drm/qxl/Kconfig"

 source "drivers/gpu/drm/msm/Kconfig"
+
+source "drivers/gpu/drm/panel/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9b009c7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o

 drm-usb-y   := drm_usb.o

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
new file mode 100644
index 000..ff6e459
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+static DEFINE_MUTEX(panel_lock);
+static LIST_HEAD(panel_list);
+
+void drm_panel_init(struct drm_panel *panel)
+{
+   INIT_LIST_HEAD(>list);
+}
+EXPORT_SYMBOL(drm_panel_init);
+
+int drm_panel_add(struct drm_panel *panel)
+{
+   mutex_lock(_lock);
+   list_add_tail(>list, _list);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_add);
+
+void drm_panel_remove(struct drm_panel *panel)
+{
+   mutex_lock(_lock);
+   list_del_init(>list);
+   mutex_unlock(_lock);
+}
+EXPORT_SYMBOL(drm_panel_remove);
+
+int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
+{
+   if (panel->connector)
+   return -EBUSY;
+
+   panel->connector = connector;
+   panel->drm = connector->dev;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_attach);
+
+int drm_panel_detach(struct drm_panel *panel)
+{
+   panel->connector = NULL;
+   panel->drm = NULL;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_detach);
+
+#ifdef CONFIG_OF
+struct drm_panel *of_drm_find_panel(struct device_node *np)
+{
+   struct drm_panel *panel;
+
+   mutex_lock(_lock);
+
+   list_for_each_entry(panel, _list, list) {
+   if (panel->dev->of_node == np) {
+   mutex_unlock(_lock);
+   return panel;
+   }
+   }
+
+   mutex_unlock(_lock);
+   return NULL;
+}

[RFC 0/3] drm: Add panel support

[Thierry Reding]

Hi,

This patch series adds support for panels to DRM. The current implementation
is very basic and only provides hooks for a panel to handle DPMS changes and
return a list of supported modes. That should be enough to support a rather
large number of panels. It should also be easy to extend the framework for
more sophisticated panels such as DSI.

I'm aware of the existing efforts to create such a framework, called CDF. My
impression was that a lot of people thought it overengineered and that it
doesn't fit well into the existing DRM infrastructure. This alternative
proposal is an attempt to start with something simpler (yet extensible) that
fits into DRM more nicely.

Patch 1 adds the "framework" if one can call it that. At the moment it isn't
anything more than a global registry that panel drivers can register panels
with and display drivers can retrieve them. All of this is very device tree
centric right now, but it shouldn't be difficult to add support for platform
data.

Patch 2 implements a simple driver for dumb panels that can have a regulator
for the supply voltage of the panel and a separate GPIO to enable the panel.
Three simple panels are currently supported by that driver.

Finally patch 3 hooks up the panel framework with the Tegra DRM driver. Note
that the framework isn't tied to the core at the moment. That can easily be
changed if we want to, but I didn't see a need so far. Instead the driver
calls the .dpms() and .get_modes() hooks in it's encoder/connector
implementation.

Thierry

Thierry Reding (3):
  drm: Add panel support
  drm/panel: Add simple panel support
  drm/tegra: Implement panel support

 .../devicetree/bindings/panel/panel-simple.txt |  25 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   2 +
 drivers/gpu/drm/drm_panel.c|  96 ++
 drivers/gpu/drm/panel/Kconfig  |  17 ++
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-simple.c   | 335 +
 drivers/gpu/host1x/drm/Kconfig |   1 +
 drivers/gpu/host1x/drm/drm.h   |   1 +
 drivers/gpu/host1x/drm/output.c|  28 +-
 include/drm/drm_panel.h|  65 
 11 files changed, 571 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/panel-simple.txt
 create mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 drivers/gpu/drm/panel/Kconfig
 create mode 100644 drivers/gpu/drm/panel/Makefile
 create mode 100644 drivers/gpu/drm/panel/panel-simple.c
 create mode 100644 include/drm/drm_panel.h

-- 
1.8.4

[RFC 0/4] Atomic Display Framework

[Ville Syrjälä]

On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann  
> wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark  wrote:
> >>
> >> I guess if you have multiple encoders + multiple connectors for the
> >> "ganging" case, then it probably just looks like 2x displays, and
> >> nothing more really needed?
> >>
> >> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario,
> >> so I'm not completely sure what the best approach is.  But if we do
> >> have hw like this, then it makes sense to support it *somehow* in KMS.
> >
> >
> > I don't have the hardware anymore so this is all working from memory, it
> > didn't look like two independent displays.  You had to explicitly set up
> > connections between the two mixers to deal with things like scaled overlays
> > that spanned both mixers (there was some in-hardware magic to make sure
> > there wasn't a visible seam where the two mixers met).
> 
> Ok, sounds like mixer == crtc (ie. the thing the combines one or more
> planes)?  So it sounds maybe a bit like:
> 
>  plane0_0 -\
> ...+---> CRTC -\
>  plane0_n -/   |
>+--> encoder -> connector
>  plane1_0 -\   |
> ...+---> CRTC -/
>  plane1_n -/

So I wonder if we should just add the x,y,w,h output parameters to crtc.
That could also be used to specify borders in the normal one crtc per
encoder case. Although the border color is then a bit a question mark.
Supposedly the crtc can have its own background color, but i guess the
border color need not match that necessarily. So maybe add an encoder
bg color property too (or maybe just slap it to the connector since we
don't currently have encoder properties).

Another related thing I really want to expose is the crtc input size
(ie. the coordinate space that the planes' output coordinates live in).
That way the user will get explicit control over the scaler in the crtc
(panel fitter in i915 lingo).

-- 
Ville Syrj?l?
Intel OTC

[pull] radeon drm-next-3.12

[Alex Deucher]

Hi Dave,

This is the radeon drm-next request.  Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes


The following changes since commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f:

  drm/vmwgfx: Split GMR2_REMAP commands if they are to large (2013-08-30 
09:03:39 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.12

for you to fetch changes up to 679fe80fbe964ea7f9f71781c2ca65b630949da3:

  drm/radeon/dpm: make sure dc performance level limits are valid (CI) 
(2013-08-30 16:31:25 -0400)


Alex Deucher (104):
  drm/edid: add quirk for Medion MD30217PG
  drm/radeon: switch r6xx+ to using CP DMA for the blit copy callback
  drm/radeon/kms: remove r6xx+ blit copy routines
  drm/radeon: add UVD->DPM helper function (v5)
  drm/radeon/dpm: use multiple UVD power states (v3)
  drm/radeon/dpm: rework thermal state handling
  drm/radeon: default to 1024M gart size on rv770+
  drm/radeon/dpm: use performance state if no UVD state
  drm/radeon/kms: fix up dce8 display watermark calc for dpm
  drm/radeon/cik: implement some more atom helpers for DPM
  drm/radeon: switch CIK to use radeon_ucode.h
  drm/radeon/cik: add support for pcie gen1/2/3 switching
  drm/radeon: add support for ASPM on CIK asics
  drm/radeon/cik: restructure rlc setup
  drm/radeon: clean up sumo_rlc_init() for code sharing
  drm/radeon: convert SI,CIK to use sumo_rlc functions
  drm/radeon: implement clock and power gating for CIK (v3)
  drm/radeon: add indirect accessors for dift registers on CIK
  drm/radeon/sumo add helper to go from vid7 to vid2
  drm/radeon: switch to pptable.h
  drm/radeon: add structs to store uvd clock voltage deps
  drm/radeon/cik: add rlc helpers for DPM
  drm/radeon: add support for thermal controller on KB/KV
  drm/radeon: add CI to r600_is_internal_thermal_sensor()
  drm/radeon: add KB/KV to r600_is_internal_thermal_sensor
  drm/radeon: add get_temperature() callbacks for CIK (v2)
  drm/radeon: adjust si_dpm function for code sharing
  drm/radeon/dpm: update cac leakage table parsing for CI
  drm/radeon/dpm: add support for parsing the atom powertune table
  drm/radeon/dpm: grab mvdd_dependency_on_mclk info from vbios
  drm/radeon: add structs to store vce clock voltage deps
  drm/radeon: add clock voltage dep tables for acp, samu
  drm/radeon: parse the vce clock voltage deps table
  drm/radeon: parse the uvd clock voltage deps table
  drm/radeon/dpm: clean up the extended table error pathes
  drm/radeon: parse the samu clock voltage deps table
  drm/radeon: parse the acp clock voltage deps table
  drm/radeon: add r600_get_pcie_lane_support helper
  drm/radeon/dpm: add vce clocks to radeon_ps
  drm/radeon/dpm: add a helper to encode pcie lane setting
  drm/radeon/dpm: add helper to fetch the vrefresh of the current mode
  drm/radeon/kms: add dpm support for KB/KV
  drm/radeon: add dpm support for CI dGPUs (v2)
  drm/radeon/dpm: add debugfs support for CI
  drm/radeon/dpm: implement force performance level for CI
  drm/radeon/dpm: implement vblank_too_short callback for CI
  drm/radeon/dpm: add debugfs support for KB/KV
  drm/radeon/dpm: implement force performance level for KB/KV
  drm/radeon/dpm: add new callback for powergating UVD (v4)
  drm/radeon: restructure UVD code to handle UVD PG (v2)
  drm/radeon/dpm: implement UVD powergating for KB/KV
  drm/radeon/dpm: implement UVD powergating for CI
  drm/radeon/dpm: add reclocking quirk for ASUS K70AF
  drm/radeon/dpm: adjust the vblank time checks for eg, ni, si
  drm/radeon: fix endian bugs in hw i2c atom routines
  drm/edid: add a helper function to extract the speaker allocation data 
block (v3)
  drm/radeon: add audio support for DCE6/8 GPUs (v12)
  drm/radeon: set speaker allocation for DCE4/5 (v2)
  drm/radeon: set speaker allocation for DCE3.2
  drm/radeon: add cg and pg flags
  drm/radeon: use new cg/pg flags for SI
  drm/radeon/si: restructure cg code (v3)
  drm/radeon: fixes for gfx clockgating on SI
  drm/radeon: handle cg in SI dpm code
  drm/radeon: enable mgcg on SI
  drm/radeon/si: properly set up the clearstate buffer for pg (v2)
  drm/radeon/si: enable DMA pg by default
  drm/radeon: restructure cg/pg on cik (v2)
  drm/radeon: fixes for gfx clockgating on CIK
  drm/radeon/cik: properly set up the clearstate buffer for pg (v2)
  drm/radeon: handle cg in CI dpm code
  drm/radeon: handle cg in KB/KV dpm code
  drm/radeon: enable mgcg on CIK
  drm/radeon: update line buffer 

[RFC 0/4] Atomic Display Framework

[Ville Syrjälä]

On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l? <
> ville.syrjala at linux.intel.com> wrote:
> 
> > On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann 
> > wrote:
> >
> > > 1.  The API is geared toward updating one object at a time.  Android's
> > graphics stack needs the entire screen updated atomically to avoid tearing,
> > and on some SoCs to avoid wedging the display hardware.  Rob Clark's atomic
> > modeset patchset worked, but copy/update/commit design meant the driver had
> > to keep a lot more internal state.
> > > >
> > >
> > > I'm not entirely sure how to avoid that, because at least some hw we
> > > need to have the entire new-state in order to validate if it is
> > > possible.
> >
> > I guess the only reason adf is a bit different is that there can only be
> > one custom (driver specific!) blob in the ioctl, so the driver is just
> > free to dump that directly into whatever internal structure it uses to
> > store the full state. So it just frees you from the per-prop state
> > buildup process.
> >
> 
> Right, the difference is that clients send the complete state they want
> rather than deltas against the current state.  This means the driver
> doesn't have to track its current state and duplicate it at the beginning
> of the flip operation, which is a minor pain on hardware with a ton of
> knobs to twist across different hardware blocks.

You could just keep around the same big blob you would expect from the
client, and incrementally update it. Not a big problem in my mind.

> 
> Maybe the important question is whether incremental atomic updates is a
> use-case that clients need in practice.  SurfaceFlinger tells the HW
> composer each frame "here's a complete description of what I want onscreen,
> make it so" and IIRC Weston works the same way.

Complete is a big word. There can be quite a bit of (either per plane,
or per crtc) state that doesn't change all that often, like gamma
ramps/luts, color adjustemnt knobs, etc. Some user space applications
probably won't even care about most of that, but with your approach
they're anyway forced to deal with it.

> 
> I used a blob rather than property/value pairs because the composition is
> going to be inherently device specific anyway.  Display controllers have
> such different features and constraints that you'd end up with each driver
> exposing a bunch of hardware-specific properties, and I'm not convinced
> that's any better than just letting the driver dictate how the requests are
> structured (modulo a handful of hardware-agnostic properties).  I'm not
> strongly tied to blobs over properties but I think the former's easier on
> driver developers.

Sure, there's a certainly stuff that's hardware specific, but I'm sure
most of the properties can be abstracted reasonably well for "normal"
hardware.

There are of course hardware specific restrictions on which combinations
of property values are valid. I have no good solution to this problem.
ATM the plan is just return EINVAL for the whole operation, or possibly
allow the driver to adjust things a bit to make it work almost like the
user requested. We may need some knob to select between strict and
relaxed modes.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 6/6] intel: Update package name and description in libdrm_intel.pc

[Damien Lespiau]

On Thu, Aug 29, 2013 at 09:31:54PM +0100, Emil Velikov wrote:
> Currently the package name and description duplicate that of the
> core libdrm. Update those to reflect reality.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Emil Velikov 

Looks good to me:
Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
> 
> Trivial change IMHO, notices while checking the package Libs
> ---
> 
>  intel/libdrm_intel.pc.in | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/intel/libdrm_intel.pc.in b/intel/libdrm_intel.pc.in
> index 3ba6793..670e4fe 100644
> --- a/intel/libdrm_intel.pc.in
> +++ b/intel/libdrm_intel.pc.in
> @@ -3,8 +3,8 @@ exec_prefix=@exec_prefix@
>  libdir=@libdir@
>  includedir=@includedir@
>  
> -Name: libdrm
> -Description: Userspace interface to kernel DRM services
> +Name: libdrm_intel
> +Description: Userspace interface to intel kernel DRM services
>  Version: @PACKAGE_VERSION@
>  Requires: libdrm
>  Libs: -L${libdir} -ldrm_intel
> -- 
> 1.8.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Michel D?nzer  ---
(In reply to comment #9)
> .addImm(Lane);

This results in the lane number being encoded verbatim in the VSRC1 instruction
field, which I don't think is correct?

I tried adding 0x80 to make it an inline literal, but Sanctuary still locks up.

Another potential gotcha I noticed in the ISA documentation is that the
V_READ/WRITELANE instructions don't respect the EXEC mask.

-- 
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/20130830/dc665783/attachment.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-dae...@freedesktop.org]

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

Johannes Obermayr  changed:

   What|Removed |Added

 CC||johannesobermayr at gmx.de

--- Comment #18 from Johannes Obermayr  ---
This one should compile (I forgot to adapt a few things after I moved it up in
my patch series):
https://github.com/jobermayr/mesa/commit/7e31d65

-- 
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/20130830/bbc5d9fd/attachment.html>

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Ben Skeggs]

On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin  wrote:
> On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs  wrote:
>> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin  
>> wrote:
>>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs  wrote:
 On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin  
 wrote:
> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs  wrote:
>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin  
>> wrote:
>>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs  
>>> wrote:
 On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin >>> alum.mit.edu> wrote:
> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach  
> wrote:
>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  
>>> wrote:
>>> > MSIs were only problematic on some old, broken chipsets. But now 
>>> > that we
>>> > already see systems where PCI legacy interrupts are somewhat 
>>> > flaky, it's
>>> > really time to move to MSIs.
>>> >
>>> > Signed-off-by: Lucas Stach 
>>> > ---
>>> >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
>>> >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 
>>> > +
>>> >  2 files changed, 18 insertions(+)
>>> >
>>> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
>>> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>>> > index 9d2cd20..ce6569f 100644
>>> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>>> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>>> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
>>> >  struct nouveau_mc {
>>> > struct nouveau_subdev base;
>>> > const struct nouveau_mc_intr *intr_map;
>>> > +   bool use_msi;
>>> >  };
>>> >
>>> >  static inline struct nouveau_mc *
>>> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
>>> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>>> > index ec9cd6f..02b337e 100644
>>> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>>> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>>> > @@ -23,6 +23,7 @@
>>> >   */
>>> >
>>> >  #include 
>>> > +#include 
>>> >
>>> >  static irqreturn_t
>>> >  nouveau_mc_intr(int irq, void *arg)
>>> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
>>> > map++;
>>> > }
>>> >
>>> > +   if (pmc->use_msi)
>>> > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
>>> Register not present everywhere.
>>>
>>> At the very least, the enabling of MSI should be disallowed on the
>>> earlier chipsets where it's not supported.  Though, it's perhaps
>>> possible that the pci_enable_msi() call will fail in all of these
>>> cases anyway.. I'm not certain.
>>>
>> MSIs are required property for everything doing PCIe. So the only 
>> cases
>> where this should fail is plain PCI/AGP devices. I don't really have 
>> a
>> test system for those old cards set up.
>>
>> But I remember Ilia having some legacy things plugged in, so maybe he
>> could test this patch and see how it goes?
>
> Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
> that it's not native PCIe, but some sort of bridge thing IIRC),
 Cases like the nv34 here (i think there's some nv4x that aren't native
 pcie too) are what I'm wondering about primarily.
>>>
>>> And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
>>> with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However merely
>>> starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
>>> it (with no clients connecting to said X), causes a "failed to idle
>>> channel" message in dmesg, which apparently never rectifies itself, so
>>> X is hung forever. FTR, there were no displays connected either, but I
>>> tried the exact same procedure without the MSI patch and it worked
>>> fine. Here is the init sequence with the MSI patch:
>> I don't suppose bashing 0x1868 instead of 0x88068 works here?  If not,
>
> Should that work on the NV42 as well?
 I believe so.  NV4x has both the 0x18xx and 0x88xxx apertures I believe.

>
>> next thing would be to mmiotrace the binary driver and see if you can
>> make it enable+use MSI on it.  I doubt the current legacy driver does
>> it by default, but there was some magic to enable it that you can
>> probably find if you google around.
>
> I've yet to set up the legacy driver... I bet it doesn't compile on

[PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

[Rahul Sharma]

Thanks Mr. Dae,

I have some points for discussion.

On 30 August 2013 14:03, Inki Dae  wrote:
> Hi Rahul.
>
> Thanks for your patch set.
>
> I had just quick review to all patch series. And I think we could fully hide
> hdmiphy interfaces,
> exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
> driver.
> That may be prototyped like below,
>
> at exynos_hdmi.h
>
> /* Define hdmiphy callbacks. */
> struct exynos_hdmiphy_ops {
> void (*enable)(struct device *dev);
> void (*disable)(struct device *dev);
> int (*check_mode)(struct device *dev, struct drm_display_mode
> *mode);
> int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
> int (*apply)(struct device *dev);
> };
>

Above looks fine to me. I will hide the ops as you suggested.

>
> at exynos_hdmi.c
>
> /*
>   * Add a new structure for hdmi driver data.
>   * type could be HDMI_TYPE13 or HDMI_TYPE14.
>   * i2c_hdmiphy could be true or false: true means that current hdmi device
> uses i2c
>   * based hdmiphy device, otherwise platform device based one.
>   */
> struct hdmi_drv_data {
> unsigned int type;
> unsigned int i2c_hdmiphy;
> };
>
> ...
>
> /* Add new members to hdmi context. */
> struct hdmi_context {
> ...
> struct hdmi_drv_data *drv_data;
> struct hdmiphy_ops *ops;
> ...
> };
>
>
> /* Add hdmi device data according Exynos SoC. */
> static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
> .type = HDMI_TYPE14,
> .i2c_hdmiphy = true
> };
>
> static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
> .type = HDMI_TYPE14,
> .i2c_hdmiphy = false
> };
>
>
> static struct of_device_id hdmi_match_types[] = {
> {
> .compatible = "samsung,exynos4212-hdmi",
> .data   = (void *)_hdmi_drv_data,
> }, {
> ...
>
> .compatible = "samsung,exynos5420-hdmi",
> .data   = (void *)_hdmi_drv_data,
> }, {
> }
> };
>
> /* the below example function shows how hdmiphy interfaces can be hided from
> hdmi driver. */
> static void hdmi_mode_set(...)
> {
> ...
> hdata->ops->set_mode(hdata->hdmiphy_dev, mode);

This looks fine.

> }
>
> static int hdmi_get_phy_device(struct hdmi_context *hdata)
> {
> struct hdmi_drv_data *data = hdata->drv_data;
>
> ...
> /* Register hdmiphy driver according to i2c_hdmiphy value. */
> ret = exynos_hdmiphy_driver_register(data->i2c_hdmiphy);
> ...
> /* Get hdmiphy driver ops according to i2c_hdmiphy value. */
> hdata->ops = exynos_hdmiphy_get_ops(data->i2c_hdmiphy);
> ...
> }
>
>
> at exynos_hdmiphy.c
>
> /* Define hdmiphy ops respectively. */
> struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
> .enable = exynos_hdmiphy_i2c_enable,
> .disable = exynos_hdmiphy_i2c_disable,
> ...
> };
>
> struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
> .enable = exynos_hdmiphy_platdev_enable,
> .disable = exynos_hdmiphy_platdev_disable,
> ...
> };

Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata->dev),
we use i2c_master_send or writeb.

>
> struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int i2c_hdmiphy)
> {
> /* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
> if (i2c_hdmiphy)
> return _i2c_ops;
>
> return _platdev_ops;
> }

We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.

>
> int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
> {
> ...
> /* Register hdmiphy driver appropriately according to i2c_hdmiphy.
> */
> if (i2c_hdmiphy) {
> ret = i2c_add_driver(_i2c_driver);
> ...
> } else {
> ret = platform_driver_register(_platform_driver);
> ...
> }
>

Here i2c_hdmiphy flag helps in avoiding registering both i2c
and platform drivers for phy. But is it a concern that we should
not register 2 drivers on different buses for single hw device. I am
still not clear on this.

Otherwise we do not need to maintain i2c_hdmiphy flag.

Secondly, we always have registration of i2c driver for ddc and
hdmiphy driver in hdmi probe. It works. I have also tested above
series for 5420 and 5250 smdk board. There are no issues.

regards,
Rahul Sharma.

> return ret;
> }
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
>> Sent: Friday, August 30, 2013 3:59 PM
>> To: linux-samsung-soc at vger.kernel.org; dri-devel at lists.freedesktop.org
>> Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at 
>> 

[Bug 68391] [radeonsi] Crash unigine-sanctuary

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Vladimir Ysikov  ---
I have GPU lockup with this patch.

-- 
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/20130830/1bc3f302/attachment.html>

[PATCH] drm/msm: convert to drm_bridge

[Rob Clark]

Drop the msm_connector base class, and special calls to base class
methods from the encoder, and use instead drm_bridge.  This allows for a
cleaner division between the hdmi (and in future dsi) blocks, from the
mdp block.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/Makefile|   2 +-
 drivers/gpu/drm/msm/hdmi/hdmi.c |  49 +++-
 drivers/gpu/drm/msm/hdmi/hdmi.h |  31 +-
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c  | 167 
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c   | 156 ++
 drivers/gpu/drm/msm/mdp4/mdp4_dtv_encoder.c |  12 --
 drivers/gpu/drm/msm/mdp4/mdp4_kms.c |   9 +-
 drivers/gpu/drm/msm/msm_connector.c |  34 --
 drivers/gpu/drm/msm/msm_connector.h |  68 ---
 drivers/gpu/drm/msm/msm_drv.h   |   6 +-
 10 files changed, 274 insertions(+), 260 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
 delete mode 100644 drivers/gpu/drm/msm/msm_connector.c
 delete mode 100644 drivers/gpu/drm/msm/msm_connector.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 439dfb5..e179148 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -7,6 +7,7 @@ msm-y := \
adreno/adreno_gpu.o \
adreno/a3xx_gpu.o \
hdmi/hdmi.o \
+   hdmi/hdmi_bridge.o \
hdmi/hdmi_connector.o \
hdmi/hdmi_i2c.o \
hdmi/hdmi_phy_8960.o \
@@ -17,7 +18,6 @@ msm-y := \
mdp4/mdp4_irq.o \
mdp4/mdp4_kms.o \
mdp4/mdp4_plane.o \
-   msm_connector.o \
msm_drv.o \
msm_fb.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 12ecfb9..50d11df 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -56,8 +56,9 @@ static irqreturn_t hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }

-void hdmi_destroy(struct hdmi *hdmi)
+void hdmi_destroy(struct kref *kref)
 {
+   struct hdmi *hdmi = container_of(kref, struct hdmi, refcount);
struct hdmi_phy *phy = hdmi->phy;

if (phy)
@@ -70,9 +71,10 @@ void hdmi_destroy(struct hdmi *hdmi)
 }

 /* initialize connector */
-int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
-   struct drm_connector *connector)
+int hdmi_init(struct drm_device *dev, struct drm_encoder *encoder)
 {
+   struct hdmi *hdmi = NULL;
+   struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = hdmi_pdev;
struct hdmi_platform_config *config;
int ret;
@@ -85,11 +87,19 @@ int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,

config = pdev->dev.platform_data;

+   hdmi = kzalloc(sizeof(*hdmi), GFP_KERNEL);
+   if (!hdmi) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   kref_init(>refcount);
+
get_device(>dev);

hdmi->dev = dev;
hdmi->pdev = pdev;
-   hdmi->connector = connector;
+   hdmi->encoder = encoder;

/* not sure about which phy maps to which msm.. probably I miss some */
if (config->phy_init)
@@ -152,6 +162,22 @@ int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
goto fail;
}

+   hdmi->bridge = hdmi_bridge_init(hdmi);
+   if (IS_ERR(hdmi->bridge)) {
+   ret = PTR_ERR(hdmi->bridge);
+   dev_err(dev->dev, "failed to create HDMI bridge: %d\n", ret);
+   hdmi->bridge = NULL;
+   goto fail;
+   }
+
+   hdmi->connector = hdmi_connector_init(hdmi);
+   if (IS_ERR(hdmi->connector)) {
+   ret = PTR_ERR(hdmi->connector);
+   dev_err(dev->dev, "failed to create HDMI connector: %d\n", ret);
+   hdmi->connector = NULL;
+   goto fail;
+   }
+
hdmi->irq = platform_get_irq(pdev, 0);
if (hdmi->irq < 0) {
ret = hdmi->irq;
@@ -168,11 +194,22 @@ int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
goto fail;
}

+   encoder->bridge = hdmi->bridge;
+
+   priv->bridges[priv->num_bridges++]   = hdmi->bridge;
+   priv->connectors[priv->num_connectors++] = hdmi->connector;
+
return 0;

 fail:
-   if (hdmi)
-   hdmi_destroy(hdmi);
+   if (hdmi) {
+   /* bridge/connector are normally destroyed by drm: */
+   if (hdmi->bridge)
+   hdmi->bridge->funcs->destroy(hdmi->bridge);
+   if (hdmi->connector)
+   hdmi->connector->funcs->destroy(hdmi->connector);
+   hdmi_destroy(>refcount);
+   }

return ret;
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 34703fe..2c2ec56 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -30,6 +30,8 @@
 struct hdmi_phy;

 struct hdmi 

linux-next: Tree for Aug 30 (nouveau)

[Randy Dunlap]

On 08/29/13 03:00, Stephen Rothwell wrote:
> Hi all,
> 


on x86_64:

ERROR: "nouveau_switcheroo_optimus_dsm" [drivers/gpu/drm/nouveau/nouveau.ko] 
undefined!


Full randconfig file is attached.


-- 
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.11.0-rc7 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_PCSPKR_PLATFORM is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_PCI_QUIRKS=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#

[PATCH v2 1/2] drm: Add drm_bridge

[Rob Clark]

On Wed, Aug 14, 2013 at 4:47 PM, Sean Paul  wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it will participate in mode
> set, and dpms (via the enable/disable hooks).
>
> Signed-off-by: Sean Paul 

Ok, I've had a chance to rebase my msm drm-bridge patch on top of this
latest version (which I'll be sending in a couple of minutes)

Reviewed-by: Rob Clark 


> ---
>  drivers/gpu/drm/drm_crtc.c| 50 ++
>  drivers/gpu/drm/drm_crtc_helper.c | 89 
> ++-
>  include/drm/drm_crtc.h| 55 
>  3 files changed, 175 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fc83bb9..0311e2b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_connector_unplug_all);
>
> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> +   const struct drm_bridge_funcs *funcs)
> +{
> +   int ret;
> +
> +   drm_modeset_lock_all(dev);
> +
> +   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_BRIDGE);
> +   if (ret)
> +   goto out;
> +
> +   bridge->dev = dev;
> +   bridge->funcs = funcs;
> +
> +   list_add_tail(>head, >mode_config.bridge_list);
> +   dev->mode_config.num_bridge++;
> +
> + out:
> +   drm_modeset_unlock_all(dev);
> +   return ret;
> +}
> +EXPORT_SYMBOL(drm_bridge_init);
> +
> +void drm_bridge_cleanup(struct drm_bridge *bridge)
> +{
> +   struct drm_device *dev = bridge->dev;
> +
> +   drm_modeset_lock_all(dev);
> +   drm_mode_object_put(dev, >base);
> +   list_del(>head);
> +   dev->mode_config.num_bridge--;
> +   drm_modeset_unlock_all(dev);
> +}
> +EXPORT_SYMBOL(drm_bridge_cleanup);
> +
>  int drm_encoder_init(struct drm_device *dev,
>   struct drm_encoder *encoder,
>   const struct drm_encoder_funcs *funcs,
> @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
> struct drm_mode_group *gr
> total_objects += dev->mode_config.num_crtc;
> total_objects += dev->mode_config.num_connector;
> total_objects += dev->mode_config.num_encoder;
> +   total_objects += dev->mode_config.num_bridge;
>
> group->id_list = kzalloc(total_objects * sizeof(uint32_t), 
> GFP_KERNEL);
> if (!group->id_list)
> @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
> struct drm_mode_group *gr
> group->num_crtcs = 0;
> group->num_connectors = 0;
> group->num_encoders = 0;
> +   group->num_bridges = 0;
> return 0;
>  }
>
> @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device 
> *dev,
> struct drm_crtc *crtc;
> struct drm_encoder *encoder;
> struct drm_connector *connector;
> +   struct drm_bridge *bridge;
> int ret;
>
> if ((ret = drm_mode_group_init(dev, group)))
> @@ -1223,6 +1261,11 @@ int drm_mode_group_init_legacy_group(struct drm_device 
> *dev,
> group->id_list[group->num_crtcs + group->num_encoders +
>group->num_connectors++] = connector->base.id;
>
> +   list_for_each_entry(bridge, >mode_config.bridge_list, head)
> +   group->id_list[group->num_crtcs + group->num_encoders +
> +  group->num_connectors + group->num_bridges++] =
> +   bridge->base.id;
> +
> return 0;
>  }
>  EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
> @@ -3905,6 +3948,7 @@ void drm_mode_config_init(struct drm_device *dev)
> INIT_LIST_HEAD(>mode_config.fb_list);
> INIT_LIST_HEAD(>mode_config.crtc_list);
> INIT_LIST_HEAD(>mode_config.connector_list);
> +   INIT_LIST_HEAD(>mode_config.bridge_list);
> INIT_LIST_HEAD(>mode_config.encoder_list);
> INIT_LIST_HEAD(>mode_config.property_list);
> INIT_LIST_HEAD(>mode_config.property_blob_list);
> @@ -3941,6 +3985,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> struct drm_connector *connector, *ot;
> struct drm_crtc *crtc, *ct;
> struct drm_encoder *encoder, *enct;
> +   struct drm_bridge *bridge, *brt;
> struct drm_framebuffer *fb, *fbt;
> struct drm_property *property, *pt;
> struct drm_property_blob *blob, *bt;
> @@ -3951,6 +3996,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> encoder->funcs->destroy(encoder);
> }
>
> +   list_for_each_entry_safe(bridge, brt,
> +>mode_config.bridge_list, 

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Ben Skeggs]

On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs  wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin  wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs  wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin  
>>> wrote:
 On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs  wrote:
> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin  
> wrote:
>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs  wrote:
>>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin  
>>> wrote:
 On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach  wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  
>> wrote:
>> > MSIs were only problematic on some old, broken chipsets. But now 
>> > that we
>> > already see systems where PCI legacy interrupts are somewhat 
>> > flaky, it's
>> > really time to move to MSIs.
>> >
>> > Signed-off-by: Lucas Stach 
>> > ---
>> >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
>> >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 
>> > +
>> >  2 files changed, 18 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
>> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> > index 9d2cd20..ce6569f 100644
>> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
>> >  struct nouveau_mc {
>> > struct nouveau_subdev base;
>> > const struct nouveau_mc_intr *intr_map;
>> > +   bool use_msi;
>> >  };
>> >
>> >  static inline struct nouveau_mc *
>> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
>> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> > index ec9cd6f..02b337e 100644
>> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> > @@ -23,6 +23,7 @@
>> >   */
>> >
>> >  #include 
>> > +#include 
>> >
>> >  static irqreturn_t
>> >  nouveau_mc_intr(int irq, void *arg)
>> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
>> > map++;
>> > }
>> >
>> > +   if (pmc->use_msi)
>> > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
>> Register not present everywhere.
>>
>> At the very least, the enabling of MSI should be disallowed on the
>> earlier chipsets where it's not supported.  Though, it's perhaps
>> possible that the pci_enable_msi() call will fail in all of these
>> cases anyway.. I'm not certain.
>>
> MSIs are required property for everything doing PCIe. So the only 
> cases
> where this should fail is plain PCI/AGP devices. I don't really have a
> test system for those old cards set up.
>
> But I remember Ilia having some legacy things plugged in, so maybe he
> could test this patch and see how it goes?

 Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
 that it's not native PCIe, but some sort of bridge thing IIRC),
>>> Cases like the nv34 here (i think there's some nv4x that aren't native
>>> pcie too) are what I'm wondering about primarily.
>>
>> And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
>> with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However merely
>> starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
>> it (with no clients connecting to said X), causes a "failed to idle
>> channel" message in dmesg, which apparently never rectifies itself, so
>> X is hung forever. FTR, there were no displays connected either, but I
>> tried the exact same procedure without the MSI patch and it worked
>> fine. Here is the init sequence with the MSI patch:
> I don't suppose bashing 0x1868 instead of 0x88068 works here?  If not,

 Should that work on the NV42 as well?
>>> I believe so.  NV4x has both the 0x18xx and 0x88xxx apertures I believe.
>>>

> next thing would be to mmiotrace the binary driver and see if you can
> make it enable+use MSI on it.  I doubt the current legacy driver does
> it by default, but there was some magic to enable it that you can
> probably find if you google around.

 I've yet to set up the legacy driver... I bet it doesn't compile on
 3.11, so I'll have to patch it to nuke procfs/i2c...

>
>>
>> [  307.049812] nouveau  [  DEVICE][:04:00.0] BOOT0  : 0x034a00b1
>> [  307.049815] nouveau  [  

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Ben Skeggs]

On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin  wrote:
> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs  wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin  wrote:
>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs  wrote:
 On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin  
 wrote:
> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs  wrote:
>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin  
>> wrote:
>>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach  wrote:
 Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  
> wrote:
> > MSIs were only problematic on some old, broken chipsets. But now 
> > that we
> > already see systems where PCI legacy interrupts are somewhat flaky, 
> > it's
> > really time to move to MSIs.
> >
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
> >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 
> > +
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > index 9d2cd20..ce6569f 100644
> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
> >  struct nouveau_mc {
> > struct nouveau_subdev base;
> > const struct nouveau_mc_intr *intr_map;
> > +   bool use_msi;
> >  };
> >
> >  static inline struct nouveau_mc *
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > index ec9cd6f..02b337e 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > @@ -23,6 +23,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> >  static irqreturn_t
> >  nouveau_mc_intr(int irq, void *arg)
> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
> > map++;
> > }
> >
> > +   if (pmc->use_msi)
> > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
> Register not present everywhere.
>
> At the very least, the enabling of MSI should be disallowed on the
> earlier chipsets where it's not supported.  Though, it's perhaps
> possible that the pci_enable_msi() call will fail in all of these
> cases anyway.. I'm not certain.
>
 MSIs are required property for everything doing PCIe. So the only cases
 where this should fail is plain PCI/AGP devices. I don't really have a
 test system for those old cards set up.

 But I remember Ilia having some legacy things plugged in, so maybe he
 could test this patch and see how it goes?
>>>
>>> Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
>>> that it's not native PCIe, but some sort of bridge thing IIRC),
>> Cases like the nv34 here (i think there's some nv4x that aren't native
>> pcie too) are what I'm wondering about primarily.
>
> And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
> with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However merely
> starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
> it (with no clients connecting to said X), causes a "failed to idle
> channel" message in dmesg, which apparently never rectifies itself, so
> X is hung forever. FTR, there were no displays connected either, but I
> tried the exact same procedure without the MSI patch and it worked
> fine. Here is the init sequence with the MSI patch:
 I don't suppose bashing 0x1868 instead of 0x88068 works here?  If not,
>>>
>>> Should that work on the NV42 as well?
>> I believe so.  NV4x has both the 0x18xx and 0x88xxx apertures I believe.
>>
>>>
 next thing would be to mmiotrace the binary driver and see if you can
 make it enable+use MSI on it.  I doubt the current legacy driver does
 it by default, but there was some magic to enable it that you can
 probably find if you google around.
>>>
>>> I've yet to set up the legacy driver... I bet it doesn't compile on
>>> 3.11, so I'll have to patch it to nuke procfs/i2c...
>>>

>
> [  307.049812] nouveau  [  DEVICE][:04:00.0] BOOT0  : 0x034a00b1
> [  307.049815] nouveau  [  DEVICE][:04:00.0] Chipset: NV34 (NV34)
> [  307.049819] nouveau  [  DEVICE][:04:00.0] Family : NV30
> [  307.050648] nouveau  [   VBIOS][:04:00.0] checking PRAMIN for 

[PATCH 2/6] tests/*version: add missing string.h header

[Rob Clark]

On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov  
wrote:
> Prodives memset() and strlen(), used in tests/setversion
> tests/getversion respectively.
>
> Signed-off-by: Emil Velikov 

Reviewed-by: Rob Clark 

> ---
>  tests/getversion.c | 1 +
>  tests/setversion.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/tests/getversion.c b/tests/getversion.c
> index 711d376..53d1d35 100644
> --- a/tests/getversion.c
> +++ b/tests/getversion.c
> @@ -25,6 +25,7 @@
>   *
>   */
>
> +#include 
>  #include "drmtest.h"
>
>  /**
> diff --git a/tests/setversion.c b/tests/setversion.c
> index 3aaf7cc..5a5d01c 100644
> --- a/tests/setversion.c
> +++ b/tests/setversion.c
> @@ -26,6 +26,7 @@
>   */
>
>  #include 
> +#include 
>  #include "drmtest.h"
>
>  /**
> --
> 1.8.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] tests/modetest: silence compiler warning about uninitialised variables

[Rob Clark]

On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov  
wrote:
> The compiler is unaware of that we have at least one crts/connector/plane
> thus it complains that some of our variables will be used uninitialised.
>
> Signed-off-by: Emil Velikov 

Reviewed-by: Rob Clark 

> ---
>
> This patch looks like a rather silly thing to do, although it seems like
> the only was to silence the gcc compiler
> ---
>  tests/modetest/modetest.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index f96b930..ed604b4 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -781,7 +781,7 @@ static struct crtc *pipe_find_crtc(struct device *dev, 
> struct pipe_arg *pipe)
>
>  static int pipe_find_crtc_and_mode(struct device *dev, struct pipe_arg *pipe)
>  {
> -   drmModeModeInfo *mode;
> +   drmModeModeInfo *mode = NULL;
> int i;
>
> pipe->mode = NULL;
> @@ -838,8 +838,8 @@ struct property_arg {
>
>  static void set_property(struct device *dev, struct property_arg *p)
>  {
> -   drmModeObjectProperties *props;
> -   drmModePropertyRes **props_info;
> +   drmModeObjectProperties *props = NULL;
> +   drmModePropertyRes **props_info = NULL;
> const char *obj_type;
> int ret;
> int i;
> --
> 1.8.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] freedreno: set automake options to include subdir-objects

[Rob Clark]

On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov  
wrote:
> Handles automake complains about lack of forward-compatibility, due to the
> source files in the kgsl and msm backends/folders.
>
> Cc: Rob Clark 
> Signed-off-by: Emil Velikov 

I've tested these two (this and 4/6).. they seem to work fine for me,
although I won't claim to be an automake guru, so couldn't actually
tell you if they are the "right" fixes.  I wouldn't mind a reviewed-by
from someone who does know automake better, but if no one speaks up
and says otherwise, I will apply/push them.

BR,
-R

> ---
>
> I'm suspecting that the warning is caused as Archlinux always keeps track
> with latest releases, whereas other distributions prefer to use a more
> tested software
>
> automake 1.14
> autoconf 2.69
> ---
>
>  freedreno/Makefile.am | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
> index ec7e359..7903e5b 100644
> --- a/freedreno/Makefile.am
> +++ b/freedreno/Makefile.am
> @@ -1,3 +1,5 @@
> +AUTOMAKE_OPTIONS=subdir-objects
> +
>  AM_CFLAGS = \
> $(WARN_CFLAGS) \
> -I$(top_srcdir) \
> --
> 1.8.4
>

[PATCH] drm/radeon: enable UVD interrupts on CIK

[Christian König]

From: Christian K?nig 

The same as on evergreen.

Signed-off-by: Christian K?nig 
Reported-by: FrankR Huang 
---
 drivers/gpu/drm/radeon/cik.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e336a31..463c670 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6733,6 +6733,10 @@ restart_ih:
break;
}
break;
+   case 124: /* UVD */
+   DRM_DEBUG("IH: UVD int: 0x%08x\n", src_data);
+   radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
+   break;
case 146:
case 147:
addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
-- 
1.7.9.5

[RFC 0/4] Atomic Display Framework

[Rob Clark]

On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann  wrote:
> On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark  wrote:
>>
>> I guess if you have multiple encoders + multiple connectors for the
>> "ganging" case, then it probably just looks like 2x displays, and
>> nothing more really needed?
>>
>> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario,
>> so I'm not completely sure what the best approach is.  But if we do
>> have hw like this, then it makes sense to support it *somehow* in KMS.
>
>
> I don't have the hardware anymore so this is all working from memory, it
> didn't look like two independent displays.  You had to explicitly set up
> connections between the two mixers to deal with things like scaled overlays
> that spanned both mixers (there was some in-hardware magic to make sure
> there wasn't a visible seam where the two mixers met).

Ok, sounds like mixer == crtc (ie. the thing the combines one or more
planes)?  So it sounds maybe a bit like:

 plane0_0 -\
...+---> CRTC -\
 plane0_n -/   |
   +--> encoder -> connector
 plane1_0 -\   |
...+---> CRTC -/
 plane1_n -/

?

BR,
-R

[RFC 0/4] Atomic Display Framework

[Rob Clark]

On Thu, Aug 29, 2013 at 7:26 PM, Greg Hackmann  wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l?
>  wrote:
>>
>> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann 
>> > wrote:
>>
>> > > 1.  The API is geared toward updating one object at a time.  Android's
>> > > graphics stack needs the entire screen updated atomically to avoid 
>> > > tearing,
>> > > and on some SoCs to avoid wedging the display hardware.  Rob Clark's 
>> > > atomic
>> > > modeset patchset worked, but copy/update/commit design meant the driver 
>> > > had
>> > > to keep a lot more internal state.
>> > >
>> >
>> > I'm not entirely sure how to avoid that, because at least some hw we
>> > need to have the entire new-state in order to validate if it is
>> > possible.
>>
>> I guess the only reason adf is a bit different is that there can only be
>> one custom (driver specific!) blob in the ioctl, so the driver is just
>> free to dump that directly into whatever internal structure it uses to
>> store the full state. So it just frees you from the per-prop state
>> buildup process.
>
>
> Right, the difference is that clients send the complete state they want
> rather than deltas against the current state.  This means the driver doesn't
> have to track its current state and duplicate it at the beginning of the
> flip operation, which is a minor pain on hardware with a ton of knobs to
> twist across different hardware blocks.
>
> Maybe the important question is whether incremental atomic updates is a
> use-case that clients need in practice.  SurfaceFlinger tells the HW
> composer each frame "here's a complete description of what I want onscreen,
> make it so" and IIRC Weston works the same way.

weston works this way (although per-display, it handles independent
displays each with their own display loop).

But X does things more independently..  although effective use of
overlays is a bit difficult with X.. but at least a couple drivers for
hw that does not have dedicated hw cursor do use overlays/planes to
implement hw cursor.

> I used a blob rather than property/value pairs because the composition is
> going to be inherently device specific anyway.  Display controllers have
> such different features and constraints that you'd end up with each driver
> exposing a bunch of hardware-specific properties, and I'm not convinced
> that's any better than just letting the driver dictate how the requests are
> structured (modulo a handful of hardware-agnostic properties).  I'm not
> strongly tied to blobs over properties but I think the former's easier on
> driver developers.

weston (or other upcoming wayland compositors) use kms in a relatively
generic way, so you don't have a userspace component to to the driver
handling the display.  This gets rid of a lot of duplicate kms code,
which is currently duplicated in each xf86-video-foo.

The idea w/ property based "atomic" KMS is that you would have
standard properties for all the generic/core KMS fields (mode, x/y,
w/h, etc).  And driver custom and semi-custom properties for things
that are more hw specific.  Ie. if multiple different hw supports some
particular feature, for example solid-fill bg color, they would align
on the same property name.  In userspace you could query the
properties on the plane/crtc/etc to see what custom things are
supported.  I guess you could think of it as the display/kms
equivalent to GL extensions.

There are some things which are hard to express, like
upscale/downscale/bandwidth limits.  So possibly we eventually need to
define some userspace plugin API where some hw specific module can
help make better decisions about which surfaces to assign to which
planes.  But I think we want to try to share as much code in common as
possible.

BR,
-R

>>
>> But if the idea would to be totally driver specific anyway, I wouldn't
>> even bother with any of this fancy framework stuff. Just specify some
>> massive driver specific structure with a custom ioctl and call it a
>> day.
>
>
> I disagree -- this is basically what vendors do today to support Android,
> and there's a lot of common scaffolding that could go into a framework.  The
> custom ioctl handlers all look reasonably close to this:
>
> 1) import dma-bufs and fences from their respective fds
> 2) map the buffers into the display device
> 3) validate the buffer sizes against their formats and width/stride/height
> 4) validate the requested layout doesn't violate hardware constraints
> 5) hand everything off to a worker that waits for the buffers' sync fences
> to fire
> 6) commit the requested layout to hardware
> 7) unmap and release all the buffers that just left the screen
> 8) advance the sync timeline
>
> with some leeway on the ordering of (2)-(4) and (7)-(8).  ADF handles all of
> this except for (4) and (6), which are inherently hardware-specific and
> delegated to driver ops.

[PATCH] drm/radeon: enable UVD interrupts on CIK

[Alex Deucher]

On Fri, Aug 30, 2013 at 5:10 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> The same as on evergreen.
>
> Signed-off-by: Christian K?nig 
> Reported-by: FrankR Huang 

Added to my queue and cc'ed for stable.

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index e336a31..463c670 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -6733,6 +6733,10 @@ restart_ih:
> break;
> }
> break;
> +   case 124: /* UVD */
> +   DRM_DEBUG("IH: UVD int: 0x%08x\n", src_data);
> +   radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
> +   break;
> case 146:
> case 147:
> addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
> --
> 1.7.9.5
>

[PATCH] drm/radeon: fix init ordering for r600+

[Alex Deucher]

The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of the default GPU fault
page.  In most cases we put vram at zero anyway and
reserve a page for the legacy vga buffer so in practice
this shouldn't cause any problems, but better to make
it correct.

Was changed in:
6fab3febf6d949b0a12b1e4e73db38e4a177a79e

Reported-by: FrankR Huang 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c   | 9 +
 drivers/gpu/drm/radeon/evergreen.c | 9 +
 drivers/gpu/drm/radeon/ni.c| 9 +
 drivers/gpu/drm/radeon/r600.c  | 9 +
 drivers/gpu/drm/radeon/rv770.c | 9 +
 drivers/gpu/drm/radeon/si.c| 9 +
 6 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 79124f8..148c539 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6951,6 +6951,11 @@ static int cik_startup(struct radeon_device *rdev)
/* enable aspm */
cik_program_aspm(rdev);

+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
cik_mc_program(rdev);

if (rdev->flags & RADEON_IS_IGP) {
@@ -6980,10 +6985,6 @@ static int cik_startup(struct radeon_device *rdev)
}
}

-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
r = cik_pcie_gart_enable(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 1832136..6398c1f 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5053,6 +5053,11 @@ static int evergreen_startup(struct radeon_device *rdev)
/* enable aspm */
evergreen_program_aspm(rdev);

+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
evergreen_mc_program(rdev);

if (ASIC_IS_DCE5(rdev)) {
@@ -5078,10 +5083,6 @@ static int evergreen_startup(struct radeon_device *rdev)
}
}

-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
if (rdev->flags & RADEON_IS_AGP) {
evergreen_agp_enable(rdev);
} else {
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 69499ff..d60049e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1863,6 +1863,11 @@ static int cayman_startup(struct radeon_device *rdev)
/* enable aspm */
evergreen_program_aspm(rdev);

+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
evergreen_mc_program(rdev);

if (rdev->flags & RADEON_IS_IGP) {
@@ -1889,10 +1894,6 @@ static int cayman_startup(struct radeon_device *rdev)
}
}

-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 087cff4..b72d4d7 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2698,6 +2698,11 @@ static int r600_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
r600_pcie_gen2_enable(rdev);

+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
r600_mc_program(rdev);

if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
@@ -2708,10 +2713,6 @@ static int r600_startup(struct radeon_device *rdev)
}
}

-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
if (rdev->flags & RADEON_IS_AGP) {
r600_agp_enable(rdev);
} else {
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index b811296..9f58467 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1658,6 +1658,11 @@ static int rv770_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
rv770_pcie_gen2_enable(rdev);

+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
rv770_mc_program(rdev);

if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
@@ -1668,10 +1673,6 @@ static int rv770_startup(struct radeon_device *rdev)
}
}

-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
if (rdev->flags & RADEON_IS_AGP) {
rv770_agp_enable(rdev);
} else {
diff --git 

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Lucas Stach]

Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin  wrote:
> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs  wrote:
> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin  
> >> wrote:
> >>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs  wrote:
>  On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin  
>  wrote:
> > On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs  
> > wrote:
> >> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin  >> alum.mit.edu> wrote:
> >>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs  
> >>> wrote:
>  On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin   alum.mit.edu> wrote:
> > On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach  
> > wrote:
> >> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> >>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  
> >>> wrote:
> >>> > MSIs were only problematic on some old, broken chipsets. But 
> >>> > now that we
> >>> > already see systems where PCI legacy interrupts are somewhat 
> >>> > flaky, it's
> >>> > really time to move to MSIs.
> >>> >
> >>> > Signed-off-by: Lucas Stach 
> >>> > ---
> >>> >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
> >>> >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 
> >>> > +
> >>> >  2 files changed, 18 insertions(+)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
> >>> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> >>> > index 9d2cd20..ce6569f 100644
> >>> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> >>> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> >>> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
> >>> >  struct nouveau_mc {
> >>> > struct nouveau_subdev base;
> >>> > const struct nouveau_mc_intr *intr_map;
> >>> > +   bool use_msi;
> >>> >  };
> >>> >
> >>> >  static inline struct nouveau_mc *
> >>> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
> >>> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> >>> > index ec9cd6f..02b337e 100644
> >>> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> >>> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> >>> > @@ -23,6 +23,7 @@
> >>> >   */
> >>> >
> >>> >  #include 
> >>> > +#include 
> >>> >
> >>> >  static irqreturn_t
> >>> >  nouveau_mc_intr(int irq, void *arg)
> >>> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
> >>> > map++;
> >>> > }
> >>> >
> >>> > +   if (pmc->use_msi)
> >>> > +   nv_wr08(pmc->base.base.parent, 0x00088068, 
> >>> > 0xff);
> >>> Register not present everywhere.
> >>>
> >>> At the very least, the enabling of MSI should be disallowed on the
> >>> earlier chipsets where it's not supported.  Though, it's perhaps
> >>> possible that the pci_enable_msi() call will fail in all of these
> >>> cases anyway.. I'm not certain.
> >>>
> >> MSIs are required property for everything doing PCIe. So the only 
> >> cases
> >> where this should fail is plain PCI/AGP devices. I don't really 
> >> have a
> >> test system for those old cards set up.
> >>
> >> But I remember Ilia having some legacy things plugged in, so maybe 
> >> he
> >> could test this patch and see how it goes?
> >
> > Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
> > that it's not native PCIe, but some sort of bridge thing IIRC),
>  Cases like the nv34 here (i think there's some nv4x that aren't 
>  native
>  pcie too) are what I'm wondering about primarily.
> >>>
> >>> And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
> >>> with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However merely
> >>> starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
> >>> it (with no clients connecting to said X), causes a "failed to idle
> >>> channel" message in dmesg, which apparently never rectifies itself, so
> >>> X is hung forever. FTR, there were no displays connected either, but I
> >>> tried the exact same procedure without the MSI patch and it worked
> >>> fine. Here is the init sequence with the MSI patch:
> >> I don't suppose bashing 0x1868 instead of 0x88068 works here?  If not,
> >
> > Should that work on the NV42 as well?
>  I believe so.  NV4x has both the 0x18xx and 0x88xxx apertures I believe.
> 
> >
> >> next thing would be 

[PATCH 1/3] drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume

[Christian König]

Am 29.08.2013 23:24, schrieb Alex Deucher:
> For powergating, we just need to re-init the registers, there
> is no need to resture the uvd BOs.  This just adds needless
> work when powergating uvd for playback while the system is
> on.  We only need to restore the uvd BOs on an actual resume
> from suspend or when the driver loads.
>
> Signed-off-by: Alex Deucher 

We probably should mention somewhere that this patchset fixes multiple 
stream playback on Kabini, apart from that the patches are:

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/cik.c  | 13 -
>   drivers/gpu/drm/radeon/uvd_v4_2.c |  5 -
>   2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index e336a31..79124f8 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -7051,12 +7051,15 @@ static int cik_startup(struct radeon_device *rdev)
>   return r;
>   }
>   
> - r = uvd_v4_2_resume(rdev);
> + r = radeon_uvd_resume(rdev);
>   if (!r) {
> - r = radeon_fence_driver_start_ring(rdev,
> -R600_RING_TYPE_UVD_INDEX);
> - if (r)
> - dev_err(rdev->dev, "UVD fences init error (%d).\n", r);
> + r = uvd_v4_2_resume(rdev);
> + if (!r) {
> + r = radeon_fence_driver_start_ring(rdev,
> +
> R600_RING_TYPE_UVD_INDEX);
> + if (r)
> + dev_err(rdev->dev, "UVD fences init error 
> (%d).\n", r);
> + }
>   }
>   if (r)
>   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
> diff --git a/drivers/gpu/drm/radeon/uvd_v4_2.c 
> b/drivers/gpu/drm/radeon/uvd_v4_2.c
> index d7e4807..d04d507 100644
> --- a/drivers/gpu/drm/radeon/uvd_v4_2.c
> +++ b/drivers/gpu/drm/radeon/uvd_v4_2.c
> @@ -39,11 +39,6 @@ int uvd_v4_2_resume(struct radeon_device *rdev)
>   {
>   uint64_t addr;
>   uint32_t size;
> - int r;
> -
> - r = radeon_uvd_resume(rdev);
> - if (r)
> - return r;
>   
>   /* programm the VCPU memory controller bits 0-27 */
>   addr = rdev->uvd.gpu_addr >> 3;

[PATCH/RFC v3 06/19] video: display: OF support

[Laurent Pinchart]

Hi Philipp,

On Tuesday 27 August 2013 11:30:51 Philipp Zabel wrote:
> Hi Laurent,
> 
> I have another small issue with the graph helpers below:
> 
> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> [...]
> 
> > +/*
> > -
> > > 
> >   * Graph Helpers
> >   */
> > 
> > @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> > struct list_head *entities)> 
> >  }
> >  EXPORT_SYMBOL_GPL(display_entity_link_graph);
> > 
> > +#ifdef CONFIG_OF
> > +
> > +static int display_of_entity_link_entity(struct device *dev,
> > +struct display_entity *entity,
> > +struct list_head *entities,
> > +struct display_entity *root)
> > +{
> > +   u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> > +   const struct device_node *node = entity->dev->of_node;
> > +   struct media_entity *local = >entity;
> > +   struct device_node *ep = NULL;
> > +   int ret = 0;
> > +
> > +   dev_dbg(dev, "creating links for entity %s\n", local->name);
> > +
> > +   while (1) {
> > +   struct media_entity *remote = NULL;
> > +   struct media_pad *remote_pad;
> > +   struct media_pad *local_pad;
> > +   struct display_of_link link;
> > +   struct display_entity *ent;
> > +   struct device_node *next;
> > +
> > +   /* Get the next endpoint and parse its link. */
> > +   next = display_of_get_next_endpoint(node, ep);
> > +   if (next == NULL)
> > +   break;
> > +
> > +   of_node_put(ep);
> > +   ep = next;
> > +
> > +   dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> > +
> > +   ret = display_of_parse_link(ep, );
> > +   if (ret < 0) {
> > +   dev_err(dev, "failed to parse link for %s\n",
> > +   ep->full_name);
> > +   continue;
> > +   }
> > +
> > +   /* Skip source pads, they will be processed from the other end 
> > of
> > +* the link.
> > +*/
> > +   if (link.local_port >= local->num_pads) {
> > +   dev_err(dev, "invalid port number %u on %s\n",
> > +   link.local_port, link.local_node->full_name);
> > +   display_of_put_link();
> > +   ret = -EINVAL;
> > +   break;
> > +   }
> > +
> > +   local_pad = >pads[link.local_port];
> > +
> > +   if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> > +   dev_dbg(dev, "skipping source port %s:%u\n",
> > +   link.local_node->full_name, link.local_port);
> > +   display_of_put_link();
> > +   continue;
> > +   }
> > +
> > +   /* Find the remote entity. If not found, just skip the link as
> > +* it goes out of scope of the entities handled by the notifier.
> > +*/
> > +   list_for_each_entry(ent, entities, list) {
> > +   if (ent->dev->of_node == link.remote_node) {
> > +   remote = >entity;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (root->dev->of_node == link.remote_node)
> > +   remote = >entity;
> > +
> > +   if (remote == NULL) {
> > +   dev_dbg(dev, "no entity found for %s\n",
> > +   link.remote_node->full_name);
> > +   display_of_put_link();
> > +   continue;
> > +   }
> > +
> > +   if (link.remote_port >= remote->num_pads) {
> > +   dev_err(dev, "invalid port number %u on %s\n",
> > +   link.remote_port, link.remote_node->full_name);
> > +   display_of_put_link();
> > +   ret = -EINVAL;
> > +   break;
> > +   }
> > +
> > +   remote_pad = >pads[link.remote_port];
> > +
> > +   display_of_put_link();
> > +
> > +   /* Create the media link. */
> > +   dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
> > +   remote->name, remote_pad->index,
> > +   local->name, local_pad->index);
> > +
> > +   ret = media_entity_create_link(remote, remote_pad->index,
> > +  local, local_pad->index,
> > +  link_flags);
> > +   if (ret < 0) {
> > +   dev_err(dev,
> > +   "failed to create %s:%u -> %s:%u link\n",
> > +   remote->name, remote_pad->index,
> > +   local->name, local_pad->index);
> > +   break;
> > +   }
> > +   }
> > +
> > +   

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

Need to get my stuff out the door ;-) Highlights:
- pc8+ support from Paulo
- more vma patches from Ben.
- Kconfig option to enable preliminary support by default (Josh
  Triplett)
- Optimized cpu cache flush handling and support for write-through caching
  of display planes on Iris (Chris)
- rc6 tuning from St?phane Marchesin for more stability
- VECS seqno wrap/semaphores fix (Ben)
- a pile of smaller cleanups and improvements all over

Note that I've ditched Ben's execbuf vma conversion for 3.12 since not yet
ready. But there's still other vma conversion stuff in here.

Cheers, Daniel

The following changes since commit 5c536613d8ebda3da0448550d0a997651a6048e2:

  drm/i915: Fix FB WM for HSW (2013-08-09 20:27:43 +0200)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-08-23

for you to fetch changes up to fb1ae911f4e58c2cf28fcd48b59f54d17283da07:

  drm/i915: Print seqnos as unsigned in debugfs (2013-08-23 14:52:37 +0200)


Ben Widawsky (10):
  drm/i915: WARN_ON failed map_and_fenceable
  drm/i915: Initialize seqno for VECS too
  drm/i915: Get VECS semaphore info on error
  drm/i915: Remove node only when allocated
  drm/i915: cleanup map in bind
  drm: WARN when removing unallocated node
  drm/i915: s/obj->exec_list/obj->obj_exec_link in debugfs
  drm/i915: Switch eviction code to use vmas
  drm/i915: prepare bind_to_vm for preallocated vma
  drm/i915/vma: Correct use after free in eviction

Chris Wilson (9):
  drm/i915: Update rules for reading cache lines through the LLC
  drm/i915: Track when an object is pinned for use by the display engine
  drm/i915: Update rules for writing through the LLC with the cpu
  drm/i915: Allow the GPU to cache stolen memory
  drm/i915: Only do a chipset flush after a clflush
  drm/i915: Use Write-Through cacheing for the display plane on Iris
  drm/i915: Allow the user to set bo into the DISPLAY cache domain
  drm/i915: Print the changes required for modeset
  drm/i915: Drop the overzealous warning from i915_gem_set_cache_level

Damien Lespiau (4):
  drm/i915: Remove DSPARB_HWCONTROL()
  drm/i915: Remove HAS_PIPE_CONTROL()
  drm: Remove IS_IRONLAKE_D()
  drm/i915: Remove I915_READ_{NOPID, SYNC_0, SYNC_1})()

Daniel Vetter (6):
  drm/i915: reserve I915_CACHING_DISPLAY and document cache modes
  drm/i915: clarify error paths in create_stolen_for_preallocated
  drm/i915: use vma->node directly and rewrap map in bind
  drm/i915: unpin backing storage in dmabuf_unmap
  drm/i915: explicit store base gem object in dma_buf->priv
  drm/i915: Use POSTING_READ in lcpll code

Guillaume Clement (1):
  i915: Fix SDVO potentially turning off randomly

Jani Nikula (3):
  drm/i915: remove unused leftover variable irq_received
  drm/i915: give more distinctive names to ring hangcheck action enums
  drm/i915: drop unnecessary local variable to suppress build warning

Jesse Barnes (3):
  drm/i915: make IVB FDI training match spec v3
  drm/i915: Expose energy counter on SNB+ through debugfs
  drm/i915: drop WaMbcDriverBootEnable workaround

Josh Triplett (1):
  i915: Add a Kconfig option to turn on i915.preliminary_hw_support by 
default

Paulo Zanoni (20):
  drm/i915: remove set but unused variables
  drm/i915: print a message when we detect an early Haswell SDV
  drm/i915: check the power well when redisabling VGA
  drm/i915: clarify Haswell power well bit names
  drm/i915: enable the power well before module unload
  drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq
  drm/i915: wrap GTIMR changes
  drm/i915: wrap GEN6_PMIMR changes
  drm/i915: don't update GEN6_PMIMR when it's not needed
  drm/i915: add dev_priv->pm_irq_mask
  drm/i915: don't disable/reenable IVB error interrupts when not needed
  drm/i915: don't queue PM events we won't process
  drm/i915: fix how we mask PMIMR when adding work to the queue
  drm/i915: merge HSW and SNB PM irq handlers
  drm/i915: grab force_wake when restoring LCPLL
  drm/i915: fix SDEIMR assertion when disabling LCPLL
  drm/i915: allow package C8+ states on Haswell (disabled)
  drm/i915: add i915_pc8_status debugfs file
  drm/i915: add i915.pc8_timeout function
  drm/i915: enable Package C8+ by default

Rafael Barbalho (1):
  drm/i915: Cleaning up the relocate entry function

St?phane Marchesin (1):
  drm/i915: tune the RC6 threshold for stability

Ville Syrj?l? (2):
  drm/i915: Fix context size calculation on SNB/IVB/VLV
  drm/i915: Print seqnos as unsigned in debugfs

Vinit Azad (1):
  drm/i915: Only unmask required PM interrupts

 drivers/gpu/drm/Kconfig|  11 +
 drivers/gpu/drm/drm_mm.c   |   3 +
 

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Just a one-line patch to fix a black screen issue on rare ivb machines,:w
cc: stable. Normally I'd just shovel this into the -next pull request this
late in the -rc cycle, but Linus was making noises about not getting real
fixes which are cc: stable. So here we go ;-)

Cheers, Daniel

The following changes since commit d8dfad3876e438b759da3c833d62fb8b2267:

  Linux 3.11-rc7 (2013-08-25 17:43:22 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-08-30

for you to fetch changes up to 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d:

  drm/i915: ivb: fix edp voltage swing reg val (2013-08-30 00:07:27 +0200)


Imre Deak (1):
  drm/i915: ivb: fix edp voltage swing reg val

 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[git pull] drm fixes

[Dave Airlie]

Since we are getting to the pointy end, one i915 black screen on some 
machines, and one vmwgfx stop userspace ability to nuke the VM,

there might be one or two ati or nouveau fixes trickle in before final, 
but I think this should pretty much be it.

Dave.


The following changes since commit d8dfad3876e438b759da3c833d62fb8b2267:

  Linux 3.11-rc7 (2013-08-25 17:43:22 -0700)

are available in the git repository at:

  ssh://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 6e4dcff3adbf25acb87e74500a58e3c07bdec40f:

  drm/vmwgfx: Split GMR2_REMAP commands if they are to large (2013-08-30 
09:03:39 +1000)


Dave Airlie (1):
  Merge tag 'drm-intel-fixes-2013-08-30' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Imre Deak (1):
  drm/i915: ivb: fix edp voltage swing reg val

Jakob Bornecrantz (1):
  drm/vmwgfx: Split GMR2_REMAP commands if they are to large

 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 58 +
 2 files changed, 40 insertions(+), 20 deletions(-)

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-dae...@freedesktop.org]

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

--- Comment #17 from tux_mind  ---
i forget to give you the output of my llvm-config --ldflags:
-L/usr/lib64/llvm -Wl,-R -Wl,/usr/lib64/llvm  -lz -lpthread -lffi -lrt -ldl -lm

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-dae...@freedesktop.org]

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

--- Comment #16 from tux_mind  ---
applied your patch, got a missing mesalibdir error in automake.

added this:
dnl Where to install internal libraries
mesalibdir="\$(libdir)/mesa-${VERSION}"
AC_SUBST([mesalibdir])

to configure.ac to get automake works fine.

after a bit of compiling i get:
libtool: link: x86_64-pc-linux-gnu-gcc -shared  -fPIC -DPIC 
.libs/libllvmradeon9.2.0-rc1_la-radeon_uvd.o
.libs/libllvmradeon9.2.0-rc1_la-radeon_setup_tgsi_llvm.o
.libs/libllvmradeon9.2.0-rc1_la-radeon_llvm_emit.o
.libs/libllvmradeon9.2.0-rc1_la-radeon_llvm_util.o  -Wl,--whole-archive
../../../../src/gallium/auxiliary/.libs/libgallium.a -Wl,--no-whole-archive 
-L/usr/lib64/llvm -lz -lpthread -lffi -ldl -lm -Wl,--as-needed -lrt -lelf 
-march=corei7 -O0 -Wl,--no-undefined -Wl,-R -Wl,/usr/lib64/llvm -Wl,-O1  
-Wl,-soname -Wl,libllvmradeon9.2.0-rc1.so -o .libs/libllvmradeon9.2.0-rc1.so
.libs/libllvmradeon9.2.0-rc1_la-radeon_setup_tgsi_llvm.o: In function
`tgsi2llvmtype':
/var/tmp/portage/media-libs/mesa-9.2.0_rc1/work/Mesa-9.2.0-rc1/src/gallium/drivers/radeon/radeon_llvm.h:139:
undefined reference to `LLVMInt32TypeInContext'

followed by hundreds of:
undefined reference to `LLVM$whatever'

probably it's missing a -lllvm when making the shared object.
but i read that llvm ldflag it's something special and need to be taken from
llvm-config --ldflags output.
after a little search in mesa sources i find that a scons script ( never heard
of this language before ) call env.ParseConfig on llvm-config output:
http://www.scons.org/doc/1.2.0/HTML/scons-user/c1814.html
https://github.com/jobermayr/mesa/blob/master/scons/llvm.py

how can i fix that?
thanks for your support :)

PS: i'm keeping using my dirty-patched version without problems ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] radeon kms: fix uninitialised hotplug work usage in r100_irq_process()

[Sergey Senozhatsky]

On (08/29/13 16:06), Alex Deucher wrote:
> On Thu, Aug 29, 2013 at 4:07 PM, Greg Kroah-Hartman
>  wrote:
> > On Thu, Aug 29, 2013 at 02:27:52PM -0400, Alex Deucher wrote:
> >> On Thu, Aug 29, 2013 at 6:55 AM, Meelis Roos  wrote:
> >> >> Reported-by: Meelis Roos 
> >> >> Signed-off-by: Sergey Senozhatsky 
> >> >
> >> > It works, thank you for quick response!
> >> >
> >> > Tested-by: Meelis Roos 
> >>
> >> Thanks.  I've added it to my patch queue.
> >
> > Can you add a cc: stable mark if it also is going to affect the stable
> > kernels as well?
> >
> 
> Yes, already done.
>

Thank you Meelis for testing.



As far as I remember, original patch did not apply to
some stable kernels. I'll keep an eye on it and will
backport.

Thanks,
-ss

> Alex
> 
> > thanks,
> >
> > greg k-h
> 

Re: [PATCH 1/3] drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume

[Christian König]

Am 29.08.2013 23:24, schrieb Alex Deucher:

For powergating, we just need to re-init the registers, there
is no need to resture the uvd BOs.  This just adds needless
work when powergating uvd for playback while the system is
on.  We only need to restore the uvd BOs on an actual resume
from suspend or when the driver loads.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com


We probably should mention somewhere that this patchset fixes multiple 
stream playback on Kabini, apart from that the patches are:


Reviewed-by: Christian König christian.koe...@amd.com


---
  drivers/gpu/drm/radeon/cik.c  | 13 -
  drivers/gpu/drm/radeon/uvd_v4_2.c |  5 -
  2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e336a31..79124f8 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7051,12 +7051,15 @@ static int cik_startup(struct radeon_device *rdev)
return r;
}
  
-	r = uvd_v4_2_resume(rdev);

+   r = radeon_uvd_resume(rdev);
if (!r) {
-   r = radeon_fence_driver_start_ring(rdev,
-  R600_RING_TYPE_UVD_INDEX);
-   if (r)
-   dev_err(rdev-dev, UVD fences init error (%d).\n, r);
+   r = uvd_v4_2_resume(rdev);
+   if (!r) {
+   r = radeon_fence_driver_start_ring(rdev,
+  
R600_RING_TYPE_UVD_INDEX);
+   if (r)
+   dev_err(rdev-dev, UVD fences init error 
(%d).\n, r);
+   }
}
if (r)
rdev-ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
diff --git a/drivers/gpu/drm/radeon/uvd_v4_2.c 
b/drivers/gpu/drm/radeon/uvd_v4_2.c
index d7e4807..d04d507 100644
--- a/drivers/gpu/drm/radeon/uvd_v4_2.c
+++ b/drivers/gpu/drm/radeon/uvd_v4_2.c
@@ -39,11 +39,6 @@ int uvd_v4_2_resume(struct radeon_device *rdev)
  {
uint64_t addr;
uint32_t size;
-   int r;
-
-   r = radeon_uvd_resume(rdev);
-   if (r)
-   return r;
  
  	/* programm the VCPU memory controller bits 0-27 */

addr = rdev-uvd.gpu_addr  3;


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

Re: [PATCH 6/6] drm/nouveau: use MSI interrupts

[Lucas Stach]

Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
 On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
  On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
  On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
  On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
  On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu 
  wrote:
  On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
  On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu 
  wrote:
  On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
  On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu 
  wrote:
  On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de 
  wrote:
  Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
  On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de 
  wrote:
   MSIs were only problematic on some old, broken chipsets. But 
   now that we
   already see systems where PCI legacy interrupts are somewhat 
   flaky, it's
   really time to move to MSIs.
  
   Signed-off-by: Lucas Stach d...@lynxeye.de
   ---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 
   +
2 files changed, 18 insertions(+)
  
   diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
   b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
   index 9d2cd20..ce6569f 100644
   --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
   +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
   @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
   struct nouveau_subdev base;
   const struct nouveau_mc_intr *intr_map;
   +   bool use_msi;
};
  
static inline struct nouveau_mc *
   diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
   b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
   index ec9cd6f..02b337e 100644
   --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
   +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
   @@ -23,6 +23,7 @@
 */
  
#include subdev/mc.h
   +#include core/option.h
  
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
   @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
   map++;
   }
  
   +   if (pmc-use_msi)
   +   nv_wr08(pmc-base.base.parent, 0x00088068, 
   0xff);
  Register not present everywhere.
 
  At the very least, the enabling of MSI should be disallowed on the
  earlier chipsets where it's not supported.  Though, it's perhaps
  possible that the pci_enable_msi() call will fail in all of these
  cases anyway.. I'm not certain.
 
  MSIs are required property for everything doing PCIe. So the only 
  cases
  where this should fail is plain PCI/AGP devices. I don't really 
  have a
  test system for those old cards set up.
 
  But I remember Ilia having some legacy things plugged in, so maybe 
  he
  could test this patch and see how it goes?
 
  Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
  that it's not native PCIe, but some sort of bridge thing IIRC),
  Cases like the nv34 here (i think there's some nv4x that aren't 
  native
  pcie too) are what I'm wondering about primarily.
 
  And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
  with AutoAddGPU disabled the NV18 and NV42 seem fine. However merely
  starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
  it (with no clients connecting to said X), causes a failed to idle
  channel message in dmesg, which apparently never rectifies itself, so
  X is hung forever. FTR, there were no displays connected either, but I
  tried the exact same procedure without the MSI patch and it worked
  fine. Here is the init sequence with the MSI patch:
  I don't suppose bashing 0x1868 instead of 0x88068 works here?  If not,
 
  Should that work on the NV42 as well?
  I believe so.  NV4x has both the 0x18xx and 0x88xxx apertures I believe.
 
 
  next thing would be to mmiotrace the binary driver and see if you can
  make it enable+use MSI on it.  I doubt the current legacy driver does
  it by default, but there was some magic to enable it that you can
  probably find if you google around.
 
  I've yet to set up the legacy driver... I bet it doesn't compile on
  3.11, so I'll have to patch it to nuke procfs/i2c...
 
 
 
  [  307.049812] nouveau  [  DEVICE][:04:00.0] BOOT0  : 0x034a00b1
  [  307.049815] nouveau  [  DEVICE][:04:00.0] Chipset: NV34 (NV34)
  [  307.049819] nouveau  [  DEVICE][:04:00.0] Family : NV30
  [  307.050648] nouveau  [   VBIOS][:04:00.0] checking PRAMIN for 
  image...
  [  307.050652] nouveau  [   VBIOS][:04:00.0] ... signature not 
  found
  [  307.050653] nouveau  [   VBIOS][:04:00.0] checking PROM for 
  image...
  [  307.195201] nouveau  [   VBIOS][:04:00.0] ... appears to be 
  valid
  

RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

[Inki Dae]

Hi Rahul.

Thanks for your patch set.

I had just quick review to all patch series. And I think we could fully hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,

at exynos_hdmi.h

/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
int (*apply)(struct device *dev);
};


at exynos_hdmi.c

/*
  * Add a new structure for hdmi driver data.
  * type could be HDMI_TYPE13 or HDMI_TYPE14.
  * i2c_hdmiphy could be true or false: true means that current hdmi device
uses i2c
  * based hdmiphy device, otherwise platform device based one.
  */
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};

...

/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};


/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};

static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};


static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data   = (void *)exynos4212_hdmi_drv_data,
}, {
...

.compatible = samsung,exynos5420-hdmi,
.data   = (void *)exynos5420_hdmi_drv_data,
}, {
}
};

/* the below example function shows how hdmiphy interfaces can be hided from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
}

static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;

...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}


at exynos_hdmiphy.c

/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};

struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};

struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;

return hdmiphy_platdev_ops;
}

int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
...
/* Register hdmiphy driver appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy) {
ret = i2c_add_driver(hdmiphy_i2c_driver);
...
} else {
ret = platform_driver_register(hdmiphy_platform_driver);
...
}

return ret; 
}

Thanks,
Inki Dae

 -Original Message-
 From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
 Sent: Friday, August 30, 2013 3:59 PM
 To: linux-samsung-...@vger.kernel.org; dri-devel@lists.freedesktop.org
 Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
 seanp...@chromium.org; l.st...@pengutronix.de; tomasz.f...@gmail.com;
 s.nawro...@samsung.com; jo...@samsung.com; r.sh.o...@gmail.com; Rahul
 Sharma
 Subject: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
 driver
 
 Currently, exynos hdmiphy operations and configs are kept
 inside the hdmi driver. Hdmiphy related code is tightly
 coupled with hdmi IP driver.
 
 This series also removes hdmiphy dummy clock for hdmiphy
 and replace it with Phy PMU Control from the hdmiphy driver.
 
 At the end, support for exynos5420 hdmiphy is added to the
 hdmiphy driver which is a platform device.
 
 Drm related paches are based on exynos-drm-next branch at
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
 
 Arch patches are dependent on
 http://www.mail-archive.com/linux-samsung-
 s...@vger.kernel.org/msg22195.html
 
 Rahul Sharma (7):
   drm/exynos: move hdmiphy related code to hdmiphy driver
   drm/exynos: remove dummy hdmiphy clock
   drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
   drm/exynos: add support for exynos5420 hdmiphy
   exynos/drm: fix ddc i2c device probe failure
   ARM: dts: update hdmiphy dt node for exynos5250
   ARM: dts: update hdmiphy dt node for exynos5420
 
  

RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

[Inki Dae]

One more thing, you would need to check if other driver can be probed in
probe context. With your patch, exynos_hdmiphy_driver_register() is called
in hdmi_probe() via hdmi_get_phy_device(), and then
platform_driver_reigster() is called via the
exynos_hdmiphy_driver_register(). I remember that was failed.

Thanks,
Inki Dae

 -Original Message-
 From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
 [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
 Behalf Of Inki Dae
 Sent: Friday, August 30, 2013 5:33 PM
 To: 'Rahul Sharma'; linux-samsung-...@vger.kernel.org; dri-
 de...@lists.freedesktop.org
 Cc: kgene@samsung.com; sw0312@samsung.com; jo...@samsung.com;
 s.nawro...@samsung.com
 Subject: RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
 driver
 
 Hi Rahul.
 
 Thanks for your patch set.
 
 I had just quick review to all patch series. And I think we could fully
 hide
 hdmiphy interfaces,
 exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
 driver.
 That may be prototyped like below,
 
 at exynos_hdmi.h
 
 /* Define hdmiphy callbacks. */
 struct exynos_hdmiphy_ops {
   void (*enable)(struct device *dev);
   void (*disable)(struct device *dev);
   int (*check_mode)(struct device *dev, struct drm_display_mode
 *mode);
   int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
   int (*apply)(struct device *dev);
 };
 
 
 at exynos_hdmi.c
 
 /*
   * Add a new structure for hdmi driver data.
   * type could be HDMI_TYPE13 or HDMI_TYPE14.
   * i2c_hdmiphy could be true or false: true means that current hdmi
 device
 uses i2c
   * based hdmiphy device, otherwise platform device based one.
   */
 struct hdmi_drv_data {
   unsigned int type;
   unsigned int i2c_hdmiphy;
 };
 
 ...
 
 /* Add new members to hdmi context. */
 struct hdmi_context {
   ...
   struct hdmi_drv_data *drv_data;
   struct hdmiphy_ops *ops;
   ...
 };
 
 
 /* Add hdmi device data according Exynos SoC. */
 static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
   .type = HDMI_TYPE14,
   .i2c_hdmiphy = true
 };
 
 static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
   .type = HDMI_TYPE14,
   .i2c_hdmiphy = false
 };
 
 
 static struct of_device_id hdmi_match_types[] = {
   {
   .compatible = samsung,exynos4212-hdmi,
   .data   = (void *)exynos4212_hdmi_drv_data,
   }, {
   ...
 
   .compatible = samsung,exynos5420-hdmi,
   .data   = (void *)exynos5420_hdmi_drv_data,
   }, {
   }
 };
 
 /* the below example function shows how hdmiphy interfaces can be hided
 from
 hdmi driver. */
 static void hdmi_mode_set(...)
 {
   ...
   hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
 }
 
 static int hdmi_get_phy_device(struct hdmi_context *hdata)
 {
   struct hdmi_drv_data *data = hdata-drv_data;
 
   ...
   /* Register hdmiphy driver according to i2c_hdmiphy value. */
   ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
   ...
   /* Get hdmiphy driver ops according to i2c_hdmiphy value. */
   hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
   ...
 }
 
 
 at exynos_hdmiphy.c
 
 /* Define hdmiphy ops respectively. */
 struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
   .enable = exynos_hdmiphy_i2c_enable,
   .disable = exynos_hdmiphy_i2c_disable,
   ...
 };
 
 struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
   .enable = exynos_hdmiphy_platdev_enable,
   .disable = exynos_hdmiphy_platdev_disable,
   ...
 };
 
 struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
 {
   /* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
   if (i2c_hdmiphy)
   return hdmiphy_i2c_ops;
 
   return hdmiphy_platdev_ops;
 }
 
 int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
 {
   ...
   /* Register hdmiphy driver appropriately according to i2c_hdmiphy.
 */
   if (i2c_hdmiphy) {
   ret = i2c_add_driver(hdmiphy_i2c_driver);
   ...
   } else {
   ret = platform_driver_register(hdmiphy_platform_driver);
   ...
   }
 
   return ret;
 }
 
 Thanks,
 Inki Dae
 
  -Original Message-
  From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
  Sent: Friday, August 30, 2013 3:59 PM
  To: linux-samsung-...@vger.kernel.org; dri-devel@lists.freedesktop.org
  Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
  seanp...@chromium.org; l.st...@pengutronix.de; tomasz.f...@gmail.com;
  s.nawro...@samsung.com; jo...@samsung.com; r.sh.o...@gmail.com; Rahul
  Sharma
  Subject: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
  driver
 
  Currently, exynos hdmiphy operations and configs are kept
  inside the hdmi driver. Hdmiphy related code is tightly
  coupled with hdmi IP driver.
 
  This series also 

[PATCH] drm/radeon: enable UVD interrupts on CIK

[Christian König]

From: Christian König christian.koe...@amd.com

The same as on evergreen.

Signed-off-by: Christian König christian.koe...@amd.com
Reported-by: FrankR Huang frankr.hu...@amd.com
---
 drivers/gpu/drm/radeon/cik.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e336a31..463c670 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6733,6 +6733,10 @@ restart_ih:
break;
}
break;
+   case 124: /* UVD */
+   DRM_DEBUG(IH: UVD int: 0x%08x\n, src_data);
+   radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
+   break;
case 146:
case 147:
addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
-- 
1.7.9.5

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

RE: [PATCH 1/1] drm/exynos: Fix build error with exynos_drm_connector.c

[Inki Dae]

 -Original Message-
 From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
 Sent: Friday, August 30, 2013 6:11 PM
 To: dri-devel@lists.freedesktop.org
 Cc: inki@samsung.com; sachin.ka...@linaro.org; patc...@linaro.org;
 Andrzej Hajda
 Subject: [PATCH 1/1] drm/exynos: Fix build error with
 exynos_drm_connector.c
 
 exynos_drm_connector.c now uses videomode helper API. Hence select
 VIDEOMODE_HELPERS at DRM_EXYNOS level itself instead of at
 DRM_EXYNOS_FIMD to avoid the following compilation error when FIMD
 is not selected (introduced by commit cf796235a6 drm/exynos: fimd:
 replace struct fb_videomode with videomode):
 drivers/built-in.o: In function `exynos_drm_connector_get_modes':
 drivers/gpu/drm/exynos/exynos_drm_connector.c:86:
 undefined reference to `drm_display_mode_from_videomode'

Applied.

Thanks,
Inki Dae

 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 Cc: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/Kconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/exynos/Kconfig
 b/drivers/gpu/drm/exynos/Kconfig
 index 80a251a..4752f22 100644
 --- a/drivers/gpu/drm/exynos/Kconfig
 +++ b/drivers/gpu/drm/exynos/Kconfig
 @@ -6,6 +6,7 @@ config DRM_EXYNOS
   select FB_CFB_COPYAREA
   select FB_CFB_IMAGEBLIT
   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
 + select VIDEOMODE_HELPERS
   help
 Choose this option if you have a Samsung SoC EXYNOS chipset.
 If M is selected the module will be called exynosdrm.
 @@ -26,7 +27,6 @@ config DRM_EXYNOS_FIMD
   bool Exynos DRM FIMD
   depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
   select FB_MODE_HELPERS
 - select VIDEOMODE_HELPERS
   help
 Choose this option if you want to use Exynos FIMD for DRM.
 
 --
 1.7.9.5

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

Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

[Rahul Sharma]

Thanks Mr. Dae,

I have some points for discussion.

On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
 Hi Rahul.

 Thanks for your patch set.

 I had just quick review to all patch series. And I think we could fully hide
 hdmiphy interfaces,
 exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
 driver.
 That may be prototyped like below,

 at exynos_hdmi.h

 /* Define hdmiphy callbacks. */
 struct exynos_hdmiphy_ops {
 void (*enable)(struct device *dev);
 void (*disable)(struct device *dev);
 int (*check_mode)(struct device *dev, struct drm_display_mode
 *mode);
 int (*set_mode)(struct device *dev, struct drm_display_mode *mode);
 int (*apply)(struct device *dev);
 };


Above looks fine to me. I will hide the ops as you suggested.


 at exynos_hdmi.c

 /*
   * Add a new structure for hdmi driver data.
   * type could be HDMI_TYPE13 or HDMI_TYPE14.
   * i2c_hdmiphy could be true or false: true means that current hdmi device
 uses i2c
   * based hdmiphy device, otherwise platform device based one.
   */
 struct hdmi_drv_data {
 unsigned int type;
 unsigned int i2c_hdmiphy;
 };

 ...

 /* Add new members to hdmi context. */
 struct hdmi_context {
 ...
 struct hdmi_drv_data *drv_data;
 struct hdmiphy_ops *ops;
 ...
 };


 /* Add hdmi device data according Exynos SoC. */
 static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
 .type = HDMI_TYPE14,
 .i2c_hdmiphy = true
 };

 static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
 .type = HDMI_TYPE14,
 .i2c_hdmiphy = false
 };


 static struct of_device_id hdmi_match_types[] = {
 {
 .compatible = samsung,exynos4212-hdmi,
 .data   = (void *)exynos4212_hdmi_drv_data,
 }, {
 ...

 .compatible = samsung,exynos5420-hdmi,
 .data   = (void *)exynos5420_hdmi_drv_data,
 }, {
 }
 };

 /* the below example function shows how hdmiphy interfaces can be hided from
 hdmi driver. */
 static void hdmi_mode_set(...)
 {
 ...
 hdata-ops-set_mode(hdata-hdmiphy_dev, mode);

This looks fine.

 }

 static int hdmi_get_phy_device(struct hdmi_context *hdata)
 {
 struct hdmi_drv_data *data = hdata-drv_data;

 ...
 /* Register hdmiphy driver according to i2c_hdmiphy value. */
 ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
 ...
 /* Get hdmiphy driver ops according to i2c_hdmiphy value. */
 hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
 ...
 }


 at exynos_hdmiphy.c

 /* Define hdmiphy ops respectively. */
 struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
 .enable = exynos_hdmiphy_i2c_enable,
 .disable = exynos_hdmiphy_i2c_disable,
 ...
 };

 struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
 .enable = exynos_hdmiphy_platdev_enable,
 .disable = exynos_hdmiphy_platdev_disable,
 ...
 };

Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata-dev),
we use i2c_master_send or writeb.


 struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int i2c_hdmiphy)
 {
 /* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
 if (i2c_hdmiphy)
 return hdmiphy_i2c_ops;

 return hdmiphy_platdev_ops;
 }

We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.


 int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
 {
 ...
 /* Register hdmiphy driver appropriately according to i2c_hdmiphy.
 */
 if (i2c_hdmiphy) {
 ret = i2c_add_driver(hdmiphy_i2c_driver);
 ...
 } else {
 ret = platform_driver_register(hdmiphy_platform_driver);
 ...
 }


Here i2c_hdmiphy flag helps in avoiding registering both i2c
and platform drivers for phy. But is it a concern that we should
not register 2 drivers on different buses for single hw device. I am
still not clear on this.

Otherwise we do not need to maintain i2c_hdmiphy flag.

Secondly, we always have registration of i2c driver for ddc and
hdmiphy driver in hdmi probe. It works. I have also tested above
series for 5420 and 5250 smdk board. There are no issues.

regards,
Rahul Sharma.

 return ret;
 }

 Thanks,
 Inki Dae

 -Original Message-
 From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
 Sent: Friday, August 30, 2013 3:59 PM
 To: linux-samsung-...@vger.kernel.org; dri-devel@lists.freedesktop.org
 Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
 seanp...@chromium.org; l.st...@pengutronix.de; tomasz.f...@gmail.com;
 s.nawro...@samsung.com; 

[PATCH] drm/radeon: fix init ordering for r600+

[Alex Deucher]

The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of the default GPU fault
page.  In most cases we put vram at zero anyway and
reserve a page for the legacy vga buffer so in practice
this shouldn't cause any problems, but better to make
it correct.

Was changed in:
6fab3febf6d949b0a12b1e4e73db38e4a177a79e

Reported-by: FrankR Huang frankr.hu...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c   | 9 +
 drivers/gpu/drm/radeon/evergreen.c | 9 +
 drivers/gpu/drm/radeon/ni.c| 9 +
 drivers/gpu/drm/radeon/r600.c  | 9 +
 drivers/gpu/drm/radeon/rv770.c | 9 +
 drivers/gpu/drm/radeon/si.c| 9 +
 6 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 79124f8..148c539 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6951,6 +6951,11 @@ static int cik_startup(struct radeon_device *rdev)
/* enable aspm */
cik_program_aspm(rdev);
 
+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
cik_mc_program(rdev);
 
if (rdev-flags  RADEON_IS_IGP) {
@@ -6980,10 +6985,6 @@ static int cik_startup(struct radeon_device *rdev)
}
}
 
-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
r = cik_pcie_gart_enable(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 1832136..6398c1f 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5053,6 +5053,11 @@ static int evergreen_startup(struct radeon_device *rdev)
/* enable aspm */
evergreen_program_aspm(rdev);
 
+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
evergreen_mc_program(rdev);
 
if (ASIC_IS_DCE5(rdev)) {
@@ -5078,10 +5083,6 @@ static int evergreen_startup(struct radeon_device *rdev)
}
}
 
-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
if (rdev-flags  RADEON_IS_AGP) {
evergreen_agp_enable(rdev);
} else {
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 69499ff..d60049e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1863,6 +1863,11 @@ static int cayman_startup(struct radeon_device *rdev)
/* enable aspm */
evergreen_program_aspm(rdev);
 
+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
evergreen_mc_program(rdev);
 
if (rdev-flags  RADEON_IS_IGP) {
@@ -1889,10 +1894,6 @@ static int cayman_startup(struct radeon_device *rdev)
}
}
 
-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 087cff4..b72d4d7 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2698,6 +2698,11 @@ static int r600_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
r600_pcie_gen2_enable(rdev);
 
+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
r600_mc_program(rdev);
 
if (!rdev-me_fw || !rdev-pfp_fw || !rdev-rlc_fw) {
@@ -2708,10 +2713,6 @@ static int r600_startup(struct radeon_device *rdev)
}
}
 
-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
if (rdev-flags  RADEON_IS_AGP) {
r600_agp_enable(rdev);
} else {
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index b811296..9f58467 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1658,6 +1658,11 @@ static int rv770_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
rv770_pcie_gen2_enable(rdev);
 
+   /* scratch needs to be initialized before MC */
+   r = r600_vram_scratch_init(rdev);
+   if (r)
+   return r;
+
rv770_mc_program(rdev);
 
if (!rdev-me_fw || !rdev-pfp_fw || !rdev-rlc_fw) {
@@ -1668,10 +1673,6 @@ static int rv770_startup(struct radeon_device *rdev)
}
}
 
-   r = r600_vram_scratch_init(rdev);
-   if (r)
-   return r;
-
if (rdev-flags  RADEON_IS_AGP) {

Re: [PATCH] drm/radeon: enable UVD interrupts on CIK

[Alex Deucher]

On Fri, Aug 30, 2013 at 5:10 AM, Christian König
deathsim...@vodafone.de wrote:
 From: Christian König christian.koe...@amd.com

 The same as on evergreen.

 Signed-off-by: Christian König christian.koe...@amd.com
 Reported-by: FrankR Huang frankr.hu...@amd.com

Added to my queue and cc'ed for stable.

Alex

 ---
  drivers/gpu/drm/radeon/cik.c |4 
  1 file changed, 4 insertions(+)

 diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
 index e336a31..463c670 100644
 --- a/drivers/gpu/drm/radeon/cik.c
 +++ b/drivers/gpu/drm/radeon/cik.c
 @@ -6733,6 +6733,10 @@ restart_ih:
 break;
 }
 break;
 +   case 124: /* UVD */
 +   DRM_DEBUG(IH: UVD int: 0x%08x\n, src_data);
 +   radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
 +   break;
 case 146:
 case 147:
 addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
 --
 1.7.9.5

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

Re: [RFC 0/4] Atomic Display Framework

[Rob Clark]

On Thu, Aug 29, 2013 at 7:26 PM, Greg Hackmann ghackm...@google.com wrote:
 On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä
 ville.syrj...@linux.intel.com wrote:

 On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
  On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann ghackm...@google.com
  wrote:

   1.  The API is geared toward updating one object at a time.  Android's
   graphics stack needs the entire screen updated atomically to avoid 
   tearing,
   and on some SoCs to avoid wedging the display hardware.  Rob Clark's 
   atomic
   modeset patchset worked, but copy/update/commit design meant the driver 
   had
   to keep a lot more internal state.
  
 
  I'm not entirely sure how to avoid that, because at least some hw we
  need to have the entire new-state in order to validate if it is
  possible.

 I guess the only reason adf is a bit different is that there can only be
 one custom (driver specific!) blob in the ioctl, so the driver is just
 free to dump that directly into whatever internal structure it uses to
 store the full state. So it just frees you from the per-prop state
 buildup process.


 Right, the difference is that clients send the complete state they want
 rather than deltas against the current state.  This means the driver doesn't
 have to track its current state and duplicate it at the beginning of the
 flip operation, which is a minor pain on hardware with a ton of knobs to
 twist across different hardware blocks.

 Maybe the important question is whether incremental atomic updates is a
 use-case that clients need in practice.  SurfaceFlinger tells the HW
 composer each frame here's a complete description of what I want onscreen,
 make it so and IIRC Weston works the same way.

weston works this way (although per-display, it handles independent
displays each with their own display loop).

But X does things more independently..  although effective use of
overlays is a bit difficult with X.. but at least a couple drivers for
hw that does not have dedicated hw cursor do use overlays/planes to
implement hw cursor.

 I used a blob rather than property/value pairs because the composition is
 going to be inherently device specific anyway.  Display controllers have
 such different features and constraints that you'd end up with each driver
 exposing a bunch of hardware-specific properties, and I'm not convinced
 that's any better than just letting the driver dictate how the requests are
 structured (modulo a handful of hardware-agnostic properties).  I'm not
 strongly tied to blobs over properties but I think the former's easier on
 driver developers.

weston (or other upcoming wayland compositors) use kms in a relatively
generic way, so you don't have a userspace component to to the driver
handling the display.  This gets rid of a lot of duplicate kms code,
which is currently duplicated in each xf86-video-foo.

The idea w/ property based atomic KMS is that you would have
standard properties for all the generic/core KMS fields (mode, x/y,
w/h, etc).  And driver custom and semi-custom properties for things
that are more hw specific.  Ie. if multiple different hw supports some
particular feature, for example solid-fill bg color, they would align
on the same property name.  In userspace you could query the
properties on the plane/crtc/etc to see what custom things are
supported.  I guess you could think of it as the display/kms
equivalent to GL extensions.

There are some things which are hard to express, like
upscale/downscale/bandwidth limits.  So possibly we eventually need to
define some userspace plugin API where some hw specific module can
help make better decisions about which surfaces to assign to which
planes.  But I think we want to try to share as much code in common as
possible.

BR,
-R


 But if the idea would to be totally driver specific anyway, I wouldn't
 even bother with any of this fancy framework stuff. Just specify some
 massive driver specific structure with a custom ioctl and call it a
 day.


 I disagree -- this is basically what vendors do today to support Android,
 and there's a lot of common scaffolding that could go into a framework.  The
 custom ioctl handlers all look reasonably close to this:

 1) import dma-bufs and fences from their respective fds
 2) map the buffers into the display device
 3) validate the buffer sizes against their formats and width/stride/height
 4) validate the requested layout doesn't violate hardware constraints
 5) hand everything off to a worker that waits for the buffers' sync fences
 to fire
 6) commit the requested layout to hardware
 7) unmap and release all the buffers that just left the screen
 8) advance the sync timeline

 with some leeway on the ordering of (2)-(4) and (7)-(8).  ADF handles all of
 this except for (4) and (6), which are inherently hardware-specific and
 delegated to driver ops.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [RFC 0/4] Atomic Display Framework

[Ville Syrjälä]

On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
 On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann ghackm...@google.com wrote:
  On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark robdcl...@gmail.com wrote:
 
  I guess if you have multiple encoders + multiple connectors for the
  ganging case, then it probably just looks like 2x displays, and
  nothing more really needed?
 
  I'm a bit fuzzy on what the hw looks like in this ganging scenario,
  so I'm not completely sure what the best approach is.  But if we do
  have hw like this, then it makes sense to support it *somehow* in KMS.
 
 
  I don't have the hardware anymore so this is all working from memory, it
  didn't look like two independent displays.  You had to explicitly set up
  connections between the two mixers to deal with things like scaled overlays
  that spanned both mixers (there was some in-hardware magic to make sure
  there wasn't a visible seam where the two mixers met).
 
 Ok, sounds like mixer == crtc (ie. the thing the combines one or more
 planes)?  So it sounds maybe a bit like:
 
  plane0_0 -\
 ...+--- CRTC -\
  plane0_n -/   |
+-- encoder - connector
  plane1_0 -\   |
 ...+--- CRTC -/
  plane1_n -/

So I wonder if we should just add the x,y,w,h output parameters to crtc.
That could also be used to specify borders in the normal one crtc per
encoder case. Although the border color is then a bit a question mark.
Supposedly the crtc can have its own background color, but i guess the
border color need not match that necessarily. So maybe add an encoder
bg color property too (or maybe just slap it to the connector since we
don't currently have encoder properties).

Another related thing I really want to expose is the crtc input size
(ie. the coordinate space that the planes' output coordinates live in).
That way the user will get explicit control over the scaler in the crtc
(panel fitter in i915 lingo).

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68391] [radeonsi] Crash unigine-sanctuary

[bugzilla-daemon]

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

--- Comment #9 from Vladimir Ysikov granti...@gmail.com ---
I have GPU lockup with this patch.

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

[PATCH] drm/msm: convert to drm_bridge

[Rob Clark]

Drop the msm_connector base class, and special calls to base class
methods from the encoder, and use instead drm_bridge.  This allows for a
cleaner division between the hdmi (and in future dsi) blocks, from the
mdp block.

Signed-off-by: Rob Clark robdcl...@gmail.com
---
 drivers/gpu/drm/msm/Makefile|   2 +-
 drivers/gpu/drm/msm/hdmi/hdmi.c |  49 +++-
 drivers/gpu/drm/msm/hdmi/hdmi.h |  31 +-
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c  | 167 
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c   | 156 ++
 drivers/gpu/drm/msm/mdp4/mdp4_dtv_encoder.c |  12 --
 drivers/gpu/drm/msm/mdp4/mdp4_kms.c |   9 +-
 drivers/gpu/drm/msm/msm_connector.c |  34 --
 drivers/gpu/drm/msm/msm_connector.h |  68 ---
 drivers/gpu/drm/msm/msm_drv.h   |   6 +-
 10 files changed, 274 insertions(+), 260 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
 delete mode 100644 drivers/gpu/drm/msm/msm_connector.c
 delete mode 100644 drivers/gpu/drm/msm/msm_connector.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 439dfb5..e179148 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -7,6 +7,7 @@ msm-y := \
adreno/adreno_gpu.o \
adreno/a3xx_gpu.o \
hdmi/hdmi.o \
+   hdmi/hdmi_bridge.o \
hdmi/hdmi_connector.o \
hdmi/hdmi_i2c.o \
hdmi/hdmi_phy_8960.o \
@@ -17,7 +18,6 @@ msm-y := \
mdp4/mdp4_irq.o \
mdp4/mdp4_kms.o \
mdp4/mdp4_plane.o \
-   msm_connector.o \
msm_drv.o \
msm_fb.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 12ecfb9..50d11df 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -56,8 +56,9 @@ static irqreturn_t hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-void hdmi_destroy(struct hdmi *hdmi)
+void hdmi_destroy(struct kref *kref)
 {
+   struct hdmi *hdmi = container_of(kref, struct hdmi, refcount);
struct hdmi_phy *phy = hdmi-phy;
 
if (phy)
@@ -70,9 +71,10 @@ void hdmi_destroy(struct hdmi *hdmi)
 }
 
 /* initialize connector */
-int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
-   struct drm_connector *connector)
+int hdmi_init(struct drm_device *dev, struct drm_encoder *encoder)
 {
+   struct hdmi *hdmi = NULL;
+   struct msm_drm_private *priv = dev-dev_private;
struct platform_device *pdev = hdmi_pdev;
struct hdmi_platform_config *config;
int ret;
@@ -85,11 +87,19 @@ int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
 
config = pdev-dev.platform_data;
 
+   hdmi = kzalloc(sizeof(*hdmi), GFP_KERNEL);
+   if (!hdmi) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   kref_init(hdmi-refcount);
+
get_device(pdev-dev);
 
hdmi-dev = dev;
hdmi-pdev = pdev;
-   hdmi-connector = connector;
+   hdmi-encoder = encoder;
 
/* not sure about which phy maps to which msm.. probably I miss some */
if (config-phy_init)
@@ -152,6 +162,22 @@ int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
goto fail;
}
 
+   hdmi-bridge = hdmi_bridge_init(hdmi);
+   if (IS_ERR(hdmi-bridge)) {
+   ret = PTR_ERR(hdmi-bridge);
+   dev_err(dev-dev, failed to create HDMI bridge: %d\n, ret);
+   hdmi-bridge = NULL;
+   goto fail;
+   }
+
+   hdmi-connector = hdmi_connector_init(hdmi);
+   if (IS_ERR(hdmi-connector)) {
+   ret = PTR_ERR(hdmi-connector);
+   dev_err(dev-dev, failed to create HDMI connector: %d\n, ret);
+   hdmi-connector = NULL;
+   goto fail;
+   }
+
hdmi-irq = platform_get_irq(pdev, 0);
if (hdmi-irq  0) {
ret = hdmi-irq;
@@ -168,11 +194,22 @@ int hdmi_init(struct hdmi *hdmi, struct drm_device *dev,
goto fail;
}
 
+   encoder-bridge = hdmi-bridge;
+
+   priv-bridges[priv-num_bridges++]   = hdmi-bridge;
+   priv-connectors[priv-num_connectors++] = hdmi-connector;
+
return 0;
 
 fail:
-   if (hdmi)
-   hdmi_destroy(hdmi);
+   if (hdmi) {
+   /* bridge/connector are normally destroyed by drm: */
+   if (hdmi-bridge)
+   hdmi-bridge-funcs-destroy(hdmi-bridge);
+   if (hdmi-connector)
+   hdmi-connector-funcs-destroy(hdmi-connector);
+   hdmi_destroy(hdmi-refcount);
+   }
 
return ret;
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 34703fe..2c2ec56 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -30,6 +30,8 @@
 struct hdmi_phy;
 
 struct hdmi 

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

[bugzilla-daemon]

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

--- Comment #11 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #9)
 .addImm(Lane);

This results in the lane number being encoded verbatim in the VSRC1 instruction
field, which I don't think is correct?

I tried adding 0x80 to make it an inline literal, but Sanctuary still locks up.

Another potential gotcha I noticed in the ISA documentation is that the
V_READ/WRITELANE instructions don't respect the EXEC mask.

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

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

Johannes Obermayr johannesoberm...@gmx.de changed:

   What|Removed |Added

 CC||johannesoberm...@gmx.de

--- Comment #18 from Johannes Obermayr johannesoberm...@gmx.de ---
This one should compile (I forgot to adapt a few things after I moved it up in
my patch series):
https://github.com/jobermayr/mesa/commit/7e31d65

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

[RFC 0/3] drm: Add panel support

[Thierry Reding]

Hi,

This patch series adds support for panels to DRM. The current implementation
is very basic and only provides hooks for a panel to handle DPMS changes and
return a list of supported modes. That should be enough to support a rather
large number of panels. It should also be easy to extend the framework for
more sophisticated panels such as DSI.

I'm aware of the existing efforts to create such a framework, called CDF. My
impression was that a lot of people thought it overengineered and that it
doesn't fit well into the existing DRM infrastructure. This alternative
proposal is an attempt to start with something simpler (yet extensible) that
fits into DRM more nicely.

Patch 1 adds the framework if one can call it that. At the moment it isn't
anything more than a global registry that panel drivers can register panels
with and display drivers can retrieve them. All of this is very device tree
centric right now, but it shouldn't be difficult to add support for platform
data.

Patch 2 implements a simple driver for dumb panels that can have a regulator
for the supply voltage of the panel and a separate GPIO to enable the panel.
Three simple panels are currently supported by that driver.

Finally patch 3 hooks up the panel framework with the Tegra DRM driver. Note
that the framework isn't tied to the core at the moment. That can easily be
changed if we want to, but I didn't see a need so far. Instead the driver
calls the .dpms() and .get_modes() hooks in it's encoder/connector
implementation.

Thierry

Thierry Reding (3):
  drm: Add panel support
  drm/panel: Add simple panel support
  drm/tegra: Implement panel support

 .../devicetree/bindings/panel/panel-simple.txt |  25 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   2 +
 drivers/gpu/drm/drm_panel.c|  96 ++
 drivers/gpu/drm/panel/Kconfig  |  17 ++
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-simple.c   | 335 +
 drivers/gpu/host1x/drm/Kconfig |   1 +
 drivers/gpu/host1x/drm/drm.h   |   1 +
 drivers/gpu/host1x/drm/output.c|  28 +-
 include/drm/drm_panel.h|  65 
 11 files changed, 571 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/panel-simple.txt
 create mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 drivers/gpu/drm/panel/Kconfig
 create mode 100644 drivers/gpu/drm/panel/Makefile
 create mode 100644 drivers/gpu/drm/panel/panel-simple.c
 create mode 100644 include/drm/drm_panel.h

-- 
1.8.4

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

Re: [RFC 0/4] Atomic Display Framework

[Rob Clark]

On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann ghackm...@google.com wrote:
 On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark robdcl...@gmail.com wrote:

 I guess if you have multiple encoders + multiple connectors for the
 ganging case, then it probably just looks like 2x displays, and
 nothing more really needed?

 I'm a bit fuzzy on what the hw looks like in this ganging scenario,
 so I'm not completely sure what the best approach is.  But if we do
 have hw like this, then it makes sense to support it *somehow* in KMS.


 I don't have the hardware anymore so this is all working from memory, it
 didn't look like two independent displays.  You had to explicitly set up
 connections between the two mixers to deal with things like scaled overlays
 that spanned both mixers (there was some in-hardware magic to make sure
 there wasn't a visible seam where the two mixers met).

Ok, sounds like mixer == crtc (ie. the thing the combines one or more
planes)?  So it sounds maybe a bit like:

 plane0_0 -\
...+--- CRTC -\
 plane0_n -/   |
   +-- encoder - connector
 plane1_0 -\   |
...+--- CRTC -/
 plane1_n -/

?

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/4] Atomic Display Framework

[Ville Syrjälä]

On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote:
 On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä 
 ville.syrj...@linux.intel.com wrote:
 
  On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
   On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann ghackm...@google.com
  wrote:
 
   1.  The API is geared toward updating one object at a time.  Android's
  graphics stack needs the entire screen updated atomically to avoid tearing,
  and on some SoCs to avoid wedging the display hardware.  Rob Clark's atomic
  modeset patchset worked, but copy/update/commit design meant the driver had
  to keep a lot more internal state.
   
  
   I'm not entirely sure how to avoid that, because at least some hw we
   need to have the entire new-state in order to validate if it is
   possible.
 
  I guess the only reason adf is a bit different is that there can only be
  one custom (driver specific!) blob in the ioctl, so the driver is just
  free to dump that directly into whatever internal structure it uses to
  store the full state. So it just frees you from the per-prop state
  buildup process.
 
 
 Right, the difference is that clients send the complete state they want
 rather than deltas against the current state.  This means the driver
 doesn't have to track its current state and duplicate it at the beginning
 of the flip operation, which is a minor pain on hardware with a ton of
 knobs to twist across different hardware blocks.

You could just keep around the same big blob you would expect from the
client, and incrementally update it. Not a big problem in my mind.

 
 Maybe the important question is whether incremental atomic updates is a
 use-case that clients need in practice.  SurfaceFlinger tells the HW
 composer each frame here's a complete description of what I want onscreen,
 make it so and IIRC Weston works the same way.

Complete is a big word. There can be quite a bit of (either per plane,
or per crtc) state that doesn't change all that often, like gamma
ramps/luts, color adjustemnt knobs, etc. Some user space applications
probably won't even care about most of that, but with your approach
they're anyway forced to deal with it.

 
 I used a blob rather than property/value pairs because the composition is
 going to be inherently device specific anyway.  Display controllers have
 such different features and constraints that you'd end up with each driver
 exposing a bunch of hardware-specific properties, and I'm not convinced
 that's any better than just letting the driver dictate how the requests are
 structured (modulo a handful of hardware-agnostic properties).  I'm not
 strongly tied to blobs over properties but I think the former's easier on
 driver developers.

Sure, there's a certainly stuff that's hardware specific, but I'm sure
most of the properties can be abstracted reasonably well for normal
hardware.

There are of course hardware specific restrictions on which combinations
of property values are valid. I have no good solution to this problem.
ATM the plan is just return EINVAL for the whole operation, or possibly
allow the driver to adjust things a bit to make it work almost like the
user requested. We may need some knob to select between strict and
relaxed modes.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] freedreno: set automake options to include subdir-objects

[Rob Clark]

On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Handles automake complains about lack of forward-compatibility, due to the
 source files in the kgsl and msm backends/folders.

 Cc: Rob Clark robcl...@freedesktop.org
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

I've tested these two (this and 4/6).. they seem to work fine for me,
although I won't claim to be an automake guru, so couldn't actually
tell you if they are the right fixes.  I wouldn't mind a reviewed-by
from someone who does know automake better, but if no one speaks up
and says otherwise, I will apply/push them.

BR,
-R

 ---

 I'm suspecting that the warning is caused as Archlinux always keeps track
 with latest releases, whereas other distributions prefer to use a more
 tested software

 automake 1.14
 autoconf 2.69
 ---

  freedreno/Makefile.am | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
 index ec7e359..7903e5b 100644
 --- a/freedreno/Makefile.am
 +++ b/freedreno/Makefile.am
 @@ -1,3 +1,5 @@
 +AUTOMAKE_OPTIONS=subdir-objects
 +
  AM_CFLAGS = \
 $(WARN_CFLAGS) \
 -I$(top_srcdir) \
 --
 1.8.4

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

[Bug 68708] Intel+Radeon Hybrid laptop hang on boot while being on the battery

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #84931|0   |1
is obsolete||

--- Comment #4 from Alex Deucher ag...@yahoo.com ---
Created attachment 84933
  -- https://bugs.freedesktop.org/attachment.cgi?id=84933action=edit
possible fix

Functionally the same as the previous one, but cleaner.

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

Re: [PATCH v2 1/2] drm: Add drm_bridge

[Rob Clark]

On Wed, Aug 14, 2013 at 4:47 PM, Sean Paul seanp...@chromium.org wrote:
 This patch adds the notion of a drm_bridge. A bridge is a chained
 device which hangs off an encoder. The drm driver using the bridge
 should provide the association between encoder and bridge. Once a
 bridge is associated with an encoder, it will participate in mode
 set, and dpms (via the enable/disable hooks).

 Signed-off-by: Sean Paul seanp...@chromium.org

Ok, I've had a chance to rebase my msm drm-bridge patch on top of this
latest version (which I'll be sending in a couple of minutes)

Reviewed-by: Rob Clark robdcl...@gmail.com


 ---
  drivers/gpu/drm/drm_crtc.c| 50 ++
  drivers/gpu/drm/drm_crtc_helper.c | 89 
 ++-
  include/drm/drm_crtc.h| 55 
  3 files changed, 175 insertions(+), 19 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index fc83bb9..0311e2b 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_connector_unplug_all);

 +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
 +   const struct drm_bridge_funcs *funcs)
 +{
 +   int ret;
 +
 +   drm_modeset_lock_all(dev);
 +
 +   ret = drm_mode_object_get(dev, bridge-base, DRM_MODE_OBJECT_BRIDGE);
 +   if (ret)
 +   goto out;
 +
 +   bridge-dev = dev;
 +   bridge-funcs = funcs;
 +
 +   list_add_tail(bridge-head, dev-mode_config.bridge_list);
 +   dev-mode_config.num_bridge++;
 +
 + out:
 +   drm_modeset_unlock_all(dev);
 +   return ret;
 +}
 +EXPORT_SYMBOL(drm_bridge_init);
 +
 +void drm_bridge_cleanup(struct drm_bridge *bridge)
 +{
 +   struct drm_device *dev = bridge-dev;
 +
 +   drm_modeset_lock_all(dev);
 +   drm_mode_object_put(dev, bridge-base);
 +   list_del(bridge-head);
 +   dev-mode_config.num_bridge--;
 +   drm_modeset_unlock_all(dev);
 +}
 +EXPORT_SYMBOL(drm_bridge_cleanup);
 +
  int drm_encoder_init(struct drm_device *dev,
   struct drm_encoder *encoder,
   const struct drm_encoder_funcs *funcs,
 @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
 struct drm_mode_group *gr
 total_objects += dev-mode_config.num_crtc;
 total_objects += dev-mode_config.num_connector;
 total_objects += dev-mode_config.num_encoder;
 +   total_objects += dev-mode_config.num_bridge;

 group-id_list = kzalloc(total_objects * sizeof(uint32_t), 
 GFP_KERNEL);
 if (!group-id_list)
 @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
 struct drm_mode_group *gr
 group-num_crtcs = 0;
 group-num_connectors = 0;
 group-num_encoders = 0;
 +   group-num_bridges = 0;
 return 0;
  }

 @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device 
 *dev,
 struct drm_crtc *crtc;
 struct drm_encoder *encoder;
 struct drm_connector *connector;
 +   struct drm_bridge *bridge;
 int ret;

 if ((ret = drm_mode_group_init(dev, group)))
 @@ -1223,6 +1261,11 @@ int drm_mode_group_init_legacy_group(struct drm_device 
 *dev,
 group-id_list[group-num_crtcs + group-num_encoders +
group-num_connectors++] = connector-base.id;

 +   list_for_each_entry(bridge, dev-mode_config.bridge_list, head)
 +   group-id_list[group-num_crtcs + group-num_encoders +
 +  group-num_connectors + group-num_bridges++] =
 +   bridge-base.id;
 +
 return 0;
  }
  EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
 @@ -3905,6 +3948,7 @@ void drm_mode_config_init(struct drm_device *dev)
 INIT_LIST_HEAD(dev-mode_config.fb_list);
 INIT_LIST_HEAD(dev-mode_config.crtc_list);
 INIT_LIST_HEAD(dev-mode_config.connector_list);
 +   INIT_LIST_HEAD(dev-mode_config.bridge_list);
 INIT_LIST_HEAD(dev-mode_config.encoder_list);
 INIT_LIST_HEAD(dev-mode_config.property_list);
 INIT_LIST_HEAD(dev-mode_config.property_blob_list);
 @@ -3941,6 +3985,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 struct drm_connector *connector, *ot;
 struct drm_crtc *crtc, *ct;
 struct drm_encoder *encoder, *enct;
 +   struct drm_bridge *bridge, *brt;
 struct drm_framebuffer *fb, *fbt;
 struct drm_property *property, *pt;
 struct drm_property_blob *blob, *bt;
 @@ -3951,6 +3996,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 encoder-funcs-destroy(encoder);
 }

 +   list_for_each_entry_safe(bridge, brt,
 +dev-mode_config.bridge_list, head) {
 +   

Re: [PATCH 2/6] tests/*version: add missing string.h header

[Rob Clark]

On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 Prodives memset() and strlen(), used in tests/setversion
 tests/getversion respectively.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Rob Clark robdcl...@gmail.com

 ---
  tests/getversion.c | 1 +
  tests/setversion.c | 1 +
  2 files changed, 2 insertions(+)

 diff --git a/tests/getversion.c b/tests/getversion.c
 index 711d376..53d1d35 100644
 --- a/tests/getversion.c
 +++ b/tests/getversion.c
 @@ -25,6 +25,7 @@
   *
   */

 +#include string.h
  #include drmtest.h

  /**
 diff --git a/tests/setversion.c b/tests/setversion.c
 index 3aaf7cc..5a5d01c 100644
 --- a/tests/setversion.c
 +++ b/tests/setversion.c
 @@ -26,6 +26,7 @@
   */

  #include limits.h
 +#include string.h
  #include drmtest.h

  /**
 --
 1.8.4

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

[RFC 2/3] drm/panel: Add simple panel support

[Thierry Reding]

Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.

Support is added for three panels: An AU Optronics 10.1 WSVGA, a
Chunghwa Picture Tubes 10.1 WXGA and a Panasonic 10.1 WUXGA TFT LCD
panel.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 .../devicetree/bindings/panel/panel-simple.txt |  25 ++
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/panel/Kconfig  |  13 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-simple.c   | 335 +
 5 files changed, 375 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/panel-simple.txt
 create mode 100644 drivers/gpu/drm/panel/Makefile
 create mode 100644 drivers/gpu/drm/panel/panel-simple.c

diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt 
b/Documentation/devicetree/bindings/panel/panel-simple.txt
new file mode 100644
index 000..dfd4b76
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panel-simple.txt
@@ -0,0 +1,25 @@
+Simple display panel
+
+Required properties:
+- compatible: should be one of:
+  - auo,b101aw03: AU Optronics Corporation 10.1 WSVGA TFT LCD panel
+  - cptt,claa101wb03: Chunghwa Picture Tubes Ltd. 10.1 WXGA TFT LCD panel
+  - pc,vvx10f004b00: Panasonic Corporation 10.1 WUXGA TFT LCD panel
+
+Optional properties:
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- power-supply: regulator to provide the supply voltage
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   panel: panel {
+   compatible = cptt,claa101wb01;
+   ddc-i2c-bus = panelddc;
+
+   power-supply = vdd_pnl_reg;
+   enable-gpios = gpio 90 0;
+
+   backlight = backlight;
+   };
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9b009c7..764a5ec 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_DRM_TILCDC)  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_MSM) += msm/
 obj-y  += i2c/
+obj-y  += panel/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 2ddd5bd..843087b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -2,3 +2,16 @@ menuconfig DRM_PANEL
bool DRM panel support
help
  Panel registration and lookup framework.
+
+if DRM_PANEL
+
+config DRM_PANEL_SIMPLE
+   bool support for simple panels
+   depends on OF
+   help
+ DRM panel driver for dumb panels that need at most a regulator and
+ a GPIO to be powered up. Optionally a backlight can be attached so
+ that it can be automatically turned off when the panel goes into a
+ low power state.
+
+endif
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
new file mode 100644
index 000..af9dfa2
--- /dev/null
+++ b/drivers/gpu/drm/panel/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
new file mode 100644
index 000..e38cd6f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include linux/backlight.h
+#include linux/gpio.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include 

Re: [PATCH 3/6] tests/modetest: silence compiler warning about uninitialised variables

[Rob Clark]

On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 The compiler is unaware of that we have at least one crts/connector/plane
 thus it complains that some of our variables will be used uninitialised.

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Rob Clark robdcl...@gmail.com

 ---

 This patch looks like a rather silly thing to do, although it seems like
 the only was to silence the gcc compiler
 ---
  tests/modetest/modetest.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
 index f96b930..ed604b4 100644
 --- a/tests/modetest/modetest.c
 +++ b/tests/modetest/modetest.c
 @@ -781,7 +781,7 @@ static struct crtc *pipe_find_crtc(struct device *dev, 
 struct pipe_arg *pipe)

  static int pipe_find_crtc_and_mode(struct device *dev, struct pipe_arg *pipe)
  {
 -   drmModeModeInfo *mode;
 +   drmModeModeInfo *mode = NULL;
 int i;

 pipe-mode = NULL;
 @@ -838,8 +838,8 @@ struct property_arg {

  static void set_property(struct device *dev, struct property_arg *p)
  {
 -   drmModeObjectProperties *props;
 -   drmModePropertyRes **props_info;
 +   drmModeObjectProperties *props = NULL;
 +   drmModePropertyRes **props_info = NULL;
 const char *obj_type;
 int ret;
 int i;
 --
 1.8.4

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

[RFC 3/3] drm/tegra: Implement panel support

[Thierry Reding]

Use the DRM panel framework to attach a panel to an output.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/host1x/drm/Kconfig  |  1 +
 drivers/gpu/host1x/drm/drm.h|  1 +
 drivers/gpu/host1x/drm/output.c | 28 ++--
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
index 69853a4..01b036d 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/host1x/drm/Kconfig
@@ -2,6 +2,7 @@ config DRM_TEGRA
bool NVIDIA Tegra DRM
depends on DRM
select DRM_KMS_HELPER
+   select DRM_PANEL
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 02ce020..a30276c 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -195,6 +195,7 @@ struct tegra_output {
const struct tegra_output_ops *ops;
enum tegra_output_type type;
 
+   struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
unsigned int hpd_irq;
diff --git a/drivers/gpu/host1x/drm/output.c b/drivers/gpu/host1x/drm/output.c
index 137ae81..2ce03c1 100644
--- a/drivers/gpu/host1x/drm/output.c
+++ b/drivers/gpu/host1x/drm/output.c
@@ -11,6 +11,7 @@
 #include linux/of_gpio.h
 #include linux/i2c.h
 
+#include drm/drm_panel.h
 #include drm.h
 
 static int tegra_connector_get_modes(struct drm_connector *connector)
@@ -19,6 +20,9 @@ static int tegra_connector_get_modes(struct drm_connector 
*connector)
struct edid *edid = NULL;
int err = 0;
 
+   if (output-panel)
+   return output-panel-funcs-get_modes(output-panel);
+
if (output-edid)
edid = kmemdup(output-edid, sizeof(*edid), GFP_KERNEL);
else if (output-ddc)
@@ -74,6 +78,9 @@ tegra_connector_detect(struct drm_connector *connector, bool 
force)
else
status = connector_status_connected;
} else {
+   if (output-panel)
+   status = connector_status_connected;
+
if (connector-connector_type == DRM_MODE_CONNECTOR_LVDS)
status = connector_status_connected;
}
@@ -105,6 +112,11 @@ static const struct drm_encoder_funcs encoder_funcs = {
 
 static void tegra_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
+   struct tegra_output *output = encoder_to_output(encoder);
+   struct drm_panel *panel = output-panel;
+
+   if (panel  panel-funcs  panel-funcs-dpms)
+   panel-funcs-dpms(panel, mode);
 }
 
 static bool tegra_encoder_mode_fixup(struct drm_encoder *encoder,
@@ -153,14 +165,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
 
 int tegra_output_parse_dt(struct tegra_output *output)
 {
+   struct device_node *ddc, *panel;
enum of_gpio_flags flags;
-   struct device_node *ddc;
size_t size;
int err;
 
if (!output-of_node)
output-of_node = output-dev-of_node;
 
+   panel = of_parse_phandle(output-of_node, nvidia,panel, 0);
+   if (panel) {
+   output-panel = of_drm_find_panel(panel);
+   if (!output-panel)
+   return -EPROBE_DEFER;
+
+   of_node_put(panel);
+   }
+
output-edid = of_get_property(output-of_node, nvidia,edid, size);
 
ddc = of_parse_phandle(output-of_node, nvidia,ddc-i2c-bus, 0);
@@ -175,7 +196,7 @@ int tegra_output_parse_dt(struct tegra_output *output)
of_node_put(ddc);
}
 
-   if (!output-edid  !output-ddc)
+   if (!output-panel  !output-edid  !output-ddc)
return -ENODEV;
 
output-hpd_gpio = of_get_named_gpio_flags(output-of_node,
@@ -242,6 +263,9 @@ int tegra_output_init(struct drm_device *drm, struct 
tegra_output *output)
   connector);
drm_connector_helper_add(output-connector, connector_helper_funcs);
 
+   if (output-panel)
+   drm_panel_attach(output-panel, output-connector);
+
drm_encoder_init(drm, output-encoder, encoder_funcs, encoder);
drm_encoder_helper_add(output-encoder, encoder_helper_funcs);
 
-- 
1.8.4

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

[RFC 1/3] drm: Add panel support

[Thierry Reding]

Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.

The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.

Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/Kconfig   |  2 +
 drivers/gpu/drm/Makefile  |  1 +
 drivers/gpu/drm/drm_panel.c   | 96 +++
 drivers/gpu/drm/panel/Kconfig |  4 ++
 include/drm/drm_panel.h   | 65 +
 5 files changed, 168 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 drivers/gpu/drm/panel/Kconfig
 create mode 100644 include/drm/drm_panel.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..b4d8402 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
 source drivers/gpu/drm/qxl/Kconfig
 
 source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/panel/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9b009c7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 
 drm-usb-y   := drm_usb.o
 
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
new file mode 100644
index 000..ff6e459
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include linux/err.h
+#include linux/export.h
+
+#include drm/drm_crtc.h
+#include drm/drm_panel.h
+
+static DEFINE_MUTEX(panel_lock);
+static LIST_HEAD(panel_list);
+
+void drm_panel_init(struct drm_panel *panel)
+{
+   INIT_LIST_HEAD(panel-list);
+}
+EXPORT_SYMBOL(drm_panel_init);
+
+int drm_panel_add(struct drm_panel *panel)
+{
+   mutex_lock(panel_lock);
+   list_add_tail(panel-list, panel_list);
+   mutex_unlock(panel_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_add);
+
+void drm_panel_remove(struct drm_panel *panel)
+{
+   mutex_lock(panel_lock);
+   list_del_init(panel-list);
+   mutex_unlock(panel_lock);
+}
+EXPORT_SYMBOL(drm_panel_remove);
+
+int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
+{
+   if (panel-connector)
+   return -EBUSY;
+
+   panel-connector = connector;
+   panel-drm = connector-dev;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_attach);
+
+int drm_panel_detach(struct drm_panel *panel)
+{
+   panel-connector = NULL;
+   panel-drm = NULL;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_detach);
+
+#ifdef CONFIG_OF
+struct drm_panel *of_drm_find_panel(struct device_node *np)
+{
+   struct drm_panel *panel;
+
+   mutex_lock(panel_lock);
+
+   list_for_each_entry(panel, panel_list, list) {
+   if (panel-dev-of_node == np) {
+   mutex_unlock(panel_lock);
+   

[pull] radeon drm-next-3.12

[Alex Deucher]

Hi Dave,

This is the radeon drm-next request.  Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes


The following changes since commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f:

  drm/vmwgfx: Split GMR2_REMAP commands if they are to large (2013-08-30 
09:03:39 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-3.12

for you to fetch changes up to 679fe80fbe964ea7f9f71781c2ca65b630949da3:

  drm/radeon/dpm: make sure dc performance level limits are valid (CI) 
(2013-08-30 16:31:25 -0400)


Alex Deucher (104):
  drm/edid: add quirk for Medion MD30217PG
  drm/radeon: switch r6xx+ to using CP DMA for the blit copy callback
  drm/radeon/kms: remove r6xx+ blit copy routines
  drm/radeon: add UVD-DPM helper function (v5)
  drm/radeon/dpm: use multiple UVD power states (v3)
  drm/radeon/dpm: rework thermal state handling
  drm/radeon: default to 1024M gart size on rv770+
  drm/radeon/dpm: use performance state if no UVD state
  drm/radeon/kms: fix up dce8 display watermark calc for dpm
  drm/radeon/cik: implement some more atom helpers for DPM
  drm/radeon: switch CIK to use radeon_ucode.h
  drm/radeon/cik: add support for pcie gen1/2/3 switching
  drm/radeon: add support for ASPM on CIK asics
  drm/radeon/cik: restructure rlc setup
  drm/radeon: clean up sumo_rlc_init() for code sharing
  drm/radeon: convert SI,CIK to use sumo_rlc functions
  drm/radeon: implement clock and power gating for CIK (v3)
  drm/radeon: add indirect accessors for dift registers on CIK
  drm/radeon/sumo add helper to go from vid7 to vid2
  drm/radeon: switch to pptable.h
  drm/radeon: add structs to store uvd clock voltage deps
  drm/radeon/cik: add rlc helpers for DPM
  drm/radeon: add support for thermal controller on KB/KV
  drm/radeon: add CI to r600_is_internal_thermal_sensor()
  drm/radeon: add KB/KV to r600_is_internal_thermal_sensor
  drm/radeon: add get_temperature() callbacks for CIK (v2)
  drm/radeon: adjust si_dpm function for code sharing
  drm/radeon/dpm: update cac leakage table parsing for CI
  drm/radeon/dpm: add support for parsing the atom powertune table
  drm/radeon/dpm: grab mvdd_dependency_on_mclk info from vbios
  drm/radeon: add structs to store vce clock voltage deps
  drm/radeon: add clock voltage dep tables for acp, samu
  drm/radeon: parse the vce clock voltage deps table
  drm/radeon: parse the uvd clock voltage deps table
  drm/radeon/dpm: clean up the extended table error pathes
  drm/radeon: parse the samu clock voltage deps table
  drm/radeon: parse the acp clock voltage deps table
  drm/radeon: add r600_get_pcie_lane_support helper
  drm/radeon/dpm: add vce clocks to radeon_ps
  drm/radeon/dpm: add a helper to encode pcie lane setting
  drm/radeon/dpm: add helper to fetch the vrefresh of the current mode
  drm/radeon/kms: add dpm support for KB/KV
  drm/radeon: add dpm support for CI dGPUs (v2)
  drm/radeon/dpm: add debugfs support for CI
  drm/radeon/dpm: implement force performance level for CI
  drm/radeon/dpm: implement vblank_too_short callback for CI
  drm/radeon/dpm: add debugfs support for KB/KV
  drm/radeon/dpm: implement force performance level for KB/KV
  drm/radeon/dpm: add new callback for powergating UVD (v4)
  drm/radeon: restructure UVD code to handle UVD PG (v2)
  drm/radeon/dpm: implement UVD powergating for KB/KV
  drm/radeon/dpm: implement UVD powergating for CI
  drm/radeon/dpm: add reclocking quirk for ASUS K70AF
  drm/radeon/dpm: adjust the vblank time checks for eg, ni, si
  drm/radeon: fix endian bugs in hw i2c atom routines
  drm/edid: add a helper function to extract the speaker allocation data 
block (v3)
  drm/radeon: add audio support for DCE6/8 GPUs (v12)
  drm/radeon: set speaker allocation for DCE4/5 (v2)
  drm/radeon: set speaker allocation for DCE3.2
  drm/radeon: add cg and pg flags
  drm/radeon: use new cg/pg flags for SI
  drm/radeon/si: restructure cg code (v3)
  drm/radeon: fixes for gfx clockgating on SI
  drm/radeon: handle cg in SI dpm code
  drm/radeon: enable mgcg on SI
  drm/radeon/si: properly set up the clearstate buffer for pg (v2)
  drm/radeon/si: enable DMA pg by default
  drm/radeon: restructure cg/pg on cik (v2)
  drm/radeon: fixes for gfx clockgating on CIK
  drm/radeon/cik: properly set up the clearstate buffer for pg (v2)
  drm/radeon: handle cg in CI dpm code
  drm/radeon: handle cg in KB/KV dpm code
  drm/radeon: enable mgcg on CIK
  drm/radeon: update line buffer 

Re: [PATCH 6/6] intel: Update package name and description in libdrm_intel.pc

[Damien Lespiau]

On Thu, Aug 29, 2013 at 09:31:54PM +0100, Emil Velikov wrote:
 Currently the package name and description duplicate that of the
 core libdrm. Update those to reflect reality.
 
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Looks good to me:
Reviewed-by: Damien Lespiau damien.lesp...@intel.com

-- 
Damien

 ---
 
 Trivial change IMHO, notices while checking the package Libs
 ---
 
  intel/libdrm_intel.pc.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/intel/libdrm_intel.pc.in b/intel/libdrm_intel.pc.in
 index 3ba6793..670e4fe 100644
 --- a/intel/libdrm_intel.pc.in
 +++ b/intel/libdrm_intel.pc.in
 @@ -3,8 +3,8 @@ exec_prefix=@exec_prefix@
  libdir=@libdir@
  includedir=@includedir@
  
 -Name: libdrm
 -Description: Userspace interface to kernel DRM services
 +Name: libdrm_intel
 +Description: Userspace interface to intel kernel DRM services
  Version: @PACKAGE_VERSION@
  Requires: libdrm
  Libs: -L${libdir} -ldrm_intel
 -- 
 1.8.4
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 55420] [Wine] fails to compile GLSL shader in Falcon BMS 4.32u3

[bugzilla-daemon]

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

Ian Romanick i...@freedesktop.org changed:

   What|Removed |Added

   Assignee|i...@freedesktop.org |dri-devel@lists.freedesktop
   ||.org
 CC||mar...@gmail.com
  Component|glsl-compiler   |Drivers/Gallium/r600

--- Comment #1 from Ian Romanick i...@freedesktop.org ---
This seems like an issue in the r600 back-end.  The glsl-compiler component is
the common front-end code.  Perhaps Marek can comment...

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

[Bug 55420] [Wine] fails to compile GLSL shader in Falcon BMS 4.32u3

[bugzilla-daemon]

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

--- Comment #2 from Marek Olšák mar...@gmail.com ---
Please test latest Mesa master. TGSI recently got support for array
declarations of temporaries, making register allocation possible with indirect
addressing. That said, I'm not sure if the r600g shader backend takes advantage
of it.

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

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

[bugzilla-daemon]

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

--- Comment #14 from Marek Olšák mar...@gmail.com ---
That commit does break something, but it was fixed in:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=0d7f087483d014305ec96a84ce5a28355f843c86

In other words, can you checkout 7948ed1250cae78ae1b22dbce4ab23aceacc6159, then
cherry-pick 0d7f087483d014305ec96a84ce5a28355f843c86, and then see if the issue
is still there?

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

Re: [git pull] drm fixes

[Linus Torvalds]

On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie airl...@linux.ie wrote:

   ssh://people.freedesktop.org/~airlied/linux drm-fixes

Please people! When you post ssh addresses, always remember to also
post your user name and password or private key with the pull request.

Ok?

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

Re: [git pull] drm fixes

[Dave Airlie]

On Sat, Aug 31, 2013 at 9:18 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie airl...@linux.ie wrote:

   ssh://people.freedesktop.org/~airlied/linux drm-fixes

 Please people! When you post ssh addresses, always remember to also
 post your user name and password or private key with the pull request.

 Ok?

Oh sorry [1]

Oops, forgot to add the -public to my request-pull command line,

git://people.freedesktop.org/~airlied/linux drm-fixes

should be the right thing.

Dave.

[1]

-BEGIN RSA PRIVATE KEY-
MIIEpAIBAAKCAQEA8Sxk4nlsPzPf6Ezgr1wmWoggaCnsLc6t1K5tHZjqtZfhPTGS
Vwv5s+pcEdsq408TGNk8wMNyvTWp1WgY0r3xxr9+FI6Phv69aQwbvtJ43Hvn3XCz
9EAXCmXY/rhWvFOOKVh0NFVc7Bzul+jW0J1TUXxu5fbq2eSy7P02QCb7JZLYQc1J
TxZkcAgFjYV1tU1q0NRh9Y4EoUI1nYjVbhFXuXvzL2YB0u6PciPm7n0Yqfwgs1MU
lZuiEzehd89Vm9y2LSzcYamimsv569WletzvtnUWGkyGxUCA0T8yGexu4/r3883I
8amLb8rj/4XeWlxtKsFV+oAF9Ru7SPPq8oah7QIDAQABAoIBADYO/2YMVYktNYk6
gjqMa0RrsufmTbxO0YQUvPyfZCzkKGaxD95XHteHNrAB8nEVLnCpcQa8SKHEv5bI
SJgkX2dvUPGGqwFVZFuBjU6OmuzBEU3/jza2jvOTtLoT081O5VS7MQDyCWwbaBfA
5zXHrf9b5vfBCw9gRgL9FwX2NuFKw64UogKz/t+x7h6fqL8yCCwjdTRvOrDpLUto
x4y7Xbc5lvppzLoxpR4CGDB8PNXfHwYsw3uAJd5A0RxjXcBy0yLgOmMzK4yDxQgF
qPaV3LyUtVWx6hqBS15v7Vu58aW1d3hjqy1QQFC2iQ61bBqVyQrhFLAN5C9z22h8
XFT5SUECgYEA+QksPviu2JgrAw/0VzHHL/7CpXlgwdXvkcTqLxTNBMbcsJOfUxYX
IZf2hT8gReveeHxRoHCwX2fmfqXSsa70z2vpseo/hC+2OHF9tXezU2hFzwdS/lMZ
5wqxm2wxgiM0G4ZeILZ+YapXfHoutgLPanFSWh22pmsIqt00LcvMlWUCgYEA9+rv
UfA/k5YLrpaPj87dRTQ5PKTO/z7UgEkFfHaQFok8nu+M+tuuNZHVuKJ+gPBx/L9J
gIwpc0h1xz0eYFAFAuwBBslLHvJUOK5VRYEKHVxYTUVi3TzM471dLjGGIekwB16j
bCBXXTLOhAtYJ3h0YCfHK80gkqVvEBD+fvvl9ekCgYB2uZTKgKx6vjDjSNvoJecc
ToxlbzRdtKx+Bi7PO09yk4vq8rXmWoW0kkoIxEuSihyJvFr97jtngJU2k7+azhoQ
ORY0p8SYNFbfGdwgg2yOuwts48UBUoTqzQJXYoFH1Zil9q0xU091KEyFH4rdYwGX
cWcdZ0UImcaMDuEtZBeosQKBgQCYVQ4aLeISwFaLP04VEgnZ9P3aanYaVjPiY3vw
fzWH82mBSzY4CfXgSqyk14udlKClqa/zQaxSfsqH0uEwUtrRccwrrFHxQPtJHK2e
mGxroAtN532Y7TwED54KvTlq6sqtLJSD4tdrl8VXU1UmY5g2YRq7qj4CfY5hs998
jTE+yQKBgQCSrChX2Q1qj/+SqiX2058uDfkLzAlo4sP2mLvqREKW7NbF72UgS1Ws
Bbr52p6ISi2yeCylkf+7EkEGUX5lelkyP8UrawsPoTWDyPoaRurSqGwthkGPCSDW
8kRPWlu7rJD+ZZC61EdtQJAKUCXuLVcK3+SXp3PNPZQW7LMOLdbixQ==
-END RSA PRIVATE KEY-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68775] New: RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 68775
  Assignee: dri-devel@lists.freedesktop.org
   Summary: RV635 (r600) 600_DEBUG=sb causes GPU reset playing
Second Life
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: shawn.st...@rogers.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 9.2
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 84943
  -- https://bugs.freedesktop.org/attachment.cgi?id=84943action=edit
dmesg of kernel w/ gpu reset info

Without 600_DEBUG=sb game loads but poor performance

With 600_DEBUG=sb GPU resets over and over unless VT switch out of X to
console.

cmdline: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc7.git2.2.fc21.x86_64
root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 rd.luks=0
vconsole.keymap=us rd.lvm.lv=fedora/root rhgb quiet slub_debug=-
cgroup_disable=memory radeon.dpm=1 console=tty0 console=ttyS0,38400n8
LANG=en_US.UTF-8

See dmesg attachment for gpu reset information

RPMs:

mesa-libGL-9.2-0.14.20130723.fc19.x86_64
libdrm-2.4.46-1.fc19.x86_64
kernel-3.11.0-0.rc7.git2.2.fc21.x86_64 (non-debug builds)

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