date:20140403

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

--- Comment #21 from nb  ---
great! also working for me with the kernel parameters. So happy, the first time
i help squash a bug :')
Now, how we make this go uptream, so it work out of the box and we can close
this ticket :B

-- 
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/20140403/64286484/attachment.html>

[Bug 76865] R600: OpenCL regression since llvm revision 204072

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

Bruno Jim?nez  changed:

   What|Removed |Added

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

--- Comment #1 from Bruno Jim?nez  ---
Bug solved with revision 205562:
http://llvm.org/viewvc/llvm-project?view=revision&revision=205562

-- 
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/20140403/82acf72e/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

--- Comment #2 from Garrett  ---
Hi Christian. Thanks for your help.  They are not 100% the same.  I hope that I
am not misleading you.  My, aplogies in advance, if it works out to be so.

xorg3.15, Kernel 3.13.7 vs. 3.14

Precompiled Openelec builds:

working:
xorg 3.15, Kernel 3.13.7, no patch
http://xbmcnightlybuilds.com/openelec-generic-x86_64-r18022-g4473271-download/

Not working:
xorg 3.15, Kernel 3.14, patch
http://saraev.ca/OpenELEC-Generic.x86_64-devel-20140330151700-r18049-g02739c3.tar

Tonight I will make a new build environment to test PURELY the patch/un-patch. 
I am a bit new to building kernel Dri/Drm modules.  But I should be able to
figure it out.

HUMM:   
clock   24.0Hz  good
clock  23.98Hz  bad

It might be that my LCD does not like 23.98?  Thanks.  I will post back with
the results.

-- 
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/20140403/0d382d9c/attachment.html>

[PATCH v4] drm/exynos: add super device support

This patch adds super device support to bind sub drivers
using device tree.

For this, you should add a super device node to each machine dt files
like belows,

In case of using MIPI-DSI,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>, <&dsi>;
};

In case of using DisplayPort,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>, <&dp>;
};

In case of using Parallel panel,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>;
};

And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.

ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI

With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.

Previous RFC patch,
 http://www.spinics.net/lists/dri-devel/msg54671.html

Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
  drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
  should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.

Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
  is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
  . 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
  . crtcs and connectors propery names are also specific to Linux so
change them to generic name.

Changlog v3:
- Do not probe/remove dpi module if fimd node has no port node.

Changelog v4:
- Move some codes for getting resources from each bind function to
  each probe function.
  . if -EPROBE_DEFER is returned at bind context, components will be
bound and unbound repeatedly by deferred probe feature.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |   45 ---
 drivers/gpu/drm/exynos/exynos_drm_core.c |  216 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   17 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   16 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  202 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   73 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  110 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   87 +---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   61 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |   59 +---
 drivers/gpu/drm/exynos/exynos_mixer.c|   54 ++--
 12 files changed, 499 insertions(+), 445 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a59bca9..cb9aa58 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs 
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
 };

-static int exynos_dp_initialize(struct exynos_drm_display *display,
-   struct drm_device *drm_dev)
-{
-   struct exynos_dp_device *dp = display->ctx;
-
-   dp->drm_dev = drm_dev;
-
-   return 0;
-}
-
 static bool find_bridge(const char *compat, struct bridge_init *bridge)
 {
bridge->client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)
 }

 static struct exynos_drm_display_ops exynos_dp_display_ops = {
-   .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
 };
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct 
exynos_dp_device *dp)
return 0;
 }

-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void 
*data)
 {
+   struct platform_device *pdev = to_platform_device(dev);
+   struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;

@@ -1293,21 +1285,40 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
disable_irq(dp->irq);

+   dp->drm_dev = drm_dev;
exynos_dp_display.ctx = dp;

platform_set_

[PATCH 7/7] drm/exynos: replace hdmi reset with hdmi disable

Before setting the core and timing generation registers,
hdmi driver resets the whole hdmi hardware, which also
resets the audio related registers.

Hdmi reset is replaced by hdmi disable which is called
just before setting the core and timing registers. It
also ensure that audio settings are not changed.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shirish S 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   40 ++
 1 file changed, 16 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index fce2f7b..4c69139 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -197,6 +197,7 @@ struct hdmi_context {
struct i2c_client   *hdmiphy_port;

/* current hdmiphy conf regs */
+   struct drm_display_mode current_mode;
struct hdmi_conf_regs   mode_conf;

struct hdmi_resources   res;
@@ -1350,20 +1351,15 @@ static void hdmi_audio_control(struct hdmi_context 
*hdata, bool onoff)
HDMI_ASP_EN : HDMI_ASP_DIS, HDMI_ASP_MASK);
 }

-static void hdmi_conf_reset(struct hdmi_context *hdata)
+static void hdmi_start(struct hdmi_context *hdata, bool start)
 {
-   u32 reg;
+   u32 val = start ? HDMI_TG_EN : 0;

-   if (hdata->type == HDMI_TYPE13)
-   reg = HDMI_V13_CORE_RSTOUT;
-   else
-   reg = HDMI_CORE_RSTOUT;
+   if (hdata->current_mode.flags & DRM_MODE_FLAG_INTERLACE)
+   val |= HDMI_FIELD_EN;

-   /* resetting HDMI core */
-   hdmi_reg_writemask(hdata, reg,  0, HDMI_CORE_SW_RSTOUT);
-   usleep_range(1, 12000);
-   hdmi_reg_writemask(hdata, reg, ~0, HDMI_CORE_SW_RSTOUT);
-   usleep_range(1, 12000);
+   hdmi_reg_writemask(hdata, HDMI_CON_0, val, HDMI_EN);
+   hdmi_reg_writemask(hdata, HDMI_TG_CMD, val, HDMI_TG_EN | HDMI_FIELD_EN);
 }

 static void hdmi_conf_init(struct hdmi_context *hdata)
@@ -1500,12 +1496,7 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
*hdata)
clk_prepare_enable(hdata->res.sclk_hdmi);

/* enable HDMI and timing generator */
-   hdmi_reg_writemask(hdata, HDMI_CON_0, ~0, HDMI_EN);
-   if (core->int_pro_mode[0])
-   hdmi_reg_writemask(hdata, HDMI_TG_CMD, ~0, HDMI_TG_EN |
-   HDMI_FIELD_EN);
-   else
-   hdmi_reg_writemask(hdata, HDMI_TG_CMD, ~0, HDMI_TG_EN);
+   hdmi_start(hdata, true);
 }

 static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
@@ -1667,12 +1658,7 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
*hdata)
clk_prepare_enable(hdata->res.sclk_hdmi);

/* enable HDMI and timing generator */
-   hdmi_reg_writemask(hdata, HDMI_CON_0, ~0, HDMI_EN);
-   if (core->int_pro_mode[0])
-   hdmi_reg_writemask(hdata, HDMI_TG_CMD, ~0, HDMI_TG_EN |
-   HDMI_FIELD_EN);
-   else
-   hdmi_reg_writemask(hdata, HDMI_TG_CMD, ~0, HDMI_TG_EN);
+   hdmi_start(hdata, true);
 }

 static void hdmi_mode_apply(struct hdmi_context *hdata)
@@ -1788,7 +1774,7 @@ static void hdmi_conf_apply(struct hdmi_context *hdata)
hdmiphy_conf_apply(hdata);

mutex_lock(&hdata->hdmi_mutex);
-   hdmi_conf_reset(hdata);
+   hdmi_start(hdata, false);
hdmi_conf_init(hdata);
mutex_unlock(&hdata->hdmi_mutex);

@@ -2029,6 +2015,9 @@ static void hdmi_mode_set(struct exynos_drm_display 
*display,
m->vrefresh, (m->flags & DRM_MODE_FLAG_INTERLACE) ?
"INTERLACED" : "PROGERESSIVE");

+   /* preserve mode information for later use. */
+   drm_mode_copy(&hdata->current_mode, mode);
+
if (hdata->type == HDMI_TYPE13)
hdmi_v13_mode_set(hdata, mode);
else
@@ -2089,6 +2078,9 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)
goto out;
mutex_unlock(&hdata->hdmi_mutex);

+   /* HDMI System Disable */
+   hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_EN);
+
hdmiphy_poweroff(hdata);

cancel_delayed_work(&hdata->hotplug_work);
-- 
1.7.9.5

[PATCH 6/7] drm/exynos: Read hpd gpio in is_connected callback

From: Sean Paul 

This patch adds a gpio read of hpd during the is_connected
callback. This fixes the case where hdmi is off going into
suspend and the cable is plugged in while suspended. In this
case, the hpd interrupt does not fire and is_connected will
return false.

Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b2cbf43..fce2f7b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1031,6 +1031,8 @@ static enum drm_connector_status hdmi_detect(struct 
drm_connector *connector,
 {
struct hdmi_context *hdata = ctx_from_connector(connector);

+   hdata->hpd = gpio_get_value(hdata->hpd_gpio);
+
return hdata->hpd ? connector_status_connected :
connector_status_disconnected;
 }
-- 
1.7.9.5

[PATCH 5/7] drm/exynos: add hdmiphy power on/off sequence

From: Shirish S 

This patch implements the power on/off sequence
of HDMI PHY in exynos5420 and exynos5250 as provided
by the hardware team.

This has been verified for mulitple iterations of
S2R.

Signed-off-by: Shirish S 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   40 +-
 drivers/gpu/drm/exynos/regs-hdmi.h   |7 +-
 2 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 539e603..b2cbf43 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1711,16 +1711,44 @@ static void hdmiphy_conf_reset(struct hdmi_context 
*hdata)

 static void hdmiphy_poweron(struct hdmi_context *hdata)
 {
-   if (hdata->type == HDMI_TYPE14)
-   hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0,
-   HDMI_PHY_POWER_OFF_EN);
+   if (hdata->type != HDMI_TYPE14)
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   /* For PHY Mode Setting */
+   hdmiphy_reg_writeb(hdata, HDMIPHY_MODE_SET_DONE,
+   HDMI_PHY_ENABLE_MODE_SET);
+   /* Phy Power On */
+   hdmiphy_reg_writeb(hdata, HDMIPHY_POWER,
+   HDMI_PHY_POWER_ON);
+   /* For PHY Mode Setting */
+   hdmiphy_reg_writeb(hdata, HDMIPHY_MODE_SET_DONE,
+   HDMI_PHY_DISABLE_MODE_SET);
+   /* PHY SW Reset */
+   hdmiphy_conf_reset(hdata);
 }

 static void hdmiphy_poweroff(struct hdmi_context *hdata)
 {
-   if (hdata->type == HDMI_TYPE14)
-   hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0,
-   HDMI_PHY_POWER_OFF_EN);
+   if (hdata->type != HDMI_TYPE14)
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   /* PHY SW Reset */
+   hdmiphy_conf_reset(hdata);
+   /* For PHY Mode Setting */
+   hdmiphy_reg_writeb(hdata, HDMIPHY_MODE_SET_DONE,
+   HDMI_PHY_ENABLE_MODE_SET);
+
+   /* PHY Power Off */
+   hdmiphy_reg_writeb(hdata, HDMIPHY_POWER,
+   HDMI_PHY_POWER_OFF);
+
+   /* For PHY Mode Setting */
+   hdmiphy_reg_writeb(hdata, HDMIPHY_MODE_SET_DONE,
+   HDMI_PHY_DISABLE_MODE_SET);
 }

 static void hdmiphy_conf_apply(struct hdmi_context *hdata)
diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
b/drivers/gpu/drm/exynos/regs-hdmi.h
index 344a5db..fd4c590 100644
--- a/drivers/gpu/drm/exynos/regs-hdmi.h
+++ b/drivers/gpu/drm/exynos/regs-hdmi.h
@@ -579,7 +579,12 @@
 #define HDMI_TG_3D HDMI_TG_BASE(0x00F0)

 /* HDMI PHY Registers Offsets*/
-#define HDMIPHY_MODE_SET_DONE  (0x7C >> 2)
+#define HDMIPHY_POWER  (0x74 >> 2)
+#define HDMIPHY_MODE_SET_DONE  (0x7c >> 2)
+
+/* HDMI PHY Values */
+#define HDMI_PHY_POWER_ON  0x80
+#define HDMI_PHY_POWER_OFF 0xff

 /* HDMI PHY Values */
 #define HDMI_PHY_DISABLE_MODE_SET  0x80
-- 
1.7.9.5

[PATCH 4/7] drm/exynos: hdmi: remove unnecessary memset

From: Daniel Kurtz 

Our resources were just zalloc'ed as part of hdata.
They are already 0.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8973..539e603 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2151,8 +2151,6 @@ static int hdmi_resources_init(struct hdmi_context *hdata)

DRM_DEBUG_KMS("HDMI resource init\n");

-   memset(res, 0, sizeof(*res));
-
/* get clocks, power */
res->hdmi = devm_clk_get(dev, "hdmi");
if (IS_ERR(res->hdmi)) {
-- 
1.7.9.5

[PATCH 3/7] drm/exynos: check for null pointers in error handling

From: Paul Taysom 

Smatch error from arm build: drivers/gpu/drm/exynos/
exynos_hdmi.c:2374 hdmi_probe() error: potential NULL
dereference 'hdata->hdmiphy_port'.

Added check for hdata->hdmiphy_port that it is not NULL.

Signed-off-by: Paul Taysom 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f6d4435..5ed8973 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2356,7 +2356,8 @@ static int hdmi_probe(struct platform_device *pdev)
return 0;

 err_hdmiphy:
-   put_device(&hdata->hdmiphy_port->dev);
+   if (hdata->hdmiphy_port)
+   put_device(&hdata->hdmiphy_port->dev);
 err_ddc:
put_device(&hdata->ddc_adpt->dev);
return ret;
-- 
1.7.9.5

[PATCH 2/7] drm/exynos: Debounce HDMI hotplug interrupts

From: Sean Paul 

This patch debounces hotplug interrupts generated by the HDMI hotplug
gpio. The reason this is needed is that we get multiple (5) interrupts
every time a monitor is inserted which causes us to needlessly enable
and disable the IP block.

Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 79f98ac..f6d4435 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -51,6 +51,8 @@
 #define get_hdmi_display(dev)  platform_get_drvdata(to_platform_device(dev))
 #define ctx_from_connector(c)  container_of(c, struct hdmi_context, connector)

+#define HOTPLUG_DEBOUNCE_MS1100
+
 /* AVI header and aspect ratio */
 #define HDMI_AVI_VERSION   0x02
 #define HDMI_AVI_LENGTH0x0D
@@ -189,6 +191,7 @@ struct hdmi_context {

void __iomem*regs;
int irq;
+   struct delayed_work hotplug_work;

struct i2c_adapter  *ddc_adpt;
struct i2c_client   *hdmiphy_port;
@@ -2058,6 +2061,8 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)

hdmiphy_poweroff(hdata);

+   cancel_delayed_work(&hdata->hotplug_work);
+
clk_disable_unprepare(res->sclk_hdmi);
clk_disable_unprepare(res->hdmi);
/* reset pmu hdmiphy control bit to disable hdmiphy */
@@ -2108,9 +2113,11 @@ static struct exynos_drm_display hdmi_display = {
.ops = &hdmi_display_ops,
 };

-static irqreturn_t hdmi_irq_thread(int irq, void *arg)
+static void hdmi_hotplug_work_func(struct work_struct *work)
 {
-   struct hdmi_context *hdata = arg;
+   struct hdmi_context *hdata;
+
+   hdata = container_of(work, struct hdmi_context, hotplug_work.work);

mutex_lock(&hdata->hdmi_mutex);
hdata->hpd = 1;//gpio_get_value(hdata->hpd_gpio);
@@ -2118,6 +2125,14 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg)

if (hdata->drm_dev)
drm_helper_hpd_irq_event(hdata->drm_dev);
+}
+
+static irqreturn_t hdmi_irq_thread(int irq, void *arg)
+{
+   struct hdmi_context *hdata = arg;
+
+   mod_delayed_work(system_wq, &hdata->hotplug_work,
+   msecs_to_jiffies(HOTPLUG_DEBOUNCE_MS));

return IRQ_HANDLED;
 }
