dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[PATCH] drm/radeon: Avoid double gpu reset by adding a timeout on IB ring tests.
by Matthew Dawson 08 Feb '16

08 Feb '16

When the radeon driver resets a gpu, it attempts to test whether all the rings can successfully handle an IB. If these rings fail to respond, the process will wait forever. Another gpu reset can't happen at this point, as the current reset holds a lock required to do so. Instead, make all the IB tests run with a timeout, so the system can attempt to recover in this case. While this doesn't fix the underlying issue with card resets failing, it gives the system a higher chance of recovering. These timeouts have been confirmed to help both a Tathi and Hawaii card recover after a gpu reset. I haven't been able to test this on other cards, but everything compiles. I wasn't sure what to use for a timeout value, so for now I've used radeon_lockup_timeout. When that is 0, the timeout functionality in this patch is also disabled. This also adds a new function, radeon_fence_wait_timeout, that behaves like radeon_fence_wait except allowing a different timeout value to be passed to radeon_fence_wait_seq_timeout. Signed-off-by: Matthew Dawson <matthew(a)mjdsystems.ca> --- drivers/gpu/drm/radeon/cik_sdma.c | 3 ++- drivers/gpu/drm/radeon/r100.c | 3 ++- drivers/gpu/drm/radeon/r600.c | 3 ++- drivers/gpu/drm/radeon/r600_dma.c | 3 ++- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_fence.c | 25 ++++++++++++++++++++++--- drivers/gpu/drm/radeon/radeon_vce.c | 3 ++- drivers/gpu/drm/radeon/uvd_v1_0.c | 3 ++- 8 files changed, 35 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik_sdma.c b/drivers/gpu/drm/radeon/cik_sdma.c index d16f2ee..014f5ca 100644 --- a/drivers/gpu/drm/radeon/cik_sdma.c +++ b/drivers/gpu/drm/radeon/cik_sdma.c @@ -737,7 +737,8 @@ int cik_sdma_ib_test(struct radeon_device *rdev, struct radeon_ring *ring) DRM_ERROR("radeon: failed to schedule ib (%d).\n", r); return r; } - r = radeon_fence_wait(ib.fence, false); + r = radeon_fence_wait_timeout(ib.fence, false, msecs_to_jiffies( + (radeon_lockup_timeout) ? radeon_lockup_timeout : MAX_SCHEDULE_TIMEOUT)); if (r) { DRM_ERROR("radeon: fence wait failed (%d).\n", r); return r; diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 5eae0a8..5386c09 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -3732,7 +3732,8 @@ int r100_ib_test(struct radeon_device *rdev, struct radeon_ring *ring) DRM_ERROR("radeon: failed to schedule ib (%d).\n", r); goto free_ib; } - r = radeon_fence_wait(ib.fence, false); + r = radeon_fence_wait_timeout(ib.fence, false, msecs_to_jiffies( + (radeon_lockup_timeout) ? radeon_lockup_timeout : MAX_SCHEDULE_TIMEOUT)); if (r) { DRM_ERROR("radeon: fence wait failed (%d).\n", r); goto free_ib; diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index cc2fdf0..8fbe5d7 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -3381,7 +3381,8 @@ int r600_ib_test(struct radeon_device *rdev, struct radeon_ring *ring) DRM_ERROR("radeon: failed to schedule ib (%d).\n", r); goto free_ib; } - r = radeon_fence_wait(ib.fence, false); + r = radeon_fence_wait_timeout(ib.fence, false, msecs_to_jiffies( + (radeon_lockup_timeout) ? radeon_lockup_timeout : MAX_SCHEDULE_TIMEOUT)); if (r) { DRM_ERROR("radeon: fence wait failed (%d).\n", r); goto free_ib; diff --git a/drivers/gpu/drm/radeon/r600_dma.c b/drivers/gpu/drm/radeon/r600_dma.c index d2dd29a..3ff614d 100644 --- a/drivers/gpu/drm/radeon/r600_dma.c +++ b/drivers/gpu/drm/radeon/r600_dma.c @@ -368,7 +368,8 @@ int r600_dma_ib_test(struct radeon_device *rdev, struct radeon_ring *ring) DRM_ERROR("radeon: failed to schedule ib (%d).\n", r); return r; } - r = radeon_fence_wait(ib.fence, false); + r = radeon_fence_wait_timeout(ib.fence, false, msecs_to_jiffies( + (radeon_lockup_timeout) ? radeon_lockup_timeout : MAX_SCHEDULE_TIMEOUT)); if (r) { DRM_ERROR("radeon: fence wait failed (%d).\n", r); return r; diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 5ae6db9..0b698b6 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -382,6 +382,7 @@ void radeon_fence_driver_force_completion(struct radeon_device *rdev, int ring); int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence **fence, int ring); void radeon_fence_process(struct radeon_device *rdev, int ring); bool radeon_fence_signaled(struct radeon_fence *fence); +int radeon_fence_wait_timeout(struct radeon_fence *fence, bool interruptible, long timeout); int radeon_fence_wait(struct radeon_fence *fence, bool interruptible); int radeon_fence_wait_next(struct radeon_device *rdev, int ring); int radeon_fence_wait_empty(struct radeon_device *rdev, int ring); diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 05815c4..9fec805 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -527,7 +527,7 @@ static long radeon_fence_wait_seq_timeout(struct radeon_device *rdev, } /** - * radeon_fence_wait - wait for a fence to signal + * radeon_fence_wait_timeout - wait for a fence to signal with timeout * * @fence: radeon fence object * @intr: use interruptible sleep @@ -535,9 +535,10 @@ static long radeon_fence_wait_seq_timeout(struct radeon_device *rdev, * Wait for the requested fence to signal (all asics). * @intr selects whether to use interruptable (true) or non-interruptable * (false) sleep when waiting for the fence. + * @timeout: maximum time to wait, or MAX_SCHEDULE_TIMEOUT for infinite wait * Returns 0 if the fence has passed, error for all other cases. */ -int radeon_fence_wait(struct radeon_fence *fence, bool intr) +int radeon_fence_wait_timeout(struct radeon_fence *fence, bool intr, long timeout) { uint64_t seq[RADEON_NUM_RINGS] = {}; long r; @@ -552,9 +553,11 @@ int radeon_fence_wait(struct radeon_fence *fence, bool intr) return fence_wait(&fence->base, intr); seq[fence->ring] = fence->seq; - r = radeon_fence_wait_seq_timeout(fence->rdev, seq, intr, MAX_SCHEDULE_TIMEOUT); + r = radeon_fence_wait_seq_timeout(fence->rdev, seq, intr, timeout); if (r < 0) { return r; + } else if (r == 0) { + return -ETIMEDOUT; } r = fence_signal(&fence->base); @@ -564,6 +567,22 @@ int radeon_fence_wait(struct radeon_fence *fence, bool intr) } /** + * radeon_fence_wait - wait for a fence to signal + * + * @fence: radeon fence object + * @intr: use interruptible sleep + * + * Wait for the requested fence to signal (all asics). + * @intr selects whether to use interruptable (true) or non-interruptable + * (false) sleep when waiting for the fence. + * Returns 0 if the fence has passed, error for all other cases. + */ +int radeon_fence_wait(struct radeon_fence *fence, bool intr) +{ + return radeon_fence_wait_timeout(fence, intr, MAX_SCHEDULE_TIMEOUT); +} + +/** * radeon_fence_wait_any - wait for a fence to signal on any ring * * @rdev: radeon device pointer diff --git a/drivers/gpu/drm/radeon/radeon_vce.c b/drivers/gpu/drm/radeon/radeon_vce.c index 7eb1ae7..7d80dad 100644 --- a/drivers/gpu/drm/radeon/radeon_vce.c +++ b/drivers/gpu/drm/radeon/radeon_vce.c @@ -810,7 +810,8 @@ int radeon_vce_ib_test(struct radeon_device *rdev, struct radeon_ring *ring) goto error; } - r = radeon_fence_wait(fence, false); + r = radeon_fence_wait_timeout(fence, false, msecs_to_jiffies( + (radeon_lockup_timeout) ? radeon_lockup_timeout : MAX_SCHEDULE_TIMEOUT)); if (r) { DRM_ERROR("radeon: fence wait failed (%d).\n", r); } else { diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c b/drivers/gpu/drm/radeon/uvd_v1_0.c index c6b1cbc..35caa89 100644 --- a/drivers/gpu/drm/radeon/uvd_v1_0.c +++ b/drivers/gpu/drm/radeon/uvd_v1_0.c @@ -522,7 +522,8 @@ int uvd_v1_0_ib_test(struct radeon_device *rdev, struct radeon_ring *ring) goto error; } - r = radeon_fence_wait(fence, false); + r = radeon_fence_wait_timeout(fence, false, msecs_to_jiffies( + (radeon_lockup_timeout) ? radeon_lockup_timeout : MAX_SCHEDULE_TIMEOUT)); if (r) { DRM_ERROR("radeon: fence wait failed (%d).\n", r); goto error; -- 2.7.0

