dri-devel October 2014

dri-devel@lists.freedesktop.org

139 participants
947 discussions

[PATCH] drm/exynos: vidi: fix build warning
by Inki Dae 07 Oct '14

07 Oct '14

encoder object isn't used anymore so remove it. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index 9395e85..50faf91 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -630,7 +630,6 @@ static int vidi_remove(struct platform_device *pdev) { struct exynos_drm_manager *mgr = platform_get_drvdata(pdev); struct vidi_context *ctx = mgr->ctx; - struct drm_encoder *encoder = ctx->encoder; if (ctx->raw_edid != (struct edid *)fake_edid_info) { kfree(ctx->raw_edid); -- 1.7.9.5

1 0

[PATCH] drm/exynos: remove explicit encoder/connector de-initialization
by Andrzej Hajda 07 Oct '14

07 Oct '14

All KMS objects are destroyed by drm_mode_config_cleanup in proper order so component drivers should not care about it. Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> --- Hi Inki, This is another spin-off of exynos_drm tests regarding your component support update. The patch is based as usual on the latest exynos-drm-next branch. Regards Andrzej --- drivers/gpu/drm/exynos/exynos_dp_core.c | 5 ----- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 ---- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ---- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 --- drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ------ 5 files changed, 22 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index cd50ece..6adb1e5 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1355,13 +1355,8 @@ static void exynos_dp_unbind(struct device *dev, struct device *master, void *data) { struct exynos_drm_display *display = dev_get_drvdata(dev); - struct exynos_dp_device *dp = display->ctx; - struct drm_encoder *encoder = dp->encoder; exynos_dp_dpms(display, DRM_MODE_DPMS_OFF); - - exynos_dp_connector_destroy(&dp->connector); - encoder->funcs->destroy(encoder); } static const struct component_ops exynos_dp_ops = { diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index 96c87db..3dc678e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -338,14 +338,10 @@ err_del_component: int exynos_dpi_remove(struct device *dev) { - struct drm_encoder *encoder = exynos_dpi_display.encoder; struct exynos_dpi *ctx = exynos_dpi_display.ctx; exynos_dpi_dpms(&exynos_dpi_display, DRM_MODE_DPMS_OFF); - exynos_dpi_connector_destroy(&ctx->connector); - encoder->funcs->destroy(encoder); - if (ctx->panel) drm_panel_detach(ctx->panel); diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index 24741d8..acf7e9e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -1660,13 +1660,9 @@ static void exynos_dsi_unbind(struct device *dev, struct device *master, void *data) { struct exynos_dsi *dsi = exynos_dsi_display.ctx; - struct drm_encoder *encoder = dsi->encoder; exynos_dsi_dpms(&exynos_dsi_display, DRM_MODE_DPMS_OFF); - exynos_dsi_connector_destroy(&dsi->connector); - encoder->funcs->destroy(encoder); - mipi_dsi_host_unregister(&dsi->dsi_host); } diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index d565207..9395e85 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -639,9 +639,6 @@ static int vidi_remove(struct platform_device *pdev) return -EINVAL; } - encoder->funcs->destroy(encoder); - drm_connector_cleanup(&ctx->connector); - return 0; } diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 7910fb3..563a19e 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2312,12 +2312,6 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data) static void hdmi_unbind(struct device *dev, struct device *master, void *data) { - struct exynos_drm_display *display = get_hdmi_display(dev); - struct drm_encoder *encoder = display->encoder; - struct hdmi_context *hdata = display->ctx; - - hdmi_connector_destroy(&hdata->connector); - encoder->funcs->destroy(encoder); } static const struct component_ops hdmi_component_ops = { -- 1.9.1

1 1

[PATCH v8 0/2] mfd: add atmel-hlcdc driver
by Boris Brezillon 07 Oct '14

07 Oct '14

Hi Lee, As proposed in my last atmel-hlcdc series I have split the series in order to get the accepted parts merged. This series is the one all others depend on. Could you take it in your tree so that other maintainers can rely on the fact this part will be merged before other parts. Moreover, I know this is late, but can you include it in one of your 3.18 pull request as suggested by Thierry. If you can't, can you provide Thierry and Dave with a stable branch including this driver ? Best Regards, Boris Boris Brezillon (2): mfd: add atmel-hlcdc driver mfd: add documentation for atmel-hlcdc DT bindings .../devicetree/bindings/mfd/atmel-hlcdc.txt | 51 +++++++++ drivers/mfd/Kconfig | 6 + drivers/mfd/Makefile | 1 + drivers/mfd/atmel-hlcdc.c | 122 +++++++++++++++++++++ include/linux/mfd/atmel-hlcdc.h | 85 ++++++++++++++ 5 files changed, 265 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt create mode 100644 drivers/mfd/atmel-hlcdc.c create mode 100644 include/linux/mfd/atmel-hlcdc.h -- 1.9.1

4 18

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend
by bugzilla-daemon＠freedesktop.org 06 Oct '14

06 Oct '14

https://bugs.freedesktop.org/show_bug.cgi?id=83262 Kevin <wittyman37(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Kevin <wittyman37(a)yahoo.com> --- I can confirm that as of the Linux kernel 3.16.4 that reclocking is now working after resuming from suspend. Yay! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 82154] New: [HAWAII] gpu-reset when closing gwenview, fails to resume (atombios stuck executing), then flickery noise
by bugzilla-daemon＠freedesktop.org 06 Oct '14

06 Oct '14

https://bugs.freedesktop.org/show_bug.cgi?id=82154 Priority: medium Bug ID: 82154 Assignee: dri-devel(a)lists.freedesktop.org Summary: [HAWAII] gpu-reset when closing gwenview, fails to resume (atombios stuck executing), then flickery noise Severity: normal Classification: Unclassified OS: All Reporter: luziphermcleod(a)yahoo.ie Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Observation: ============ With Hawaii acceleration enabled (including drm) I just got a gpu reset that failed to recover. It happended when I closed a gwenview window after a few hours of use (window manager was cinnamon). After going black and switching off for a while, the screens (2x DVI and 1x HDMI) came back, but displayed only flickery noise (I could see where the mouse pointer would've been as a differently noisy rectangle, and could move it). I could still ssh into the machine and aquire dmesg and Xorg.0.log. Interesting messages from dmesg: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing C466 (len 254, WS 0, PS 4) @ 0xC490 [drm:atom_execute_table_locked] *ERROR* atombios stuck executing B9EC (len 145, WS 0, PS 8) @ 0xBA77 [drm:ci_dpm_enable] *ERROR* ci_start_dpm failed [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed Driver Stack Details: ===================== 1) Kernel: agd5f's drm-next-3.17-wip (2014-08-03), Hawaii accel enabled 2) libdrm: git (2014-08-03) 3) mesa: git (2014-08-03) 4) Xorg-server: 1.16.0 5) xf86-video-ati: git (2014-08-03 with patch to enable accel) 6) glamor: xorg-server integrated 1.0.0 7) llvm: 3.5svn (updated recently) 8) new radeon firmware files for hawaii accel Hardware Configuration: ===================== Graphics Card: Hawaii XT, Sapphire Radeon R9 290X Tri-X OC, 4GB GDDR5 Processor: Core i7-965 (LGA 1366) Mainboard: Asus P6T Deluxe RAM: 6GB -- You are receiving this mail because: You are the assignee for the bug.

1 5

[RFC 0/7] drm: add DPI bus support
by Boris Brezillon 06 Oct '14

06 Oct '14

Hello, This is a proposal to address one of the issue I've been facing with the atmel-hlcdc driver. This driver provides a DPI (or raw RGB) bus on which we might access several devices (a panel, an HDMI encoder, or any other type of encoder). My problem is that I have to find the best bus format according to the devices connected on the bus. Another problem is when 2 devices on the same bus requires 2 orthogonal formats, we should be able to detect this kind of issue and reject the requested mode setting. This implementation was designed in a few hours and thus is far from perfect. It is given as a starting point to further discuss the available solution I have to support this kind of configuration. Patches 1 and 2 implement a basic DPI bus infrastructure (or whatever name we decide to use: DPI is a MIPI standard that involves more than just video bus format description). Patches 3 and 4 add DPI panel support, and patches 5, 6 and 7 implement a DPI host in the atmel-hlcdc driver (the driver I'm currently working on). This implementation also has the benefit of keeping the display controller driver indepedant of slave device types (panels, encoders, bridges, ...). Feel free to share your thoughts on this problem (and/or the proposed solution). Best Regards, Boris Boris Brezillon (7): drm: add DPI bus support drm: add DPI connector/encoder definitions drm: support panels connected on a DPI bus drm: panel: move foxlink fl500wvr00-a0t panel to the DPI panel list drm: atmel-hlcdc: add DPI support drm: atmel-hlcdc: move to DPI ARM: at91/dt: define sama5d3xek panel as a DPI device arch/arm/boot/dts/sama5d36ek.dts | 12 +- arch/arm/boot/dts/sama5d3_lcd.dtsi | 6 +- arch/arm/boot/dts/sama5d3xdm.dtsi | 28 +- drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/atmel-hlcdc/Kconfig | 1 + drivers/gpu/drm/atmel-hlcdc/Makefile | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 11 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 12 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 6 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dpi.c | 212 +++++++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 443 ----------------------- drivers/gpu/drm/drm_crtc.c | 2 + drivers/gpu/drm/drm_mipi_dpi.c | 369 +++++++++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 331 +++++++++++++++-- include/drm/drm_mipi_dpi.h | 169 +++++++++ include/uapi/drm/drm_mode.h | 2 + 17 files changed, 1100 insertions(+), 511 deletions(-) create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dpi.c delete mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c create mode 100644 drivers/gpu/drm/drm_mipi_dpi.c create mode 100644 include/drm/drm_mipi_dpi.h -- 1.9.1

