[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task

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

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

--- Comment #8 from Andy Furniss  ---
(In reply to Andy Furniss from comment #7)
> (In reply to Christian K?nig from comment #6)
> > (In reply to Andy Furniss from comment #5)
> > > I don't know about Elemental as it's far harder to trigger, but first try
> > > with valley produced -
> > > 
> > > [  156.617954] radeon :01:00.0: GPU fault detected: 146 0x02e83504
> > > [  156.617960] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
> > > 0x00010F17
> > > [  156.617961] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
> > > 0x08035004
> > > [  156.617963] VM fault (0x04, vmid 4) at page 69399, read from VGT (53)
> > 
> > Sounds like a different problem triggered by the same patchset to me.
> > 
> > But first things first, is the original issue with the list corruption
> > fixed? If yes we can start to look into this one as well.
> 
> It's OK so far, but then I need more time as I don't really know how to
> trigger it and last time I called it as OK (in another bug) it wasn't.

Still haven't crashed Elemental but have got -

[29066.333908] [drm:radeon_gem_va_update_vm] *ERROR* Couldn't update BO_VA
(-512)
[29066.335653] [drm:radeon_gem_va_update_vm] *ERROR* Couldn't update BO_VA
(-512)

-- 
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/20141023/8e5b80ee/attachment.html>

[RFC 1/2] PM / Domains: Power on domain early during system resume

[Grygorii Strashko]

Hi Krzysztof,

On 10/23/2014 04:48 PM, Krzysztof Kozlowski wrote:
> When resuming the system the power domain has to be powered on early so
> any runtime PM aware devices could resume.
> 
> This fixes following scenario reproduced on Exynos DRM:
> 1. Power domain is off before suspending the system.
> 2. System is suspended to RAM.
> 3. Resuming starts. The Exynos DRM driver resume callback is called.
> 4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns
> the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
> 5. The Exynos DSI driver calls pm_runtime_get. The driver runtime
> resumes and this should turn LCD power domain on.
> 6. Unfortunately the domain cannot be turned on because system resume is
> in progress and genpd->prepared_count is positive.

Just interesting, what value will be returned by pm_runtime_enabled()
from any of your .resume() callback (for any device which belongs to
some Generic PM domain)?

I'm asking, because as I can see Runtime PM can be disabled from 
pm_genpd_prepare().

Thank you.

Oh. I've just found that you might get this issue if you will try to do
suspend when PM domain is ON ;)

Any way, In my opinion, It might be better to fix pm_genpd_prepare() so
it will not increment prepared_count when initial state of the GPD is
GPD_STATE_POWER_OFF. Seems it's needed only in opposite case -
when state of GPD has to be restored from pm_genpd_resume_noirq().

> 
> Steps to reproduce:
> 1. Add runtime PM to Exynos DSI driver.
> 2. Build Exynos DRM/FB without FRAMEBUFFER_CONSOLE.
> 3. Enable the connector and screen (e.g. with modeset-vsync application).
> 4. echo 3 > /sys/devices/platform/exynos-drm/graphics/fb0/blank
> 5. echo mem > /sys/power/state
> 6. Resume.
> [   77.712469] PM: early resume of devices complete after 3.854 msecs
> [   77.712739] exynos-dsi 11c8.dsi: pm_genpd_resume()
> [   77.712758] exynos4-fimc 1180.fimc: pm_genpd_resume()
> [   77.712774] exynos4-fimc 1181.fimc: pm_genpd_resume()
> [   77.712787] exynos-drm-fimc 1182.fimc: pm_genpd_resume()
> [   77.712802] exynos-drm-fimc 1183.fimc: pm_genpd_resume()
> [   77.712815] s5p-mipi-csis 1188.csis: pm_genpd_resume()
> [   77.712829] s5p-mipi-csis 1189.csis: pm_genpd_resume()
> [   77.712843] exynos-fimc-lite 1239.fimc-lite: pm_genpd_resume()
> [   77.712856] exynos-fimc-lite 123a.fimc-lite: pm_genpd_resume()
> [   77.713788] exynos4-fb 11c0.fimd: pm_genpd_resume()
> [   77.713912] wake disabled for irq 184
> [   77.713923] wake disabled for irq 185
> [   77.714082] wake disabled for irq 173
> [   77.715676] wake disabled for irq 176
> [   77.718540] exynos4-fb 11c0.fimd: pm_genpd_runtime_resume()
> [   77.718567] exynos4-fb 11c0.fimd: state restore latency exceeded, new 
> value 1708 ns
> [   77.718636] exynos-dsi 11c8.dsi: pm_genpd_runtime_resume()
> [   77.892366] exynos-dsi 11c8.dsi: PLL failed to stabilize
> [   77.892377] exynos-dsi 11c8.dsi: failed to configure DSI PLL
> [   78.192168] exynos-dsi 11c8.dsi: timeout waiting for reset
> [   78.211578] exynos-dsi 11c8.dsi: waiting for bus lanes timed out
> [   78.307173] exynos-dsi 11c8.dsi: xfer timed out: d1 00 (null)
> [   78.307190] panel_s6e8aa0 11c8.dsi.0: error -110 reading dcs seq(0xd1)
> [   78.307199] panel_s6e8aa0 11c8.dsi.0: read id failed
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>   drivers/base/power/domain.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 40bc2f4072cc..4fdfe404a04c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -179,8 +179,7 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
> *genpd)
>   }
>   finish_wait(>status_wait_queue, );
>   
> - if (genpd->status == GPD_STATE_ACTIVE
> - || (genpd->prepared_count > 0 && genpd->suspend_power_off))
> + if (genpd->status == GPD_STATE_ACTIVE)
>   return 0;
>   
>   if (genpd->status != GPD_STATE_POWER_OFF) {
> 

regards,
-grygorii

[Bug 74718] r600g: graphics artifacts with geometry shaders with RV730

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

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

--- Comment #8 from Dieter N?tzel  ---
Is this still a problem for you?

Looks very similar as mesa-demos/glsl/geom-outlining-150 on my RV730 AGP.
I have a geom-outlining-150-shader.log with R600_DEBUG=gs,vs,fs,ps if needed.

-- 
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/20141023/db22de67/attachment.html>

[Bug 85320] [RV630] GPU hangs using UVD hardware acceleration

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

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

--- Comment #12 from Eugene  ---
Anyway I'm ready to test anything that possible.

-- 
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/20141023/11530668/attachment.html>

[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730

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

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

--- Comment #7 from Dieter N?tzel  ---
Ping!

What's needed?

-- 
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/20141023/47948752/attachment.html>

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #12 from kb at spatium.org ---
note xrandr is on good kernel, dmesg in on bad

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #11 from kb at spatium.org ---
Created attachment 154681
  --> https://bugzilla.kernel.org/attachment.cgi?id=154681=edit
dmesg with drm.debug=0xe on BAD kernel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #10 from kb at spatium.org ---
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
Identifier: 0x51
Timestamp:  20519
Subpixel:   no subpixels
Clones:
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
load detection: 1 
range: (0, 1)
HDMI-0 connected 1920x1080+0+0 (0x54) normal (normal left inverted right x axis
y axis) 160mm x 90mm
Identifier: 0x52
Timestamp:  20519
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID: 
00004c2d09050100
30120103801009780aee91a3544c9926
0f5054bdef80714f8100814081809500
950fb3000101023a801871382d40582c
4500a05a001e662150b051001b30
40703600a05a001e00fd0018
4b1a5117000a20202020202000fc
0053414d53554e470a2020202020016f
020327f14b901f041305140312202122
230907078301e2000fe305030167
030c003000b82d011d007251d01e206e
285500a05a001e011d00bc52d01e
20b8285540a05a001e011d801871
1c1620582c2500a05a009e011d80
d0721c1620102c2580a05a009e00
00fd
dither: off 
supported: off, on
audio: auto 
supported: off, on, auto
underscan vborder: 0 
range: (0, 128)
underscan hborder: 0 
range: (0, 128)
underscan: off 
supported: off, on, auto
coherent: 1 
range: (0, 1)
  1920x1080 (0x54) 148.500MHz +HSync +VSync *current +preferred
h: width  1920 start 2008 end 2052 total 2200 skew0 clock  67.50KHz
v: height 1080 start 1084 end 1089 total 1125   clock  60.00Hz
  1920x1080 (0x55) 148.500MHz +HSync +VSync
h: width  1920 start 2448 end 2492 total 2640 skew0 clock  56.25KHz
v: height 1080 start 1084 end 1089 total 1125   clock  50.00Hz
  1920x1080 (0x56) 148.352MHz +HSync +VSync
h: width  1920 start 2008 end 2052 total 2200 skew0 clock  67.43KHz
v: height 1080 start 1084 end 1089 total 1125   clock  59.94Hz
  1920x1080i (0x57) 74.250MHz +HSync +VSync Interlace
h: width  1920 start 2008 end 2052 total 2200 skew0 clock  33.75KHz
v: height 1080 start 1084 end 1094 total 1125   clock  60.00Hz
  1920x1080i (0x58) 74.250MHz +HSync +VSync Interlace
h: width  1920 start 2448 end 2492 total 2640 skew0 clock  28.12KHz
v: height 1080 start 1084 end 1094 total 1125   clock  50.00Hz
  1920x1080 (0x59) 74.250MHz +HSync +VSync
h: width  1920 start 2008 end 2052 total 2200 skew0 clock  33.75KHz
v: height 1080 start 1084 end 1089 total 1125   clock  30.00Hz
  1920x1080 (0x5a) 74.250MHz +HSync +VSync
h: width  1920 start 2448 end 2492 total 2640 skew0 clock  28.12KHz
v: height 1080 start 1084 end 1089 total 1125   clock  25.00Hz
  1920x1080 (0x5b) 74.250MHz +HSync +VSync
h: width  1920 start 2558 end 2602 total 2750 skew0 clock  27.00KHz
v: height 1080 start 1084 end 1089 total 1125   clock  24.00Hz
  1920x1080i (0x5c) 74.176MHz +HSync +VSync Interlace
h: width  1920 start 2008 end 2052 total 2200 skew0 clock  33.72KHz
v: height 1080 start 1084 end 1094 total 1125   clock  59.94Hz
  1920x1080 (0x5d) 74.176MHz +HSync +VSync
h: width  1920 start 2008 end 2052 total 2200 skew0 clock  33.72KHz
v: height 1080 start 1084 end 1089 total 1125   clock  29.97Hz
  1920x1080 (0x5e) 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
  1680x1050 (0x5f) 119.000MHz +HSync -VSync
h: width  1680 start 1728 end 1760 total 1840 skew0 clock  64.67KHz
v: height 1050 start 1053 end 1059 total 1080   clock  59.88Hz
  1280x1024 (0x60) 135.000MHz +HSync +VSync
h: width  1280 start 1296 end 1440 total 1688 skew0 clock  79.98KHz
v: height 1024 start 1025 end 1028 total 1066   clock  75.02Hz
  1280x1024 (0x61) 108.000MHz +HSync +VSync
h: width  1280 start 1328 end 1440 total 1688 skew0 clock  63.98KHz
v: height 1024 start 1025 end 1028 total 1066   clock  60.02Hz
  1440x900 (0x62) 136.750MHz -HSync +VSync
h: width  1440 start 1536 end 1688 total 1936 skew0 clock  70.64KHz
v: height  900 start  903 end  909 total  942   clock  

[Bug 83861] radeon power management cause audio skips and glitch

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

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

--- Comment #6 from Yomi  ---
Francesco says this doesn't happen if one passes the option `radeon.dpm=0`, but
I have that in my bootloader config, and though it hasn't happened while this
system has been up for about two days, it is happening now since I've returned
from suspend.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 85376] New: Dolphin emulator has bad colors

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

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

Bug ID: 85376
   Summary: Dolphin emulator has bad colors
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: ghallberg+bugzilla at gmail.com

Created attachment 108308
  --> https://bugs.freedesktop.org/attachment.cgi?id=108308=edit
Fifo-file which displays the discoloration

When using recent versions of dolphin-emulator with open source amd drivers,
the graphics are tinted blue.

An example can be seen in this link: http://imgur.com/eLqLMdW

The example image was created when running the attached fifo-file in dolphin.

This is using the latest version of dolphin from the git-repo:
4.0.r3771.ce3a039-1 built with gcc 4.9.1-2 from the arch repositories

mesa is the 10.3.1 from the arch repositories and seems to be built with clang.

I'm running on an AMD A6-6400K APU.

I've tested the same versions of the software on my intel-based laptop, and the
discoloration is not present there.

-- 
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/20141023/0c4eb1cc/attachment.html>

[PATCH] drm/panel: simple: Update calls to gpiod_get*()

[Alexandre Courbot]

Add the new flags argument to calls of (devm_)gpiod_get*() and
remove any direction setting code afterwards.

Currently both forms (with or without the flags argument)
are valid thanks to transitional macros in
. These macros will be removed once
all consumers are updated and the flags argument will become
compulsary.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/panel/panel-simple.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f8c820..83d93062930d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -247,21 +247,14 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
if (IS_ERR(panel->supply))
return PTR_ERR(panel->supply);

-   panel->enable_gpio = devm_gpiod_get_optional(dev, "enable");
+   panel->enable_gpio = devm_gpiod_get_optional(dev, "enable",
+GPIOD_OUT_LOW);
if (IS_ERR(panel->enable_gpio)) {
err = PTR_ERR(panel->enable_gpio);
dev_err(dev, "failed to request GPIO: %d\n", err);
return err;
}

-   if (panel->enable_gpio) {
-   err = gpiod_direction_output(panel->enable_gpio, 0);
-   if (err < 0) {
-   dev_err(dev, "failed to setup GPIO: %d\n", err);
-   return err;
-   }
-   }
-
backlight = of_parse_phandle(dev->of_node, "backlight", 0);
if (backlight) {
panel->backlight = of_find_backlight_by_node(backlight);
-- 
2.1.2

[PATCH] drm/panel: s6e8aa0: Update calls to gpiod_get*()

[Alexandre Courbot]

Add the new flags argument to calls of (devm_)gpiod_get*() and
remove any direction setting code afterwards.

Currently both forms (with or without the flags argument)
are valid thanks to transitional macros in
. These macros will be removed once
all consumers are updated and the flags argument will become
compulsary.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/panel/panel-s6e8aa0.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
index b5217fe37f02..6427aa187735 100644
--- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -1019,17 +1019,12 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
return ret;
}

-   ctx->reset_gpio = devm_gpiod_get(dev, "reset");
+   ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
dev_err(dev, "cannot get reset-gpios %ld\n",
PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
-   ret = gpiod_direction_output(ctx->reset_gpio, 1);
-   if (ret < 0) {
-   dev_err(dev, "cannot configure reset-gpios %d\n", ret);
-   return ret;
-   }

ctx->brightness = GAMMA_LEVEL_NUM - 1;

-- 
2.1.2

[PATCH] drm/panel: ld9040: Update calls to gpiod_get*()

[Alexandre Courbot]

Add the new flags argument to calls of (devm_)gpiod_get*() and
remove any direction setting code afterwards.

Currently both forms (with or without the flags argument)
are valid thanks to transitional macros in
. These macros will be removed once
all consumers are updated and the flags argument will become
compulsary.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/panel/panel-ld9040.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
b/drivers/gpu/drm/panel/panel-ld9040.c
index 42ac67b21e9f..dd1d3f2e624e 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -336,17 +336,12 @@ static int ld9040_probe(struct spi_device *spi)
if (ret < 0)
return ret;

-   ctx->reset_gpio = devm_gpiod_get(dev, "reset");
+   ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
dev_err(dev, "cannot get reset-gpios %ld\n",
PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
-   ret = gpiod_direction_output(ctx->reset_gpio, 1);
-   if (ret < 0) {
-   dev_err(dev, "cannot configure reset-gpios %d\n", ret);
-   return ret;
-   }

spi->bits_per_word = 9;
ret = spi_setup(spi);
-- 
2.1.2

[PATCH v2 2/2] drm/panel: Add HannStar HSD070PWW1 7.0" WXGA TFT LCD panel

[Philipp Zabel]

This patch adds support for the HannStar Display Corp. HSD070PWW1 7.0"
WXGA TFT LCD panel to the simple-panel driver. The binding documentation
is included.
This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizontal blanking interval
is 160 clocks, and the vertical blanking interval is 23 lines.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Added bpc in panel_desc
 - Use non-zero front and back-porches
---
 .../bindings/panel/hannstar,hsd070pww1.txt |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt

diff --git a/Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt 
b/Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt
new file mode 100644
index 000..211c226
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt
@@ -0,0 +1,7 @@
+HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "hannstar,hsd070pww1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f..1dc5e52 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -542,6 +542,29 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
},
 };

+static const struct drm_display_mode hannstar_hsd070pww1_mode = {
+   .clock = 71100,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 1,
+   .hsync_end = 1280 + 1 + 158,
+   .htotal = 1280 + 1 + 158 + 1,
+   .vdisplay = 800,
+   .vsync_start = 800 + 1,
+   .vsync_end = 800 + 1 + 21,
+   .vtotal = 800 + 1 + 21 + 1,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc hannstar_hsd070pww1 = {
+   .modes = _hsd070pww1_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 151,
+   .height = 94,
+   },
+};
+
 static const struct drm_display_mode innolux_n116bge_mode = {
.clock = 71000,
.hdisplay = 1366,
@@ -667,6 +690,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
}, {
+   .compatible = "hannstar,hsd070pww1",
+   .data = _hsd070pww1,
+   }, {
.compatible = "innolux,n116bge",
.data = _n116bge,
}, {
-- 
2.1.1

[PATCH v2 1/2] of: Add vendor prefix for HannStar Display Corporation

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Rebased onto v3.18-rc1
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..9863039 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -64,6 +64,7 @@ gmt   Global Mixed-mode Technology, Inc.
 google Google, Inc.
 gumstixGumstix, Inc.
 gw Gateworks Corporation
+hannstar   HannStar Display Corporation
 haoyu  Haoyu Microelectronic Co. Ltd.
 hisilicon  Hisilicon Limited.
 honeywell  Honeywell
-- 
2.1.1

[Bug 85311] radeon 0000:01:00.0: Max Payload Size 16384, but upstream 0000:00:01.0 set to 128; if necessary, use "pci=pcie_bus_safe" and report a bug

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(DRI - non Intel)  |PCI
   Assignee|drivers_video-dri at kernel-bu |drivers_pci at 
kernel-bugs.osd
   |gs.osdl.org |l.org

--- Comment #5 from Alan  ---
Moving to PCI

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 85351] 3.17-rc5 hangs on Supermicro X8DAH system

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
   Assignee|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk

--- Comment #7 from Alan  ---
Reproducable case seems to be using firefox to review/edit an object you've
uploaded to Shapeways. Another one is to load a fairly curved shape into
OpenScad and hit F5 to view then rotate it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[RFC 2/2] drm/exynos/dsi: Add runtime PM so LCD power domain could be turned off

[Krzysztof Kozlowski]

Add runtime Power Management to the Exynos DSI driver so the LCD power
domain could be turned off.

This slightly reduces the energy consumption when screen is completely
turned off. On Trats2 board when the system was idle the energy
consumption dropped by 1% (from 92.2 mA to 91.1 mA).

Before the patch:
$ cat cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
lcd0-power-domain   on
/devices/11c0.fimd  suspended
/devices/11c8.dsi   unsupported
After applying the patch:
lcd0-power-domain   off
/devices/11c0.fimd  suspended
/devices/11c8.dsi   suspended

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 24741d8758e8..19ed36d2d557 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -1356,6 +1357,8 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
if (dsi->state & DSIM_STATE_ENABLED)
return 0;

+   pm_runtime_get_sync(dsi->dev);
+
ret = exynos_dsi_poweron(dsi);
if (ret < 0)
return ret;
@@ -1392,6 +1395,8 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
drm_panel_unprepare(dsi->panel);
exynos_dsi_poweroff(dsi);

+   pm_runtime_put_sync(dsi->dev);
+
dsi->state &= ~DSIM_STATE_ENABLED;
 }

@@ -1772,6 +1777,8 @@ static int exynos_dsi_probe(struct platform_device *pdev)
if (ret)
goto err_del_component;

+   pm_runtime_enable(>dev);
+
return ret;

 err_del_component:
@@ -1781,6 +1788,8 @@ err_del_component:

 static int exynos_dsi_remove(struct platform_device *pdev)
 {
+   pm_runtime_disable(>dev);
+
component_del(>dev, _dsi_component_ops);
exynos_drm_component_del(>dev, EXYNOS_DEVICE_TYPE_CONNECTOR);

-- 
1.9.1

[RFC 1/2] PM / Domains: Power on domain early during system resume

[Krzysztof Kozlowski]

When resuming the system the power domain has to be powered on early so
any runtime PM aware devices could resume.

This fixes following scenario reproduced on Exynos DRM:
1. Power domain is off before suspending the system.
2. System is suspended to RAM.
3. Resuming starts. The Exynos DRM driver resume callback is called.
4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns
   the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
5. The Exynos DSI driver calls pm_runtime_get. The driver runtime
   resumes and this should turn LCD power domain on.
6. Unfortunately the domain cannot be turned on because system resume is
   in progress and genpd->prepared_count is positive.

Steps to reproduce:
1. Add runtime PM to Exynos DSI driver.
2. Build Exynos DRM/FB without FRAMEBUFFER_CONSOLE.
3. Enable the connector and screen (e.g. with modeset-vsync application).
4. echo 3 > /sys/devices/platform/exynos-drm/graphics/fb0/blank
5. echo mem > /sys/power/state
6. Resume.
[   77.712469] PM: early resume of devices complete after 3.854 msecs
[   77.712739] exynos-dsi 11c8.dsi: pm_genpd_resume()
[   77.712758] exynos4-fimc 1180.fimc: pm_genpd_resume()
[   77.712774] exynos4-fimc 1181.fimc: pm_genpd_resume()
[   77.712787] exynos-drm-fimc 1182.fimc: pm_genpd_resume()
[   77.712802] exynos-drm-fimc 1183.fimc: pm_genpd_resume()
[   77.712815] s5p-mipi-csis 1188.csis: pm_genpd_resume()
[   77.712829] s5p-mipi-csis 1189.csis: pm_genpd_resume()
[   77.712843] exynos-fimc-lite 1239.fimc-lite: pm_genpd_resume()
[   77.712856] exynos-fimc-lite 123a.fimc-lite: pm_genpd_resume()
[   77.713788] exynos4-fb 11c0.fimd: pm_genpd_resume()
[   77.713912] wake disabled for irq 184
[   77.713923] wake disabled for irq 185
[   77.714082] wake disabled for irq 173
[   77.715676] wake disabled for irq 176
[   77.718540] exynos4-fb 11c0.fimd: pm_genpd_runtime_resume()
[   77.718567] exynos4-fb 11c0.fimd: state restore latency exceeded, new 
value 1708 ns
[   77.718636] exynos-dsi 11c8.dsi: pm_genpd_runtime_resume()
[   77.892366] exynos-dsi 11c8.dsi: PLL failed to stabilize
[   77.892377] exynos-dsi 11c8.dsi: failed to configure DSI PLL
[   78.192168] exynos-dsi 11c8.dsi: timeout waiting for reset
[   78.211578] exynos-dsi 11c8.dsi: waiting for bus lanes timed out
[   78.307173] exynos-dsi 11c8.dsi: xfer timed out: d1 00 (null)
[   78.307190] panel_s6e8aa0 11c8.dsi.0: error -110 reading dcs seq(0xd1)
[   78.307199] panel_s6e8aa0 11c8.dsi.0: read id failed

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/base/power/domain.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 40bc2f4072cc..4fdfe404a04c 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -179,8 +179,7 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
*genpd)
}
finish_wait(>status_wait_queue, );