3 5

[Bug 109101] New: [A10-7800] CPU is capped to 3GHz if BAPM is enabled
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '16

08 Feb '16

https://bugzilla.kernel.org/show_bug.cgi?id=109101 Bug ID: 109101 Summary: [A10-7800] CPU is capped to 3GHz if BAPM is enabled Product: Drivers Version: 2.5 Kernel Version: 4.2.6 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: immarcescibilis(a)outlook.com Regression: No I have an A10-7800 APU with a 3.5GHz clock (3.9/3.8/3.6 turbo) on an MSI A88XM-E45 board that doesn't seem to suffer from the lack of BAPM, since it was disabled by default and I had to enable it manually, after doing some research on how to enable TurboCore on Linux. The fact of the matter is not only that it doesn't work at all, but that it caps the CPU clock to 3GHz even on full load. If I disable BAPM, the clocks raise normally to 3.5GHz. In my tests, I've noticed a couple of things: - Cool'n'Quiet is irrelevant. BAPM throttles the CPU clock whether Cool'n'Quiet is disabled or enabled; - With BAPM enabled, both CPU and GPU temperatures rise together when on full load, even if there's no GPU usage; - The turbo frequencies are never reached. I made all measurements with turbostat while running either POV-Ray or stress --cpu. -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

[PATCH] drm/exynos: dp: Fix panel and bridge lookup logic
by Javier Martinez Canillas 08 Feb '16