@@ -2315,6 +2330,8 @@ static int hdmi_probe(struct platform_device *pdev)

hdata->hpd = 1;//gpio_get_value(hdata->hpd_gpio);

+   INIT_DELAYED_WORK(&hdata->hotplug_work, hdmi_hotplug_work_func);
+
ret = devm_request_threaded_irq(dev, hdata->irq, NULL,
hdmi_irq_thread, IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
@@ -2351,6 +2368,8 @@ static int hdmi_remove(struct platform_device *pdev)
struct exynos_drm_display *display = get_hdmi_display(dev);
struct hdmi_context *hdata = display->ctx;

+   cancel_delayed_work_sync(&hdata->hotplug_work);
+
put_device(&hdata->hdmiphy_port->dev);
put_device(&hdata->ddc_adpt->dev);
pm_runtime_disable(&pdev->dev);
-- 
1.7.9.5

[PATCH 1/7] drm/exynos: Don't reset hdmiphy on hdmi off

From: Sean Paul 

This patch removes the hdmiphy reset in hdmi_poweroff. The hdmiphy reset
was added to take advantage of exynos clockgating, doing it would gate
the entire TV domain. Unfortunately, mixer is included in the TV domain
and its vsync interrupts are stopped when TV is gated.

Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f3189af..79f98ac 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2056,11 +2056,6 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)
goto out;
mutex_unlock(&hdata->hdmi_mutex);

-   /*
-* The TV power domain needs any condition of hdmiphy to turn off and
-* its reset state seems to meet the condition.
-*/
-   hdmiphy_conf_reset(hdata);
hdmiphy_poweroff(hdata);

clk_disable_unprepare(res->sclk_hdmi);
-- 
1.7.9.5

[PATCH 0/7] drm/exynos: fixes for hdmi related issues

From: Rahul Sharma 

Series is addressing various issues in the drm hdmi driver
for exynos Soc.

Based on Inki Dae's exynos-drm-next branch.

Daniel Kurtz (1):
  drm/exynos: hdmi: remove unnecessary memset

Paul Taysom (1):
  drm/exynos: check for null pointers in error handling

Rahul Sharma (1):
  drm/exynos: replace hdmi reset with hdmi disable

Sean Paul (3):
  drm/exynos: Don't reset hdmiphy on hdmi off
  drm/exynos: Debounce HDMI hotplug interrupts
  drm/exynos: Read hpd gpio in is_connected callback

Shirish S (1):
  drm/exynos: add hdmiphy power on/off sequence

 drivers/gpu/drm/exynos/exynos_hdmi.c |  115 ++
 drivers/gpu/drm/exynos/regs-hdmi.h   |7 ++-
 2 files changed, 81 insertions(+), 41 deletions(-)

-- 
1.7.9.5

[Bug 42960] Display does not work when resuming from suspend

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

--- Comment #20 from Sandeep  ---
Yes!

Adding acpi_sleep=s3_bios to kernel parmeters works. Now, on suspend and resume
the laptop's LVDS panel cames back to life - no external display attached.

-- 
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/20140403/154c0a29/attachment.html>

[Bug 76998] hang on CEDAR right after log on

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

Alex Deucher  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #1 from Alex Deucher  ---
please attach your xorg log and dmesg output.  Can you use git to bisect the
kernel and find out what commit caused the regression?

-- 
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/20140403/a4dbbc4f/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #58 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 42960 ***

-- 
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/20140403/a811c712/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

Alex Deucher  changed:

   What|Removed |Added

 CC||zboszor at pr.hu

--- Comment #19 from Alex Deucher  ---
*** Bug 43829 has been marked as a duplicate of this bug. ***

-- 
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/20140403/ceaef475/attachment-0001.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #57 from Jose P.  ---
(In reply to comment #55)
> (In reply to comment #49)
> > I have a similar issue with a samsumg series 3 laptop with "VGA compatible
> > controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD
> > 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc.
> > [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external
> > monitor show the system is still responsive.
> > 
> > BUT I can make the screen turn on after suspend with the next command:
> > sudo pm-suspend --quirk-test --quirk-s3-bios
> > 
> > so if you can try and this work maybe we can kick this issue.
> 
> GREAT, it works for me, thank you very much!
> I did try pm-suspend with different flags some months ago.. I guess my
> testing was too conservative :(
> @ klausenbusk at hotmail.com and austin.hoppe7 at live.com , thank you too! 
> and
> once again, thanks AMD devs :)

I see now... I DID test the '--quirk-s3-bios' flag, but I need '--quirk-test',
which is not documented in the manpage...

from pm-utils-1.4.1/README.debugging:
"* To override the usual quirk filtering (for kernel modesetting, binary
drivers, and exotic hardware), pass --quirk-test along with any other quirks
you want to try.  This may make your system crash in new and exciting ways by
conflicting with the kernel when suspending or resuming, but is very useful for
debugging.  You have been warned."
Oh, well, I'm happy that someone found a solution and shared it with us all :D

-- 
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/20140403/9634a831/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #60 from Rackow, Detlev  ---
Created attachment 96870
  --> https://bugs.freedesktop.org/attachment.cgi?id=96870&action=edit
Xorg.0.log after switching to 25hz and back to 24hz

-- 
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/20140403/236f5c9b/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #59 from Rackow, Detlev  ---
Hi, I also have issues with OE 3.95.x and Radeon 6320 (AMD E-450). On my
device, issues happened with all fractional frequencies (23.9x, 29.9x, 59.9x
hz)

The test-version which Peter Fruehberger posted and which contains your
preliminary patch changed the behaviour.

With that new patch fractionalmodes (23.976, ... , ... ) are now working
fine, but with 25hz I have a problem. (Peter supposes that it's actually 50i
and I believe this too, but I'm just a user and I can only report the frequency
that I select in the XBMC-settings)

When I set the rate to 25Hz, the picture begins to shiver up and down a few
millimeters. When I don't acknowledge the new rate, XBMC switches back to the
old rate, and the picture is immediately stable as ever. 

This effect used to happen with all fractional rates in OE 3.95.x, while 25Hz
worked fine. With the mentioned test-version it is gone on the fractional
rates, but now it happens on 25Hz (or 50i, as Peter says).

As instructed, I booted OE with the kernel-parameter drm.debug=0xe and took
dmesg and Xorg.0.log immediately after switching to 25hz and falling back.

This is my first post on this site, I hope I don't mess it ;)

-- 
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/20140403/1c2390c2/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #58 from Rackow, Detlev  ---
Created attachment 96869
  --> https://bugs.freedesktop.org/attachment.cgi?id=96869&action=edit
dmesg after switching to 25hz and back to 24hz

-- 
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/20140403/6d507731/attachment.html>

[PATCH 2/3] drm/omap: fix enabling/disabling of video pipeline

On 03/04/14 17:58, Rob Clark wrote:
> On Thu, Apr 3, 2014 at 9:45 AM, Tomi Valkeinen  
> wrote:
>> At the moment the omap_crtc_pre_apply() handles the enabling, disabling
>> and configuring of encoders and panels separately from the CRTC (i.e.
>> the overlay manager).
>>
>> However, this doesn't work correctly. The encoder driver has to be in
>> control of its video input (i.e. the crtc) for correct operation.
>>
>> This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
>> pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
>> current code first enables the HDMI encoder, and CRTC after that.
>> However, the encoder expects the video stream to start during the
>> encoder's enable, and if it doesn't, there will be sync lost errors.
>>
>> The encoder enables its video source by calling src->enable(), and this
>> call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
>> in that function. Similarly for disable, which goes to
>> omap_crtc_disable().
>>
>> This patch moves the code to setup and enable/disable the crtc to
>> omap_crtc_enable. and omap_crtc_disable().
>>
>> Signed-off-by: Tomi Valkeinen 
> 
> I had to go back to look at the code to realize the extra
> 'omap_crtc->full_update = false' removal didn't actually matter (it
> was redundant).  So

The final 'omap_crtc->full_update = false;' is visible in the patch
below also, so you didn't need to go look at the code ;)

Looking at it, that removal is actually extra, not exactly part of this fix.

> Reviewed-by: Rob Clark 

Thanks!

 Tom

> 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_crtc.c | 19 ---
>>  1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index beccff2ccf84..90916abb66ef 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -121,13 +121,25 @@ static void omap_crtc_start_update(struct 
>> omap_overlay_manager *mgr)
>>  {
>>  }
>>
>> +static void set_enabled(struct drm_crtc *crtc, bool enable);
>> +
>>  static int omap_crtc_enable(struct omap_overlay_manager *mgr)
>>  {
>> +   struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
>> +
>> +   dispc_mgr_setup(omap_crtc->channel, &omap_crtc->info);
>> +   dispc_mgr_set_timings(omap_crtc->channel,
>> +   &omap_crtc->timings);
>> +   set_enabled(&omap_crtc->base, true);
>> +
>> return 0;
>>  }
>>
>>  static void omap_crtc_disable(struct omap_overlay_manager *mgr)
>>  {
>> +   struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
>> +
>> +   set_enabled(&omap_crtc->base, false);
>>  }
>>
>>  static void omap_crtc_set_timings(struct omap_overlay_manager *mgr,
>> @@ -600,7 +612,6 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
>> *apply)
>> omap_crtc->current_encoder = encoder;
>>
>> if (!omap_crtc->enabled) {
>> -   set_enabled(&omap_crtc->base, false);
>> if (encoder)
>> omap_encoder_set_enabled(encoder, false);
>> } else {
>> @@ -609,13 +620,7 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
>> *apply)
>> omap_encoder_update(encoder, omap_crtc->mgr,
>> &omap_crtc->timings);
>> omap_encoder_set_enabled(encoder, true);
>> -   omap_crtc->full_update = false;
>> }
>> -
>> -   dispc_mgr_setup(omap_crtc->channel, &omap_crtc->info);
>> -   dispc_mgr_set_timings(omap_crtc->channel,
>> -   &omap_crtc->timings);
>> -   set_enabled(&omap_crtc->base, true);
>> }
>>
>> omap_crtc->full_update = false;
>> --
>> 1.8.3.2
>>


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

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

--- Comment #26 from Jakob Nixdorf  ---
Like I said in my last comment, with your branch the GPU locks up after a
(very) short while.
I don't have time at the moment (final exams), but I will try to debug it as
soon as I get the time (maybe in 4 weeks), if it isn't fixed until then.

-- 
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/20140403/72012f79/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

--- Comment #25 from farmboy0+freedesktop at googlemail.com ---
(In reply to comment #24)
> DId yo(In reply to comment #21)
> > I amanaged to build llvm and mesa.
> > 
> > Here's my test results:
> > As for both wine applications 3D Mark 2000 and Syberia, the error is gone
> > and both applications continue past normally.
> > 
> > But Antichamber will crash the system hard.
> > I have found place in the game where the llvm error always happens.
> > When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont
> > exit with the error it will instead deadlock the whole system, only option
> > is reboot.
> 
> Did you try this branch:
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

~/workspace/llvm $ git --no-pager log -1
commit 14e6c5b9e0a0bf05afcaf4f1154f0cf82c4b5fd2
Author: Tom Stellard 
Date:   Mon Mar 3 14:27:38 2014 -0500

R600/SI: Implement VGPR register spilling

VGPRs are spilled to LDS.

Antichamber doesnt crash right away.
When it happens it looks to me like the graphics card became very very busy
suddenly.
Then the screen goes black like it doesnt get a signal anymore.
After that it crashes.

-- 
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/20140403/3d1937c6/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #56 from klausenbusk at hotmail.com ---
(In reply to comment #54)
> Awesome. To spell it out a little more explicitly, here is what I did (Arch
> x86_64 3.14-mainline) to have this apparently accomplished automatically
> from now on:
> 
> sudo su
> 
> echo 'ADD_PARAMETERS="--quirk-test --quirk-s3-bios"' >>
> /etc/pm/config.d/00-fix_dv6z_suspend_screen
> 
> pm-suspend --quirk-test --quirk-s3-bios --store-quirks-as-lkw
> 
> Which should save the quirks, perhaps with some redundancy. Checking the
> contents of the (new)
> 
> /etc/pm/last_known_working.quirkdb
> 
> file should show the matches made against your particular system, especially
> e.g. hardware and firmware details. I guess these could be patched into (for
> my HP at least)
> 
> /usr/lib/pm-utils/video-quirks/20-video-quirk-pm-hp.quirkdb
> 
> with some of the returned information, given that this file is supposed to
> have a fairly up-to-date {white,black,broken}-list.
> 
> Obviously follow this only at your own risk, etc. I have no idea how this
> would work when it comes to fglrx, or even how stable it is against
> kernel/pm/upower/whatever updates. Here are some more good references for
> information:
> 
> https://trisquel.info/en/wiki/troubleshooting-suspendhibernate
> 
> https://wiki.archlinux.org/index.php/pm-utils

Hmm. I just did:
sudo nano /etc/default/grub
found GRUB_CMDLINE_LINUX_DEFAULT and added acpi_sleep=s3_bios just before quiet
ctrl+o and ctrl+x
sudo grub-mkconfig -o /boot/grub/grub.cfg

-- 
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/20140403/53400886/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #55 from Jose P.  ---
(In reply to comment #49)
> I have a similar issue with a samsumg series 3 laptop with "VGA compatible
> controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD
> 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external
> monitor show the system is still responsive.
> 
> BUT I can make the screen turn on after suspend with the next command:
> sudo pm-suspend --quirk-test --quirk-s3-bios
> 
> so if you can try and this work maybe we can kick this issue.

GREAT, it works for me, thank you very much!
I did try pm-suspend with different flags some months ago.. I guess my testing
was too conservative :(
@ klausenbusk at hotmail.com and austin.hoppe7 at live.com , thank you too! and 
once
again, thanks AMD devs :)

-- 
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/20140403/6096e5ce/attachment.html>

[PATCH v3] drm/exynos: add super device support

This patch adds super device support to bind sub drivers
using device tree.

For this, you should add a super device node to each machine dt files
like belows,

In case of using MIPI-DSI,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>, <&dsi>;
};

In case of using DisplayPort,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>, <&dp>;
};

In case of using Parallel panel,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>;
};

And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.

ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI

With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.

Previous RFC patch,
 http://www.spinics.net/lists/dri-devel/msg54671.html

Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
  drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
  should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.

Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
  is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
  . 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
  . crtcs and connectors propery names are also specific to Linux so
change them to generic name.

Changlog v3:
- Do not probe/remove dpi module if fimd node has no port node.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |   45 ---
 drivers/gpu/drm/exynos/exynos_drm_core.c |  216 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   17 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   16 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  202 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   73 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   38 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   87 +---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   61 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |   45 ---
 drivers/gpu/drm/exynos/exynos_mixer.c|   54 ++--
 12 files changed, 451 insertions(+), 407 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a59bca9..cb9aa58 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs 
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
 };