-   if (genpd->status == GPD_STATE_ACTIVE
-   || (genpd->prepared_count > 0 && genpd->suspend_power_off))
+   if (genpd->status == GPD_STATE_ACTIVE)
return 0;

if (genpd->status != GPD_STATE_POWER_OFF) {
-- 
1.9.1

[RFC 0/2] PM and DRM: Add runtime PM to Exynos DSI

[Krzysztof Kozlowski]

Hi,

The goal of the patch 2 is to add runtime PM to the Exynos DSI driver.
This allows LCD power domain to be turned off.

However after adding this patch an interesing issue came in. The DSI
driver could not runtime resume during sustem resume because power
domain was not allowed to power on.

The issue is solved by patch 1.

Tested on Trats2 board.

Comments are welcomed.

Best regards,
Krzysztof

Krzysztof Kozlowski (2):
  PM / Domains: Power on domain early during system resume
  drm/exynos/dsi: Add runtime PM so LCD power domain could be turned off

 drivers/base/power/domain.c | 3 +--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +
 2 files changed, 10 insertions(+), 2 deletions(-)

-- 
1.9.1

[Bug 84944] tearing on radeonsi vdpau deinterlacer

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

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

--- Comment #20 from warpme at o2.pl ---
(In reply to Michel D?nzer from comment #19)
> Created attachment 108289 [details] [review]
> Add some debugging output to DRI2CanFlip v2
> 
> This one will print even more debugging output about the DRI2CanFlip failure.

Pls find Xserver log with new patch:

[1031189.617] (--) RADEON(0): HDMI max TMDS frequency 17KHz
[1031203.006] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031203.006] Window clipList extents: (1, 1)-(1920, 1080)
[1031203.006] Root window extents: (0, 0)-(1920, 1080)
[1031203.006] Can\'t flip because DRI2CanFlip failed
[1031203.038] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031203.038] Window clipList extents: (1, 1)-(1920, 1080)
[1031203.038] Root window extents: (0, 0)-(1920, 1080)
[1031203.038] Can\'t flip because DRI2CanFlip failed
[1031226.655] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031226.655] Window clipList extents: (1, 1)-(1920, 1080)
[1031226.655] Root window extents: (0, 0)-(1920, 1080)
[1031226.655] Can\'t flip because DRI2CanFlip failed
[1031226.664] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031226.664] Window clipList extents: (1, 1)-(1920, 1080)
[1031226.664] Root window extents: (0, 0)-(1920, 1080)
[1031226.664] Can\'t flip because DRI2CanFlip failed
[1031226.710] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031226.710] Window clipList extents: (1, 1)-(1920, 1080)
[1031226.710] Root window extents: (0, 0)-(1920, 1080)
[1031226.710] Can\'t flip because DRI2CanFlip failed
[1031247.095] DRI2CanFlip: Window pixmap dimensions don\'t match window
dimensions
[1031247.095] Can\'t flip because DRI2CanFlip failed
[1031251.042] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.042] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.042] Root window extents: (0, 0)-(1920, 1080)
[1031251.042] Can\'t flip because DRI2CanFlip failed
[1031251.195] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.195] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.195] Root window extents: (0, 0)-(1920, 1080)
[1031251.195] Can\'t flip because DRI2CanFlip failed
[1031251.288] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.288] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.288] Root window extents: (0, 0)-(1920, 1080)
[1031251.288] Can\'t flip because DRI2CanFlip failed
[1031251.386] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.386] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.387] Root window extents: (0, 0)-(1920, 1080)
[1031251.387] Can\'t flip because DRI2CanFlip failed
[1031251.479] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.479] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.479] Root window extents: (0, 0)-(1920, 1080)
[1031251.480] Can\'t flip because DRI2CanFlip failed
[1031251.566] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.566] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.566] Root window extents: (0, 0)-(1920, 1080)
[1031251.566] Can\'t flip because DRI2CanFlip failed
[1031251.659] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.659] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.660] Root window extents: (0, 0)-(1920, 1080)
[1031251.660] Can\'t flip because DRI2CanFlip failed
[1031251.743] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.743] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.743] Root window extents: (0, 0)-(1920, 1080)
[1031251.743] Can\'t flip because DRI2CanFlip failed
[1031251.843] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.843] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.843] Root window extents: (0, 0)-(1920, 1080)
[1031251.843] Can\'t flip because DRI2CanFlip failed
[1031251.943] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031251.943] Window clipList extents: (0, 0)-(1920, 1078)
[1031251.943] Root window extents: (0, 0)-(1920, 1080)
[1031251.943] Can\'t flip because DRI2CanFlip failed
[1031252.040] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions:
[1031252.040] Window clipList extents: (0, 0)-(1920, 1078)
[1031252.040] Root window extents: (0, 0)-(1920, 1080)
[1031252.040] Can\'t flip because DRI2CanFlip 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/20141023/00f8666b/attachment.html>

[Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for VED

[Cheng, Yao]

CC David for notifying the patch update:

Add the missing v2 changelog:
Take David's comment: add mmap support, remove the MMAP_IOCTL and add 
MMAP_OFFSET_IOCTL
Take David's comment: remove postclose() and move code to preclose()
Take David's comment: set NULL to set_busid
Forgot to take David's comment (Sorry, will add it in v3 patch): 
Replace drm_platform_init/drm_put_dev with drm_dev_alloc, drm_dev_register, 
drm_dev_unregister and drm_dev_unref

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, October 22, 2014 16:51
> To: Cheng, Yao
> Cc: Daniel Vetter; intel-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org; Kelley, Sean V; Vetter, Daniel; Abel, Michael 
> J;
> Jiang, Fei; Rao, Ram R; David Herrmann
> Subject: Re: [Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for VED
> 
> On Wed, Oct 22, 2014 at 06:37:16AM +, Cheng, Yao wrote:
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of
> > > Daniel Vetter
> > > Sent: Tuesday, October 21, 2014 5:08 PM
> > > To: Cheng, Yao
> > > Cc: intel-gfx at lists.freedesktop.org;
> > > dri-devel at lists.freedesktop.org; Kelley, Sean V; Vetter, Daniel;
> > > Abel, Michael J; Jiang, Fei; Rao, Ram R
> > > Subject: Re: [Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for
> > > VED
> > >
> > > On Tue, Oct 21, 2014 at 02:36:42PM +0800, Yao Cheng wrote:
> > > > Probes VED and creates a new drm device for hardware accelerated
> > > > video decoding.
> > > > Currently support VP8 decoding on valleyview.
> > > >
> > > > Signed-off-by: Yao Cheng 
> > >
> > > The in-patch changelog here is missing, and there's also no
> > > indication in the cover letter for what changes you've made. On a
> > > quick look you've incorporated some of David's feedback, but not all
> > > of it. That's not good, since if you only partially apply review
> > > feedback then you essentially force reviewers to read the entire
> > > patch again, which is a good way to driver them away. Also you
> > > should Cc: (in the sob section of the patch) all the people who have
> commented on your patch already.
> >
> > Oops, sorry for not following the upstreaming rules :( I might have
> > overlooked some of David's comment..have to learn more about the
> > rules.  For this version, I'll add changelog by replying my patch with
> > cc to those commenters, I assume this is not too late
> >
> > >
> > > With that out of the way some high-level review:
> > > - I think we need the full libva implementation to review the interfaces
> > >   properly. At least the little libdrm test program doesn't seem to fully
> > >   exercise it all.
> >
> > The libva driver need some time to be fully open sourced, but I can
> > upload the code to Sean's private github repo for your access. I'll
> > sync with Sean and you internally.
> 
> It doesn't need to be the final libva driver of course, just something so that
> people can look at the userspace side. So upload to some github account is
> perfectly ok.
> 
> Or do you mean we still have legal review pending on those patches? In that
> case I think we need to wait for that to complete first.
> 
> > > - The ioctl structs need to be cleaned up. You can't use uint32_t and
> > >   similar typedefs since they can clash with userspace. You must use
> __u32
> > >   and friends. Also, some of the padding fields arent' really required -
> > >   if you only have 4byte types then you don't need to align to 8 bytes.
> > >
> > > - Input validation on ioctls looks spotty at best. E.g. if you have any
> > >   padding fields you need to check that they are 0, otherwise we can't
> > >   ever reuse them as flags fields. And on principle _all_ input fields
> > >   must be validated first.
> > >
> > >   For some good guidelines for ioctls see
> > >   http://blog.ffwll.ch/2013/11/botching-up-ioctls.html
> > >
> >
> > Thanks for pointing me to the ioctl instruction... I'll read it
> > carefully and update the ioctl interfaces...
> >
> > > - Locking seems to be inexistent in places, at least some of the idr
> > >   manipulation very much looks like it's done lock-free. That doesn't work
> > >   well.
> >
> > Yes, probably we haven't considered all the scenarios carefully, is it
> > possible to review them in an internal discussion?
> 
> Imo no need for private review since I didn't spot anything fundamentally
> wrong. It's just a lot of small details, and for those I think m-l review is 
> a good
> tool. But someone needs to do that, and I don't really have the time for it.
> 
> > > - You implement file-descriptor based fences, but then also have the
> more
> > >   gem-traditional wait ioctl working on buffer objects. That's a bit a
> > >   funky mix of implicit and explicit fencing. Furthermore adding new
> > >   private fence objects isn't a good idea now that everyon is talking
> > >   about 

[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO

[Tomi Valkeinen]

On 23/10/14 11:10, Daniel Vetter wrote:

> If we want to make BACKLIGHT_CLASS_DEVICE into a library thing then I
> guess we could do that, but we must then also drag it out of all the other
> meta options to make sure it's always available. No need I think to ditch

BACKLIGHT_CLASS_DEVICE only depends on HAS_IOMEM and
BACKLIGHT_LCD_SUPPORT so there are no other meta options to avoid.
HAS_IOMEM comes from drivers/video/Kconfig's "Graphics support", and I
guess we can ignore it.

> the entire BACKLIGHT_LCD_SUPPORT meta option. And then everyone could
> select it.

I don't quite understand what purpose does BACKLIGHT_LCD_SUPPORT serve.
It doesn't enable any code, it just opens up new Kconfig options. Why
can't the Kconfig options be always available? It's just another option
to 'select', without any reason I can see.

 Tomi


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

[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED

[Cheng, Yao]

Cc Jani for notifying the patch update:

Add missing v2 changelog:
Take Jani's comment: remove BUG_ON in i915_driver_load
Take Daniel's comment: extract the VED setup related functions to 
i915_ved.c
Take Daniel's comment: add kerneldoc to describe i915_ved.c
Take Daniel's comment: rename "ipvr-ved" to "ipvr-ved-vlv"
Take Daniel's comment: unregister platform device before 
irq_free_desc() when teardown VED.
Take Daniel's comment: update i-g-t to manually unload ipvr.ko before 
unloading i915.ko
Take Daniels' comment: add WARN_ON(!intel_irqs_enabled()) in VED 
irqchip initialization function.
Take Daniel's comment: remove the trace point for VED interrupt.

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Cheng, Yao
> Sent: Wednesday, October 22, 2014 15:09
> To: Ville Syrj?l?
> Cc: Rao, Ram R; intel-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org; Jiang, Fei; Abel, Michael J; Vetter, Daniel
> Subject: Re: [Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup
> bridge for VED
> 
> > -Original Message-
> > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> > Sent: Tuesday, October 21, 2014 6:30 PM
> > To: Cheng, Yao
> > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> > Kelley, Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram
> > R
> > Subject: Re: [Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c
> > to setup bridge for VED
> >
> > On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> > > Setup minimum required resources during i915_driver_load:
> > > 1. Create a platform device to share MMIO/IRQ resources 2. Make the
> > > platform device child of i915 device for runtime PM.
> > > 3. Create IRQ chip to forward the VED irqs.
> > > VED driver (a standalone drm driver) probes the VED device and
> > > creates a new dri card on install.
> > >
> > > Currently only supports VED on valleyview.
> > > Kerneldoc is updated for i915_ved.c.
> > >
> > > Signed-off-by: Yao Cheng 
> > > ---
> > >  Documentation/DocBook/drm.tmpl  |   5 +
> > >  drivers/gpu/drm/i915/Makefile   |   3 +
> > >  drivers/gpu/drm/i915/i915_dma.c |  11 ++
> > >  drivers/gpu/drm/i915/i915_drv.h |   9 ++
> > >  drivers/gpu/drm/i915/i915_irq.c |   2 +
> > >  drivers/gpu/drm/i915/i915_reg.h |   5 +
> > >  drivers/gpu/drm/i915/i915_ved.c | 264
> > > 
> > >  7 files changed, 299 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/i915/i915_ved.c
> > >
> > > diff --git a/Documentation/DocBook/drm.tmpl
> > > b/Documentation/DocBook/drm.tmpl index d7cfc98..f1787b4 100644
> > > --- a/Documentation/DocBook/drm.tmpl
> > > +++ b/Documentation/DocBook/drm.tmpl
> > > @@ -3806,6 +3806,11 @@ int num_ioctls;
> > > !Fdrivers/gpu/drm/i915/i915_irq.c
> > > intel_runtime_pm_disable_interrupts
> > >  !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
> > >
> > > +  
> > > +VED video core integration
> > > +!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
> > > +!Idrivers/gpu/drm/i915/i915_ved.c
> > > +  
> > >  
> > >  
> > >Display Hardware Handling diff --git
> > > a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index
> > > 3a6bce0..a4b9252 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -80,6 +80,9 @@ i915-y += dvo_ch7017.o \  i915-y += i915_dma.o \
> > > i915_ums.o
> > >
> > > +# VED for VLV
> > > +i915-y += i915_ved.o
> > > +
> > >  obj-$(CONFIG_DRM_I915)  += i915.o
> > >
> > >  CFLAGS_i915_trace_points.o := -I$(src) diff --git
> > > a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> > > index 85d14e1..47714e1 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -1791,6 +1791,13 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > >   if (IS_GEN5(dev))
> > >   intel_gpu_ips_init(dev_priv);
> > >
> > > + if (IS_VALLEYVIEW(dev)) {
> >
> > These must be (IS_VLV && !IS_CHV), or maybe define some HAS_VED()
> > macro to hide that.
> 
> Accepted. Will add HAS_VED() to hide this.
> 
> >
> > > + ret = vlv_setup_ved(dev);
> > > + if (ret < 0) {
> > > + DRM_ERROR("failed to setup VED bridge: %d\n", ret);
> > > + }
> > > + }
> > > +
> > >   intel_runtime_pm_enable(dev_priv);
> > >
> > >   return 0;
> > > @@ -1833,6 +1840,10 @@ int i915_driver_unload(struct drm_device
> *dev)
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > >   int ret;
> > >
> > > + if (IS_VALLEYVIEW(dev)) {
> > > + vlv_teardown_ved(dev);
> > > + }
> > > +
> > >   ret = i915_gem_suspend(dev);
> > >   if (ret) {
> > >   DRM_ERROR("failed to idle hardware: %d\n", ret); diff --git
> > > a/drivers/gpu/drm/i915/i915_drv.h 

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #176 from Jacob  ---
(In reply to Christian K?nig from comment #175)
> (In reply to Jacob from comment #174)
> > Considering the crash occurs within an hour or two on the last kernel, but
> > only occurs every few hours on 3.15, it makes you wonder if the two issues
> > are even related.
> > Nonetheless, I'll report the result from the bisection once I got it
> 
> Kernel 3.15 has some known VM issues which are only fixed in 3.16.
> Independent of that I think we indeed have multiple different issues that
> seems to be hard to distinct.
> 
> In general you can split the issues into two categories one is with VM
> faults in the logs and the other ones are without.

Seems the one I'm bisecting for now would be the one without then.
Whenever it crashes, I get nothing in the logs at all. Nothing in dmesg, in
xorg.log or in the kern.log. Nothing at all

-- 
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/20141023/e3dab445/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #175 from Christian K?nig  ---
(In reply to Jacob from comment #174)
> Considering the crash occurs within an hour or two on the last kernel, but
> only occurs every few hours on 3.15, it makes you wonder if the two issues
> are even related.
> Nonetheless, I'll report the result from the bisection once I got it

Kernel 3.15 has some known VM issues which are only fixed in 3.16. Independent
of that I think we indeed have multiple different issues that seems to be hard
to distinct.

In general you can split the issues into two categories one is with VM faults
in the logs and the other ones are without.

-- 
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/20141023/1b7465c8/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #174 from Jacob  ---
Considering the crash occurs within an hour or two on the last kernel, but only
occurs every few hours on 3.15, it makes you wonder if the two issues are even
related.
Nonetheless, I'll report the result from the bisection once I got 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/20141023/feab7d75/attachment.html>

[Bug 86191] [Radeon HD 6850 DPM Bug] Display Hangs On Boot

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
   Assignee|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/cirrus: bind also to qemu-xen-traditional

[Dave Airlie]

No idea why I kept missing this, I've applied it to -fixes now.

Dave.

On 22 October 2014 18:14, Olaf Hering  wrote:
> Ping?
>
> On Tue, Aug 26, Olaf Hering wrote:
>
>> Ping?
>>
>> On Thu, Jun 12, Olaf Hering wrote:
>>
>> > Ping?
>> >
>> > On Fri, Apr 11, Olaf Hering wrote:
>> >
>> > > qemu as used by xend/xm toolstack uses a different subvendor id.
>> > > Bind the drm driver also to this emulated card.
>> > >
>> > > Signed-off-by: Olaf Hering 
>> > > ---
>> > >  drivers/gpu/drm/cirrus/cirrus_drv.c | 2 ++
>> > >  1 file changed, 2 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
>> > > b/drivers/gpu/drm/cirrus/cirrus_drv.c
>> > > index 953fc8a..848 100644
>> > > --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
>> > > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
>> > > @@ -31,6 +31,8 @@ static struct drm_driver driver;
>> > >  static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
>> > >   { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
>> > > 0, 0 },
>> > > + { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, PCI_VENDOR_ID_XEN,
>> > > +   0x0001, 0, 0, 0 },
>> > >   {0,}
>> > >  };
>> > >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #11 from Renato  ---
(In reply to Alex Deucher from comment #8)
> Comment 5 specifically.

I agree that it is up to the desktop environment, but, as stated in comment 1
if the kernel reports two screen attached, systemd wont't suspend  because it
thinks there's still a display that's active.

Anyway, the issue is specifically the wrong number of connected displays
detected by the kernel.

Or I'm missing something?

Cheers.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 86431] ATI/AMD Radeon HD 8670A/8670M/8750M not initializing

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk,
   ||intel-gfx-bugs at lists.freede
   ||sktop.org
  Component|Video(DRI - non Intel)  |Video(DRI - Intel)
   Assignee|drivers_video-dri at kernel-bu |intel-gfx-bugs at 
lists.freede
   |gs.osdl.org |sktop.org

--- Comment #5 from Alan  ---
(moved to Intel side)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #10 from Garri  ---
Created attachment 154661
  --> https://bugzilla.kernel.org/attachment.cgi?id=154661=edit
dmesg_xorg_log.tgz

There are no problems when the hybrid graphics is disabled in BIOS.

# cat /sys/class/drm/card0-LVDS-1/status 
connected
# cat /sys/class/drm/card0-VGA-1/status 
disconnected
# cat /sys/class/drm/card0-HDMI-A-1/status 
disconnected

Reported information is correct. Suspend on LID close works fine. Kernel and
Xorg logs are attached.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/1] GPU-DRM-GMA500: Deletion of unnecessary checks before two function calls

[One Thousand Gnomes]

On Wed, 22 Oct 2014 18:48:21 +0200
SF Markus Elfring  wrote:

> >> If you are convinced that dropping the null tests is a good idea, then you 
> >> can submit the patch that makes the change to the relevant maintainers and 
> >> mailing lists.
> 
> Would you like to integrate the following proposal into your source code 
> repository?

What platforms have you tested the code on at this point ?

Alan

[PATCH] drm/panel: s6e8aa0: Update calls to gpiod_get*()

[Andrzej Hajda]

On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
> Add the new flags argument to calls of (devm_)gpiod_get*() and
> remove any direction setting code afterwards.
> 
> Currently both forms (with or without the flags argument)
> are valid thanks to transitional macros in
> . These macros will be removed once
> all consumers are updated and the flags argument will become
> compulsary.
> 
> Signed-off-by: Alexandre Courbot 

It needs patch "gpio: Fix gpio direction flags not getting set" to work
correctly. It is not yet present in drm-next. Beside this:

Acked-by: Andrzej Hajda 

--
Regards
Andrzej


> ---
>  drivers/gpu/drm/panel/panel-s6e8aa0.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
> b/drivers/gpu/drm/panel/panel-s6e8aa0.c
> index b5217fe37f02..6427aa187735 100644
> --- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
> +++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
> @@ -1019,17 +1019,12 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
>   return ret;
>   }
>  
> - ctx->reset_gpio = devm_gpiod_get(dev, "reset");
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
>   if (IS_ERR(ctx->reset_gpio)) {
>   dev_err(dev, "cannot get reset-gpios %ld\n",
>   PTR_ERR(ctx->reset_gpio));
>   return PTR_ERR(ctx->reset_gpio);
>   }
> - ret = gpiod_direction_output(ctx->reset_gpio, 1);
> - if (ret < 0) {
> - dev_err(dev, "cannot configure reset-gpios %d\n", ret);
> - return ret;
> - }
>  
>   ctx->brightness = GAMMA_LEVEL_NUM - 1;
>  
> 

[PATCH] drm/panel: ld9040: Update calls to gpiod_get*()

[Andrzej Hajda]

On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
> Add the new flags argument to calls of (devm_)gpiod_get*() and
> remove any direction setting code afterwards.
> 
> Currently both forms (with or without the flags argument)
> are valid thanks to transitional macros in
> . These macros will be removed once
> all consumers are updated and the flags argument will become
> compulsary.
> 
> Signed-off-by: Alexandre Courbot 

It needs patch "gpio: Fix gpio direction flags not getting set" to work
correctly. It is not yet present in drm-next. Beside this:

Acked-by: Andrzej Hajda 

--
Regards
Andrzej

> ---
>  drivers/gpu/drm/panel/panel-ld9040.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
> b/drivers/gpu/drm/panel/panel-ld9040.c
> index 42ac67b21e9f..dd1d3f2e624e 100644
> --- a/drivers/gpu/drm/panel/panel-ld9040.c
> +++ b/drivers/gpu/drm/panel/panel-ld9040.c
> @@ -336,17 +336,12 @@ static int ld9040_probe(struct spi_device *spi)
>   if (ret < 0)
>   return ret;
>  
> - ctx->reset_gpio = devm_gpiod_get(dev, "reset");
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
>   if (IS_ERR(ctx->reset_gpio)) {
>   dev_err(dev, "cannot get reset-gpios %ld\n",
>   PTR_ERR(ctx->reset_gpio));
>   return PTR_ERR(ctx->reset_gpio);
>   }
> - ret = gpiod_direction_output(ctx->reset_gpio, 1);
> - if (ret < 0) {
> - dev_err(dev, "cannot configure reset-gpios %d\n", ret);
> - return ret;
> - }
>  
>   spi->bits_per_word = 9;
>   ret = spi_setup(spi);
> 

[RFC PATCH] drm/exynos: Add DECON driver

[Inki Dae]

On 2014? 10? 23? 01:34, Ajay kumar wrote:
> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae  wrote:
>>
>> Thanks for contribution.
>>
>> It seems reasonable that you separate device drivers into FIMD and DECON
>> because many registers of them have many different offsets and fields.
>> However, there may be a good solution that we can combine common sets of
>> these drivers later.
> Yes, this is the main reason behind sending this as RFC patch.
> I want to know what's the best way to do this.
> FIMD, 5433 DECON and Exynos7 DECON - all are different.
> Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer).
> So, even I am not sure how the driver layouts should be!
> 
>> Below are my comments.
>>
>> Thanks,
>> Inki Dae
>>
>> On 2014? 10? 10? 21:48, Ajay Kumar wrote:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> DECON(Display and Enhancement Controller) is the new IP
>>> in exynos7 SOC for generating video signals using pixel data.
>>
>> DECON was used since Exynos5430. And is Exynos5433 different from
>> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review?
> Yes, Exynos5433 DECON is very much different than Exynos7 DECON.
> I will see how manual can be arranged.
> 

Sorry but I couldn't continue to review without Exynos7 user manual. I
hope that I could get it ASAP.

>>>
>>> DECON driver can be used to drive 2 different interfaces on Exynos7:
>>> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>>>
>>> The existing FIMD driver code was used as a template to create
>>> DECON driver. Only DECON-INT is supported as of now, and
>>> DECON-EXT support will be added later.
>>>
>>> Signed-off-by: Akshu Agrawal 
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/exynos-decon.txt |   68 ++
>>>  drivers/gpu/drm/exynos/Kconfig |   11 +-
>>>  drivers/gpu/drm/exynos/Makefile|1 +
>>>  drivers/gpu/drm/exynos/exynos_drm_decon.c  | 1086
>> 
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   17 +-
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 +
>>>  include/video/samsung_decon.h  |  346 +++
>>>  7 files changed, 1537 insertions(+), 3 deletions(-)
>>>  create mode 100644
>> Documentation/devicetree/bindings/video/exynos-decon.txt
>>>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
>>>  create mode 100644 include/video/samsung_decon.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
>> b/Documentation/devicetree/bindings/video/exynos-decon.txt
>>> new file mode 100644
>>> index 000..e865650
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
>>> @@ -0,0 +1,68 @@
>>> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
>>> +
>>> +DECON (Display and Enhancement Controller) is the Display Controller
>> for the
>>> +Exynos7 series of SoCs which transfers the image data from a video memory
>>> +buffer to an external LCD interface.
>>> +
>>> +Required properties:
>>> +- compatible: value should be "samsung,exynos7-decon";
>>
>> If exynos5433 was just renamed to exynos7 then, it should be one of the
>> following:
>> (a) "samsung,exynos5430-decon" for Display and enhancement controller
>> IP for Exynos5430
>> (b) "samsung,exynos7" for Display and enhancement controller IP for 
>> Exynos7
>>
>> Or,
>> (a) "samsung,exynos5430-decon" for Display and enhancement controller
>> IP for Exynos5430
>>
>> (b) "samsung,exynos5433-decon" for Display and enhancement controller
>> IP for Exynos5433
>> (c) "samsung,exynos7" for Display and enhancement controller IP for 
>> Exynos7
> Eventually, we will end up here.
> 
>>
>>> +
>>> +- reg: physical base address and length of the DECON registers set.
>>> +
>>> +- interrupt-parent: should be the phandle of the decon controller's
>>> + parent interrupt controller.
>>> +
>>> +- interrupts: should contain a list of all DECON IP block interrupts
>> in the
>>> +  order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
>>> +  format depends on the interrupt controller used.
>>> +
>>> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
>>> + "lcd_sys", in the same order as they were listed in the interrupts
>>> +property.
>>> +
>>> +- pinctrl-0: pin control group to be used for this controller.
>>> +
>>> +- pinctrl-names: must contain a "default" entry.
>>> +
>>> +- clocks: must include clock specifiers corresponding to entries in the
>>> + clock-names property.
>>> +
>>> +- clock-names: list of clock names sorted in the same order as the clocks
>>> +   property. Must contain "pclk_decon0", "aclk_decon0",
>>> +"decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0",
>>> +

[Mesa-dev] [r600g] Is LLVM-compiler (--enable-r600-llvm-compiler) usable, now?

[Michel Dänzer]

On 23.10.2014 02:24, Alex Deucher wrote:
> On Wed, Oct 22, 2014 at 12:49 PM, Dieter N?tzel  
> wrote:
>>
>> subject say it all ;-)
>
> The llvm support for r600g is for compute (OpenCL).  The fact that is
> it somewhat usable for graphics is mainly for testing purposes.  There
> are no plans to expand it to handle additional graphics features,
> although any interested parties are welcome to contribute to improving
> it.  IIRC, even when you enable it, it currently only gets applied to
> compute shaders.

The LLVM compiler is used automatically for OpenCL, even without 
--enable-r600-llvm-compiler. That option allows using LLVM for graphics 
as well, but it's currently disabled by default at runtime, the user 
needs to explicitly enable it via the environment variable 
R600_DEBUG=llvm or R600_LLVM=1. Due to the limitations of that (no 
geometry shader support and other missing functionality, lots of bugs), 
I'd currently recommend against enabling it unless you want to work on 
fixing its problems.


>> Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your
>> latest work, but I think about what we could get if we find the right commit
>> between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 3.17-next).
>>
>> I do not have 3.16.x around (it is not any longer in the openSUSE kernel
>> current tree) but with latest 3.16.4 I was faster then with all 3.17.x and
>> 3.18/3.19-next kernels.

Faster doing what?


>> WC helped on RV730 (AGP) with some apps, here:

What exactly do you mean by 'WC helped'? CPU mappings of GTT have always 
used write-combining with AGP, so unless you disable AGP, the changes 
related to that shouldn't change anything.


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

[PATCH] drm/radeon: fix vm lock in radeon_gem_va_update_vm

[Christian König]

From: Christian K?nig 

Without the lock we might corrupt the BO lists.

Might be squashed into "update the VM after setting BO address" for upstreaming.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 0002575..49d56b5 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -559,12 +559,16 @@ static void radeon_gem_va_update_vm(struct radeon_device 
*rdev,
goto error_unreserve;
}

+   mutex_lock(_va->vm->mutex);
r = radeon_vm_clear_freed(rdev, bo_va->vm);
if (r)
-   goto error_unreserve;
+   goto error_unlock;

r = radeon_vm_bo_update(rdev, bo_va, _va->bo->tbo.mem);

+error_unlock:
+   mutex_unlock(_va->vm->mutex);
+
 error_unreserve:
ttm_eu_backoff_reservation(, );

-- 
1.9.1

[PATCH v8 0/2] ASoC: tda998x: add a codec to the HDMI transmitter

[Jean-Francois Moine]

The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link
from 2 different sources, I2S and S/PDIF.

This patch set first adds an interface between a HDMI transmitter and
the HDMI CODEC.

The interface is then used by the TDA998x driver to describe its audio
capabilities (DAIs), to give the audio constraints of the HDMI
device (EDID) to the audio subsystem, and to connect the chosen audio
source to the HDMI link.

v8:
- change some comments about the patches
v7:
- remove the change of the K predivider (Jyri Sarha)
- add S24_3LE and S32_LE as possible audio formats (Jyri Sarha)
- don't move the struct priv2 definition and use the
  slave encoder private data as the device private data
  (Russell King)
- remove the useless request_module (Russell King/Mark Brown)
- don't lock the HDMI module (Russell King)
- use platform_device_unregister to remove the codec
  (Russell King)
v6:
- extend the HDMI CODEC instead of using a specific CODEC
v5:
- use the TDA998x private data instead of a specific area
  for the CODEC interface
- the CODEC is TDA998x specific (Mark Brown)
v4:
- remove all the TDA998x specific stuff from the CODEC
- move the EDID scan from the CODEC to the TDA998x
- move the CODEC to sound/soc (Mark Brown)
- update the audio_sample_rate from the EDID (Andrew Jackson)
v3: fix bad rate (Andrew Jackson)
v2: check double stream start (Mark Brown)

Jean-Francois Moine (2):
  ASoC: hdmi: Add a transmitter interface to the HDMI CODEC
  drm/i2c: tda998x: Use the HDMI audio CODEC interface

 .../devicetree/bindings/drm/i2c/tda998x.txt|  18 ++
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 264 -
 include/sound/hdmi.h   |  20 ++
 sound/soc/codecs/hdmi.c| 176 +-
 5 files changed, 460 insertions(+), 19 deletions(-)
 create mode 100644 include/sound/hdmi.h

-- 
2.1.1

[PATCH v8 2/2] drm/i2c: tda998x: Use the HDMI audio CODEC interface

[Jean-Francois Moine]

This patch adds the necessary functions to interface the HDMI audio CODEC.

Signed-off-by: Jean-Francois Moine 
---
 .../devicetree/bindings/drm/i2c/tda998x.txt|  18 ++
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 264 -
 3 files changed, 270 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e9e4bce..e50e7cd 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -17,6 +17,20 @@ Optional properties:
   - video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>

+  - audio-ports: must contain one or two values selecting the source
+   in the audio port.
+   The source type is given by the corresponding entry in
+   the audio-port-names property.
+
+  - audio-port-names: must contain entries matching the entries in
+   the audio-ports property.
+   Each value may be "i2s" or "spdif", giving the type of
+   the audio source.
+
+  - #sound-dai-cells: must be set to <1> for use with the simple-card.
+   The TDA998x audio CODEC always defines two DAIs.
+   The DAI 0 is the S/PDIF input and the DAI 1 is the I2S input.
+
 Example:

tda998x: hdmi-encoder {
@@ -26,4 +40,8 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <_camera>;
pinctrl-names = "default";
+
+   audio-ports = <0x04>, <0x03>;
+   audio-port-names = "spdif", "i2s";
+   #sound-dai-cells = <1>;
};
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 4d341db..42ca744 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -22,6 +22,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select SND_SOC_HDMI_CODEC
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d476279..e558e1e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,12 +20,14 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
 #include 
 #include 
 #include 
+#include 

 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)

@@ -44,6 +46,16 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+   /* audio variables */
+   struct platform_device *pdev_codec;
+   u8 audio_ports[2];
+
+   u8 max_channels;/* EDID parameters */
+   u8 rate_mask;
+   u8 fmt;
+
+   int audio_sample_format;
 };

 #define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
@@ -624,6 +636,8 @@ tda998x_write_avi(struct tda998x_priv *priv, struct 
drm_display_mode *mode)
 sizeof(buf));
 }

+/* audio functions */
+
 static void tda998x_audio_mute(struct tda998x_priv *priv, bool on)
 {
if (on) {
@@ -639,12 +653,11 @@ static void
 tda998x_configure_audio(struct tda998x_priv *priv,
struct drm_display_mode *mode, struct tda998x_encoder_params *p)
 {
-   uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv;
+   uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv, aclk;
uint32_t n;

/* Enable audio ports */
reg_write(priv, REG_ENA_AP, p->audio_cfg);
-   reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);

/* Set audio input source */
switch (p->audio_format) {
@@ -653,6 +666,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
clksel_aip = AIP_CLKSEL_AIP_SPDIF;
clksel_fs = AIP_CLKSEL_FS_FS64SPDIF;
cts_n = CTS_N_M(3) | CTS_N_K(3);
+   aclk = 0;   /* no clock */
break;

case AFMT_I2S:
@@ -660,6 +674,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
cts_n = CTS_N_M(3) | CTS_N_K(3);
+   aclk = 1;   /* clock enable */
break;

default:
@@ -671,6 +686,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT |
AIP_CNTRL_0_ACR_MAN);   /* auto CTS */
reg_write(priv, REG_CTS_N, cts_n);
+   reg_write(priv, REG_ENA_ACLK, aclk);

/*
 * Audio input somehow depends on HDMI line rate which is
@@ -727,6 +743,137 @@ tda998x_configure_audio(struct tda998x_priv 

[PATCH] gpu: drm: Fix warning caused by a parameter description in drm_crtc.c

[Daniel Vetter]

On Thu, Oct 23, 2014 at 09:06:28AM +0900, Masanari Iida wrote:
> This patch fix following error while "make xmldocs"
> 
> Warning(.//drivers/gpu/drm/drm_crtc.c:778): Excess function parameter
>  'mode' description in 'drm_connector_get_cmdline_mode'
> 
> Signed-off-by: Masanari Iida 

Thanks, picked up for my simple drm core patches queue.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e79c8d3..171f9a5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -766,7 +766,6 @@ static void drm_mode_remove(struct drm_connector 
> *connector,
>  /**
>   * drm_connector_get_cmdline_mode - reads the user's cmdline mode
>   * @connector: connector to quwery
> - * @mode: returned mode
>   *
>   * The kernel supports per-connector configration of its consoles through
>   * use of the video= parameter. This function parses that option and
> -- 
> 2.1.2.451.g98349e5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO

[Daniel Vetter]

On Wed, Oct 22, 2014 at 11:02:26AM +0300, Tomi Valkeinen wrote:
> On 18/10/14 00:13, Jani Nikula wrote:
> > Documentation/kbuild/kconfig-language.txt warns to use select with care,
> > and in general use select only for non-visible symbols and for symbols
> > with no dependencies, because select will force a symbol to a value
> > without visiting the dependencies.
> > 
> > Select has become particularly problematic, interdependently, with the
> > BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example:
> > 
> > scripts/kconfig/conf --randconfig Kconfig
> > KCONFIG_SEED=0x48312B00
> > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 &&
> > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY
> > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI &&
> > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
> > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
> > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 &&
> > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY
> > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI &&
> > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
> > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
> > 
> > With tristates it's possible to end up selecting FOO=y depending on
> > BAR=m in the config, which gets discovered at build time, not config
> > time, like reported in the thread referenced below.
> > 
> > Do the following to fix the dependencies:
> > 
> > * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop
> >   select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of
> >   BACKLIGHT_CLASS_DEVICE.
> > 
> > * Remove config FB_BACKLIGHT altogether, and replace it with a
> >   dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting
> >   FB_BACKLIGHT select or depend on FB anyway, so we can simplify.
> > 
> > * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of
> >   selecting ACPI_VIDEO and a number of its dependencies if ACPI is
> >   enabled. This is tied to backlight, as ACPI_VIDEO depends on
> >   BACKLIGHT_CLASS_DEVICE.
> > 
> > * Replace a couple of select INPUT/VT with depends as it seemed to be
> >   necessary.
> 
> While doing 'depends on' instead of 'select' is an "easy" fix for this,
> I do dislike it quite a bit. It's a major pain to go around the kernel
> config, trying to find all the dependencies that a particular driver
> wants. If I need fb-foobar, I should just be able to enable it, instead
> of first searching and selecting its minor dependencies individually.
> 
> So, not a NACK, but a "isn't there an another way to fix this?".
> 
> Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta"
> option, it only enables a Kconfig submenu.
> 
> So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option.
> But if we do that, all the items in drivers/video/backlight/Kconfig with
> default 'y' or 'm' would get enabled by default, so I think we should
> remove the 'default's from that file. That makes sense in any case, as I
> don't see why "HP Jornada 700 series LCD Driver" should be "default y".
> 
> BACKLIGHT_CLASS_DEVICE doesn't depend on anything except
> BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should
> be safe to 'select' BACKLIGHT_CLASS_DEVICE.
> 
> BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in
> drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE
> could be made to select BACKLIGHT_CLASS_DEVICE instead.
> 
> That doesn't exactly fix anything, but I think it makes sense as
> BACKLIGHT_CLASS_DEVICE is something that's selected from all around the
> kernel, so it should be a selectable "library" instead of a Kconfig menu
> option.
> 
> I didn't look at the ACPI_VIDEO side, so no idea how messy that is.

If we want to make BACKLIGHT_CLASS_DEVICE into a library thing then I
guess we could do that, but we must then also drag it out of all the other
meta options to make sure it's always available. No need I think to ditch
the entire BACKLIGHT_LCD_SUPPORT meta option. And then everyone could
select it.

The problem is if you mix depends and select Kconfig falls over and starts
to see loops where there are none. So you really can't ever mix them for
the same symbol.

I think if we get the BACKLIGHT_CLASS_DEVICE out of the picture with that
ACPI_VIDEO should be fixable with some

select ACPI_VIDEO if ACPI

or so. Currently that doesn't work because of the backlight class knob and
select being broken.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 81576] GPU lock-ups while playing XCOM Enemy Unknown

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

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

Kamil P?ral  changed:

   What|Removed |Added

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

-- 
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/20141023/b840f1b5/attachment.html>

[Bug 85334] display freeze while playing XCOM: GPU lockup (waiting for 0x00000000000aa7a6 last fence id 0x00000000000aa7a0 on ring 0)

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

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

Kamil P?ral  changed:

   What|Removed |Added

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

-- 
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/20141023/bbd8ce4b/attachment-0001.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

Kamil P?ral  changed:

   What|Removed |Added

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

-- 
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/20141023/50bfc3d9/attachment.html>

tile property contents

[Daniel Vetter]

On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote:
> On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger  wrote:
> > > I assume the TILE property described below would be per-connector?
> > >
> > > It looks like this would handle the DP MST tiled display case.
> > >
> > > At the risk of trying to solve too much at once:
> > >
> > > There are also configurations where users configure multiple heads to
> > > drive power walls that they want to be treated as one logical monitor,
> > > similar to the DP MST tiled display case.  Normally, those powerwall
> > > configurations don't have any layout information from the monitors
> > > themselves, and the layout is configured by the user.
> > >
> > > Would it be appropriate for users to be able to set the TILE property
> > > in that sort of scenario?
> > >
> > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
> > > should be expressed in pixels rather than tiles?  Sometimes, the tiles
> > > in those powerwalls may not all have the same resolution, or may be
> > > configured with overlap.  I suppose that would make the TILE configuration
> > > specific to the current modetimings on each tile...
> > 
> > Why can't users just set that mode?
> 
> Sure, users can set the mode, but:
> 
> * Part of what the TILE property conveys is how monitors should be grouped
>   for purposes of window maximization.  Users don't have a great way to
>   express that today, that I'm aware of.

My understanding for why we want the TILE property is to avoid to
duplicate displayId parsing over every bit of userspace (and the fbcon
stuff in the kernel) interested in it. Imo the proper way for userspace is
to always just inherit whatever modeset config is already there.

> * Users might configure the mode they want, but then gnome-settings-daemon
>   may come along later and decide it knows better than the user how things
>   should be configured.  One scenario where this comes up is:
> (a) user meticulously configures his power wall
> (b) user hotplugs another monitor
>   I've definitely seen cases where window managers will try to be clever
>   in response to a hotplug, and clobber the user's current configuration.
>   If the TILE property conveyed how some set of monitors was supposed
>   to be grouped, that would hopefully give window managers additional
>   information, such that they would know to keep that group intact.

Well, imnsho gnome display control center is a bit too opiniated about
automatic modeset changes. If their assumption is that they always know
perfectly what the user wants upon hotplug I really don't want to work
around this in the kernel. Since for everything else than a laptop +
beamer gnome panel always pisses me off ;-)

I think gnome should just ask the user what it wants if there's more than
2 physical displays (treating a tiled 4k screen as one ofc), since there's
really no way at all to tell.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/dp-helper: Move the legacy helpers to gma500

[Daniel Vetter]

On Wed, Oct 22, 2014 at 5:34 PM, Alan Cox  wrote:
> On Wed, 22 Oct 2014 16:32:52 +0200
> Patrik Jakobsson  wrote:
>
>> On Wed, Oct 22, 2014 at 11:16 AM, Daniel Vetter  
>> wrote:
>> > Except for gma500 all drivers are converted to the new style helpers,
>> > which have much better abstraction of the underlying hw protocols and
>> > already much more helper functions (including the entire mst library)
>> > on top of them. Since no one seems to work on converting gma500 let's
>> > just move the code away so that new drivers don't end up accidentally
>> > using this.
>>
>> Thanks for doing this! I'll CC Alan as well.
>
> Reviewed-by: Alan Cox 
>
> Please consider adding an __deprecated marker to one of the top functions
> so it irritates me or someone else into cleaning it up properly

Done. Also added a short FIXME comment so that you don't have to check
with git blame why this is deprecated. And I dropped the EXPORT_SYMBOL
which is no longer needed, too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

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

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

--- Comment #13 from Vitaliy Filippov  ---
It seems that the StructurizeCFG branch-on-constant bug not only crashes R600,
but actually generates invalid code!

It's clearly seen that in the IR code from comment 11 (structurizecfg output of
comment 10) (j > 50) comparison is contained in block %14, so it must be
reachable. But it's unreachable because the only branch there is that constant
branch instruction from %25 that always avoids %14...

-- 
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/20141023/510405d5/attachment.html>

[PATCH v8 1/2] ASoC: hdmi: Add a transmitter interface to the HDMI CODEC

[Jean-Francois Moine]

Audio in HDMI asks for:
- the audio constraints of the HDMI device to be known when choosing
  the audio routes in the audio subsystem, and
- the HDMI transmitter to know which of its audio inputs has been
  chosen when audio streaming starts.

This patch adds the interface between a HDMI transmitter and the
HDMI CODEC.

At startup time, the HDMI transmitter device creates the HDMI device as
a child device giving a description of its DAIs and 2 callback functions,
these functions realizing the HDMI audio requirements.

Signed-off-by: Jean-Francois Moine 
---
 include/sound/hdmi.h|  20 ++
 sound/soc/codecs/hdmi.c | 176 ++--
 2 files changed, 190 insertions(+), 6 deletions(-)
 create mode 100644 include/sound/hdmi.h

diff --git a/include/sound/hdmi.h b/include/sound/hdmi.h
new file mode 100644
index 000..49062c7
--- /dev/null
+++ b/include/sound/hdmi.h
@@ -0,0 +1,20 @@
+#ifndef SND_HDMI_H
+#define SND_HDMI_H
+
+#include 
+
+/* platform_data */
+struct hdmi_data {
+   int (*get_audio)(struct device *dev,
+int *max_channels,
+int *rate_mask,
+int *fmt);
+   void (*audio_switch)(struct device *dev,
+int port_index,
+unsigned sample_rate,
+int sample_format);
+   int ndais;
+   struct snd_soc_dai_driver *dais;
+   struct snd_soc_codec_driver *driver;
+};
+#endif
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 1391ad5..f66f1f6 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -22,9 +22,148 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #define DRV_NAME "hdmi-audio-codec"

+struct hdmi_priv {
+   struct hdmi_data hdmi_data;
+   struct snd_pcm_hw_constraint_list rate_constraints;
+};
+
+static int hdmi_dev_match(struct device *dev, void *data)
+{
+   return !strcmp(dev_name(dev), (char *) data);
+}
+
+/* get the codec device */
+static struct device *hdmi_get_cdev(struct device *dev)
+{
+   struct device *cdev;
+
+   cdev = device_find_child(dev,
+DRV_NAME,
+hdmi_dev_match);
+   if (!cdev)
+   dev_err(dev, "Cannot get codec device");
+   else
+   put_device(cdev);
+   return cdev;
+}
+
+static int hdmi_startup(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct device *cdev;
+   struct hdmi_priv *priv;
+   struct snd_pcm_hw_constraint_list *rate_constraints;
+   int ret, max_channels, rate_mask, fmt;
+   u64 formats;
+   static const u32 hdmi_rates[] = {
+   32000, 44100, 48000, 88200, 96000, 176400, 192000
+   };
+
+   cdev = hdmi_get_cdev(dai->dev);
+   if (!cdev)
+   return -ENODEV;
+   priv = dev_get_drvdata(cdev);
+
+   /* get the EDID values and the rate constraints buffer */
+   ret = priv->hdmi_data.get_audio(dai->dev,
+   _channels, _mask, );
+   if (ret < 0)
+   return ret; /* no screen */
+
+   /* convert the EDID values to audio constraints */
+   rate_constraints = >rate_constraints;
+   rate_constraints->list = hdmi_rates;
+   rate_constraints->count = ARRAY_SIZE(hdmi_rates);
+   rate_constraints->mask = rate_mask;
+   snd_pcm_hw_constraint_list(runtime, 0,
+  SNDRV_PCM_HW_PARAM_RATE,
+  rate_constraints);
+
+   formats = 0;
+   if (fmt & 1)
+   formats |= SNDRV_PCM_FMTBIT_S16_LE;
+   if (fmt & 2)
+   formats |= SNDRV_PCM_FMTBIT_S20_3LE;
+   if (fmt & 4)
+   formats |= SNDRV_PCM_FMTBIT_S24_LE |
+  SNDRV_PCM_FMTBIT_S24_3LE |
+  SNDRV_PCM_FMTBIT_S32_LE;
+   snd_pcm_hw_constraint_mask64(runtime,
+   SNDRV_PCM_HW_PARAM_FORMAT,
+   formats);
+
+   snd_pcm_hw_constraint_minmax(runtime,
+   SNDRV_PCM_HW_PARAM_CHANNELS,
+   1, max_channels);
+   return 0;
+}
+
+static int hdmi_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+   struct device *cdev;
+   struct hdmi_priv *priv;
+
+   cdev = hdmi_get_cdev(dai->dev);
+   if (!cdev)
+   return -ENODEV;
+   priv = dev_get_drvdata(cdev);
+
+   priv->hdmi_data.audio_switch(dai->dev, dai->id,
+params_rate(params),
+params_format(params));
+   return 0;
+}
+
+static void 

[PATCH] gpu: drm: Fix warning caused by a parameter description in drm_crtc.c

[Masanari Iida]

This patch fix following error while "make xmldocs"

Warning(.//drivers/gpu/drm/drm_crtc.c:778): Excess function parameter
 'mode' description in 'drm_connector_get_cmdline_mode'

Signed-off-by: Masanari Iida 
---
 drivers/gpu/drm/drm_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..171f9a5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -766,7 +766,6 @@ static void drm_mode_remove(struct drm_connector *connector,
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
- * @mode: returned mode
  *
  * The kernel supports per-connector configration of its consoles through
  * use of the video= parameter. This function parses that option and
-- 
2.1.2.451.g98349e5

[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task

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

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

--- Comment #7 from Andy Furniss  ---
(In reply to Christian K?nig from comment #6)
> (In reply to Andy Furniss from comment #5)
> > I don't know about Elemental as it's far harder to trigger, but first try
> > with valley produced -
> > 
> > [  156.617954] radeon :01:00.0: GPU fault detected: 146 0x02e83504
> > [  156.617960] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
> > 0x00010F17
> > [  156.617961] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
> > 0x08035004
> > [  156.617963] VM fault (0x04, vmid 4) at page 69399, read from VGT (53)
> 
> Sounds like a different problem triggered by the same patchset to me.
> 
> But first things first, is the original issue with the list corruption
> fixed? If yes we can start to look into this one as well.

It's OK so far, but then I need more time as I don't really know how to trigger
it and last time I called it as OK (in another bug) it wasn't.

-- 
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/20141023/fe00179d/attachment.html>

[Bug 85204] [Radeon HD 5650] return from sleep state failed

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

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

--- Comment #8 from Michel D?nzer  ---
I don't think you've actually finished the bisection yet. When it's finished,
running bisect good/bad will say 'xyz is the first bad commit' followed by the
log of commit xyz. When that happens, please provide that output.

-- 
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/20141023/04fc6404/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

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

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

Michel D?nzer  changed:

   What|Removed |Added

 Attachment #108267|0   |1
is obsolete||

--- Comment #19 from Michel D?nzer  ---
Created attachment 108289
  --> https://bugs.freedesktop.org/attachment.cgi?id=108289=edit
Add some debugging output to DRI2CanFlip v2

This one will print even more debugging output about the DRI2CanFlip failure.

-- 
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/20141023/e78e0d51/attachment.html>

[Bug 85320] [RV630] GPU hangs using UVD hardware acceleration

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

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

--- Comment #11 from Christian K?nig  ---
You need the bleeding edge Mesa code to get video accerleration working on
HD2600.

But even then the hardware on the HD2600 is so buggy that it is really tricky
to get this working right.

-- 
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/20141023/7c2becad/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

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

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

--- Comment #18 from warpme at o2.pl ---
(In reply to Michel D?nzer from comment #17)
> Created attachment 108267 [details] [review]
> Add some debugging output to DRI2CanFlip
> 
> Can you rebuild xserver with this patch and get the debugging output from
> that as well?
> 
> BTW, we only really need to see each debugging message once. If you want to
> provide all of them or even the whole log file, please create an attachment
> instead of pasting it in a comment.

Pls find xserver output with patch:


[1007456.173] (--) RADEON(0): HDMI max TMDS frequency 17KHz
[1007469.503] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007469.503] Can\'t flip because DRI2CanFlip failed
[1007469.634] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007469.634] Can\'t flip because DRI2CanFlip failed
[1007493.253] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007493.253] Can\'t flip because DRI2CanFlip failed
[1007493.313] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007493.313] Can\'t flip because DRI2CanFlip failed
[1007499.269] DRI2CanFlip: Window pixmap dimensions dosn\'t match window
dimensions
[1007499.269] Can\'t flip because DRI2CanFlip failed
[1007505.997] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007505.997] Can\'t flip because DRI2CanFlip failed
[1007506.012] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007506.012] Can\'t flip because DRI2CanFlip failed
[1007506.125] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007506.125] Can\'t flip because DRI2CanFlip failed
[1007506.152] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions
[1007506.152] Can\'t flip because DRI2CanFlip failed
[1007506.207] DRI2CanFlip: Window clipList doesn\'t match root window
dimensions

-- 
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/20141023/9c58bbf9/attachment.html>

[Bug 85204] [Radeon HD 5650] return from sleep state failed

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

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

--- Comment #7 from Rafael Pereira  ---
Terrebly sorry, I did the oposite. This is the bisect result:


git bisect log
# bad: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
# good: [acfaf47549491e5f804d30855c9055ebeb6ecc7b] Linux 3.16.6
git bisect start 'v3.17' 'v3.16.6'
# good: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16
git bisect good 19583ca584d6f574384e17fe7613dfaeadcdc4a6
# good: [f2d7e4d4398092d14fb039cb4d38e502d3f019ee] checkpatch: add
fix_insert_line and fix_delete_line helpers
git bisect good f2d7e4d4398092d14fb039cb4d38e502d3f019ee
# bad: [c309bfa9b481e7dbd3e1ab819271bf3009f44859] Merge tag
'for-linus-20140808' of git://git.infradead.org/linux-mtd
git bisect bad c309bfa9b481e7dbd3e1ab819271bf3009f44859

So the last GOOD commit was this one: 

git describe --contains f2d7e4d4398092d14fb039cb4d38e502d3f019ee
v3.17-rc1~94^2~11

-- 
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/20141023/604042b9/attachment.html>

[Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for VED

[Cheng, Yao]

> > >
> > > With that out of the way some high-level review:
> > > - I think we need the full libva implementation to review the interfaces
> > >   properly. At least the little libdrm test program doesn't seem to fully
> > >   exercise it all.
> >
> > The libva driver need some time to be fully open sourced, but I can
> > upload the code to Sean's private github repo for your access. I'll
> > sync with Sean and you internally.
> 
> It doesn't need to be the final libva driver of course, just something so that
> people can look at the userspace side. So upload to some github account is
> perfectly ok.
> 
> Or do you mean we still have legal review pending on those patches? In that
> case I think we need to wait for that to complete first.

I seeyes you're right, it's still under legal review. We'll put it to 
internet as soon as being approved.

> > > - Locking seems to be inexistent in places, at least some of the idr
> > >   manipulation very much looks like it's done lock-free. That doesn't work
> > >   well.
> >
> > Yes, probably we haven't considered all the scenarios carefully, is it
> > possible to review them in an internal discussion?
> 
> Imo no need for private review since I didn't spot anything fundamentally
> wrong. It's just a lot of small details, and for those I think m-l review is 
> a good
> tool. But someone needs to do that, and I don't really have the time for it.

I see, thanks. 

> 
> > > - You implement file-descriptor based fences, but then also have the
> more
> > >   gem-traditional wait ioctl working on buffer objects. That's a bit a
> > >   funky mix of implicit and explicit fencing. Furthermore adding new
> > >   private fence objects isn't a good idea now that everyon is talking
> > >   about de-staging android syncpts as the official userspace interface.
> > >
> > >   Also, your userspace patches don't use this, so maybe we can just rip it
> > >   all out?
> >
> > Currently the libdrm_ipvr.so uses both the WAIT IOCTL and FD style
> > fence...  At beginning, both drm_ipvr_gem_bo_alloc() and
> > drm_ipvr_gem_bo_wait() use the WAIT IOCTL.
> > In drm_ipvr_gem_bo_alloc(), libdrm_ipvr tries to return an existing
> > free BO instead of requesting kernel via IOCTL, like libdrm_intel does.
> > Eventually we think the status query on multiple BOs is inefficient,
> > so we added the FD style fence to let libdrm_ipvr call select() to do
> > a batch query.  I'm fine to drop one and keep the other. Which one is
> > preferred by GEM? The WAIT_IOCTL or the FD fence?  Or do you suggest
> > directly use the Android syncpts?
> 
> The wait ioctl is the usual approach with gem drivers. Explicit fencing is 
> still in
> flux like I've said, so charging ahead and locking down an interface doesn't
> seem like a good idea. And I'd be _really_ surprised if you can benchmark the
> benefits of explicit fencing, so I don't think you can even justify the added
> complexity.

Understood...We didn't do real benchmark, the "inefficient" just means the 
logic in code.
Will double-check the perf, and rip out the FD-based fence in v3 patch if no 
real benefit.

> 
> > > - I'm a bit unclear on your usage of vxd_/pvr_ prefixes.
> > >
> >
> > Thanks for pointing out this, shall I add some description about this in 
> > next
> patch (in git commit message)?
> > We use different prefixes to distinguish the function scope, like we used to
> do on GMA series (Android product):
> > ved: decoding function only
> > vec: encoding function only (for future extension)
> > vsp: post-processing runction only (for future extension)
> > ipvr: common for all encoding/decoding/postproc
> 
> Yeah, explaining this kind of stuff in the commit message would be great.
> Or just go ahead and add a new vxd section in the drm docbook (like we
> already have for i915) and add such high-level information there.

Thanks, will add this in v3 patch.

> 
> > > The driver is fairly big and I don't really have the time to do a
> > > full blown review of even just the interfaces. I think we need to
> > > have some internal discussions about how to do this, but meanwhile
> > > we can cover some of the high-level bits.
> > >
> >
> > This is great, I'll talk with Sean on how to run this.
> 
> Yeah, we need to internally figure out how to do the review.

Thx I asked Sean to co-ordinate this :)

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

[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED

[Cheng, Yao]

> > > Please resend with a patch changelog to account for my review
> comments.
> > > And Ville's. Plus cc us both. And if there's anything you didn't
> > > address, you must reply to the review and we need to further discuss this.
> > >
> >
> > Daniel, I see, thanks for the instruction.
> > Do you mean resending the [RFC PATCH v2] with changelog and cc list?
> > Or adding changelog/cc when sending [RFC PATCH v3]?
> 
> I think you could just add the per-patch changelog for both v2 and v3 when
> sending out v3.
> -Daniel

Got it! Many thanks!


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

[Bug 85334] display freeze while playing XCOM: GPU lockup (waiting for 0x00000000000aa7a6 last fence id 0x00000000000aa7a0 on ring 0)

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

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

--- Comment #4 from Michel D?nzer  ---
See also bug 80419 and bug 81576.

-- 
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/20141023/f2d764e8/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #146 from Aaron B  ---
Go figure after saying that, I maximized a youtube video and it died when on
radeon.dpm=0. So just...guess this can just die. -_-

-- 
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/20141023/6a30bfdc/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #145 from Aaron B  ---
I'm just going to end my comments here, if someone wants to know more like
asking me to test or testing a patch related, let me know.

With radeon.dpm=0, this crash is "fixed" and never happens at all, past 4 days
have been running perfect on it. About 20 hours up time total in a row, which
is unheard of for me.

-- 
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/20141023/f87584b6/attachment.html>

[Bug 85323] [RV630] Video is stuttering using UVD hardware acceleration

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

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

Michel D?nzer  changed:

   What|Removed |Added

Summary|Video is stuttering using   |[RV630] Video is stuttering
   |hardware acceleration   |using UVD hardware
   ||acceleration

-- 
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/20141023/341eb010/attachment-0001.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

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

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

--- Comment #17 from Michel D?nzer  ---
Created attachment 108267
  --> https://bugs.freedesktop.org/attachment.cgi?id=108267=edit
Add some debugging output to DRI2CanFlip

Can you rebuild xserver with this patch and get the debugging output from that
as well?

BTW, we only really need to see each debugging message once. If you want to
provide all of them or even the whole log file, please create an attachment
instead of pasting it in a comment.

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

[Bug 85320] [RV630] GPU hangs using UVD hardware acceleration

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

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

Michel D?nzer  changed:

   What|Removed |Added

Summary|GPU hangs using hardware|[RV630] GPU hangs using UVD
   |acceleration|hardware acceleration

-- 
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/20141023/8ccdd6d7/attachment.html>

[Bug 85204] [Radeon HD 5650] return from sleep state failed

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

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

--- Comment #6 from Michel D?nzer  ---
(In reply to Rafael Pereira from comment #5)
> After bisecting, I found the first occurence (of the bug) on the following
> commit:
> 
> git describe --contains 43c40df2c7fedce640a6c39fcdf58764f6bbac5c


That's a merge of a linux-leds tree, so I'm afraid something went wrong during
the bisection. Most likely, the problem doesn't happen every time even with
affected commits, so you need to test several times before declaring a commit
good.

-- 
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/20141023/90bc5f66/attachment.html>

[RFC PATCH] drm/exynos: Add DECON driver

[Inki Dae]

Thanks for contribution.

It seems reasonable that you separate device drivers into FIMD and DECON
because many registers of them have many different offsets and fields.
However, there may be a good solution that we can combine common sets of
these drivers later.

Below are my comments.

Thanks,
Inki Dae

On 2014? 10? 10? 21:48, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.

DECON was used since Exynos5430. And is Exynos5433 different from
Exynos7? If so, could I get the Exynos7 user manual (TRM) for review?

>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/exynos-decon.txt |   68 ++
>  drivers/gpu/drm/exynos/Kconfig |   11 +-
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_decon.c  | 1086

>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   17 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 +
>  include/video/samsung_decon.h  |  346 +++
>  7 files changed, 1537 insertions(+), 3 deletions(-)
>  create mode 100644
Documentation/devicetree/bindings/video/exynos-decon.txt
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
>  create mode 100644 include/video/samsung_decon.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
b/Documentation/devicetree/bindings/video/exynos-decon.txt
> new file mode 100644
> index 000..e865650
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
> @@ -0,0 +1,68 @@
> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
> +
> +DECON (Display and Enhancement Controller) is the Display Controller
for the
> +Exynos7 series of SoCs which transfers the image data from a video memory
> +buffer to an external LCD interface.
> +
> +Required properties:
> +- compatible: value should be "samsung,exynos7-decon";

If exynos5433 was just renamed to exynos7 then, it should be one of the
following:
(a) "samsung,exynos5430-decon" for Display and enhancement controller
IP for Exynos5430
(b) "samsung,exynos7" for Display and enhancement controller IP for 
Exynos7

Or,
(a) "samsung,exynos5430-decon" for Display and enhancement controller
IP for Exynos5430

(b) "samsung,exynos5433-decon" for Display and enhancement controller
IP for Exynos5433
(c) "samsung,exynos7" for Display and enhancement controller IP for 
Exynos7


> +
> +- reg: physical base address and length of the DECON registers set.
> +
> +- interrupt-parent: should be the phandle of the decon controller's
> + parent interrupt controller.
> +
> +- interrupts: should contain a list of all DECON IP block interrupts
in the
> +  order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
> +  format depends on the interrupt controller used.
> +
> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
> + "lcd_sys", in the same order as they were listed in the interrupts
> +property.
> +
> +- pinctrl-0: pin control group to be used for this controller.
> +
> +- pinctrl-names: must contain a "default" entry.
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: list of clock names sorted in the same order as the clocks
> +   property. Must contain "pclk_decon0", "aclk_decon0",
> +"decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0",
> +"aclk_disp", "aclk_lh_disp1".

Should DECON driver really control above all clocks? I think it's enough
that DECON driver controls only lcd and bus clocks, and others could be
configured by boot-loader or by calling clk_set_rate.

> +
> +Optional Properties:
> +- samsung,power-domain: a phandle to DECON power domain node.

You are missing many properties,
samsung,invert-vden
samsung,invert-vclk
display-timings
...

refer to below document,
Documentation/devicetree/bindings/video/samsung-fimd.txt

> +
> +Example:
> +
> +SoC specific DT entry:
> +
> + decon at 1393 {
> + compatible = "samsung,exynos7-decon";
> + interrupt-parent = <>;
> + reg = <0x1393 0x1000>;
> + interrupt-names = "lcd_sys", "vsync", "fifo";
> + interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> +   

tile property contents

[Daniel Vetter]

On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger  wrote:
> I assume the TILE property described below would be per-connector?
>
> It looks like this would handle the DP MST tiled display case.
>
> At the risk of trying to solve too much at once:
>
> There are also configurations where users configure multiple heads to
> drive power walls that they want to be treated as one logical monitor,
> similar to the DP MST tiled display case.  Normally, those powerwall
> configurations don't have any layout information from the monitors
> themselves, and the layout is configured by the user.
>
> Would it be appropriate for users to be able to set the TILE property
> in that sort of scenario?
>
> For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
> should be expressed in pixels rather than tiles?  Sometimes, the tiles
> in those powerwalls may not all have the same resolution, or may be
> configured with overlap.  I suppose that would make the TILE configuration
> specific to the current modetimings on each tile...

Why can't users just set that mode?

And if this is about the initial configuration problem then we (at
intel) are working on some way to load a dt blob as a firmware image
which would contain the entire kms state, and which we'd apply in an
atomic modeset at driver load. Everyone else (boot splash, X, ...)
will then just inherit that config. That should give you even
flicker-free screen walls if you want to ;-)

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

[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

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

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

--- Comment #12 from Vitaliy Filippov  ---
Hm... Checked the test from comment 6, the result is the same - there are two
PHINode loops and one branch on constant.

Also checked the code, it looks like crash from comment 6 is also triggered by
a branch-on-constant, the difference is that it crashes when a ConstantInt is
dyn_cast<>'ed to incorrect class - Instruction (ConstantInt isn't an
Instruction!!) in handleLoopCondition() and getTerminator() is called on it.

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

[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

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

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

--- Comment #11 from Vitaliy Filippov  ---
Created attachment 108266
  --> https://bugs.freedesktop.org/attachment.cgi?id=108266=edit
StructurizeCFG IR output for the sample from comment 10

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

[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

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

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

--- Comment #10 from Vitaliy Filippov  ---
I've managed to make a reduced test case with a recursive PHI after
StructurizeCFG !!!

int main()
{
  int i, j = 0;
  while (j % 2)
  {
if (j > 100)
  j += 3;
else if (j > 50)
  break;
  }
  return j;
}

clang-3.5 -S -emit-llvm test3.c
opt-3.5 -S -structurizecfg test3.ll > test3cfg.ll

Simple to visualise with graphviz:

( echo 'digraph G {'; perl -ne 'if (/\%(\S+) = phi/) { my $a = $1; print "$a ->
$_;\n" for /\[ \%([^\s,]+)/g; }' test3cfg.ll; echo '}' ) > test3cfg.dot
dot -Tsvg test3cfg.dot > test3cfg.svg

%21 and %26 phi's loop in the result.

Also there is a branch on constant in the end of test3cfg.ll:

br i1 false, label %14, label %Flow2

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