08 Feb '16

Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support for panel") made the Exynos DP DT binding more consistent since the OF graph could be used to lookup either a panel or a bridge device node. Before that commit, a panel would be looked up using a phandle and a bridge using the OF graph which made the DT binding not consistent. But the patch broke the later case since not finding a panel dev node would cause the driver's to do a probe deferral instead of attempting to lookup a bridge device node associated with the remote endpoint. So instead of returning a -EPROBE_DEFER if a panel is not found, check if there's a bridge and only do a probe deferral if both aren't found. Fixes: a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support for panel") Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com> --- drivers/gpu/drm/exynos/exynos_dp_core.c | 55 +++++++++++++++------------------ 1 file changed, 25 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index b79c316c2ad2..673164b331c8 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = { static int exynos_dp_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; - struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL; + struct device_node *np = NULL, *endpoint = NULL; struct exynos_dp_device *dp; int ret; @@ -1404,41 +1404,36 @@ static int exynos_dp_probe(struct platform_device *pdev) platform_set_drvdata(pdev, dp); /* This is for the backward compatibility. */ - panel_node = of_parse_phandle(dev->of_node, "panel", 0); - if (panel_node) { - dp->panel = of_drm_find_panel(panel_node); - of_node_put(panel_node); + np = of_parse_phandle(dev->of_node, "panel", 0); + if (np) { + dp->panel = of_drm_find_panel(np); + of_node_put(np); if (!dp->panel) return -EPROBE_DEFER; - } else { - endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); - if (endpoint) { - panel_node = of_graph_get_remote_port_parent(endpoint); - if (panel_node) { - dp->panel = of_drm_find_panel(panel_node); - of_node_put(panel_node); - if (!dp->panel) - return -EPROBE_DEFER; - } else { - DRM_ERROR("no port node for panel device.\n"); - return -EINVAL; - } - } - } - - if (endpoint) goto out; + } endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); if (endpoint) { - bridge_node = of_graph_get_remote_port_parent(endpoint); - if (bridge_node) { - dp->ptn_bridge = of_drm_find_bridge(bridge_node); - of_node_put(bridge_node); - if (!dp->ptn_bridge) - return -EPROBE_DEFER; - } else - return -EPROBE_DEFER; + np = of_graph_get_remote_port_parent(endpoint); + if (np) { + /* The remote port can be either a panel or a bridge */ + dp->panel = of_drm_find_panel(np); + if (!dp->panel) { + dp->ptn_bridge = of_drm_find_bridge(np); + if (!dp->ptn_bridge) { + of_node_put(np); + return -EPROBE_DEFER; + } + } + of_node_put(np); + } else { + DRM_ERROR("no remote endpoint device node found.\n"); + return -EINVAL; + } + } else { + DRM_ERROR("no port endpoint subnode found.\n"); + return -EINVAL; } out: -- 2.5.0