-static int exynos_dp_initialize(struct exynos_drm_display *display,
-   struct drm_device *drm_dev)
-{
-   struct exynos_dp_device *dp = display->ctx;
-
-   dp->drm_dev = drm_dev;
-
-   return 0;
-}
-
 static bool find_bridge(const char *compat, struct bridge_init *bridge)
 {
bridge->client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)
 }

 static struct exynos_drm_display_ops exynos_dp_display_ops = {
-   .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
 };
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct 
exynos_dp_device *dp)
return 0;
 }

-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void 
*data)
 {
+   struct platform_device *pdev = to_platform_device(dev);
+   struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;

@@ -1293,21 +1285,40 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
disable_irq(dp->irq);

+   dp->drm_dev = drm_dev;
exynos_dp_display.ctx = dp;

platform_set_drvdata(pdev, &exynos_dp_display);
-   exynos_drm_display_register(&exynos_dp_display);

-   return 0;
+   return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
 }

-static int exynos_dp_remove(struct platform_device *pdev

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #54 from austin.hoppe7 at live.com ---
Awesome. To spell it out a little more explicitly, here is what I did (Arch
x86_64 3.14-mainline) to have this apparently accomplished automatically from
now on:

sudo su

echo 'ADD_PARAMETERS="--quirk-test --quirk-s3-bios"' >>
/etc/pm/config.d/00-fix_dv6z_suspend_screen

pm-suspend --quirk-test --quirk-s3-bios --store-quirks-as-lkw

Which should save the quirks, perhaps with some redundancy. Checking the
contents of the (new)

/etc/pm/last_known_working.quirkdb

file should show the matches made against your particular system, especially
e.g. hardware and firmware details. I guess these could be patched into (for my
HP at least)

/usr/lib/pm-utils/video-quirks/20-video-quirk-pm-hp.quirkdb

with some of the returned information, given that this file is supposed to have
a fairly up-to-date {white,black,broken}-list.

Obviously follow this only at your own risk, etc. I have no idea how this would
work when it comes to fglrx, or even how stable it is against
kernel/pm/upower/whatever updates. Here are some more good references for
information:

https://trisquel.info/en/wiki/troubleshooting-suspendhibernate

https://wiki.archlinux.org/index.php/pm-utils

-- 
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/20140403/f926a8b0/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #57 from Rainer Hochecker  ---
(In reply to comment #50)

> If the 'sync to display' option is on in XBMC the video pixels clock is
> master and I guess it then uses the vblank interrupt generated by the OSS
> driver. These interrupts are generated using the same clock settings that
> were used to set the PLL parameters. Why are there then ever skips reported,
> because the renderer cannot be late as it is the master and just puts a
> frame out for each vblank interrupt? or do I misunderstand something?
> Are missed vblanks reported by the OSS driver to XBMC or does XBMC keep some
> shadow adminstration to see if vblank interrupts arrive at the expected time?
> 

Almost correct. At the application level we don't see interrupts. We just
render the frames. We only can render one frame per vblank interval. Decoding
should be fasted than rendering, hence the queue of ready frames fills and
frames wait for being picked up. At this point (when the render thread comes
by) we check the timestamp attached to the frame. If the time has already
passed and there is more than a single frame in the queue, the next frame is
skipped. Means the render thread is late by minimum frametime 41ms when running
at 23.976.

So even if we run at wrong speed, the render thread should not get that late.

-- 
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/20140403/f819270c/attachment.html>

[PATCH 3/3] OMAPDSS: HDMI: fix interlace output

The HDMI output video format's yres needs to be divided by two for
interlace. Fix it.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/hdmi_wp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/omap2/dss/hdmi_wp.c 
b/drivers/video/omap2/dss/hdmi_wp.c
index cd620c6e43a0..f5f4ccf50d90 100644
--- a/drivers/video/omap2/dss/hdmi_wp.c
+++ b/drivers/video/omap2/dss/hdmi_wp.c
@@ -171,6 +171,8 @@ void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format 
*video_fmt,
video_fmt->packing_mode = HDMI_PACK_10b_RGB_YUV444;
video_fmt->y_res = param->timings.y_res;
video_fmt->x_res = param->timings.x_res;
+   if (param->timings.interlace)
+   video_fmt->y_res /= 2;

timings->hbp = param->timings.hbp;
timings->hfp = param->timings.hfp;
-- 
1.8.3.2

[PATCH 2/3] drm/omap: fix enabling/disabling of video pipeline

At the moment the omap_crtc_pre_apply() handles the enabling, disabling
and configuring of encoders and panels separately from the CRTC (i.e.
the overlay manager).

However, this doesn't work correctly. The encoder driver has to be in
control of its video input (i.e. the crtc) for correct operation.

This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
current code first enables the HDMI encoder, and CRTC after that.
However, the encoder expects the video stream to start during the
encoder's enable, and if it doesn't, there will be sync lost errors.

The encoder enables its video source by calling src->enable(), and this
call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
in that function. Similarly for disable, which goes to
omap_crtc_disable().

This patch moves the code to setup and enable/disable the crtc to
omap_crtc_enable. and omap_crtc_disable().

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index beccff2ccf84..90916abb66ef 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -121,13 +121,25 @@ static void omap_crtc_start_update(struct 
omap_overlay_manager *mgr)
 {
 }

+static void set_enabled(struct drm_crtc *crtc, bool enable);
+
 static int omap_crtc_enable(struct omap_overlay_manager *mgr)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
+
+   dispc_mgr_setup(omap_crtc->channel, &omap_crtc->info);
+   dispc_mgr_set_timings(omap_crtc->channel,
+   &omap_crtc->timings);
+   set_enabled(&omap_crtc->base, true);
+
return 0;
 }

 static void omap_crtc_disable(struct omap_overlay_manager *mgr)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
+
+   set_enabled(&omap_crtc->base, false);
 }

 static void omap_crtc_set_timings(struct omap_overlay_manager *mgr,
@@ -600,7 +612,6 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
*apply)
omap_crtc->current_encoder = encoder;

if (!omap_crtc->enabled) {
-   set_enabled(&omap_crtc->base, false);
if (encoder)
omap_encoder_set_enabled(encoder, false);
} else {
@@ -609,13 +620,7 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
*apply)
omap_encoder_update(encoder, omap_crtc->mgr,
&omap_crtc->timings);
omap_encoder_set_enabled(encoder, true);
-   omap_crtc->full_update = false;
}
-
-   dispc_mgr_setup(omap_crtc->channel, &omap_crtc->info);
-   dispc_mgr_set_timings(omap_crtc->channel,
-   &omap_crtc->timings);
-   set_enabled(&omap_crtc->base, true);
}

omap_crtc->full_update = false;
-- 
1.8.3.2

[PATCH 1/3] drm/omap: fix missing disable for unused encoder

When an encoder is no longer connected to a crtc, the driver will leave
the encoder enabled.

This patch adds code to track the encoder used for a crtc, and when the
encoder changes, the old one is disabled.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 4f624c59a660..beccff2ccf84 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -33,6 +33,7 @@ struct omap_crtc {
int pipe;
enum omap_channel channel;
struct omap_overlay_manager_info info;
+   struct drm_encoder *current_encoder;

/*
 * Temporary: eventually this will go away, but it is needed
@@ -593,6 +594,11 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
*apply)
}
}

+   if (omap_crtc->current_encoder && encoder != omap_crtc->current_encoder)
+   omap_encoder_set_enabled(omap_crtc->current_encoder, false);
+
+   omap_crtc->current_encoder = encoder;
+
if (!omap_crtc->enabled) {
set_enabled(&omap_crtc->base, false);
if (encoder)
-- 
1.8.3.2

[Intel-gfx] [PATCH] drm/i915: fix command parser debug print format mismatches

2014-04-03 Thread Damien Lespiau

On Thu, Apr 03, 2014 at 11:32:30AM +0200, Daniel Vetter wrote:
> On Wed, Apr 02, 2014 at 08:26:23AM -0700, Randy Dunlap wrote:
> > On 04/02/2014 01:24 AM, Jani Nikula wrote:
> > > Drop the cast from the pointer diff to fix:
> > > 
> > > drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' 
> > > expects
> > > argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
> > > [-Wformat]
> > > 
> > > While at it, use %u for u32.
> > > 
> > > Reported-by: Randy Dunlap 
> > > Signed-off-by: Jani Nikula 
> > > 
> > > ---
> > > 
> > > Randy, try as I might, I wasn't able to coerce gcc to spit out that
> > > warning. Please enlighten me! (Does this fix the warn?)
> > 
> > Yes, it does.  Thanks.
> > 
> > Acked-by: Randy Dunlap 
> 
> Maybe I'm blind, but I think the recent refactoring patch fixed this. Can
> someone please double-check? I always get confused with printf formats ;-)

I fixed it a couple of weeks back:
  http://lists.freedesktop.org/archives/intel-gfx/2014-March/041886.html

-- 
Damien

[PATCH v2 1/7] drm/exynos: add super device support

2014-04-02 23:06 GMT+09:00, Andrzej Hajda :
> On 04/01/2014 02:37 PM, Inki Dae wrote:
>> This patch adds super device support to bind sub drivers
>> using device tree.
>>
>> For this, you should add a super device node to each machine dt files
>> like belows,
>>
>> In case of using MIPI-DSI,
>>  display-subsystem {
>>  compatible = "samsung,exynos-display-subsystem";
>>  ports = <&fimd>, <&dsi>;
>>  };
>>
>> In case of using DisplayPort,
>>  display-subsystem {
>>  compatible = "samsung,exynos-display-subsystem";
>>  ports = <&fimd>, <&dp>;
>>  };
>>
>> In case of using Parallel panel,
>>  display-subsystem {
>>  compatible = "samsung,exynos-display-subsystem";
>>  ports = <&fimd>;
>>  };
>>
>> And if you don't add connector device node to ports property,
>> default parallel panel driver, exynos_drm_dpi module, will be used.
>>
>> ports property can have the following device nodes,
>>  fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
>>
>> With this patch, we can resolve the probing order issue without
>> some global lists. So this patch also removes the unnecessary lists and
>> stuff related to these lists.
>>
>
> (...)
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 40fd6cc..7ebfe15 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -19,10 +19,12 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "exynos_drm_drv.h"
>> @@ -144,12 +146,14 @@ static inline struct fimd_driver_data
>> *drm_fimd_get_driver_data(
>>  }
>>
>>  static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
>> -struct drm_device *drm_dev, int pipe)
>> +struct drm_device *drm_dev)
>>  {
>>  struct fimd_context *ctx = mgr->ctx;
>> +struct exynos_drm_private *priv;
>> +priv = drm_dev->dev_private;
>>
>> -ctx->drm_dev = drm_dev;
>> -ctx->pipe = pipe;
>> +mgr->drm_dev = ctx->drm_dev = drm_dev;
>> +mgr->pipe = ctx->pipe = priv->pipe++;
>>
>>  /*
>>   * enable drm irq mode.
>> @@ -803,8 +807,6 @@ static void fimd_dpms(struct exynos_drm_manager *mgr,
>> int mode)
>>  }
>>
>>  static struct exynos_drm_manager_ops fimd_manager_ops = {
>> -.initialize = fimd_mgr_initialize,
>> -.remove = fimd_mgr_remove,
>>  .dpms = fimd_dpms,
>>  .mode_fixup = fimd_mode_fixup,
>>  .mode_set = fimd_mode_set,
>> @@ -849,9 +851,10 @@ out:
>>  return IRQ_HANDLED;
>>  }
>>
>> -static int fimd_probe(struct platform_device *pdev)
>> +static int fimd_bind(struct device *dev, struct device *master, void
>> *data)
>>  {
>> -struct device *dev = &pdev->dev;
>> +struct platform_device *pdev = to_platform_device(dev);
>> +struct drm_device *drm_dev = data;
>>  struct fimd_context *ctx;
>>  struct resource *res;
>>  int win;
>> @@ -910,11 +913,16 @@ static int fimd_probe(struct platform_device *pdev)
>>  platform_set_drvdata(pdev, &fimd_manager);
>>
>>  fimd_manager.ctx = ctx;
>> -exynos_drm_manager_register(&fimd_manager);
>> +fimd_mgr_initialize(&fimd_manager, drm_dev);
>>
>> -exynos_dpi_probe(ctx->dev);
>> +exynos_drm_crtc_create(&fimd_manager);
>>
>> -pm_runtime_enable(dev);
>> +/*
>> + * It should be called after exynos_drm_crtc_create call because
>> + * exynos_dpi_probe call will try to find same lcd type
>> + * of manager to setup possible_crtcs.
>> + */
>> +exynos_dpi_probe(drm_dev, dev);
>>
>>  for (win = 0; win < WINDOWS_NR; win++)
>>  fimd_clear_win(ctx, win);
>> @@ -922,18 +930,56 @@ static int fimd_probe(struct platform_device *pdev)
>>  return 0;
>>  }
>>
>> -static int fimd_remove(struct platform_device *pdev)
>> +static void fimd_unbind(struct device *dev, struct device *master,
>> +void *data)
>>  {
>> -struct exynos_drm_manager *mgr = platform_get_drvdata(pdev);
>> +struct exynos_drm_manager *mgr = dev_get_drvdata(dev);
>> +struct drm_crtc *crtc = mgr->crtc;
>> +
>> +fimd_dpms(mgr, DRM_MODE_DPMS_OFF);
>>
>> -exynos_dpi_remove(&pdev->dev);
>> +exynos_dpi_remove(mgr->drm_dev, dev);
>>
>> -exynos_drm_manager_unregister(&fimd_manager);
>> +fimd_mgr_remove(mgr);
>>
>> -fimd_dpms(mgr, DRM_MODE_DPMS_OFF);
>> +crtc->funcs->destroy(crtc);
>> +}
>> +
>> +static const struct component_ops fimd_component_ops = {
>> +.bind   = fimd_bind,
>> +.unbind = fimd_unbind,
>> +};
>>
>> +static int fimd_probe(struct platform_device *pdev)
>> +{
>> +struct device_node *dn;
>> +
>> +/* Check if fimd node has port node. */
>> +dn = exynos_dpi_of_find_panel_node(&pdev->dev);
>> +if (dn) {
>> +struct drm_panel *panel;
>> +
>> +/*
>> +

[Bug 76501] fences regression

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

--- Comment #14 from Shawn Starr  ---
Does this fix issues where when GPU locks up X is able to resume? when X
resumes for me, there is no ability to resume using the display server and most
of the time it just GPU wedges and then I need to do a reset.

-- 
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/20140403/e0659c91/attachment.html>

[PATCH] drm/exynos: separate dpi from fimd

2014-04-03 Thread Andrzej Hajda

The patch separates dpi related routines from fimd.

Signed-off-by: Andrzej Hajda 
---
Hi Inki,

This is my attempt to separate DPI from FIMD,
it requires putting real probe back into fimd_probe, but I
guess it should not be a problem, as it is done already for dsi.
It is based on v4 of your patch.

The patch was written quickly without proper review, I can
do it tomorrow if you are interested.
If it is OK for you, please merge it with your patch.
Anyway, I have made few tests - it works.

Regards
Andrzej
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  40 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  15 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 109 +--
 3 files changed, 69 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index ac206e7..03cb126 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
force)
 {
struct exynos_dpi *ctx = connector_to_dpi(connector);

-   /* panels supported only by boot-loader are always connected */
-   if (!ctx->panel_node)
-   return connector_status_connected;
-
-   if (!ctx->panel) {
-   ctx->panel = of_drm_find_panel(ctx->panel_node);
-   if (ctx->panel)
-   drm_panel_attach(ctx->panel, &ctx->connector);
-   }
+   if (!ctx->panel->connector)
+   drm_panel_attach(ctx->panel, &ctx->connector);

-   if (ctx->panel)
-   return connector_status_connected;
-
-   return connector_status_disconnected;
+   return connector_status_connected;
 }

 static void exynos_dpi_connector_destroy(struct drm_connector *connector)
@@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return -ENOMEM;

ret = of_get_videomode(dn, vm, 0);
-   if (ret < 0)
+   if (ret < 0) {
+   devm_kfree(dev, vm);
return ret;
+   }

ctx->vm = vm;

@@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return 0;
 }