1 7

[Bug 85661] New: Double Firmware for Radeon GPUs (at least HAWAII)
by bugzilla-daemon＠bugzilla.kernel.org 06 Oct '14

06 Oct '14

https://bugzilla.kernel.org/show_bug.cgi?id=85661 Bug ID: 85661 Summary: Double Firmware for Radeon GPUs (at least HAWAII) Product: Drivers Version: 2.5 Kernel Version: 3.17.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: debian(a)carbon-project.org CC: alexdeucher(a)gmail.com Regression: No Not sure if this is a mistake or I'm missing something here, but I was looking at <https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tr…> and noticed, that there are firmware files of the same name – except case – but different content for HAWAII and others, eg. HAWAII_ce.bin and hawaii_ce.bin: 7fa992d86295f741e8cdea76c5b6c632 linux-firmware/radeon/HAWAII_ce.bin 9e05820da42549ce9c89d147cf1f8e19 linux-firmware/radeon/hawaii_ce.bin For other firmware parts (eg. mc2) there is only one version available. Now the question is: is this intended? Or should there only be one version? If I had to guess, I'd say the lower-case variants are the current ones, since they have the same checksums as the firmware I've downloaded from <http://people.freedesktop.org/~agd5f/radeon_ucode/> in the course of <https://bugs.freedesktop.org/show_bug.cgi?id=78453>. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH] Fallback to std DRI2CopyRegion when DRI2UpdatePrime fails
by Chris Wilson 06 Oct '14