2 3

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.
by Mario Kleiner 08 Feb '16

08 Feb '16

The hardware vblank counter of AMD gpu's resets to zero during a modeset. The new implementation of drm_update_vblank_count() from commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed", introduced in Linux 4.4, treats that as a counter wraparound and causes the software vblank counter to jump forward by a large distance of up to 2^24 counts. This interacts badly with 32-bit wraparound handling in drm_handle_vblank_events(), causing that function to no longer deliver pending vblank events to clients. This leads to client hangs especially if clients perform OpenGL or DRI3/Present animations while a modeset happens and triggers the hw vblank counter reset. One prominent example is a hang of KDE Plasma 5's startup progress splash screen during login, making the KDE session unuseable. Another small potential race exists when executing a modeset while vblank interrupts are enabled or just get enabled: The modeset updates radeon_crtc->lb_vblank_lead_lines during radeon_display_bandwidth_update, so if vblank interrupt handling or enable would try to access that variable multiple times at the wrong moment as part of drm_update_vblank_counter, while the scanout happens to be within lb_vblank_lead_lines before the start of vblank, it could cause inconsistent vblank counting and again trigger a jump of the software vblank counter, causing similar client hangs. The most easy way to avoid this small race is to not allow vblank enable or vblank irq's during modeset. This patch replaces calls to drm_vblank_pre/post_modeset in the drivers dpms code with calls to drm_vblank_off/on, as recommended for drivers with hw counters that reset to zero during modeset. Those calls disable vblank interrupts during the modeset sequence and reinitialize vblank counts and timestamps after the modeset properly, taking hw counter reset into account, thereby fixing the problem of forward jumping counters. During a modeset, calls to drm_vblank_get() will no-op/intentionally fail, so no vblank events or pageflips can be queued during modesetting. Radeons static and dynpm power management uses drm_vblank_get to enable vblank irqs to synchronize reclocking to start of vblank. If a modeset would happen in parallel with such a power management action, drm_vblank_get would be suppressed, sync to vblank wouldn't work and a visual glitch could happen. However that glitch would hopefully be hidden by the blanking of the crtc during modeset. A small fix to power management makes sure to check for this and prevent unbalanced vblank reference counts due to mismatched drm_vblank_get/put. Reported-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: michel(a)daenzer.net Cc: vbabka(a)suse.cz Cc: ville.syrjala(a)linux.intel.com Cc: daniel.vetter(a)ffwll.ch Cc: dri-devel(a)lists.freedesktop.org Cc: alexander.deucher(a)amd.com Cc: christian.koenig(a)amd.com --- drivers/gpu/drm/radeon/atombios_crtc.c | 10 ++++++---- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 ++-- drivers/gpu/drm/radeon/radeon_pm.c | 8 ++++++-- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 801dd60..1c853e0 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -275,23 +275,25 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) atombios_enable_crtc_memreq(crtc, ATOM_ENABLE); atombios_blank_crtc(crtc, ATOM_DISABLE); - drm_vblank_post_modeset(dev, radeon_crtc->crtc_id); + /* adjust pm to dpms *before* drm_vblank_on */ + radeon_pm_compute_clocks(rdev); + drm_vblank_on(dev, radeon_crtc->crtc_id); radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF: - drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_off(dev, radeon_crtc->crtc_id); if (radeon_crtc->enabled) atombios_blank_crtc(crtc, ATOM_ENABLE); if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) atombios_enable_crtc_memreq(crtc, ATOM_DISABLE); atombios_enable_crtc(crtc, ATOM_DISABLE); radeon_crtc->enabled = false; + /* adjust pm to dpms *after* drm_vblank_off */ + radeon_pm_compute_clocks(rdev); break; } - /* adjust pm to dpms */ - radeon_pm_compute_clocks(rdev); } static void diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index 32b338f..24152df 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -331,13 +331,13 @@ static void radeon_crtc_dpms(struct drm_crtc *crtc, int mode) RADEON_CRTC_DISP_REQ_EN_B)); WREG32_P(RADEON_CRTC_EXT_CNTL, crtc_ext_cntl, ~(mask | crtc_ext_cntl)); } - drm_vblank_post_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_on(dev, radeon_crtc->crtc_id); radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF: - drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_off(dev, radeon_crtc->crtc_id); if (radeon_crtc->crtc_id) WREG32_P(RADEON_CRTC2_GEN_CNTL, mask, ~(RADEON_CRTC2_EN | mask)); else { diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 59abebd..339a6c5 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -276,8 +276,12 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev) if (rdev->irq.installed) { for (i = 0; i < rdev->num_crtc; i++) { if (rdev->pm.active_crtcs & (1 << i)) { - rdev->pm.req_vblank |= (1 << i); - drm_vblank_get(rdev->ddev, i); + /* This can fail if a modeset is in progress */ + if (0 == drm_vblank_get(rdev->ddev, i)) + rdev->pm.req_vblank |= (1 << i); + else + DRM_DEBUG_DRIVER("crtc %d no vblank, can glitch\n", + i); } } } -- 1.9.1

