[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task
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
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(&genpd->status_wait_queue, &wait); > > - 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
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
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
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
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
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&action=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
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 74.
[Bug 83861] radeon power management cause audio skips and glitch
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
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&action=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*()
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*()
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*()
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
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 = &hannstar_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 = &foxlink_fl500wvr00_a0t, }, { + .compatible = "hannstar,hsd070pww1", + .data = &hannstar_hsd070pww1, + }, { .compatible = "innolux,n116bge", .data = &innolux_n116bge, }, { -- 2.1.1
[PATCH v2 1/2] of: Add vendor prefix for HannStar Display Corporation
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
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
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.
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
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(&pdev->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(&pdev->dev); + component_del(&pdev->dev, &exynos_dsi_component_ops); exynos_drm_component_del(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR); -- 1.9.1
[RFC 1/2] PM / Domains: Power on domain early during system resume
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(&genpd->status_wait_queue, &wait); - 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
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
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
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 de-stag
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
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
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
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
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
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
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=83651 --- Comment #10 from Garri --- Created attachment 154661 --> https://bugzilla.kernel.org/attachment.cgi?id=154661&action=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
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*()
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*()
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
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", >>> +"aclk_disp"
[Mesa-dev] [r600g] Is LLVM-compiler (--enable-r600-llvm-compiler) usable, now?
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
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(&bo_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, &bo_va->bo->tbo.mem); +error_unlock: + mutex_unlock(&bo_va->vm->mutex); + error_unreserve: ttm_eu_backoff_reservation(&ticket, &list); -- 1.9.1
[PATCH v8 0/2] ASoC: tda998x: add a codec to the HDMI transmitter
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
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 = <&pmx_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
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
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
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)
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
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
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
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
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
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, + &max_channels, &rate_mask, &fmt); + if (ret < 0) + return ret; /* no screen */ + + /* convert the EDID values to audio constraints */ + rate_constraints = &priv->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 vo
[PATCH] gpu: drm: Fix warning caused by a parameter description in drm_crtc.c
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
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
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
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&action=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
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
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
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
> > > > > > 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
> > > 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)
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.
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.
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
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
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&action=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
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
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>