-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
+struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
 {
struct exynos_dpi *ctx;
int ret;

ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
-   return -ENOMEM;
+   return NULL;

ctx->dev = dev;
exynos_dpi_display.ctx = ctx;
ctx->dpms_mode = DRM_MODE_DPMS_OFF;

ret = exynos_dpi_parse_dt(ctx);
-   if (ret < 0)
-   return ret;
+   if (ret < 0) {
+   devm_kfree(dev, ctx);
+   return NULL;
+   }
+
+   if (ctx->panel_node) {
+   ctx->panel = of_drm_find_panel(ctx->panel_node);
+   if (!ctx->panel)
+   return ERR_PTR(-EPROBE_DEFER);
+   }

-   return exynos_drm_create_enc_conn(drm_dev, &exynos_dpi_display);
+   return &exynos_dpi_display;
 }

-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
+int exynos_dpi_remove(struct device *dev)
 {
struct drm_encoder *encoder = exynos_dpi_display.encoder;
struct exynos_dpi *ctx = exynos_dpi_display.ctx;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 2b87eb7..583a0bd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
 void exynos_platform_device_ipp_unregister(void);

 #ifdef CONFIG_DRM_EXYNOS_DPI
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
-struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
+struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
+int exynos_dpi_remove(struct device *dev);
 #else
-static inline int exynos_dpi_probe(struct drm_device *drm_dev,
-   struct device *dev) { return 0; }
-static inline int exynos_dpi_remove(struct drm_device *drm_dev,
-   struct device *dev) { return 0; }
-static inline struct device_node
-   *exynos_dpi_of_find_panel_node(struct device *dev)
-{ return NULL; }
+static inline struct exynos_drm_display *
+exynos_dpi_probe(struct device *dev) { return 0; }
+static inline int exynos_dpi_remove(struct device *dev) { return 0; }
 #endif

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 76282b3..11cce7b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -24,7 +24,6 @@
 #inclu

spinlock lockup suspected on CPU error on omapdrm

2014-04-03 Thread Vikas Patil

Hi Rob,

Thanks for your comment.
Looking at the working  omapdrm code in 3.4.25, added the spin_unlock at
the start of the function sync_op_update() and again locking at the end of
the function fixes this error.
Does this looks correct fix?

-
static void sync_op_update(void)
{
struct omap_gem_sync_waiter *waiter, *n;
+ spin_unlock(&sync_lock); //vikas
list_for_each_entry_safe(waiter, n, &waiters, list) {
if (!is_waiting(waiter)) {
list_del(&waiter->list);
SYNC("notify: %p", waiter);
waiter->notify(waiter->arg);
kfree(waiter);
}
}
   + spin_lock(&sync_lock);
}
-

Thanks & Regards,
Vikas

On Wed, Apr 2, 2014 at 8:01 PM, Rob Clark  wrote:

> On Wed, Apr 2, 2014 at 8:23 AM, Vikas Patil  wrote:
> > Hi,
> > I am seeing following kernel backtrace on J6 with linux 3.8.13 when
> trying
> > to start IVI LM service. Before starting this I started the X11 and run
> some
> > GLES2/X11 based tests successfully.
> >
> > The same binaries and my graphics driver are working fine on OMAP5 and
> linux
> > 3.4.25. Is this some known BUG in omapdrm driver? If not a bug then how
> > should I go for debugging it?
> >
> > From the trace what I understood is, this is case of nested spinlock and
> I
> > might be seeing this error due to this as in the trace
> omap_gem_op_update()
> > and omap_gem_set_sync_object(), both functions are trying to acquire
> > spin_lock(&sync_lock).
> >
>
> ok, to be fair this is more about pvr and some downstream patches to
> omapdrm to make it work with pvr, than the upstream omapdrm.
>
> tbh, I don't completely remember how this used to work.. it doesn't
> seem like the sort of thing that could be easily missed.  You might
> want to compare to older omapdrm+pvr, I might have moved some of the
> locking around?
>
> Probably the best/safest thing would be to move the waiter->notify()
> callback off to omapdrm's workqueue, so it isn't called with spinlocks
> held.
>
> BR,
> -R
>
> >
> > [  719.005340] BUG: spinlock lockup suspected on CPU#0, kworker/u:2/787
> > [  719.011749]  lock: sync_lock+0x0/0x20, .magic: dead4ead, .owner:
> > kworker/u:2/787, .owner_cpu: 0
> > [  719.020507] [] (unwind_backtrace+0x0/0x138) from
> []
> > (do_raw_spin_lock+0x100/0x17c)
> > [  719.029876] [] (do_raw_spin_lock+0x100/0x17c) from
> []
> > (omap_gem_set_sync_object+0x14/0xf4)
> > [  719.039978] [] (omap_gem_set_sync_object+0x14/0xf4) from
> > [] (FreeMemCallBackCommon+0xf4/0x24c [omapdrm_pvr])
> > [  719.051635] [] (FreeMemCallBackCommon+0xf4/0x24c
> [omapdrm_pvr])
> > from [] (UnwrapExtMemoryCallBack+0x28/0x68 [omapdrm_pvr])
> > [  719.064544] [] (UnwrapExtMemoryCallBack+0x28/0x68
> > [omapdrm_pvr]) from [] (FreeResourceByPtr.part.0+0xac/0xcc
> > [omapdrm_pvr])
> > [  719.077575] [] (FreeResourceByPtr.part.0+0xac/0xcc
> > [omapdrm_pvr]) from [] (ResManFreeResByPtr+0x44/0x6c
> > [omapdrm_pvr])
> > [  719.090118] [] (ResManFreeResByPtr+0x44/0x6c [omapdrm_pvr])
> > from [] (async_unmap+0x28/0x44 [omapdrm_pvr])
> > [  719.101531] [] (async_unmap+0x28/0x44 [omapdrm_pvr]) from
> > [] (sync_op_update+0x88/0xa8)
> > [  719.111328] [] (sync_op_update+0x88/0xa8) from []
> > (omap_gem_op_update+0x14/0x24)
> > [  719.120544] [] (omap_gem_op_update+0x14/0x24) from
> []
> > (PVRSRVMISR+0xc/0x60 [omapdrm_pvr])
> > [  719.130523] [] (PVRSRVMISR+0xc/0x60 [omapdrm_pvr]) from
> > [] (process_one_work+0x1c8/0x5c0)
> > [  719.140502] [] (process_one_work+0x1c8/0x5c0) from
> []
> > (worker_thread+0x168/0x444)
> > [  719.149810] [] (worker_thread+0x168/0x444) from []
> > (kthread+0xa4/0xb0)
> > [  719.158142] [] (kthread+0xa4/0xb0) from []
> > (ret_from_fork+0x14/0x24)
> >
> > Thanking you for your time.
> >
> > Thanks & Regards,
> > Vikas
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140403/46d06f71/attachment-0001.html>

[Bug 75900] [r600g-evergreen] GPU lockup or app segfault in several games (bisected)

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

Marek Ol??k  changed:

   What|Removed |Added

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

--- Comment #16 from Marek Ol??k  ---
This has been fixed. Closing.

-- 
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/20140403/8eb30bbd/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

Christian K?nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #1 from Christian K?nig  ---
Good:
  1920x1080 (0x59)   74.2MHz +HSync +VSync
h: width  1920 start 2558 end 2602 total 2750 skew0 clock   27.0KHz
v: height 1080 start 1084 end 1089 total 1125   clock   24.0Hz

Bad:
  1920x1080 (0x59) 74.176MHz +HSync +VSync
h: width  1920 start 2558 end 2602 total 2750 skew0 clock  26.97KHz
v: height 1080 start 1084 end 1089 total 1125   clock  23.98Hz

It actually looks like the 23.98 fps mode was rounded to 24fps before and never
really worked correctly.

Are you sure my patch is the only difference in the system? Cause my patch
shouldn't have that effect.

Can you build a kernel separately and check that this is really the root cause
of it?

Thanks in advance,
Christian.

-- 
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/20140403/f72334b3/attachment.html>

[PATCH v3 00/12] Add DSI display support for Exynos based boards

Hi Andrzej,

2014-04-02 16:24 GMT+09:00, Andrzej Hajda :
> Hi Inki,
>
> I see you have took also ld9040 driver patch [1].

I think this patch should have included your DSI display support
series because the patch series includes dt binding for ld9040 driver
but has no ld9040 driver.


> Could you take the 3rd version of this patch [2].
> It fixes build dependencies.

Sorry for missing. Applied.

Thanks,
Inki Dae
>
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/102592
> [2]: http://permalink.gmane.org/gmane.comp.video.dri.devel/102659
>
> Thanks and Regards
> Andrzej
>
> On 04/01/2014 02:29 PM, Inki Dae wrote:
>> Hi Andrzej,
>>
>>
>>
>> 2014-03-28 20:52 GMT+09:00 Andrzej Hajda :
>>> Hi,
>>>
>>> This patchset adds drivers and bindings to the following devices:
>>> - Exynos DSI master,
>>> - S6E8AA0 DSI panel,
>>>
>>> It adds also display support in DTS files for the following boards:
>>> - Exynos4210/Trats,
>>> - Exynos4412/Trats2.
>>>
>>> The patchset is based on exynos_drm_next branch.
>>>
>>> It is the 3rd iteration of the patches, main changes:
>>> - based on exynos_drm_next branch,
>>> - added video interface bindings between DSI host and slave,
>>>   it seems to me to be redundand, and I hope when video interface
>>> bindings
>>>   will be stabilized it can become optional,
>>> - GPIOs implemented using gpiod framework,
>>> - removed controversial stuff (toshiba bridge implementation and arndale
>>> support),
>>>   it will be send in another set of patches
>>>
>>> Other changes are described in individual patches.
>>>
>>> Regards
>>> Andrzej
>>>
>>>
>>> Andrzej Hajda (12):
>>>   drm/mipi_dsi: add flags to DSI messages
>>>   drm/mipi_dsi: create dsi devices only for nodes with reg property
>>>   drm/exynos: disallow fbdev initialization if no device is connected
>>>   exynos/dsim: add DT bindings
>>>   drm/exynos: add DSIM driver
>>>   panel/s6e8aa0: add DT bindings
>>>   drm/panel: add S6E8AA0 driver
>>>   ARM: dts: exynos4: add MIPI DSI Master node
>>>   ARM: dts: exynos4210-trats: add panel node
>>>   ARM: dts: exynos4412-trats2: add panel node
>>>   ARM: dts: exynos4210-trats: enable exynos/fimd node
>>>   ARM: dts: exynos4412-trats2: enable exynos/fimd node
>> Picked up this patch series.
>>
>> Thanks for your contribution,
>> Inki Dae
>>
>>>  .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
>>>  .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
>>>  arch/arm/boot/dts/exynos4.dtsi |   14 +
>>>  arch/arm/boot/dts/exynos4210-trats.dts |   61 +
>>>  arch/arm/boot/dts/exynos4412-trats2.dts|   70 +
>>>  drivers/gpu/drm/drm_mipi_dsi.c |6 +-
>>>  drivers/gpu/drm/exynos/Kconfig |9 +
>>>  drivers/gpu/drm/exynos/Makefile|1 +
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   15 +
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1525
>>> 
>>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
>>>  drivers/gpu/drm/panel/Kconfig  |7 +
>>>  drivers/gpu/drm/panel/Makefile |1 +
>>>  drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069
>>> ++
>>>  include/drm/drm_mipi_dsi.h |6 +
>>>  16 files changed, 2941 insertions(+), 1 deletion(-)
>>>  create mode 100644
>>> Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
>>>  create mode 100644
>>> Documentation/devicetree/bindings/video/exynos_dsim.txt
>>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>  create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c
>>>
>>> --
>>> 1.8.3.2
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

Christian K?nig  changed:

   What|Removed |Added

  Attachment #96854|text/plain  |application/binary
  mime type||

-- 
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/20140403/fe529c30/attachment.html>

[Bug 77009] New: 24P playback video signal loss with latest DRI patches

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

  Priority: medium
Bug ID: 77009
  Assignee: dri-devel at lists.freedesktop.org
   Summary: 24P playback video signal loss with latest DRI patches
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: socalfisher at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 96854
  --> https://bugs.freedesktop.org/attachment.cgi?id=96854&action=edit
xrandr verbose and dmesg +/- problem

This patch [https://bugs.freedesktop.org/show_bug.cgi?id=76564] appears to have
broken my 24P playback which has been fine until now.  My set is a Sony KDL
40NX711 NTSC set, PC A4-3400 - HDMI to set for vid/audio stereo out speakers. 
Using Openelec- gotham nightlies (this patch is now comitted to OE-nightlies):
Playing 29.97i/59.94 plays fine enough (a few skips- why I am testing this
patch), 23.976 playback breaks the TV display- it starts to buzz then says "no
signal", I press stop and the menu/screen resumes at ~30P like normal.

"xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98" - does the same thing,
lcd loses video signal and buzzes.

I am attaching the dmesg/xrandr --verbose logs w/ drm.debug=0xe both working
w/o patch and broken w/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/20140403/4b6d3e4b/attachment.html>

[PATCH] Revert "drm/i915: fix build warning on 32-bit (v2)"

2014-04-03 Thread Jan Moskyto Matejka

This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.

The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780 and
these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
difference to unsigned long and the other commit changed the output type from
long to ptrdiff_t.

The other commit fixes the original warning the better way so I'm reverting
this commit now.
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 4cf6d02..0eaed44 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -405,7 +405,7 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
length: 0x%08X length=%d batchlen=%td\n",
 *cmd,
 length,
-(unsigned long)(batch_end - cmd));
+batch_end - cmd);
ret = -EINVAL;
break;
}
-- 
1.8.4.5