4 10

[PATCH] gma500: clean up an excessive and confusing helper
by Alan 08 Feb '16

08 Feb '16

From: Alan Cox <alan(a)linux.intel.com> This is a left over from the great clean ups in the past. It's confusing as it returns an int, yet has one caller that never uses it. The caller already has all the right private variables local so the entire function can be replaced by a simple if call. Signed-off-by: Alan Cox <alan(a)linux.intel.com> --- drivers/gpu/drm/gma500/framebuffer.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index cb95765..033d894 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -674,29 +674,17 @@ static const struct drm_mode_config_funcs psb_mode_funcs = { .output_poll_changed = psbfb_output_poll_changed, }; -static int psb_create_backlight_property(struct drm_device *dev) -{ - struct drm_psb_private *dev_priv = dev->dev_private; - struct drm_property *backlight; - - if (dev_priv->backlight_property) - return 0; - - backlight = drm_property_create_range(dev, 0, "backlight", 0, 100); - - dev_priv->backlight_property = backlight; - - return 0; -} - static void psb_setup_outputs(struct drm_device *dev) { struct drm_psb_private *dev_priv = dev->dev_private; struct drm_connector *connector; drm_mode_create_scaling_mode_property(dev); - psb_create_backlight_property(dev); + /* It is ok for this to fail - we just don't get backlight control */ + if (!dev_priv->backlight_property) + dev_priv->backlight_property = drm_property_create_range(dev, 0, + "backlight", 0, 100); dev_priv->ops->output_init(dev); list_for_each_entry(connector, &dev->mode_config.connector_list,

3 2

[GIT PULL][drm-next] drm: Add support for ARM HDLCD
by Liviu Dudau 05 Feb '16

05 Feb '16

Hi David, This is the DRM part of the ARM HDLCD driver. It has been included in linux-next for about a week and includes the Kconfig patches submitted by Arnd Bergman last week. Please pull into drm-next. Best regards, Liviu The following changes since commit 8a0d560f3e651808ae0a3d9ab9fe476e59de132b: drm/amdgpu/powerplay: include asm/div64.h for do_div() (2016-01-12 09:29:25 +1000) are available in the git repository at: git://linux-arm.org/linux-ld for-upstream/hdlcd for you to fetch changes up to 499ad2fdbe562f9e40c390d70690e26e2941ef27: MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver. (2016-01-13 12:28:54 +0000) ---------------------------------------------------------------- Liviu Dudau (3): drm: arm: Add DT bindings documentation for HDLCD driver. drm: Add support for ARM's HDLCD controller. MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver. .../devicetree/bindings/display/arm,hdlcd.txt | 79 +++ MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/arm/Kconfig | 27 + drivers/gpu/drm/arm/Makefile | 2 + drivers/gpu/drm/arm/hdlcd_crtc.c | 327 ++++++++++++ drivers/gpu/drm/arm/hdlcd_drv.c | 567 +++++++++++++++++++++ drivers/gpu/drm/arm/hdlcd_drv.h | 42 ++ drivers/gpu/drm/arm/hdlcd_regs.h | 87 ++++ 10 files changed, 1140 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt create mode 100644 drivers/gpu/drm/arm/Kconfig create mode 100644 drivers/gpu/drm/arm/Makefile create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h

1 1

[Bug 93721] Tonga [drm:amdgpu_vm_init [amdgpu]] *ERROR* Cannot allocate memory for page table array
by bugzilla-daemon＠freedesktop.org 05 Feb '16

05 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=93721 Bug ID: 93721 Summary: Tonga [drm:amdgpu_vm_init [amdgpu]] *ERROR* Cannot allocate memory for page table array Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com Created attachment 121052 --> https://bugs.freedesktop.org/attachment.cgi?id=121052&action=edit dmesg showing mem fail Been testing the latest agd5f drm-next-4.5 with powerplay=1. Nothings changed from previously reported issues, uvd still breaks powerplay and it's self, lockups with uvd possible. This particular boot I hadn't touched uvd or anything gl excepting glamor is always used. Was testing/benching vce which was going OK (apart from previously reported issue with UHD content). After I had finished testing I turned auto/down GPU/CPU which had been set high. memclk stayed stuck high. I then tried glxgears just to see if it would change the clocks. I got - libGL error: failed to open drm device: Cannot allocate memory libGL error: failed to load driver: radeonsi tried as user = same, tried glxinfo = same, did free = total used free shared buff/cache available Mem: 8139284 244600 340524 1519216 7554160 6314420 Swap: 4605948 0 4605948 Looks OK but as I had 1.5Gig in a ramdisk I deleted the file and then gl started working again - strange as I've done many tests with 6Gig in there and it just doesn't look like I was low on mem. Maybe you can see why from the memdumps in the dmesg. I haven't been able to reproduce this. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 93615] Tonga does not recover from standby
by bugzilla-daemon＠freedesktop.org 04 Feb '16

04 Feb '16

https://bugs.freedesktop.org/show_bug.cgi?id=93615 Bug ID: 93615 Summary: Tonga does not recover from standby Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: EoD(a)xmw.de Standby worked flawlessly on my BARTS (radeon/r600). With the TONGA (amdgpu/radeonsi) the system is not able to recover after the standby. Seems like a hard-lockup. I put my system into standby by doing: echo mem > /sys/power/state I tried both kernel 4.4-rc7 and the 4.5-drm-next branch. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[PATCH libdrm] android: enable building static version of libdrm
by Rob Herring 04 Feb '16

04 Feb '16

From: Sumit Semwal <sumit.semwal(a)linaro.org> Android needs libdrm built statically for recovery; enable that as well. Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> Signed-off-by: Rob Herring <robh(a)kernel.org> Cc: Chih-Wei Huang <cwhuang(a)linux.org.tw> Cc: Emil Velikov <emil.l.velikov(a)gmail.com> --- I posted this to mesa-dev, but I guess libdrm patches are supposed to go to dri-devel. Rob Android.mk | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/Android.mk b/Android.mk index 90cdcb3..1d8cd65 100644 --- a/Android.mk +++ b/Android.mk @@ -27,6 +27,8 @@ include $(CLEAR_VARS) # Import variables LIBDRM_{,H_,INCLUDE_H_,INCLUDE_VMWGFX_H_}FILES include $(LOCAL_PATH)/Makefile.sources +#static library for the device (recovery) +include $(CLEAR_VARS) LOCAL_MODULE := libdrm LOCAL_MODULE_TAGS := optional @@ -41,7 +43,24 @@ LOCAL_C_INCLUDES := \ LOCAL_CFLAGS := \ -DHAVE_VISIBILITY=1 \ -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +include $(BUILD_STATIC_LIBRARY) + +# Shared library for the device +include $(CLEAR_VARS) +LOCAL_MODULE := libdrm +LOCAL_MODULE_TAGS := optional +LOCAL_SRC_FILES := $(LIBDRM_FILES) +LOCAL_EXPORT_C_INCLUDE_DIRS := \ + $(LOCAL_PATH) \ + $(LOCAL_PATH)/include/drm + +LOCAL_C_INCLUDES := \ + $(LOCAL_PATH)/include/drm + +LOCAL_CFLAGS := \ + -DHAVE_VISIBILITY=1 \ + -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 include $(BUILD_SHARED_LIBRARY) include $(call all-makefiles-under,$(LOCAL_PATH)) -- 2.5.0

2 2

[PATCH v2 0/3] drm: adv7511: edid read fixes
by Wolfram Sang 03 Feb '16

03 Feb '16

So, here is my V2 of this series. Changes: * Added tags. Thanks to Laurent and Lars-Peter for review and to Archit for testing. Much appreciated! * rephrased the comment and commit message in patch 1 to be hopefully less confusing :) No code changes! Thanks, Wolfram Wolfram Sang (3): drm: adv7511: really enable interrupts for EDID detection drm: adv7511: mark ADV7511_REG_EDID_READ_CTRL volatile drm: adv7511: it's HPD, not HDP drivers/gpu/drm/i2c/adv7511.c | 48 ++++++++++++++++++++++++++----------------- drivers/gpu/drm/i2c/adv7511.h | 12 +++++------ 2 files changed, 35 insertions(+), 25 deletions(-) -- 2.1.4

2 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016