06 Oct '14

I was looking at a bug report today of intel/ati prime and noticed a number of sna_share_pixmap_backing() failures (called from DRI2UpdatePrime). These were failing as the request was for the scanout buffer (which is tiled and so we refuse to share it, and since it is already on the scanout we refuse to change tiling). But looking at radeon_dri2_copy_region2(), if DRI2UpdatePrime() fails, the copy is aborted and the update lost. If the copy is made to the normal window drawable is that enough for it to be propagated back through damage tracking? --- src/radeon_dri2.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c index 9a9918b..0d113b9 100644 --- a/src/radeon_dri2.c +++ b/src/radeon_dri2.c @@ -409,26 +409,27 @@ radeon_dri2_copy_region2(ScreenPtr pScreen, dst_drawable = &dst_private->pixmap->drawable; if (src_private->attachment == DRI2BufferFrontLeft) { + src_drawable = NULL; #ifdef USE_DRI2_PRIME - if (drawable->pScreen != pScreen) { + if (drawable->pScreen != pScreen) src_drawable = DRI2UpdatePrime(drawable, src_buffer); - if (!src_drawable) - return; - } else #endif + if (src_drawable == NULL) src_drawable = drawable; } if (dst_private->attachment == DRI2BufferFrontLeft) { + dst_drawable = NULL; #ifdef USE_DRI2_PRIME if (drawable->pScreen != pScreen) { dst_drawable = DRI2UpdatePrime(drawable, dest_buffer); - if (!dst_drawable) - return; - dst_ppix = (PixmapPtr)dst_drawable; - if (dst_drawable != drawable) - translate = TRUE; - } else + if (dst_drawable) { + dst_ppix = (PixmapPtr)dst_drawable; + if (dst_drawable != drawable) + translate = TRUE; + } + } #endif + if (dst_drawable == NULL) dst_drawable = drawable; } -- 2.1.1

3 3

[PATCH] gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat.
by Rickard Strandqvist 05 Oct '14

05 Oct '14

I have now eliminate the need to use the temporary string, and therefore also the use of strncat. And I think this code is clearer and more effective. Signed-off-by: Rickard Strandqvist <rickard_strandqvist(a)spectrumdigital.se> --- drivers/gpu/drm/drm_dp_mst_topology.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ac3c273..c3f6571 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -997,17 +997,18 @@ static void build_mst_prop_path(struct drm_dp_mst_port *port, struct drm_dp_mst_branch *mstb, char *proppath) { - int i; - char temp[8]; - snprintf(proppath, 255, "mst:%d", mstb->mgr->conn_base_id); + int i, len; + static const int proppath_len = 255; + memset(proppath, 0, proppath_len); + len = snprintf(proppath, proppath_len, "mst:%d", mstb->mgr->conn_base_id); for (i = 0; i < (mstb->lct - 1); i++) { int shift = (i % 2) ? 0 : 4; int port_num = mstb->rad[i / 2] >> shift; - snprintf(temp, 8, "-%d", port_num); - strncat(proppath, temp, 255); + len += snprintf(&proppath[(len < proppath_len ? len : 0)], + proppath_len - len, "-%d", port_num); } - snprintf(temp, 8, "-%d", port->port_num); - strncat(proppath, temp, 255); + snprintf(&proppath[(len < proppath_len ? len : 0)], proppath_len - len, + "-%d", port->port_num); } static void drm_dp_add_port(struct drm_dp_mst_branch *mstb, -- 1.7.10.4

2 1

[Bug 78788] New: [Radeon\VCE] Performance regression after using VCE
by bugzilla-daemon＠freedesktop.org 04 Oct '14

04 Oct '14

https://bugs.freedesktop.org/show_bug.cgi?id=78788 Priority: medium Bug ID: 78788 Assignee: dri-devel(a)lists.freedesktop.org Summary: [Radeon\VCE] Performance regression after using VCE Severity: normal Classification: Unclassified OS: Linux (All) Reporter: pontostroy(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Linux drm-next 3.15rc3 Radeon hd 7790 After using VCE video encoding, 3d performance slow down up to 3-4 times I made short video with this problem http://www.youtube.com/watch?v=YfPXHTHzO6s dmesg after vce [ 415.097591] switching from power state: [ 415.097595] ui class: performance [ 415.097596] internal class: none [ 415.097598] caps: [ 415.097611] uvd vclk: 0 dclk: 0 [ 415.097612] power level 0 sclk: 30000 mclk: 15000 pcie gen: 3 pcie lanes: 16 [ 415.097613] power level 1 sclk: 105000 mclk: 150000 pcie gen: 3 pcie lanes: 16 [ 415.097614] status: c r [ 415.097615] switching to power state: [ 415.097615] ui class: performance [ 415.097616] internal class: none [ 415.097617] caps: [ 415.097618] uvd vclk: 0 dclk: 0 [ 415.097618] power level 0 sclk: 30000 mclk: 15000 pcie gen: 3 pcie lanes: 16 [ 415.097619] power level 1 sclk: 105000 mclk: 150000 pcie gen: 3 pcie lanes: 16 [ 415.097620] status: c r [ 441.772194] switching from power state: [ 441.772198] ui class: performance [ 441.772199] internal class: none [ 441.772200] caps: [ 441.772201] uvd vclk: 0 dclk: 0 [ 441.772202] power level 0 sclk: 30000 mclk: 15000 pcie gen: 3 pcie lanes: 16 [ 441.772203] power level 1 sclk: 105000 mclk: 150000 pcie gen: 3 pcie lanes: 16 [ 441.772204] status: c r [ 441.772205] switching to power state: [ 441.772205] ui class: performance [ 441.772206] internal class: none [ 441.772207] caps: [ 441.772207] uvd vclk: 0 dclk: 0 [ 441.772208] power level 0 sclk: 30000 mclk: 15000 pcie gen: 3 pcie lanes: 16 [ 441.772209] power level 1 sclk: 105000 mclk: 150000 pcie gen: 3 pcie lanes: 16 [ 441.772210] status: c r -- You are receiving this mail because: You are the assignee for the bug.

1 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2014