Synchronization between a crtc mode_set and page_flip?

2014-04-03 Thread Archit Taneja

On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote:
> On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja  wrote:
>> Hi,
>>
>> I was trying to figure out how we are supposed to manage synchronization
>> between a mode_set and a page_flip called on a crtc.
>>
>> Say, if a mode_set is immediately followed by a page_flip. The driver can't
>> process the page_flip straight away since the hardware is still completing
>> the mode_set.
>
> I guess setcrtc is expected to be synchronous(ish).. so a lot of
> userspace won't expect the first pageflip to fail with -EBUSY.

Okay, thanks. I guess having setcrtc synchronous isn't that bad.

Archit

[Bug 77002] problems with kernel 3.14

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

--- Comment #3 from bgunteriv at gmail.com ---
Created attachment 96849
  --> https://bugs.freedesktop.org/attachment.cgi?id=96849&action=edit
mesa

-- 
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/20140403/033eaf6e/attachment.html>

[Bug 77002] problems with kernel 3.14

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

--- Comment #2 from bgunteriv at gmail.com ---
Created attachment 96848
  --> https://bugs.freedesktop.org/attachment.cgi?id=96848&action=edit
vdpauinfo

-- 
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/20140403/d2138347/attachment.html>

[Bug 77002] problems with kernel 3.14

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

--- Comment #1 from bgunteriv at gmail.com ---
Created attachment 96847
  --> https://bugs.freedesktop.org/attachment.cgi?id=96847&action=edit
Xorg.0.log

-- 
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/20140403/27fdbf7d/attachment.html>

[Bug 77002] New: problems with kernel 3.14

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

Priority: medium
Bug ID: 77002
Assignee: dri-devel at lists.freedesktop.org
Summary: problems with kernel 3.14
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: bgunteriv at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: unspecified
Component: DRM/Radeon
Product: DRI

Created attachment 96846
--> https://bugs.freedesktop.org/attachment.cgi?id=96846&action=edit
dmesg

not sure where this bug belongs.

having great issues with the new kernel 3.14 on my system trying to play any
type of media -- video or music.

currently running kernel 3.13 version 8. is the most stable.

here are my logs when running kernel 3.14
dmesg | pastebinit
http://paste.ubuntu.com/7033651/
cat ~/.xbmc/temp/xbmc.log | pastebinit
http://paste.ubuntu.com/7033687/
cat /var/log/Xorg.0.log | pastebinit
http://paste.ubuntu.com/7033653/
DISPLAY=:0 vdpauinfo | pastebinit
http://paste.ubuntu.com/7033656/
dpkg -l |grep mesa | pastebinit
http://paste.ubuntu.com/7033657/

and here's a log file when trying to play a video... both online, and from my
hard drive. and a music file (which made XBMC freeze):
http://paste.ubuntu.com/7033704/

and yes. i get the same results when running the most recent "stable" version
of the kernel 3.14. but can try to get some logs if necessary.

--
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/20140403/6c375b65/attachment.html>

[pull] radeon drm-next-3.15

2014-04-03 Thread Christian König

Hi Dave,

this is the fourth and last pull request for 3.15 radeon changes. 
Highlights this time:
- Rework of finding the right PLL numbers for display
- Couple of different bugfixes

The following changes since commit 2844ea3f252331cc0ecf3ae74f6226db2f580f8a:

   Merge branch 'primary-plane' of 
git://people.freedesktop.org/~robclark/linux into drm-next (2014-04-02 
12:09:09 +1000)

are available in the git repository at:


   git://people.freedesktop.org/~deathsimple/linux drm-next-3.15

for you to fetch changes up to f1553174a207f68a4ec19d436003097e0a4dc405:

   drm/radeon: fix typo in spectre_golden_registers (2014-04-03 12:41:18 
+0200)


Alex Deucher (3):
   drm/radeon: call drm_edid_to_eld when we update the edid
   drm/radeon: fix endian swap on hawaii clear state buffer setup
   drm/radeon: fix typo in spectre_golden_registers

Christian K?nig (2):
   drm/radeon: clear needs_reset flag if IB test fails
   drm/radeon: rework finding display PLL numbers v2

Dave Airlie (2):
   drm/radeon: fix runtime suspend breaking secondary GPUs
   drm/radeon: fix resuming mode in pm runtime resume path

  drivers/gpu/drm/radeon/cik.c|   6 +--
  drivers/gpu/drm/radeon/radeon_device.c  |  10 ++--
  drivers/gpu/drm/radeon/radeon_display.c | 244 
+
  drivers/gpu/drm/radeon/radeon_drv.c |  17 +--
  drivers/gpu/drm/radeon/radeon_ring.c|   1 +
  5 files changed, 176 insertions(+), 102 deletions(-)

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

2014-04-03 Thread Stephen Rothwell

Hi all,

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

drivers/gpu/drm/i915/intel_display.c: In function 'intel_alloc_plane_obj':
drivers/gpu/drm/i915/intel_display.c:2089:27: error: 'struct drm_crtc' has no 
member named 'fb'
   obj->stride = crtc->base.fb->pitches[0];
   ^
drivers/gpu/drm/i915/intel_display.c:2092:36: error: 'struct drm_crtc' has no 
member named 'fb'
  mode_cmd.pixel_format = crtc->base.fb->pixel_format;
^
drivers/gpu/drm/i915/intel_display.c:2093:29: error: 'struct drm_crtc' has no 
member named 'fb'
  mode_cmd.width = crtc->base.fb->width;
 ^
drivers/gpu/drm/i915/intel_display.c:2094:30: error: 'struct drm_crtc' has no 
member named 'fb'
  mode_cmd.height = crtc->base.fb->height;
  ^
drivers/gpu/drm/i915/intel_display.c:2095:34: error: 'struct drm_crtc' has no 
member named 'fb'
  mode_cmd.pitches[0] = crtc->base.fb->pitches[0];
  ^
In file included from arch/x86/include/asm/percpu.h:44:0,
 from arch/x86/include/asm/preempt.h:5,
 from include/linux/preempt.h:18,
 from include/linux/spinlock.h:50,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from drivers/gpu/drm/i915/intel_display.c:28:
drivers/gpu/drm/i915/intel_display.c:2099:65: error: 'struct drm_crtc' has no 
member named 'fb'
  if (intel_framebuffer_init(dev, to_intel_framebuffer(crtc->base.fb),
 ^
include/linux/kernel.h:833:49: note: in definition of macro 'container_of'
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
 ^
drivers/gpu/drm/i915/intel_display.c:2099:34: note: in expansion of macro 
'to_intel_framebuffer'
  if (intel_framebuffer_init(dev, to_intel_framebuffer(crtc->base.fb),
  ^
drivers/gpu/drm/i915/intel_display.c: In function 'intel_find_plane_obj':
drivers/gpu/drm/i915/intel_display.c:2124:23: error: 'struct drm_crtc' has no 
member named 'fb'
  if (!intel_crtc->base.fb)
   ^
drivers/gpu/drm/i915/intel_display.c:2130:24: error: 'struct drm_crtc' has no 
member named 'fb'
  kfree(intel_crtc->base.fb);
^
drivers/gpu/drm/i915/intel_display.c:2131:18: error: 'struct drm_crtc' has no 
member named 'fb'
  intel_crtc->base.fb = NULL;
  ^
drivers/gpu/drm/i915/intel_display.c:2143:23: error: 'struct drm_crtc' has no 
member named 'fb'
   if (!i->active || !c->fb)
   ^
In file included from arch/x86/include/asm/percpu.h:44:0,
 from arch/x86/include/asm/preempt.h:5,
 from include/linux/preempt.h:18,
 from include/linux/spinlock.h:50,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from drivers/gpu/drm/i915/intel_display.c:28:
drivers/gpu/drm/i915/intel_display.c:2146:30: error: 'struct drm_crtc' has no 
member named 'fb'
   fb = to_intel_framebuffer(c->fb);
  ^
include/linux/kernel.h:833:49: note: in definition of macro 'container_of'
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
 ^
drivers/gpu/drm/i915/intel_display.c:2146:8: note: in expansion of macro 
'to_intel_framebuffer'
   fb = to_intel_framebuffer(c->fb);
^
drivers/gpu/drm/i915/intel_display.c:2148:31: error: 'struct drm_crtc' has no 
member named 'fb'
drm_framebuffer_reference(c->fb);
   ^
drivers/gpu/drm/i915/intel_display.c:2149:20: error: 'struct drm_crtc' has no 
member named 'fb'
intel_crtc->base.fb = c->fb;
^
drivers/gpu/drm/i915/intel_display.c:2149:27: error: 'struct drm_crtc' has no 
member named 'fb'
intel_crtc->base.fb = c->fb;
   ^
drivers/gpu/drm/i915/intel_display.c: In function 'i9xx_get_plane_config':
drivers/gpu/drm/i915/intel_display.c:5745:12: error: 'struct drm_crtc' has no 
member named 'fb'
  crtc->base.fb = kzalloc(sizeof(struct intel_framebuffer), GFP_KERNEL);
^
drivers/gpu/drm/i915/intel_display.c:5746:17: error: 'struct drm_crtc' has no 
member named 'fb'
  if (!crtc->base.fb) {
 ^
drivers/gpu/drm/i915/intel_display.c:5759:12: error: 'struct drm_crtc' has no 
member named 'fb'
  crtc->base.fb->pixel_format = fourcc;
^
drivers/gpu/drm/i915/intel_display.c:5760:12: error: 'struct drm_crtc' has no 
member named 'fb'
  crtc->base.fb->bits_per_pixel =
^
drivers/gpu/drm/i915/inte

[PATCH] drm: fix for "Replace crtc fb with primary plane fb"

2014-04-03 Thread Stephen Rothwell

fig.crtc_list, head) {
-   if (!c->fb)
+   if (!c->primary->fb)
continue;

-   fb = to_intel_framebuffer(c->fb);
+   fb = to_intel_framebuffer(c->primary->fb);
if (intel_pin_and_fence_fb_obj(dev, fb->obj, NULL)) {
DRM_ERROR("failed to pin boot fb on pipe %d\n",
  to_intel_crtc(c)->pipe);
-   drm_framebuffer_unreference(c->fb);
-   c->fb = NULL;
+   drm_framebuffer_unreference(c->primary->fb);
+   c->primary->fb = NULL;
}
}
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index d6d78c86c232..2b1d42dbfe13 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -481,7 +481,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
intel_crtc = to_intel_crtc(crtc);

-   if (!intel_crtc->active || !crtc->fb) {
+   if (!intel_crtc->active || !crtc->primary->fb) {
DRM_DEBUG_KMS("pipe %c not active or no fb, skipping\n",
  pipe_name(intel_crtc->pipe));
continue;
@@ -491,7 +491,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
DRM_DEBUG_KMS("found possible fb from plane %c\n",
  pipe_name(intel_crtc->pipe));
plane_config = &intel_crtc->plane_config;
-   fb = to_intel_framebuffer(crtc->fb);
+   fb = to_intel_framebuffer(crtc->primary->fb);
max_size = plane_config->size;
}
}
@@ -560,7 +560,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
if (!intel_crtc->active)
continue;

-   WARN(!crtc->fb,
+   WARN(!crtc->primary->fb,
 "re-used BIOS config but lost an fb on crtc %d\n",
 crtc->base.id);
}
-- 
1.9.1

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140403/410895a3/attachment-0001.sig>

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

2014-04-03 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit f4510a2752b7 ("drm:
Replace crtc fb with primary plane fb (v3)") from the drm tree and commit
262ca2b08fbd ("drm/i915: Rename similar plane functions to avoid
confusion") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/gpu/drm/i915/intel_display.c
index 3ffe5a6124f1,c31c6203c7ca..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -2291,9 -2398,11 +2398,11 @@@ void intel_display_handle_reset(struct 
 * disabling them without disabling the entire crtc) allow again
 * a NULL crtc->fb.
 */
 -  if (intel_crtc->active && crtc->fb)
 +  if (intel_crtc->active && crtc->primary->fb)
-   dev_priv->display.update_plane(crtc, crtc->primary->fb,
-  crtc->x, crtc->y);
+   dev_priv->display.update_primary_plane(crtc,
 - crtc->fb,
++ 
crtc->primary->fb,
+  crtc->x,
+  crtc->y);
mutex_unlock(&crtc->mutex);
}
  }
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140403/f87e4707/attachment.sig>

[PATCH v2 0/7] drm/exynos: more cleanup with super device support

2014-04-03 Thread Andrzej Hajda

On 04/03/2014 11:05 AM, ??? wrote:
> Hi Andrzej,
>
>> Hi Inki,
>>
>> On 04/01/2014 02:37 PM, Inki Dae wrote:
>>> This patch series cleans up exynos drm framework and kms sub drivers
>>> using the component framework[1].
>> I have tested it on trats platform (fimd + dsi), it works.
>> However it seems to be suboptimal.
>> In case of deferred probing of any of components (due to lack of some
>> resources, ex. clock, regulator, phy), all components
>> which were already bound are unbound and re-bound later when another
>> driver is added, this causes multiple unnecessary free/re-allocate cycles.
> The components bound and then unbound wouldn't be bound again because the 
> components unbound are removed component_list like below,
>
> ret = try_to_bring_up_masters(component);
> if (ret < 0) {
>list_del(&component->node);
>kfree(component);
> }
>
> And I cannot see that components are freed and re-allocated repeatedly. See 
> the below log,
>
> [1.425000] [drm] Initialized drm 1.1.0 20060810
> [1.43] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
> [1.435000] exynos4-fb 11c0.fimd: adding component (ops 
> fimd_component_ops)
> [1.445000] exynos-dsi 11c8.dsi: adding component (ops 
> exynos_dsi_component_ops)
> [1.45] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [1.455000] [drm] No driver support for vblank timestamp query.
> [1.465000] exynos-drm display-subsystem.8: binding 11c0.fimd (ops 
> fimd_component_ops)
> [1.47] exynos-drm display-subsystem.8: bound 11c0.fimd (ops 
> fimd_component_ops)
> [1.48] exynos-drm display-subsystem.8: binding 11c8.dsi (ops 
> exynos_dsi_component_ops)
> [1.49] exynos-drm display-subsystem.8: failed to bind 11c8.dsi 
> (ops exynos_dsi_component_ops): -12
> [1.50] exynos-drm display-subsystem.8: master bind failed: -12
> [1.505000] exynos-dsi: probe of 11c8.dsi failed with error -12
Here you have error -12 - ENOMEM, so everything just fails, and this is
OK. The problem is in case of deferred probe.
Good way to simulate it is to make mipi-phy driver as module and insmod
it from userspace.

Regards
Andrzej

>
> I have tested it on universal, trats, trats2 boards. And they all work fine.
> But there was one thing I missed. That is that dpi probe and remove shoudn't 
> be called if fimd node has no port node. For this, I posted it again.
>
> Did you check it again? It seems your missing something. And Can you tell me 
> more details how did you test it? If there is no any problem, I'm going to 
> have pull request today or tomorrow.

The problem I have described has nothing to do with dpi, in fact dpi
driver was disabled in this test.
Anyway I will test DPI separately.

>
> Thanks,
> Inki Dae
>
>> Maybe I miss something, but I guess registration list(s) + DT super-node
>> should perform better.
>>
>> Here is sample log from trats with mipi-phy driver delayed probe:
>>
>>  binding 11c0.fimd (ops fimd_component_ops)
>>  bound 11c0.fimd (ops fimd_component_ops)
>>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>>  unbinding 11c0.fimd (ops fimd_component_ops)
>>  master bind failed: -517
>>  binding 11c0.fimd (ops fimd_component_ops)
>>  bound 11c0.fimd (ops fimd_component_ops)
>>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>>  unbinding 11c0.fimd (ops fimd_component_ops)
>>  master bind failed: -517
>>  binding 11c0.fimd (ops fimd_component_ops)
>>  bound 11c0.fimd (ops fimd_component_ops)
>>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>>  unbinding 11c0.fimd (ops fimd_component_ops)
>>  master bind failed: -517
>>  binding 11c0.fimd (ops fimd_component_ops)
>>  bound 11c0.fimd (ops fimd_component_ops)
>>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>>  unbinding 11c0.fimd (ops fimd_component_ops)
>>  master bind failed: -517
>>  binding 11c0.fimd (ops fimd_component_ops)
>>  bound 11c0.fimd (ops fimd_component_ops)
>>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>>  bound 11c8.dsi (ops exynos_dsi_component_ops)
>>
>> This log will grow with number of devices probed in-between.
>>
>> Regards
>> Andrzej
>>
>>> And this patch series had been posted for RFC[2].
>>>
>>> Thanks,
>>> Inki Dae

[Intel-gfx] [PATCH] drm/i915: fix command parser debug print format mismatches

2014-04-03 Thread Daniel Vetter

On Wed, Apr 02, 2014 at 08:26:23AM -0700, Randy Dunlap wrote:
> On 04/02/2014 01:24 AM, Jani Nikula wrote:
> > Drop the cast from the pointer diff to fix:
> > 
> > drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
> > argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
> > [-Wformat]
> > 
> > While at it, use %u for u32.
> > 
> > Reported-by: Randy Dunlap 
> > Signed-off-by: Jani Nikula 
> > 
> > ---
> > 
> > Randy, try as I might, I wasn't able to coerce gcc to spit out that
> > warning. Please enlighten me! (Does this fix the warn?)
> 
> Yes, it does.  Thanks.
> 
> Acked-by: Randy Dunlap 

Maybe I'm blind, but I think the recent refactoring patch fixed this. Can
someone please double-check? I always get confused with printf formats ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] gpu: host1x: handle the correct # of syncpt regs

2014-04-03 Thread Terje Bergström

On 01.04.2014 23:10, Stephen Warren wrote:
> diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
> index db9017adfe2b..17407b2de2bf 100644
> --- a/drivers/gpu/host1x/hw/intr_hw.c
> +++ b/drivers/gpu/host1x/hw/intr_hw.c
> @@ -47,7 +47,7 @@ static irqreturn_t syncpt_thresh_isr(int irq, void *dev_id)
>   unsigned long reg;
>   int i, id;
>  
> - for (i = 0; i <= BIT_WORD(host->info->nb_pts); i++) {
> + for (i = 0; i < BITS_TO_LONGS(host->info->nb_pts); i++) {
>   reg = host1x_sync_readl(host,
>   HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(i));
>   for_each_set_bit(id, ®, BITS_PER_LONG) {
> @@ -64,7 +64,7 @@ static void _host1x_intr_disable_all_syncpt_intrs(struct 
> host1x *host)
>  {
>   u32 i;
>  
> - for (i = 0; i <= BIT_WORD(host->info->nb_pts); ++i) {
> + for (i = 0; i < BITS_TO_LONGS(host->info->nb_pts); ++i) {
>   host1x_sync_writel(host, 0xu,
>   HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(i));
>   host1x_sync_writel(host, 0xu,
> 

Wouldn't this break in architectures with 64-bit longs? Probably the
safest way would be to use DIV_ROUND_UP(host->info->nb_pts, 32), because
we know there are 32 bits in each host1x register.

Terje

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #53 from Joshua Roys  ---
Seems to work for me too.  I'm sure one of Alex's patches helped out too, so
thank you Alex.

I do get this on resume, but that's probably for another bug:
[  117.375124] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[  117.375127] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
E442 (len 2585, WS 4, PS 4) @ 0xEB2C
[  117.436913] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max
voltage
[  117.436914] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

-- 
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/20140403/032c5eb1/attachment.html>

[PATCH 2/3] drm/omap: fix enabling/disabling of video pipeline

2014-04-03 Thread Rob Clark

On Thu, Apr 3, 2014 at 9:45 AM, Tomi Valkeinen  wrote:
> At the moment the omap_crtc_pre_apply() handles the enabling, disabling
> and configuring of encoders and panels separately from the CRTC (i.e.
> the overlay manager).
>
> However, this doesn't work correctly. The encoder driver has to be in
> control of its video input (i.e. the crtc) for correct operation.
>
> This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
> pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
> current code first enables the HDMI encoder, and CRTC after that.
> However, the encoder expects the video stream to start during the
> encoder's enable, and if it doesn't, there will be sync lost errors.
>
> The encoder enables its video source by calling src->enable(), and this
> call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
> in that function. Similarly for disable, which goes to
> omap_crtc_disable().
>
> This patch moves the code to setup and enable/disable the crtc to
> omap_crtc_enable. and omap_crtc_disable().
>
> Signed-off-by: Tomi Valkeinen 

I had to go back to look at the code to realize the extra
'omap_crtc->full_update = false' removal didn't actually matter (it
was redundant).  So

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index beccff2ccf84..90916abb66ef 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -121,13 +121,25 @@ static void omap_crtc_start_update(struct 
> omap_overlay_manager *mgr)
>  {
>  }
>
> +static void set_enabled(struct drm_crtc *crtc, bool enable);
> +
>  static int omap_crtc_enable(struct omap_overlay_manager *mgr)
>  {
> +   struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
> +
> +   dispc_mgr_setup(omap_crtc->channel, &omap_crtc->info);
> +   dispc_mgr_set_timings(omap_crtc->channel,
> +   &omap_crtc->timings);
> +   set_enabled(&omap_crtc->base, true);
> +
> return 0;
>  }
>
>  static void omap_crtc_disable(struct omap_overlay_manager *mgr)
>  {
> +   struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
> +
> +   set_enabled(&omap_crtc->base, false);
>  }
>
>  static void omap_crtc_set_timings(struct omap_overlay_manager *mgr,
> @@ -600,7 +612,6 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
> *apply)
> omap_crtc->current_encoder = encoder;
>
> if (!omap_crtc->enabled) {
> -   set_enabled(&omap_crtc->base, false);
> if (encoder)
> omap_encoder_set_enabled(encoder, false);
> } else {
> @@ -609,13 +620,7 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
> *apply)
> omap_encoder_update(encoder, omap_crtc->mgr,
> &omap_crtc->timings);
> omap_encoder_set_enabled(encoder, true);
> -   omap_crtc->full_update = false;
> }
> -
> -   dispc_mgr_setup(omap_crtc->channel, &omap_crtc->info);
> -   dispc_mgr_set_timings(omap_crtc->channel,
> -   &omap_crtc->timings);
> -   set_enabled(&omap_crtc->base, true);
> }
>
> omap_crtc->full_update = false;
> --
> 1.8.3.2
>

[PATCH 1/3] drm/omap: fix missing disable for unused encoder

2014-04-03 Thread Rob Clark

On Thu, Apr 3, 2014 at 9:45 AM, Tomi Valkeinen  wrote:
> When an encoder is no longer connected to a crtc, the driver will leave
> the encoder enabled.
>
> This patch adds code to track the encoder used for a crtc, and when the
> encoder changes, the old one is disabled.
>
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Rob Clark 


> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 4f624c59a660..beccff2ccf84 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -33,6 +33,7 @@ struct omap_crtc {
> int pipe;
> enum omap_channel channel;
> struct omap_overlay_manager_info info;
> +   struct drm_encoder *current_encoder;
>
> /*
>  * Temporary: eventually this will go away, but it is needed
> @@ -593,6 +594,11 @@ static void omap_crtc_pre_apply(struct omap_drm_apply 
> *apply)
> }
> }
>
> +   if (omap_crtc->current_encoder && encoder != 
> omap_crtc->current_encoder)
> +   omap_encoder_set_enabled(omap_crtc->current_encoder, false);
> +
> +   omap_crtc->current_encoder = encoder;
> +
> if (!omap_crtc->enabled) {
> set_enabled(&omap_crtc->base, false);
> if (encoder)
> --
> 1.8.3.2
>

[PATCH v2 0/7] drm/exynos: more cleanup with super device support

2014-04-03 Thread 대인기


>On 04/03/2014 11:05 AM, ??? wrote:
>> Hi Andrzej,
>>
>>> Hi Inki,
>>
>>> On 04/01/2014 02:37 PM, Inki Dae wrote:
 This patch series cleans up exynos drm framework and kms sub drivers
 using the component framework[1].
>>> I have tested it on trats platform (fimd + dsi), it works.
>>> However it seems to be suboptimal.
>>> In case of deferred probing of any of components (due to lack of some
>>> resources, ex. clock, regulator, phy), all components
>>> which were already bound are unbound and re-bound later when another
>>> driver is added, this causes multiple unnecessary free/re-allocate cycles.
>> The components bound and then unbound wouldn't be bound again because the 
>> components unbound are removed component_list l>ike below,
>>
>> ret = try_to_bring_up_masters(component);
>> if (ret < 0) {
>>list_del(&component->node);
>>kfree(component);
>> }
>>
>> And I cannot see that components are freed and re-allocated repeatedly. See 
>> the below log,
>>
>> [1.425000] [drm] Initialized drm 1.1.0 20060810
>> [1.43] exynos-drm-ipp exynos-drm-ipp: drm ipp registered 
>> successfully.
>> [1.435000] exynos4-fb 11c0.fimd: adding component (ops 
>> fimd_component_ops)
>> [1.445000] exynos-dsi 11c8.dsi: adding component (ops 
>> exynos_dsi_component_ops)
>> [1.45] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [1.455000] [drm] No driver support for vblank timestamp query.
>> [1.465000] exynos-drm display-subsystem.8: binding 11c0.fimd (ops 
>> fimd_component_ops)
>> [1.47] exynos-drm display-subsystem.8: bound 11c0.fimd (ops 
>> fimd_component_ops)
>> [1.48] exynos-drm display-subsystem.8: binding 11c8.dsi (ops 
>> exynos_dsi_component_ops)
>> [1.49] exynos-drm display-subsystem.8: failed to bind 11c8.dsi 
>> (ops exynos_dsi_component_ops): -12
>> [1.50] exynos-drm display-subsystem.8: master bind failed: -12
>> [1.505000] exynos-dsi: probe of 11c8.dsi failed with error -12
>Here you have error -12 - ENOMEM, so everything just fails, and this is
>OK. The problem is in case of deferred probe.
>Good way to simulate it is to make mipi-phy driver as module and insmod
>it from userspace.
>

Reproduced by returning -EPROBE_DEFER at exynos_dsi_bind(). Right, in this 
case, the component isn't removed from component_list because all components 
are added to component_list, and the components are also attached to master. In 
turn, exynos_drm_load() will return -EPROBE_DEFER so the components will be 
unbound and bound repeatedly.

So to resolve this issue, it needs for -EPROBE_DEFER is returned only in 
exynos_dsi_probe, not exynos_dsi_bind. For this, I fixed it and tested it.

Will post it again.

Thanks for testing,
Inki Dae

>Regards
>Andrzej
>
>
>> I have tested it on universal, trats, trats2 boards. And they all work fine.
>> But there was one thing I missed. That is that dpi probe and remove shoudn't 
>> be called if fimd node has no port node. For this, I post>ed it again.
>>
>> Did you check it again? It seems your missing something. And Can you tell me 
>> more details how did you test it? If there is no any pr>>oblem, I'm going to 
>> have pull request today or tomorrow.
>
>The problem I have described has nothing to do with dpi, in fact dpi
>driver was disabled in this test.
>Anyway I will test DPI separately.
>
>>

[PATCH] drm/ttm: Hide the implementation details of reservation

2014-04-03 Thread Thomas Hellstrom

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/qxl/qxl_release.c  |2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |   26 +-
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |8 +++---
 include/drm/ttm/ttm_bo_driver.h|   47 
 4 files changed, 47 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 821ab7b..14e776f 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -349,7 +349,7 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)
qxl_fence_add_release_locked(&qbo->fence, release->id);

ttm_bo_add_to_lru(bo);
-   ww_mutex_unlock(&bo->resv->lock);
+   __ttm_bo_unreserve(bo);
entry->reserved = false;
}
spin_unlock(&bdev->fence_lock);
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9df79ac..4ab9f71 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -412,7 +412,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
int ret;

spin_lock(&glob->lru_lock);
-   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
+   ret = __ttm_bo_reserve(bo, false, true, false, 0);

spin_lock(&bdev->fence_lock);
(void) ttm_bo_wait(bo, false, false, true);
@@ -443,7 +443,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
ttm_bo_add_to_lru(bo);
}

-   ww_mutex_unlock(&bo->resv->lock);
+   __ttm_bo_unreserve(bo);
}

kref_get(&bo->list_kref);
@@ -494,7 +494,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
sync_obj = driver->sync_obj_ref(bo->sync_obj);
spin_unlock(&bdev->fence_lock);

-   ww_mutex_unlock(&bo->resv->lock);
+   __ttm_bo_unreserve(bo);
spin_unlock(&glob->lru_lock);

ret = driver->sync_obj_wait(sync_obj, false, interruptible);
@@ -514,7 +514,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return ret;

spin_lock(&glob->lru_lock);
-   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
+   ret = __ttm_bo_reserve(bo, false, true, false, 0);

/*
 * We raced, and lost, someone else holds the reservation now,
@@ -532,7 +532,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
spin_unlock(&bdev->fence_lock);

if (ret || unlikely(list_empty(&bo->ddestroy))) {
-   ww_mutex_unlock(&bo->resv->lock);
+   __ttm_bo_unreserve(bo);
spin_unlock(&glob->lru_lock);
return ret;
}
@@ -577,11 +577,11 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
kref_get(&nentry->list_kref);
}

-   ret = ttm_bo_reserve_nolru(entry, false, true, false, 0);
+   ret = __ttm_bo_reserve(entry, false, true, false, 0);
if (remove_all && ret) {
spin_unlock(&glob->lru_lock);
-   ret = ttm_bo_reserve_nolru(entry, false, false,
-  false, 0);
+   ret = __ttm_bo_reserve(entry, false, false,
+  false, 0);
spin_lock(&glob->lru_lock);
}

@@ -726,7 +726,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

spin_lock(&glob->lru_lock);
list_for_each_entry(bo, &man->lru, lru) {
-   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
+   ret = __ttm_bo_reserve(bo, false, true, false, 0);
if (!ret)
break;
}
@@ -1630,7 +1630,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)

spin_lock(&glob->lru_lock);
list_for_each_entry(bo, &glob->swap_lru, swap) {
-   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
+   ret = __ttm_bo_reserve(bo, false, true, false, 0);
if (!ret)
break;
}
@@ -1697,7 +1697,7 @@ out:
 * already swapped buffer.
 */

-   ww_mutex_unlock(&bo->resv->lock);
+   __ttm_bo_unreserve(bo);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
 }
@@ -1731,10 +1731,10 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
return -ERESTARTSYS;
if (!ww_mutex_is_locked(&bo->resv->lock))
goto out_unlock;
-   ret = ttm_bo_reserve_nolru(bo, true, false, false, NULL);
+   ret = __ttm_bo_reserve(bo, true, false, false, NULL);

drm/i915: XPS13 backlight regression in v3.14

2014-04-03 Thread Jani Nikula

On Thu, 03 Apr 2014, James Hogan  wrote:
> Hi,
>
> I've noticed that v3.14 breaks the backlight on Dell XPS13. Reverting the 
> following commit fixes the issue for me (i.e. the GUI brightness controls 
> work 
> again):
>
> bc0bb9fd1c78 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
>
> It appears that in v3.14 (with the above patch):
> * intel_backlight/brightness=4882 (max & default) causes 
> acpi_video0/brightness to have no effect.
> * intel_backlight/brightness=0 causes acpi_video0/brightness to behave 
> corrrectly (the firmware (I assume) fades the brightness gradually when 
> acpi_video0/brightness is set)
> * intel_backlight/brightness=something else in between often causes 
> acpi_video0 and intel_backlight to apparently "fight" over the backlight, 
> resulting in brightness flickering up and down every second or so.
>
> Reverting the above patch on v3.14:
> * intel_backlight/brightness has no effect
> * acpi_video0/brightness works normally
>
> It doesn't seem quite as simple as them trying to use the same hardware since 
> when intel_backlight/brightness=4882, acpi_video0/brightness has no effect at 
> all, so I don't really get what's going on.
>
> Can anybody shed some light or suggest a proper fix for this recurring issue?

Tracked at https://bugs.freedesktop.org/show_bug.cgi?id=76276

BR,
Jani.


>
> Thanks
> James

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2/2] drm/vmwgfx: Remove authorization requirements around some more ioctls

2014-04-03 Thread Thomas Hellstrom

These ioctls require a valid handle referenced by the caller to succeed,
which implies that the caller has or has had sufficient privileges.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index c700958..4a223bb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -171,10 +171,10 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl,
  DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_UNLOCKED | DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_FENCE_SIGNALED,
  vmw_fence_obj_signaled_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_UNLOCKED | DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_FENCE_UNREF, vmw_fence_obj_unref_ioctl,
  DRM_UNLOCKED | DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_FENCE_EVENT, vmw_fence_event_ioctl,
@@ -205,7 +205,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
  DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_SYNCCPU,
  vmw_user_dmabuf_synccpu_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_UNLOCKED | DRM_RENDER_ALLOW),
 };

 static struct pci_device_id vmw_pci_id_list[] = {
-- 
1.7.10.4

[PATCH 1/2] drm/vmwgfx: Fix query buffer locking order violation

2014-04-03 Thread Thomas Hellstrom

The query buffers were reserved while holding the binding mutex, which
caused a circular locking dependency.

Cc: stable at vger.kernel.org
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 701d520..8bb26dc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -117,10 +117,10 @@ static void vmw_hw_context_destroy(struct vmw_resource 
*res)
(void) vmw_context_binding_state_kill
(&container_of(res, struct vmw_user_context, res)->cbs);
(void) vmw_gb_context_destroy(res);
+   mutex_unlock(&dev_priv->binding_mutex);
if (dev_priv->pinned_bo != NULL &&
!dev_priv->query_cid_valid)
__vmw_execbuf_release_pinned_bo(dev_priv, NULL);
-   mutex_unlock(&dev_priv->binding_mutex);
mutex_unlock(&dev_priv->cmdbuf_mutex);
return;
}
-- 
1.7.10.4

[PATCH v2 0/7] drm/exynos: more cleanup with super device support

2014-04-03 Thread Andrzej Hajda

Hi Inki,

On 04/01/2014 02:37 PM, Inki Dae wrote:
> This patch series cleans up exynos drm framework and kms sub drivers
> using the component framework[1].

I have tested it on trats platform (fimd + dsi), it works.
However it seems to be suboptimal.
In case of deferred probing of any of components (due to lack of some
resources, ex. clock, regulator, phy), all components
which were already bound are unbound and re-bound later when another
driver is added, this causes multiple unnecessary free/re-allocate cycles.
Maybe I miss something, but I guess registration list(s) + DT super-node
should perform better.

Here is sample log from trats with mipi-phy driver delayed probe:

 binding 11c0.fimd (ops fimd_component_ops)
 bound 11c0.fimd (ops fimd_component_ops)
 binding 11c8.dsi (ops exynos_dsi_component_ops)
 failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
 unbinding 11c0.fimd (ops fimd_component_ops)
 master bind failed: -517
 binding 11c0.fimd (ops fimd_component_ops)
 bound 11c0.fimd (ops fimd_component_ops)
 binding 11c8.dsi (ops exynos_dsi_component_ops)
 failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
 unbinding 11c0.fimd (ops fimd_component_ops)
 master bind failed: -517
 binding 11c0.fimd (ops fimd_component_ops)
 bound 11c0.fimd (ops fimd_component_ops)
 binding 11c8.dsi (ops exynos_dsi_component_ops)
 failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
 unbinding 11c0.fimd (ops fimd_component_ops)
 master bind failed: -517
 binding 11c0.fimd (ops fimd_component_ops)
 bound 11c0.fimd (ops fimd_component_ops)
 binding 11c8.dsi (ops exynos_dsi_component_ops)
 failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
 unbinding 11c0.fimd (ops fimd_component_ops)
 master bind failed: -517
 binding 11c0.fimd (ops fimd_component_ops)
 bound 11c0.fimd (ops fimd_component_ops)
 binding 11c8.dsi (ops exynos_dsi_component_ops)
 bound 11c8.dsi (ops exynos_dsi_component_ops)

This log will grow with number of devices probed in-between.

Regards
Andrzej

> 
> And this patch series had been posted for RFC[2].
> 
> Thanks,
> Inki Dae
> 
> [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html
> [2] http://comments.gmane.org/gmane.comp.video.dri.devel/101200
> 
> 
> Inki Dae (7):
>   drm/exynos: add super device support
>   drm/exynos: dpi: fix hotplug fail issue
>   drm/exynos: register platform driver at each kms sub drivers
>   ARM: dts: exynos4210-universal: add super device node for exynos drm
>   ARM: dts: exynos4210-trats: add super device node for exynos drm
>   ARM: dts: exynos4412-trats2: add super device node for exynos drm
>   exynos/drm: add DT bindings
> 
>  .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 +++
>  arch/arm/boot/dts/exynos4210-trats.dts |5 +
>  arch/arm/boot/dts/exynos4210-universal_c210.dts|5 +
>  arch/arm/boot/dts/exynos4412-trats2.dts|5 +
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   46 ++--
>  drivers/gpu/drm/exynos/exynos_drm_core.c   |  216 +++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   17 ++
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |4 +
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c|   21 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  256 
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   79 +++---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c|   39 ++-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   77 --
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   |   61 +++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   46 ++--
>  drivers/gpu/drm/exynos/exynos_mixer.c  |   55 -
>  16 files changed, 490 insertions(+), 474 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
>

[PATCH] DRM: Armada: Use devm_ioremap_resource()

2014-04-03 Thread Jingoo Han

Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().

Signed-off-by: Jingoo Han 
---
 drivers/gpu/drm/armada/armada_crtc.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index d8e3982..23b0123 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1037,10 +1037,10 @@ int armada_drm_crtc_create(struct drm_device *dev, 
unsigned num,
if (ret)
return ret;

-   base = devm_request_and_ioremap(dev->dev, res);
-   if (!base) {
+   base = devm_ioremap_resource(dev->dev, res);
+   if (IS_ERR(base)) {
DRM_ERROR("failed to ioremap register\n");
-   return -ENOMEM;
+   return PTR_ERR(base);
}

dcrtc = kzalloc(sizeof(*dcrtc), GFP_KERNEL);
-- 
1.7.10.4

[Nouveau] [PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

2014-04-03 Thread Ben Skeggs

On Thu, Apr 3, 2014 at 12:23 AM, Ilia Mirkin  wrote:
> On Wed, Apr 2, 2014 at 10:14 AM, Alexandre Courbot  
> wrote:
> + /* Need to figure out how to handle sw for gk20a */
> + if (device->chipset == 0xea)
> + goto skip_sw_init;

 The commit message makes it sound like SW isn't needed since gk20a
 "lacks any display hardware". In that case the comment here doesn't make
 much sense.
>>
>> Correct. As far as I have looked (that is, not very far), SW methods
>> are used for display-related functions, but there might be other
>> use-cases too. Maybe someone who knows better can confirm?
>
> http://cgit.freedesktop.org/~darktama/nouveau/tree/nvkm/engine/software/nvc0.c
>
> Take a look at nvc0_software_mthd_mp_control -- that's used in the
> mesa driver to... well, control those things :) They're related to
> PGRAPH, which should be available on the GK20A. [Not sure what they do
> though. One of them is about turning off error reporting.]
Hm, I don't know why I didn't notice that was there for now.. I
wouldn't be entirely surprised if nvidia had reserved method ids in
the 3d object class that were supposed to be used for this, rather
than from a sw object class..

>
>   -ilia

[PATCH 10/12] drm/nouveau/graph: add GK20A support

2014-04-03 Thread Ben Skeggs

On Thu, Apr 3, 2014 at 12:03 AM, Alexandre Courbot  wrote:
> On Wed, Mar 26, 2014 at 1:24 PM, Ben Skeggs  wrote:
>> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  
>> wrote:
>>> Add a GR device for GK20A based on NVE4, with the correct classes
>>> definitions (GK20A's 3D class is 0xa297).
>>>
>>> Most of the NVE4 code can be used on GK20A, so make relevant bits of
>>> NVE4 available to other chips as well.
>> This will need a bit of a rebase on top of the tree I mentioned
>> earlier (also queued for drm-next now), where I've further split out
>> and named the various chunks of state.
>
> Will do that.
>
>>
>> Does GK104 match entirely correctly, or just happen to work?  I could
>> probably hunt down the GK20A netlist images and check that actually :)
>
> Do you mean, the init sequence? I haven't checked in detail (we are
> certainly doing things differently in the non-DRM driver), but the
> registers seem to match and the GPU is able to render after that. I
> admit I have not looked much further for now.
I meant the arrays of register data, there's generally been some
differences for most major chipset bumps.  Where can I find the
netlist firmware packages that go with the android driver?  I can pull
all the required info out of there to check :)

>
> The only register that does not exist on GK20A is 0x260, but when
> accessing it Nouveau will be able to continue unharmed after a memory
> fault.
I have it in my queue to fix that too, the register doesn't exist on a
couple of the other chips we support too.

[PATCH v2 0/7] drm/exynos: more cleanup with super device support

2014-04-03 Thread 대인기

Hi Andrzej,

> Hi Inki,
>
> On 04/01/2014 02:37 PM, Inki Dae wrote:
>> This patch series cleans up exynos drm framework and kms sub drivers
>> using the component framework[1].
>
> I have tested it on trats platform (fimd + dsi), it works.
> However it seems to be suboptimal.
> In case of deferred probing of any of components (due to lack of some
> resources, ex. clock, regulator, phy), all components
> which were already bound are unbound and re-bound later when another
> driver is added, this causes multiple unnecessary free/re-allocate cycles.

The components bound and then unbound wouldn't be bound again because the 
components unbound are removed component_list like below,

ret = try_to_bring_up_masters(component);
if (ret < 0) {
   list_del(&component->node);
   kfree(component);
}

And I cannot see that components are freed and re-allocated repeatedly. See the 
below log,

[1.425000] [drm] Initialized drm 1.1.0 20060810
[1.43] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
[1.435000] exynos4-fb 11c0.fimd: adding component (ops 
fimd_component_ops)
[1.445000] exynos-dsi 11c8.dsi: adding component (ops 
exynos_dsi_component_ops)
[1.45] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.455000] [drm] No driver support for vblank timestamp query.
[1.465000] exynos-drm display-subsystem.8: binding 11c0.fimd (ops 
fimd_component_ops)
[1.47] exynos-drm display-subsystem.8: bound 11c0.fimd (ops 
fimd_component_ops)
[1.48] exynos-drm display-subsystem.8: binding 11c8.dsi (ops 
exynos_dsi_component_ops)
[1.49] exynos-drm display-subsystem.8: failed to bind 11c8.dsi (ops 
exynos_dsi_component_ops): -12
[1.50] exynos-drm display-subsystem.8: master bind failed: -12
[1.505000] exynos-dsi: probe of 11c8.dsi failed with error -12

I have tested it on universal, trats, trats2 boards. And they all work fine.
But there was one thing I missed. That is that dpi probe and remove shoudn't be 
called if fimd node has no port node. For this, I posted it again.

Did you check it again? It seems your missing something. And Can you tell me 
more details how did you test it? If there is no any problem, I'm going to have 
pull request today or tomorrow.

Thanks,
Inki Dae

> Maybe I miss something, but I guess registration list(s) + DT super-node
> should perform better.
> 
> Here is sample log from trats with mipi-phy driver delayed probe:
> 
>  binding 11c0.fimd (ops fimd_component_ops)
>  bound 11c0.fimd (ops fimd_component_ops)
>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>  unbinding 11c0.fimd (ops fimd_component_ops)
>  master bind failed: -517
>  binding 11c0.fimd (ops fimd_component_ops)
>  bound 11c0.fimd (ops fimd_component_ops)
>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>  unbinding 11c0.fimd (ops fimd_component_ops)
>  master bind failed: -517
>  binding 11c0.fimd (ops fimd_component_ops)
>  bound 11c0.fimd (ops fimd_component_ops)
>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>  unbinding 11c0.fimd (ops fimd_component_ops)
>  master bind failed: -517
>  binding 11c0.fimd (ops fimd_component_ops)
>  bound 11c0.fimd (ops fimd_component_ops)
>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>  failed to bind 11c8.dsi (ops exynos_dsi_component_ops): -517
>  unbinding 11c0.fimd (ops fimd_component_ops)
>  master bind failed: -517
>  binding 11c0.fimd (ops fimd_component_ops)
>  bound 11c0.fimd (ops fimd_component_ops)
>  binding 11c8.dsi (ops exynos_dsi_component_ops)
>  bound 11c8.dsi (ops exynos_dsi_component_ops)
> 
> This log will grow with number of devices probed in-between.
> 
> Regards
> Andrzej
> 
> > 
> > And this patch series had been posted for RFC[2].
> > 
> > Thanks,
> > Inki Dae

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #52 from klausenbusk at hotmail.com ---
(In reply to comment #51)
> maybe the same issue? https://bugs.freedesktop.org/show_bug.cgi?id=42960
> 
> also, isn't pm-utils somehow deprecated?
> if we add the parameter in /etc/pm/config.d/ will the command "systemctl
> suspend" be able to turn on the screen? i think that "systemctl suspend"
> doesn't rely on pm-utils

I looked in the pm-utils sourcecode, and adding acpi_sleep=s3_bios to the
cmdline fix it for me.

You can read a little about it here:
https://www.kernel.org/doc/Documentation/power/video.txt

-- 
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/20140403/c60cfa0e/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

nb  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=73882

-- 
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/20140403/d3c15761/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

nb  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=73882

-- 
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/20140403/dfe9ea61/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

--- Comment #18 from nb  ---
and how we make this work with
"systemctl suspend"??

isn't pm-utils deprecated?

-- 
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/20140403/64474523/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

nb  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=42960

-- 
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/20140403/8b4ec715/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

nb  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=43829

-- 
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/20140403/765bd79b/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #51 from nb  ---
maybe the same issue? https://bugs.freedesktop.org/show_bug.cgi?id=42960

also, isn't pm-utils somehow deprecated?
if we add the parameter in /etc/pm/config.d/ will the command "systemctl
suspend" be able to turn on the screen? i think that "systemctl suspend"
doesn't rely on pm-utils

-- 
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/20140403/59a676b4/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #56 from Christian K?nig  ---
@Garrett:

That looks rather interesting. First of all please open up a new bug report, I
want to separate this problem from the discussion here.

To this new bug report please add the output of "xrandr --verbose" and your
dmesg logs of the 23.98 mode in the working and not working case.

I have a pretty good idea what's going wrong here, but you need to test a
couple of patches to make sure.

-- 
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/20140403/ae992015/attachment.html>

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

--- Comment #50 from Helge Bahmann  ---
(In reply to comment #49)
> I have a similar issue with a samsumg series 3 laptop with "VGA compatible
> controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD
> 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external
> monitor show the system is still responsive.
> 
> BUT I can make the screen turn on after suspend with the next command:
> sudo pm-suspend --quirk-test --quirk-s3-bios

whoa, that worked as well for me! I'll try to dissect unless someone else jumps
to it, and then make good on my promise above :)

-- 
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/20140403/4d8fd177/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

--- Comment #17 from Sandeep  ---
I was able to apply this workaround "permanently" by creating a config file in
/etc/pm/config.d/ with the following line:

ADD_PARAMETERS="--quirk-s3-bios"

So, I have a temporary workaround, but it would be preferable to have this work
out of the box.

-- 
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/20140403/75ff4d73/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

--- Comment #16 from Sandeep  ---
Yes, that worked! Suspending using 

"pm-suspend --quirk-test --quirk-s3-bios"

and the laptop LVDS panel works after resume.

-- 
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/20140403/913d6e53/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #55 from Garrett  ---
Created attachment 96820
  --> https://bugs.freedesktop.org/attachment.cgi?id=96820&action=edit
dmesg xrandr old code working 23.98

xrandr prepatch 1920x1080px23.98 OK LCD display.
"xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98"
[  183.991214] [drm:radeon_compute_pll_avivo], 14818, pll dividers - fb: 32.6
ref: 2, post 11
LCD = "DISPLAY" button 1080/24p.

-- 
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/20140403/bf1d7b2a/attachment-0001.html>

drm/i915: XPS13 backlight regression in v3.14

2014-04-03 Thread James Hogan

Hi,

I've noticed that v3.14 breaks the backlight on Dell XPS13. Reverting the 
following commit fixes the issue for me (i.e. the GUI brightness controls work 
again):

bc0bb9fd1c78 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE

It appears that in v3.14 (with the above patch):
* intel_backlight/brightness=4882 (max & default) causes 
acpi_video0/brightness to have no effect.
* intel_backlight/brightness=0 causes acpi_video0/brightness to behave 
corrrectly (the firmware (I assume) fades the brightness gradually when 
acpi_video0/brightness is set)
* intel_backlight/brightness=something else in between often causes 
acpi_video0 and intel_backlight to apparently "fight" over the backlight, 
resulting in brightness flickering up and down every second or so.

Reverting the above patch on v3.14:
* intel_backlight/brightness has no effect
* acpi_video0/brightness works normally

It doesn't seem quite as simple as them trying to use the same hardware since 
when intel_backlight/brightness=4882, acpi_video0/brightness has no effect at 
all, so I don't really get what's going on.

Can anybody shed some light or suggest a proper fix for this recurring issue?

Thanks
James
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140403/f537f96c/attachment-0001.sig>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #54 from Garrett  ---
Created attachment 96819
  --> https://bugs.freedesktop.org/attachment.cgi?id=96819&action=edit
xrandr 1920x1080x23.98 crashed

ok "xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98" crashes the screen.
Same as the OE when playing a 24p video.
[ 4592.767636] [drm:radeon_compute_pll_avivo], 148340 - 14834, pll dividers -
fb: 741.7 ref: 50, post 10
LMK if you need more.

-- 
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/20140403/442d1267/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

--- Comment #24 from Tom Stellard  ---
DId yo(In reply to comment #21)
> I amanaged to build llvm and mesa.
> 
> Here's my test results:
> As for both wine applications 3D Mark 2000 and Syberia, the error is gone
> and both applications continue past normally.
> 
> But Antichamber will crash the system hard.
> I have found place in the game where the llvm error always happens.
> When I use your version of llvm 3.5 instead of llvm 3.4 Antichamber wont
> exit with the error it will instead deadlock the whole system, only option
> is reboot.

Did you try this branch:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

-- 
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/20140403/5f8b467c/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

--- Comment #53 from Garrett  ---
Created attachment 96817
  --> https://bugs.freedesktop.org/attachment.cgi?id=96817&action=edit
xrandr 1920x1080x24p and OE crashed lcd

Sorry.  Here you go: dmesg just after- "xrandr --output HDMI-0 --mode 1920x1080
--rate 24". It did change refresh w/o blank screen: 
[2465.347782] [drm:radeon_compute_pll_avivo], 148500 - 14850, pll dividers -
fb: 29.7 ref: 2, post 10.My LCD shows 1080/24P now pressing remote
"DISPLAY" button.

Opening OE 24p video >> crashes the screen.  dmesg while on a crashed screen.
[958.084974] [drm:radeon_compute_pll_avivo], 148340 - 14834, pll dividers - fb:
741.7 ref: 50, post 10

-- 
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/20140403/a62d4df6/attachment.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

--- Comment #23 from Sean Rhone  ---
(In reply to comment #22)
> I'm also getting this same error when trying to run Diablo III: Reaper of
> Souls via Wine. My setup is identical to ubu's with the only differences
> being that I'm using Netrunner (KDE) and that my graphics card is a HD 7750.
> When running the game, it consistently crashes after retrieving the
> character list with the "LLVM runs out of registers" error.

Can also confirm a similar scenario with Diablo III (using Radeon HD 7850,
Kernel 3.14.0-999-generic #201404020331, Xubuntu 14.04, oibaf's PPA, Wine
1.7.15).

-- 
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/20140403/4815d2e8/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

--- Comment #15 from nb  ---
Hi! i've been experiencing some similar issue.
(i posted in bug https://bugs.freedesktop.org/show_bug.cgi?id=43829.)

Have you tried with
sudo pm-suspend --quirk-test --quirk-s3-bios

because if i run this my screen is able to turn on after the resume. Can you
try it?

-- 
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/20140403/83f2efed/attachment.html>

[PATCH] drm: gem-cma: Fix warnings due to improper printk formats

2014-04-03 Thread Laurent Pinchart

Hi Dave,

Could you please take this patch in your tree ?

What's the expected process when sending patches to the mailing list by the 
way ? Do you track them somehow, or always expect pull requests ?

On Tuesday 04 March 2014 19:10:17 Laurent Pinchart wrote:
> Use the %pad printk specifier to print dma_addr_t variables. This fixes
> warnings on platforms where dma_addr_t has a different size than int or
> size_t.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c index 6b51bf9..c049e5b 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -292,9 +292,9 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
> *cma_obj, struct seq_file *m
> 
>   off = drm_vma_node_start(&obj->vma_node);
> 
> - seq_printf(m, "%2d (%2d) %08llx %08Zx %p %d",
> + seq_printf(m, "%2d (%2d) %08llx %pad %p %d",
>   obj->name, obj->refcount.refcount.counter,
> - off, cma_obj->paddr, cma_obj->vaddr, obj->size);
> + off, &cma_obj->paddr, cma_obj->vaddr, obj->size);
> 
>   seq_printf(m, "\n");
>  }
> @@ -342,7 +342,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device
> *dev, size_t size, cma_obj->paddr = sg_dma_address(sgt->sgl);
>   cma_obj->sgt = sgt;
> 
> - DRM_DEBUG_PRIME("dma_addr = 0x%x, size = %zu\n", cma_obj->paddr, size);
> + DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", &cma_obj->paddr, size);
> 
>   return &cma_obj->base;
>  }

-- 
Regards,

Laurent Pinchart

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black