[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #47 from austin.hoppe7 at live.com --- Kernel 3.14-rc8 (with PRIME) + mesa 10.2-git (radeon driver with kms and dpm) Still the same issue, suspend + resume works fine but the laptop's screen does not turn back on. Using an external monitor confirms that the system itself is functional after resume. When running fglrx, there is no issue. HP dv6z 6100 CTO QE (ca. 2011). CPU: AMD 18-3510mx, iGPU: Radeon HD 6620g, dGPU: Radeon HD 6750m. -- 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/20140331/24a4eef5/attachment.html>
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 --- Comment #18 from John Lenz --- Just to confirm, I had this exact problem with mesa 10.1 and diablo 3, and the attached patch fixes the problem. I played for ~1.5 hours with no crash, when before it would crash within 2-3 minutes. -- 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/20140331/de7dafa0/attachment.html>
[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations
https://bugs.freedesktop.org/show_bug.cgi?id=76564 --- Comment #42 from Christian K?nig --- The only other option I'm aware of would be to adjust the modes to have a doable pixel clock. On modern displays we could for exampler increase the vertical blanking period slightly to make the mode hit a pixel clock that is exactly representable. -- 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/20140331/ffc2a837/attachment.html>
[RFC 1/4] drm: exynos: Add infrastructure to support FIMD post processors
Hi Ajay,
On 03/19/2014 03:22 PM, Ajay Kumar wrote:
> Exynos variants support post pocessors(PP) for FIMD (MDNIE and IELCD)
> which work closely with fimd. These post processors have strict
> dependency on FIMD for poweron/poweroff. This patch adds an
> infrastructure in FIMD driver to accomodate such devices.
>
> Added structure definition for FIMD PP and interfaces from FIMD
> driver to control FIMD PP.
>
> Signed-off-by: Ajay Kumar
> Signed-off-by: Shirish S
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 162
> +++
> drivers/gpu/drm/exynos/exynos_fimd_pp.h | 52 ++
> include/video/samsung_fimd.h | 6 +-
> 3 files changed, 219 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/exynos/exynos_fimd_pp.h
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index a5511be..a584d8e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -30,6 +30,7 @@
> #include "exynos_drm_fbdev.h"
> #include "exynos_drm_crtc.h"
> #include "exynos_drm_iommu.h"
> +#include "exynos_fimd_pp.h"
>
> /*
> * FIMD stands for Fully Interactive Mobile Display and
> @@ -113,11 +114,14 @@ struct fimd_context {
> void __iomem*regs;
> struct drm_display_mode mode;
> struct fimd_win_datawin_data[WINDOWS_NR];
> + struct list_headfimd_pp_list;
> unsigned intdefault_win;
> unsigned long irq_flags;
> u32 vidcon0;
> u32 vidcon1;
> boolsuspended;
> + boolenable_pp;
> + boolpp_running;
> int pipe;
> wait_queue_head_t wait_vsync_queue;
> atomic_twait_vsync_event;
> @@ -145,6 +149,12 @@ static inline struct fimd_driver_data
> *drm_fimd_get_driver_data(
> return (struct fimd_driver_data *)of_id->data;
> }
>
> +void fimd_add_pp_to_list(struct fimd_context *ctx,
> + struct exynos_fimd_pp *pp)
> +{
> + list_add_tail(&pp->list, &ctx->fimd_pp_list);
> +}
> +
> static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
> struct drm_device *drm_dev)
> {
> @@ -214,17 +224,49 @@ static void fimd_mode_set(struct exynos_drm_manager
> *mgr,
> const struct drm_display_mode *in_mode)
> {
> struct fimd_context *ctx = mgr->ctx;
> + struct exynos_fimd_pp *pp_display;
>
> drm_mode_copy(&ctx->mode, in_mode);
> +
> + /* mode_set for the post processors*/
> + list_for_each_entry(pp_display, &ctx->fimd_pp_list, list)
> + if (pp_display->ops->mode_set)
> + pp_display->ops->mode_set(pp_display->ctx, in_mode);
> +}
> +
> +static int fimd_wait_till_per_frame_off(struct fimd_context *ctx)
> +{
> + unsigned int val = readl(ctx->regs + VIDCON0);
> + int count = 10;
> +
> + val &= ~(VIDCON0_ENVID_F);
> + writel(val, ctx->regs + VIDCON0);
> +
> + while (count) {
> + val = readl(ctx->regs + VIDCON0);
> + if ((val & VIDCON0_ENVID_F) == 0)
> + break;
> + mdelay(17);
Do we really need mdelay here? This function is not called in atomic
context, is it?
> + count--;
> + }
> +
> + if (count == 0) {
> + DRM_ERROR("FIMD per frame switch off TIMEDOUT\n");
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> }
Have you tried to use interrupts/completion instead of busy-waiting
approach?
>
> static void fimd_commit(struct exynos_drm_manager *mgr)
> {
> struct fimd_context *ctx = mgr->ctx;
> struct drm_display_mode *mode = &ctx->mode;
> + struct exynos_fimd_pp *pp_display;
> struct fimd_driver_data *driver_data;
> u32 val, clkdiv, vidcon1;
> int hblank, vblank, vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
> + int ret = 0;
>
> driver_data = ctx->driver_data;
> if (ctx->suspended)
> @@ -234,6 +276,30 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> if (mode->htotal == 0 || mode->vtotal == 0)
> return;
>
> + /* The FIMD and the post processor(PP) poweroff calls below are needed
> + * here to make sure that fimd_commit doesn't switch on the PPs twice
> + * in a row. For proper working we need to keep fimd, and the PPs
> + * off, before we start again. This flag "pp_running" will also help
> + * in syncing any of the clock enable/disable calls in PP routines.
> + */
> + if (ctx->enable_pp && ctx->pp_running) {
> + if (fimd_wait_till_per_frame_off(ctx))
> + DRM_ERROR("failed to switch off fimd p
[PATCH 0/4] Two-ended allocation support
Cheers, This patchset is respun on top of today's drm-next. It has only been compile-tested, since my test computer is currently on strike in support of Ukraine. It was a simple spin though, so Mr. Murphy will likely stay away. Only Radeon behavior is affected, all other drivers have just compiling changes. - Lauri
[PATCH 1/4] drm: Optionally create mm blocks from top-to-bottom
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.
For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.
Original patch by Chris Wilson.
v2 by Ben:
Update callers in i915_gem_object_bind_to_gtt()
Turn search flags and allocation flags into separate enums
Make checkpatch happy where logical/easy
v3 by Ben:
Rebased on top of the many drm_mm changes since the original patches
Remove ATOMIC from allocator flags (Chris)
Reverse order of TOPDOWN and BOTTOMUP
v4 by Lauri:
Remove i915 parts, they don't apply
Respin on top of drm-next
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/drm_mm.c | 56 +++-
include/drm/drm_mm.h | 29 +
2 files changed, 66 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a2d45b74..1728bcc 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -102,7 +102,8 @@ static struct drm_mm_node
*drm_mm_search_free_in_range_generic(const struct drm_
static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
unsigned long size, unsigned alignment,
-unsigned long color)
+unsigned long color,
+enum drm_mm_allocator_flags flags)
{
struct drm_mm *mm = hole_node->mm;
unsigned long hole_start = drm_mm_hole_node_start(hole_node);
@@ -115,12 +116,22 @@ static void drm_mm_insert_helper(struct drm_mm_node
*hole_node,
if (mm->color_adjust)
mm->color_adjust(hole_node, color, &adj_start, &adj_end);
+ if (flags & DRM_MM_CREATE_TOP)
+ adj_start = adj_end - size;
+
if (alignment) {
unsigned tmp = adj_start % alignment;
- if (tmp)
- adj_start += alignment - tmp;
+ if (tmp) {
+ if (flags & DRM_MM_CREATE_TOP)
+ adj_start -= tmp;
+ else
+ adj_start += alignment - tmp;
+ }
}
+ BUG_ON(adj_start < hole_start);
+ BUG_ON(adj_end > hole_end);
+
if (adj_start == hole_start) {
hole_node->hole_follows = 0;
list_del(&hole_node->hole_stack);
@@ -215,16 +226,17 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
unsigned long size, unsigned alignment,
unsigned long color,
- enum drm_mm_search_flags flags)
+ enum drm_mm_search_flags sflags,
+ enum drm_mm_allocator_flags aflags)
{
struct drm_mm_node *hole_node;
hole_node = drm_mm_search_free_generic(mm, size, alignment,
- color, flags);
+ color, sflags);
if (!hole_node)
return -ENOSPC;
- drm_mm_insert_helper(hole_node, node, size, alignment, color);
+ drm_mm_insert_helper(hole_node, node, size, alignment, color, aflags);
return 0;
}
EXPORT_SYMBOL(drm_mm_insert_node_generic);
@@ -233,7 +245,8 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
struct drm_mm_node *node,
unsigned long size, unsigned alignment,
unsigned long color,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ enum drm_mm_allocator_flags flags)
{
struct drm_mm *mm = hole_node->mm;
unsigned long hole_start = drm_mm_hole_node_start(hole_node);
@@ -248,13 +261,20 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
if (adj_end > end)
adj_end = end;
+ if (flags & DRM_MM_CREATE_TOP)
+ adj_start = adj_end - size;
+
if (mm->color_adjust)
mm->color_adjust(hole_node, color, &adj_start, &adj_end);
if (alignment) {
unsigned tmp = adj_start % alignment;
- if (tmp)
- adj_start += alignment - tmp;
+ if (tmp) {
+ if (flags & DRM_MM_CREATE_TOP)
+
[PATCH 2/4] drm/ttm: Add optional support for two-ended allocation
Allocating small bos from one end and large ones from the other helps
improve the quality of fragmentation.
This depends on "drm: Optionally create mm blocks from top-to-bottom" by
Chris Wilson.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 16 +---
include/drm/ttm/ttm_bo_driver.h | 7 ++-
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9df79ac..caf7cd3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1453,7 +1453,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
struct ttm_bo_driver *driver,
struct address_space *mapping,
uint64_t file_page_offset,
- bool need_dma32)
+ bool need_dma32,
+ uint32_t alloc_threshold)
{
int ret = -EINVAL;
@@ -1476,6 +1477,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
bdev->dev_mapping = mapping;
bdev->glob = glob;
bdev->need_dma32 = need_dma32;
+ bdev->alloc_threshold = alloc_threshold;
bdev->val_seq = 0;
spin_lock_init(&bdev->fence_lock);
mutex_lock(&glob->device_list_mutex);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index c58eba33..db9fcb4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -55,6 +55,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
*man,
struct ttm_range_manager *rman = (struct ttm_range_manager *) man->priv;
struct drm_mm *mm = &rman->mm;
struct drm_mm_node *node = NULL;
+ enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
unsigned long lpfn;
int ret;
@@ -65,12 +66,21 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
*man,
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node)
return -ENOMEM;
+ /**
+* If the driver requested a threshold, use two-ended allocation.
+* Pinned buffers require bottom-up allocation.
+*/
+ if (man->bdev->alloc_threshold &&
+ !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT) &&
+ man->bdev->alloc_threshold < (mem->num_pages * PAGE_SIZE))
+ aflags = DRM_MM_CREATE_TOP;
spin_lock(&rman->lock);
- ret = drm_mm_insert_node_in_range(mm, node, mem->num_pages,
- mem->page_alignment,
+ ret = drm_mm_insert_node_in_range_generic(mm, node, mem->num_pages,
+ mem->page_alignment, 0,
placement->fpfn, lpfn,
- DRM_MM_SEARCH_BEST);
+ DRM_MM_SEARCH_BEST,
+ aflags);
spin_unlock(&rman->lock);
if (unlikely(ret)) {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5d8aabe..f5fe6df 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -565,6 +565,7 @@ struct ttm_bo_device {
struct delayed_work wq;
bool need_dma32;
+ uint32_t alloc_threshold;
};
/**
@@ -751,6 +752,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device
*bdev);
* @file_page_offset: Offset into the device address space that is available
* for buffer data. This ensures compatibility with other users of the
* address space.
+ * @alloc_threshold: If non-zero, use this as the threshold for two-ended
+ * allocation.
*
* Initializes a struct ttm_bo_device:
* Returns:
@@ -760,7 +763,9 @@ extern int ttm_bo_device_init(struct ttm_bo_device *bdev,
struct ttm_bo_global *glob,
struct ttm_bo_driver *driver,
struct address_space *mapping,
- uint64_t file_page_offset, bool need_dma32);
+ uint64_t file_page_offset,
+ bool need_dma32,
+ uint32_t alloc_threshold);
/**
* ttm_bo_unmap_virtual
--
1.8.3.1
[PATCH 3/4] drm: Update the drivers for the two-ended allocation param
This updates the other drivers to build, no-op behavior-wise.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 3 ++-
drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
9 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index b824622..61f9e39 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -262,7 +262,8 @@ int ast_mm_init(struct ast_private *ast)
&ast_bo_driver,
dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index f488be5..9dfd24a 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -228,7 +228,8 @@ int bochs_mm_init(struct bochs_device *bochs)
&bochs_bo_driver,
bochs->dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 92e6b77..74e8e21 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -262,7 +262,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
&cirrus_bo_driver,
dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9c52f68..489bc33 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3270,7 +3270,8 @@ search_free:
ret = drm_mm_insert_node_in_range_generic(&vm->mm, &vma->node,
size, alignment,
obj->cache_level, 0, gtt_max,
- DRM_MM_SEARCH_DEFAULT);
+ DRM_MM_SEARCH_DEFAULT,
+ DRM_MM_CREATE_DEFAULT);
if (ret) {
ret = i915_gem_evict_something(dev, vm, size, alignment,
obj->cache_level, flags);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 63a6dc7..dd72d35 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1072,7 +1072,8 @@ alloc:
&ppgtt->node, GEN6_PD_SIZE,
GEN6_PD_ALIGN, 0,
0, dev_priv->gtt.base.total,
- DRM_MM_SEARCH_DEFAULT);
+ DRM_MM_SEARCH_DEFAULT,
+ DRM_MM_CREATE_DEFAULT);
if (ret == -ENOSPC && !retried) {
ret = i915_gem_evict_something(dev, &dev_priv->gtt.base,
GEN6_PD_SIZE, GEN6_PD_ALIGN,
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 5a00e90..6844b24 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -262,7 +262,8 @@ int mgag200_mm_init(struct mga_device *mdev)
&mgag200_bo_driver,
dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
[PATCH 4/4] drm/radeon: Use two-ended allocation with a 512kb threshold
This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases improved slightly (openarena, urban
terror).
512kb was measured as the most optimal threshold for 3d workloads common to
radeon.
Other drivers may need different thresholds according to their workloads.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index c8a8a51..1aef339 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -710,7 +710,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
&radeon_bo_driver,
rdev->ddev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
- rdev->need_dma32);
+ rdev->need_dma32,
+ 512 * 1024);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
--
1.8.3.1
[PATCH 2/4] drm/ttm: Add optional support for two-ended allocation
Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen:
> Allocating small bos from one end and large ones from the other helps
> improve the quality of fragmentation.
>
> This depends on "drm: Optionally create mm blocks from top-to-bottom" by
> Chris Wilson.
>
You are breaking bisectability here. This patch deliberately introduces
a build failure that you only fix up in the next two patches. This isn't
acceptable, you must squash the following patches in to avoid the
breakage.
Also if the first patch is from Chris Wilson and you only did some small
changes this should be reflected in the author name of the patch.
> Signed-off-by: Lauri Kasanen
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 16 +---
> include/drm/ttm/ttm_bo_driver.h | 7 ++-
> 3 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 9df79ac..caf7cd3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1453,7 +1453,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> struct ttm_bo_driver *driver,
> struct address_space *mapping,
> uint64_t file_page_offset,
> -bool need_dma32)
> +bool need_dma32,
> +uint32_t alloc_threshold)
> {
> int ret = -EINVAL;
>
> @@ -1476,6 +1477,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> bdev->dev_mapping = mapping;
> bdev->glob = glob;
> bdev->need_dma32 = need_dma32;
> + bdev->alloc_threshold = alloc_threshold;
> bdev->val_seq = 0;
> spin_lock_init(&bdev->fence_lock);
> mutex_lock(&glob->device_list_mutex);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> index c58eba33..db9fcb4 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> @@ -55,6 +55,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
> *man,
> struct ttm_range_manager *rman = (struct ttm_range_manager *) man->priv;
> struct drm_mm *mm = &rman->mm;
> struct drm_mm_node *node = NULL;
> + enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> unsigned long lpfn;
> int ret;
>
> @@ -65,12 +66,21 @@ static int ttm_bo_man_get_node(struct
> ttm_mem_type_manager *man,
> node = kzalloc(sizeof(*node), GFP_KERNEL);
> if (!node)
> return -ENOMEM;
> + /**
> + * If the driver requested a threshold, use two-ended allocation.
> + * Pinned buffers require bottom-up allocation.
> + */
> + if (man->bdev->alloc_threshold &&
> + !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT) &&
> + man->bdev->alloc_threshold < (mem->num_pages * PAGE_SIZE))
> + aflags = DRM_MM_CREATE_TOP;
>
> spin_lock(&rman->lock);
> - ret = drm_mm_insert_node_in_range(mm, node, mem->num_pages,
> - mem->page_alignment,
> + ret = drm_mm_insert_node_in_range_generic(mm, node, mem->num_pages,
> + mem->page_alignment, 0,
> placement->fpfn, lpfn,
> - DRM_MM_SEARCH_BEST);
> + DRM_MM_SEARCH_BEST,
> + aflags);
> spin_unlock(&rman->lock);
>
> if (unlikely(ret)) {
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 5d8aabe..f5fe6df 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -565,6 +565,7 @@ struct ttm_bo_device {
> struct delayed_work wq;
>
> bool need_dma32;
> + uint32_t alloc_threshold;
> };
>
> /**
> @@ -751,6 +752,8 @@ extern int ttm_bo_device_release(struct ttm_bo_device
> *bdev);
> * @file_page_offset: Offset into the device address space that is available
> * for buffer data. This ensures compatibility with other users of the
> * address space.
> + * @alloc_threshold: If non-zero, use this as the threshold for two-ended
> + * allocation.
> *
> * Initializes a struct ttm_bo_device:
> * Returns:
> @@ -760,7 +763,9 @@ extern int ttm_bo_device_init(struct ttm_bo_device *bdev,
> struct ttm_bo_global *glob,
> struct ttm_bo_driver *driver,
> struct address_space *mapping,
> - uint64_t file_page_offset, bool need_dma32);
> + uint64_t file_page_offset,
> + bool need_dma32,
> + uint32_t alloc_threshold);
>
> /**
> * ttm_bo_unmap_virtual
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions
[Bug 76659] Display does not return from DPMS off using ATI drivers
https://bugs.freedesktop.org/show_bug.cgi?id=76659 --- Comment #6 from Tyler Brock --- Created attachment 96662 --> https://bugs.freedesktop.org/attachment.cgi?id=96662&action=edit System returning from lock-screen sleep Today when I woke the computer it had a black screen, switching to terminal showed the terminal shifted from off center (usually the login text appears at the top left of the screen). -- 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/20140331/3a53ac2d/attachment.html>
[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations
https://bugs.freedesktop.org/show_bug.cgi?id=76564 --- Comment #43 from Alex Deucher --- We could also update the adjusted mode clock to the actual clock set by the pll so that drm_calc_timestamping_constants() uses the actual clock value on the PLL. E.g., diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index daa4dd3..2a2da82 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1085,6 +1085,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode atombios_crtc_program_ss(rdev, ATOM_ENABLE, radeon_crtc->pll_id, radeon_crtc->crtc_id, &radeon_crtc->ss); } + mode->clock = pll_clock * 10; } static int dce4_crtc_do_set_base(struct drm_crtc *crtc, -- 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/20140331/56b1bd99/attachment.html>
[Bug 76659] Display does not return from DPMS off using ATI drivers
https://bugs.freedesktop.org/show_bug.cgi?id=76659 Alex Deucher changed: What|Removed |Added Attachment #96662|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/45faf8bc/attachment.html>
[Bug 73291] New: Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 Bug ID: 73291 Summary: Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen Product: Drivers Version: 2.5 Kernel Version: 3.13.7 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: mike.cloaked at gmail.com Regression: No Created attachment 131071 --> https://bugzilla.kernel.org/attachment.cgi?id=131071&action=edit systemd journal for current boot with kernel 3.13.6 Running arch linux stock kernel. Previous Kernel 3.13.6 boots to graphical screen giving a usable laptop but problems with radeon apparent from systemd journal log. Updating the kernel to 3.13.7 boots the laptop, but the graphical screen is blank apart from static cursor at top left of the screen. The kernel is still running and able to ssh in to get at the log files (attached). No graphics is usable. Hybrid graphics in this Lenovo Thinkpad S540 is: $ lspci | egrep '(Graphics|Display)' 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) 06:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A] i915 and radeon modules are built into the initial ramdisk. xrandr only sees one provider: $ xrandr --listproviders Providers: number : 1 Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel I have tried adding intel.modeset=0, and separately radeon.runpm=0 to the kernel line but this does not remedy the situation. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #1 from Mike Cloaked --- Created attachment 131081 --> https://bugzilla.kernel.org/attachment.cgi?id=131081&action=edit xorg log for kernel 3.13.6 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #2 from Mike Cloaked --- Created attachment 131091 --> https://bugzilla.kernel.org/attachment.cgi?id=131091&action=edit systemd journal for current boot with kernel 3.13.7 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #3 from Mike Cloaked --- Created attachment 131101 --> https://bugzilla.kernel.org/attachment.cgi?id=131101&action=edit xorg log for kernel 3.13.7 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76840] New: HybridGraphics: Kernel driver in use: radeon but adapter not listed
181] [drm] vram apper at 0xA000 [4.750182] [drm] size 3145728 [4.750183] [drm] fb depth is 24 [4.750184] [drm]pitch is 4096 [4.750269] radeon :03:00.0: fb1: radeondrmfb frame buffer device [4.751709] [drm] Initialized radeon 2.37.0 20080528 for :03:00.0 on minor 1 However, xrandr, inxi and glxinfo (noone except lspci) won't show the radeon device. Starting X with device configured as radeon, crashes with the error (EE) no screens found(EE) LIBGL_DEBUG=verbose DRI_PRIME=0 glxgears libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 305 frames in 5.0 seconds = 60.952 FPS 301 frames in 5.0 seconds = 60.000 FPS LIBGL_DEBUG=verbose DRI_PRIME=1 glxgears libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 36463 frames in 5.0 seconds = 7292.515 FPS 35941 frames in 5.0 seconds = 7188.027 FPS 35969 frames in 5.0 seconds = 7193.778 FPS 35990 frames in 5.0 seconds = 7197.914 FPS 36353 frames in 5.0 seconds = 7270.465 FPS 36544 frames in 5.0 seconds = 7308.674 FPS 36281 frames in 5.0 seconds = 7256.154 FPS mike-g337 tmp # DRI_PRIME=0 glxinfo | grep 'OpenGL render' OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile mike-g337 tmp # DRI_PRIME=1 glxinfo | grep 'OpenGL render' OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile Attached is a file containing: xorg.conf Xorg.0.log - intel device Xorg.0.log - radeon device Xorg.1.log intel device lspci -kvvv dmesg inxi -G glxinfo xrandr --listproviders fglrx Xorg.1.log Hope it helps. Thank you in advance, Mike. -- 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/20140331/1bd99a9a/attachment-0001.html>
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #4 from Mike Cloaked --- The system is dual boot arch linux and Windows 8.1, boot is UEFI using the rEFInd boot manager, but that should not be relevant to the fail mode reported in this bugzilla. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/4] drm/ttm: Add optional support for two-ended allocation
On Mon, 31 Mar 2014 14:41:05 +0200 Lucas Stach wrote: > Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen: > > Allocating small bos from one end and large ones from the other helps > > improve the quality of fragmentation. > > > > This depends on "drm: Optionally create mm blocks from top-to-bottom" by > > Chris Wilson. > > > You are breaking bisectability here. This patch deliberately introduces > a build failure that you only fix up in the next two patches. This isn't > acceptable, you must squash the following patches in to avoid the > breakage. > > Also if the first patch is from Chris Wilson and you only did some small > changes this should be reflected in the author name of the patch. OK, will squash and resend. Then the changes are mostly mine in the singular patch. BTW, how would I handle the case of a different author, when I cannot use git-send-email due to network mail restrictions? I can't send email from an address I don't own. - Lauri
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #1 from Alex Deucher --- There are no displays connected to the radeon card. You can only use it for rendering, not display. You need to set up the radeon card to be used as an offload sink. Additionally, you need to be sunning a compositor. xrandr --listproviders xrandr --setprovideroffloadsink radeon Intel -- 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/20140331/23560376/attachment.html>
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #5 from Alex Deucher --- The radeon driver appears to be loading fine. Additionally, there are no displays connected to the radeon so it will only be used when you set it up as an offload sink. The warning in your kernel logs appear to be from the intel driver: Mar 31 15:01:10 lenovo1 kernel: [ cut here ] Mar 31 15:01:10 lenovo1 kernel: WARNING: CPU: 1 PID: 57 at drivers/gpu/drm/i915/intel_opregion.c:266 swsci+0x2ec/0x300 [i915]() Mar 31 15:01:10 lenovo1 kernel: excessive driver sleep timeout (DSPL) 1280 Mar 31 15:01:10 lenovo1 kernel: Modules linked in: i915(+) video button intel_agp intel_gtt radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core Mar 31 15:01:10 lenovo1 kernel: CPU: 1 PID: 57 Comm: modprobe Not tainted 3.13.6-1-ARCH #1 Mar 31 15:01:10 lenovo1 kernel: Hardware name: LENOVO 20B3CTO1WW/20B3CTO1WW, BIOS GPET54WW (1.54 ) 02/19/2014 Mar 31 15:01:10 lenovo1 kernel: 0009 880221de7810 81513274 880221de7858 Mar 31 15:01:10 lenovo1 kernel: 880221de7848 81061a3d c9c68218 880221d6 Mar 31 15:01:10 lenovo1 kernel: 01f4 0008 880221de7920 880221de78a8 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #2 from Michael Eagle --- And how can I --setprovideroffloadsink if xrandr --listproviders only shows Intel device? -- 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/20140331/63a9a842/attachment.html>
[PATCH] drm: Add support for two-ended allocation
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.
For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.
Based on drm_mm work by Chris Wilson.
--
Radeon uses a 512kb threshold.
This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases improved slightly (openarena, urban
terror).
512kb was measured as the most optimal threshold for 3d workloads common to
radeon.
Other drivers may need different thresholds according to their workloads.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 3 +-
drivers/gpu/drm/bochs/bochs_mm.c | 3 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 3 +-
drivers/gpu/drm/drm_mm.c | 56 +--
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +-
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 16 --
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/drm_mm.h | 29 +++---
include/drm/ttm/ttm_bo_driver.h | 7 -
15 files changed, 105 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index b824622..61f9e39 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -262,7 +262,8 @@ int ast_mm_init(struct ast_private *ast)
&ast_bo_driver,
dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index f488be5..9dfd24a 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -228,7 +228,8 @@ int bochs_mm_init(struct bochs_device *bochs)
&bochs_bo_driver,
bochs->dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 92e6b77..74e8e21 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -262,7 +262,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
&cirrus_bo_driver,
dev->anon_inode->i_mapping,
DRM_FILE_PAGE_OFFSET,
-true);
+true,
+0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a2d45b74..1728bcc 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -102,7 +102,8 @@ static struct drm_mm_node
*drm_mm_search_free_in_range_generic(const struct drm_
static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
unsigned long size, unsigned alignment,
-unsigned long color)
+unsigned long color,
+enum drm_mm_allocator_flags flags)
{
struct drm_mm *mm = hole_node->mm;
unsigned long hole_start = drm_mm_hole_node_start(hole_node);
@@ -115,12 +116,22 @@ static void drm_mm_insert_helper(struct drm_mm_node
*hole_node,
if (mm->color_adjust)
mm->color_adjust(hole_node, color, &adj_start, &adj_end);
+ if (flags & DRM_MM_CREATE_TOP)
+ adj_start = adj_end - size;
+
if (alignment) {
unsigned tmp = adj_start % alignment;
- if (tmp)
- adj_start += alignment - tmp;
+ if
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #3 from Alex Deucher --- Remove your xorg.conf and try again. -- 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/20140331/9ddd5a7c/attachment.html>
[PATCH 2/4] drm/ttm: Add optional support for two-ended allocation
Am Montag, den 31.03.2014, 17:51 +0300 schrieb Lauri Kasanen: > On Mon, 31 Mar 2014 14:41:05 +0200 > Lucas Stach wrote: > > > Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen: > > > Allocating small bos from one end and large ones from the other helps > > > improve the quality of fragmentation. > > > > > > This depends on "drm: Optionally create mm blocks from top-to-bottom" by > > > Chris Wilson. > > > > > You are breaking bisectability here. This patch deliberately introduces > > a build failure that you only fix up in the next two patches. This isn't > > acceptable, you must squash the following patches in to avoid the > > breakage. > > > > Also if the first patch is from Chris Wilson and you only did some small > > changes this should be reflected in the author name of the patch. > > OK, will squash and resend. Then the changes are mostly mine in the > singular patch. > > BTW, how would I handle the case of a different author, when I cannot > use git-send-email due to network mail restrictions? I can't send email > from an address I don't own. > You should send it from your address, but start the patch description with a line "From: Original Author ", so git picks up the proper authorship. Git send-email does this the same way. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] drm: Make drm_clflush_virt_range() void*
From: Ville Syrj?l?
Currently drm_cflush_virt_rage() takes a char* so the caller probably
has to do pointless casting to avoid compiler warnings. Make the
argument void* instead to avoid such issues.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_cache.c | 3 ++-
include/drm/drmP.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index bb8f580..be7046e 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -125,10 +125,11 @@ drm_clflush_sg(struct sg_table *st)
EXPORT_SYMBOL(drm_clflush_sg);
void
-drm_clflush_virt_range(char *addr, unsigned long length)
+drm_clflush_virt_range(void *virt, unsigned long length)
{
#if defined(CONFIG_X86)
if (cpu_has_clflush) {
+ char *addr = virt;
char *end = addr + length;
mb();
for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2f49510..330e868 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1294,7 +1294,7 @@ extern int drm_remove_magic(struct drm_master *master,
drm_magic_t magic);
/* Cache management (drm_cache.c) */
void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
void drm_clflush_sg(struct sg_table *st);
-void drm_clflush_virt_range(char *addr, unsigned long length);
+void drm_clflush_virt_range(void *virt, unsigned long length);
/* Locking IOCTL support (drm_lock.h) */
extern int drm_lock(struct drm_device *dev, void *data,
--
1.8.3.2
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 --- Comment #7 from Tom Stellard --- Is there anything printed to your dmesg log when the game locks up? -- 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/20140331/458cfa9b/attachment.html>
drm/msm: msm-next for 3.15-rc1 (plus one omapdrm)
Dave, Here are the msm patches for 3.15, plus one omapdrm patch from Laurent. I checked with Tomi and he didn't have anything to send at the moment for 3.15-rc1, so I'm including Laurent's patch as a favor. BR, -R The following changes since commit c32fc9c803f8ed90a7548810de48ca33a3020168: Merge tag 'vmwgfx-next-2014-03-28' of git://people.freedesktop.org/~thomash/linux into drm-next (2014-03-31 11:29:38 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux msm-next for you to fetch changes up to 06fb220b2d1a80be5621fa06ef276a3890e6be78: drm/omap: Don't dereference list head when the connectors list is empty (2014-03-31 11:06:51 -0400) Laurent Pinchart (1): drm/omap: Don't dereference list head when the connectors list is empty Rob Clark (8): drm/msm: hdmi audio support drm/msm: add hang_debug module param drm/msm: spin helper drm/msm: crank down gpu when inactive drm/msm: add chip-id param drm/msm: use componentised device support drm/msm: validate flags, etc drm/msm/mdp: add timeout for irq wait drivers/gpu/drm/msm/Makefile| 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 105 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 65 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 16 +- drivers/gpu/drm/msm/hdmi/hdmi.c | 50 -- drivers/gpu/drm/msm/hdmi/hdmi.h | 25 +++ drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 273 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 26 ++- drivers/gpu/drm/msm/mdp/mdp_kms.c | 3 +- drivers/gpu/drm/msm/msm_drv.c | 139 +++- drivers/gpu/drm/msm/msm_drv.h | 4 + drivers/gpu/drm/msm/msm_gem_submit.c| 15 +- drivers/gpu/drm/msm/msm_gpu.c | 85 +- drivers/gpu/drm/msm/msm_gpu.h | 16 +- drivers/gpu/drm/omapdrm/omap_fb.c | 3 +- include/uapi/drm/msm_drm.h | 12 ++ 16 files changed, 742 insertions(+), 96 deletions(-) create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_audio.c
[PATCH] drm/radeon: call drm_edid_to_eld when we update the edid
This needs to be done to update some of the fields in
the connector structure used by the audio code.
Noticed by several users on irc.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index fbd8b93..6e6f82c 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -792,6 +792,7 @@ int radeon_ddc_get_modes(struct radeon_connector
*radeon_connector)
if (radeon_connector->edid) {
drm_mode_connector_update_edid_property(&radeon_connector->base,
radeon_connector->edid);
ret = drm_add_edid_modes(&radeon_connector->base,
radeon_connector->edid);
+ drm_edid_to_eld(&radeon_connector->base,
radeon_connector->edid);
return ret;
}
drm_mode_connector_update_edid_property(&radeon_connector->base, NULL);
--
1.8.3.1
[PATCH] drm/radeon: rework finding display PLL numbers v2
On Sun, Mar 30, 2014 at 4:22 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This completely reworks how the PLL parameters are generated and
> should result in better matching dot clock frequencies.
>
> Probably needs quite a bit of testing.
>
> bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76564
>
> v2: more cleanup and comments.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 243
>
> 1 file changed, 153 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index fbd8b93..4e83ffd 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -34,6 +34,8 @@
> #include
> #include
>
> +#include
> +
> static void avivo_crtc_load_lut(struct drm_crtc *crtc)
> {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> @@ -799,66 +801,57 @@ int radeon_ddc_get_modes(struct radeon_connector
> *radeon_connector)
> }
>
> /* avivo */
> -static void avivo_get_fb_div(struct radeon_pll *pll,
> -u32 target_clock,
> -u32 post_div,
> -u32 ref_div,
> -u32 *fb_div,
> -u32 *frac_fb_div)
> -{
> - u32 tmp = post_div * ref_div;
>
> - tmp *= target_clock;
> - *fb_div = tmp / pll->reference_freq;
> - *frac_fb_div = tmp % pll->reference_freq;
> -
> -if (*fb_div > pll->max_feedback_div)
> - *fb_div = pll->max_feedback_div;
> -else if (*fb_div < pll->min_feedback_div)
> -*fb_div = pll->min_feedback_div;
> -}
> -
> -static u32 avivo_get_post_div(struct radeon_pll *pll,
> - u32 target_clock)
> +/**
> + * avivo_reduce_ratio - fractional number reduction
> + *
> + * @nom: nominator
> + * @den: denominator
> + * @nom_min: minimum value for nominator
> + * @den_min: minimum value for denominator
> + *
> + * Find the greatest common divisor and apply it on both nominator and
> + * denominator, but make nominator and denominator are at least as large
> + * as their minimum values.
> + */
> +static void avivo_reduce_ratio(unsigned *nom, unsigned *den,
> + unsigned nom_min, unsigned den_min)
> {
> - u32 vco, post_div, tmp;
> -
> - if (pll->flags & RADEON_PLL_USE_POST_DIV)
> - return pll->post_div;
> -
> - if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
> - if (pll->flags & RADEON_PLL_IS_LCD)
> - vco = pll->lcd_pll_out_min;
> - else
> - vco = pll->pll_out_min;
> - } else {
> - if (pll->flags & RADEON_PLL_IS_LCD)
> - vco = pll->lcd_pll_out_max;
> - else
> - vco = pll->pll_out_max;
> + unsigned tmp;
> +
> + /* reduce the numbers to a simpler ratio */
> + tmp = gcd(*nom, *den);
> + *nom /= tmp;
> + *den /= tmp;
> +
> + /* make sure nominator is large enough */
> +if (*nom < nom_min) {
> + tmp = (nom_min + *nom - 1) / *nom;
> + *nom *= tmp;
> + *den *= tmp;
> }
>
> - post_div = vco / target_clock;
> - tmp = vco % target_clock;
> -
> - if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
> - if (tmp)
> - post_div++;
> - } else {
> - if (!tmp)
> - post_div--;
> + /* make sure the denominator is large enough */
> + if (*den < den_min) {
> + tmp = (den_min + *den - 1) / *den;
> + *nom *= tmp;
> + *den *= tmp;
> }
> -
> - if (post_div > pll->max_post_div)
> - post_div = pll->max_post_div;
> - else if (post_div < pll->min_post_div)
> - post_div = pll->min_post_div;
> -
> - return post_div;
> }
>
> -#define MAX_TOLERANCE 10
> -
> +/**
> + * radeon_compute_pll_avivo - compute PLL paramaters
> + *
> + * @pll: information about the PLL
> + * @dot_clock_p: resulting pixel clock
> + * fb_div_p: resulting feedback divider
> + * frac_fb_div_p: fractional part of the feedback divider
> + * ref_div_p: resulting reference divider
> + * post_div_p: resulting reference divider
> + *
> + * Try to calculate the PLL parameters to generate the given frequency:
> + * dot_clock = (ref_freq * feedback_div) / (ref_div * post_div)
> + */
> void radeon_compute_pll_avivo(struct radeon_pll *pll,
> u32 freq,
> u32 *dot_clock_p,
> @@ -867,53 +860,123 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> u32 *ref_div_p,
> u32 *post_div_p)
> {
> - u32 ta
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #4 from Michael Eagle --- Created attachment 96671 --> https://bugs.freedesktop.org/attachment.cgi?id=96671&action=edit crash -- 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/20140331/e07f5449/attachment.html>
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #5 from Michael Eagle --- Created attachment 96672 --> https://bugs.freedesktop.org/attachment.cgi?id=96672&action=edit crashimg2 -- 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/20140331/83a766cd/attachment.html>
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #6 from Michael Eagle --- Created attachment 96673 --> https://bugs.freedesktop.org/attachment.cgi?id=96673&action=edit crashimg3 -- 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/20140331/f474f628/attachment.html>
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #6 from Mike Cloaked --- Perhaps this warning will not occur when kernel 3.14.x is used when it is released to arch in the near future. I presume that new patches in kernel 3.13.7 makes the difference between a successful boot to graphical screen in 3.13.6 and fail in 3.13.7 but it would be nice to know if there is a workaround until this is resolved in kernel > 3.13.7? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed
https://bugs.freedesktop.org/show_bug.cgi?id=76840 --- Comment #7 from Michael Eagle --- Sorry, seems like the comment I entered just vanished, So, without my xorg conf, X server crashes with the following: (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 31 18:11:05 2014 (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX (II) [KMS] Kernel modesetting enabled. X: ../../../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed. If I restart mdm once again or if I execute, startx. Then the system hangs, and I can't access any VTYs but I can reboot with CTRL + Alt + del. However, if I rmmod the radeon driver and then modprobe it once again. I get kernel panic, and I could only reboot from the powerbutton. Attached images from above represents crash backtrace messages after modprobe fails. Hope it helps, Thank you. -- 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/20140331/212e69ef/attachment.html>
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #7 from Alex Deucher --- (In reply to Mike Cloaked from comment #6) > Perhaps this warning will not occur when kernel 3.14.x is used when it is > released to arch in the near future. I presume that new patches in kernel > 3.13.7 makes the difference between a successful boot to graphical screen in > 3.13.6 and fail in 3.13.7 but it would be nice to know if there is a > workaround until this is resolved in kernel > 3.13.7? Can you bisect? If the warning is related to the problem, it's an intel driver issue rather than a radeon driver issue. Does the system work ok if you blacklist the radeon driver? E.g., add modprobe.blacklist=radeon to the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: Make drm_clflush_virt_range() void*
On Mon, Mar 31, 2014 at 06:08:51PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Currently drm_cflush_virt_rage() takes a char* so the caller probably > has to do pointless casting to avoid compiler warnings. Make the > argument void* instead to avoid such issues. > > Signed-off-by: Ville Syrj?l? Can we not use a gcc'ism to allow pointer arithmetic on void *? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #8 from Mike Cloaked --- What I am seeing seems to be the same as in the Fedora bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1070219 I don't have the system set up for bisecting. However I will boot with the radeon driver blacklisted and report back. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon: call drm_edid_to_eld when we update the edid
Am 31.03.2014 17:19, schrieb Alex Deucher:
> This needs to be done to update some of the fields in
> the connector structure used by the audio code.
>
> Noticed by several users on irc.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Added to my drm-next-3.15 branch.
Thanks,
Christian.
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index fbd8b93..6e6f82c 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -792,6 +792,7 @@ int radeon_ddc_get_modes(struct radeon_connector
> *radeon_connector)
> if (radeon_connector->edid) {
>
> drm_mode_connector_update_edid_property(&radeon_connector->base,
> radeon_connector->edid);
> ret = drm_add_edid_modes(&radeon_connector->base,
> radeon_connector->edid);
> + drm_edid_to_eld(&radeon_connector->base,
> radeon_connector->edid);
> return ret;
> }
> drm_mode_connector_update_edid_property(&radeon_connector->base, NULL);
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #9 from Mike Cloaked --- Booting with modprobe.blacklist=radeon added to the kernel line in the rEFInd boot manager gives a successful boot to a graphical screen. So thank you, this is a workaround for the present. I can upload the systemd journal for this boot if it is useful? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations
https://bugs.freedesktop.org/show_bug.cgi?id=76564 --- Comment #44 from jeroen --- (In reply to comment #43) > We could also update the adjusted mode clock to the actual clock set by the > pll so that drm_calc_timestamping_constants() uses the actual clock value on > the PLL. E.g., > > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c > b/drivers/gpu/drm/radeon/atombios_crtc.c > index daa4dd3..2a2da82 100644 > --- a/drivers/gpu/drm/radeon/atombios_crtc.c > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c > @@ -1085,6 +1085,7 @@ static void atombios_crtc_set_pll(struct drm_crtc > *crtc, struct drm_display_mode > atombios_crtc_program_ss(rdev, ATOM_ENABLE, > radeon_crtc->pll_id, > radeon_crtc->crtc_id, > &radeon_crtc->ss); > } > + mode->clock = pll_clock * 10; > } > > static int dce4_crtc_do_set_base(struct drm_crtc *crtc, I think that would only help if radeon_compute_pll_avivo could not compute an exact match. In the case of 23.976Hz the target clock is 74170kHz and the PLL is set exactly to this value. This does raise another question why the target clock' last digit is always zero? For example, for 23.976Hz the target clock should be 74176kHz (with correct rounding). I looked through the source code, but the target clock seems to come all the way from some deep generic drm code. 74176kHz could be matched by the PLL using fb=927.2, post_div=10 and ref_div=125 -- 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/20140331/be7fa3c4/attachment.html>
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #10 from Mike Cloaked --- Created attachment 13 --> https://bugzilla.kernel.org/attachment.cgi?id=13&action=edit systemd journal with 3.13.7 booted with radeon module blacklisted -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #11 from Mike Cloaked --- For completeness I removed the radeon module from the initial ramdisk, and added: install radeon /bin/false to the file /etc/modprobe.d/blacklist.conf Now the system boots to a working graphical screen for kernel 3.13.7 with only the Intel i915 running. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: Make drm_clflush_virt_range() void*
On Mon, Mar 31, 2014 at 04:40:47PM +0100, Chris Wilson wrote: > On Mon, Mar 31, 2014 at 06:08:51PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > Currently drm_cflush_virt_rage() takes a char* so the caller probably > > has to do pointless casting to avoid compiler warnings. Make the > > argument void* instead to avoid such issues. > > > > Signed-off-by: Ville Syrj?l? > > Can we not use a gcc'ism to allow pointer arithmetic on void *? Personally I'd be fine with that. So if no one disagrees I can send a v2. -- Ville Syrj?l? Intel OTC
crtc ganging in KMS, "large" displays, etc
I thought I'd kick off a thread to better discuss how to deal with "large" displays which need multiple crtcs/planes merged to deal without output larger than a certain width. What I have in mind basically amounts to driver-custom-properties and shouldn't really need much/anything in the way of drm core or helper support[1]. There may of course be some room to make helpers/core more aware of crtc ganging if it turns out to be something that many drivers are doing in the same way. But to start with my bigger concern is getting the userspace interface right. This is semi-related to a thread started earlier by Aaron Plattner on xorg-devel: http://lists.freedesktop.org/archives/xorg-devel/2014-January/039984.html As I see it, there are really two different scenarios: 1) single encoder/connector: double up on planes (pipes) and crtcs (mixers), but still a single connector. 2) double up entire pipe.. this scenario is more like what Aaron mentioned. This could mean using multiple DVI or HDMI connectors, or multiple DSI channels. In the DSI case, I'm not entirely sure yet the implications for a dsi panel driver, but I think it needs to be a bit aware. --- For the first scenario, the approach I am leaning towards is a 'SLAVE_CRTC'[2] property on the crtc. The idea being that userspace could pick an otherwise unused CRTC, and assign it as a slave in order to enable higher resolutions. The primary crtc could use the slave's mixer and primary plane. The existing encoder->possible_crtcs would be used by userspace to figure out which crtc(s) it could pick to use as a slave. The property approach seems like it should fit in nicely with the plans for atomic. The driver can decide whether a given mode is possible during the atomic 'test' step based on the proposed SLAVE_CRTC value. We do possibly get funny edge cases where a CRTC isn't yet available but will be after next vblank, but this is basically the same scenario with have already with moving planes between crtcs (and where an EBUSY or similar return value from atomic would make sense). For non-primary planes, it may be sufficient to expose max width/height dimensions and let userspace figure out when it needs to use multiple planes for a single layer. For the second scenario, I am less sure. We could of course also have some sort of 'SLAVE_CONNECTOR' property (since encoders themselves don't currently have/need properties). But this probably depends on the outcome of the xorg/xrandr userspace discussion. Anyways, I'd of course be interested to hear from others who will have to tackle the same problem in their own drivers, whether the 'SLAVE_CRTC' approach works for them or not, etc. It looks like the first scenario is something I'll get to deal with pretty soon now (ie. approximately as soon as I buy myself a 4k DP monitor ;-)) BR, -R [1] assuming it is acceptable for initial modeset for fbcon picking a lower resolution which can be supported without a slave encoder. Most/all phones/tablets disable fbcon, so this doesn't seem like it should be a problem.. [2] if anyone envisions scenarios where we need to gang more than 2 crtcs, we could invert the property, and have 'PRIMARY_CRTC' property that gets set on each of the slaves.
[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations
https://bugs.freedesktop.org/show_bug.cgi?id=76564 Christian K?nig changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment #45 from Christian K?nig --- (In reply to comment #44) > (In reply to comment #43) > > We could also update the adjusted mode clock to the actual clock set by the > > pll so that drm_calc_timestamping_constants() uses the actual clock value on > > the PLL. E.g., > > > > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c > > b/drivers/gpu/drm/radeon/atombios_crtc.c > > index daa4dd3..2a2da82 100644 > > --- a/drivers/gpu/drm/radeon/atombios_crtc.c > > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c > > @@ -1085,6 +1085,7 @@ static void atombios_crtc_set_pll(struct drm_crtc > > *crtc, struct drm_display_mode > > atombios_crtc_program_ss(rdev, ATOM_ENABLE, > > radeon_crtc->pll_id, > > radeon_crtc->crtc_id, > > &radeon_crtc->ss); > > } > > + mode->clock = pll_clock * 10; > > } > > > > static int dce4_crtc_do_set_base(struct drm_crtc *crtc, > > I think that would only help if radeon_compute_pll_avivo could not compute > an exact match. In the case of 23.976Hz the target clock is 74170kHz and the > PLL is set exactly to this value. > This does raise another question why the target clock' last digit is always > zero? For example, for 23.976Hz the target clock should be 74176kHz (with > correct rounding). I looked through the source code, but the target clock > seems to come all the way from some deep generic drm code. > > 74176kHz could be matched by the PLL using fb=927.2, post_div=10 and > ref_div=125 You might want to take a look at atombios_adjust_pll which does the mode fixup before a mode is actually used. Since atombios always works with 10khz pixel clock which always sets the target clocks last digit to zero. -- 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/20140331/edfa0382/attachment-0001.html>
[Intel-gfx] [PATCH] drm/edid: Populate picture aspect ratio for CEA modes
On Mon, 20 Jan 2014 19:07:23 +0200 Ville Syrj?l? wrote: > On Mon, Dec 23, 2013 at 11:27:40AM +0530, Vandana Kannan wrote: > > Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or > > CEA-861E Table 4. This is useful for filling up the detail in AVI > > infoframe. > > > > v2: Ville's inputs incorporated. Added picture aspect ratio as part of > > edid_cea_modes instead of DRM_MODE > > > > Signed-off-by: Vandana Kannan > > Reviewed-by: Alex Deucher > > Reviewed-by: Ville Syrj?l? Note this one is needed for the patch I just reviewed to populate the PAR bits. -- Jesse Barnes, Intel Open Source Technology Center
[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list
On Fri, Mar 21, 2014 at 08:31:29AM +0530, Vandana Kannan wrote:
> Populate PAR in infoframe structure. If there is a user setting for PAR, then
> that value is set. Else, value is taken from CEA mode list if VIC is found.
> Else, PAR is calculated from resolution. If none of these conditions are
> satisfied, PAR is NONE as per initialization.
>
> As a next step, create a property that would enable a user space app to set
> aspect ratio. (will be pushed as a separate patch)
>
> Signed-off-by: Vandana Kannan
> Cc: Jesse Barnes
> Cc: Vijay Purushothaman
> Cc: Ville Syrj?l?
> Cc: intel-gfx at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_edid.c | 34 ++
> include/drm/drm_crtc.h |1 +
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d4e3f9d..3db693f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2452,6 +2452,21 @@ u8 drm_match_cea_mode(const struct drm_display_mode
> *to_match)
> }
> EXPORT_SYMBOL(drm_match_cea_mode);
>
> +/**
> + * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
> + * the input VIC from the CEA mode list
> + *
> + * Returns picture aspect ratio
> + */
> +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
> +{
> + /* return picture aspect ratio for video_code - 1 to access the
> + * right array element
> + */
> + return edid_cea_modes[video_code-1].picture_aspect_ratio;
> +}
> +EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
> +
> /*
> * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
> * specific block).
> @@ -3613,6 +3628,25 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
> frame->video_code = drm_match_cea_mode(mode);
>
> frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> +
> + /* Populate picture aspect ratio from either CEA mode list or
> + * user input
> + */
> + if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
> + mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
> + frame->picture_aspect = mode->picture_aspect_ratio;
Please pardon my ignorance, but how can userspace actually set this part
of the mode? I couldn't find any code which sets this anywhere ...
-Daniel
> + else if (frame->video_code > 0)
> + frame->picture_aspect = drm_get_cea_aspect_ratio(
> + frame->video_code);
> + else {
> + if (!(mode->vdisplay % 3) &&
> + (((mode->vdisplay * 4) / 3) == mode->hdisplay))
> + frame->picture_aspect = HDMI_PICTURE_ASPECT_4_3;
> + else if (!(mode->vdisplay % 9) &&
> + (((mode->vdisplay * 16) / 9) == mode->hdisplay))
> + frame->picture_aspect = HDMI_PICTURE_ASPECT_16_9;
> + }
> +
> frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 27f828c..50dc55a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -983,6 +983,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device
> *dev,
> extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> +extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8
> video_code);
> extern bool drm_detect_hdmi_monitor(struct edid *edid);
> extern bool drm_detect_monitor_audio(struct edid *edid);
> extern bool drm_rgb_quant_range_selectable(struct edid *edid);
> --
> 1.7.9.5
>
> ___
> 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
[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
https://bugzilla.kernel.org/show_bug.cgi?id=73291 Mike Cloaked changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations
https://bugs.freedesktop.org/show_bug.cgi?id=76564 --- Comment #46 from jeroen --- (In reply to comment #45) > (In reply to comment #44) > > (In reply to comment #43) > > > We could also update the adjusted mode clock to the actual clock set by > > > the > > > pll so that drm_calc_timestamping_constants() uses the actual clock value > > > on > > > the PLL. E.g., > > > > > > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c > > > b/drivers/gpu/drm/radeon/atombios_crtc.c > > > index daa4dd3..2a2da82 100644 > > > --- a/drivers/gpu/drm/radeon/atombios_crtc.c > > > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c > > > @@ -1085,6 +1085,7 @@ static void atombios_crtc_set_pll(struct drm_crtc > > > *crtc, struct drm_display_mode > > > atombios_crtc_program_ss(rdev, ATOM_ENABLE, > > > radeon_crtc->pll_id, > > > radeon_crtc->crtc_id, > > > &radeon_crtc->ss); > > > } > > > + mode->clock = pll_clock * 10; > > > } > > > > > > static int dce4_crtc_do_set_base(struct drm_crtc *crtc, > > > > I think that would only help if radeon_compute_pll_avivo could not compute > > an exact match. In the case of 23.976Hz the target clock is 74170kHz and the > > PLL is set exactly to this value. > > This does raise another question why the target clock' last digit is always > > zero? For example, for 23.976Hz the target clock should be 74176kHz (with > > correct rounding). I looked through the source code, but the target clock > > seems to come all the way from some deep generic drm code. > > > > 74176kHz could be matched by the PLL using fb=927.2, post_div=10 and > > ref_div=125 > > You might want to take a look at atombios_adjust_pll which does the mode > fixup before a mode is actually used. > > Since atombios always works with 10khz pixel clock which always sets the > target clocks last digit to zero. atombios_adjust_pll seems to do nothing to compensate for the 10kHz pixel clock, or didn't you mean that? When I look at drm_calc_timestamping_constants(), does this mean the vblank moment is calculated by the OSS driver? What about Alex' idea in comment 43? Would tat help Christian? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/1028ba82/attachment.html>
[Bug 76865] New: R600: OpenCL regression since llvm revision 204072
https://bugs.freedesktop.org/show_bug.cgi?id=76865 Priority: medium Bug ID: 76865 Assignee: dri-devel at lists.freedesktop.org Summary: R600: OpenCL regression since llvm revision 204072 Severity: normal Classification: Unclassified OS: All Reporter: brunojimen at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Starting with llvm revision 204072: commit 2683baa8acbcfc44b94a7af781c43674d28d9a2e Author: Matt Arsenault Date: Mon Mar 17 18:58:11 2014 + R600: Match sign_extend_inreg to BFE instructions Some of the tests from Opencv OpenCL have started to fail, for example test 'Arithm/Absdiff.Mat/3' My system is an Arch Linux with Kernel 3.13.7 and mesa from git at commit 3a8bd97. My card is an AMD HD5470 (AMD CEDAR) If any more information is needed, just ask. -- 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/20140331/4bcf7c8f/attachment.html>
[PATCHv4 06/13] drm: Add primary plane helpers (v2)
On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
...
> > +* N.B., we call set_config() directly here rather than using
> > +* drm_mode_set_config_internal. We're reprogramming the same
> > +* connectors that were already in use, so we shouldn't need the extra
> > +* cross-CRTC fb refcounting to accomodate stealing connectors.
> > +* drm_mode_setplane() already handles the basic refcounting for the
> > +* framebuffers involved in this operation.
>
> Wrong. The current crtc helper logic disables all disconnected connectors
> forcefully on each set_config. Nope, I didn't make those semantics ... So
> I think we need to think a bit harder here again.
>
> See drm_helper_disable_unused_functions.
I think I'm still missing something here; can you clarify what the
problematic case would be?
I only see a call to __drm_helper_disable_unused_functions() in the CRTC
helper in cases where mode_changed = 1, which I don't believe it ever
should be through the setplane() calls. We should just be updating the
framebuffer (and possibly panning) without touching any of the
connectors, so I don't see how unrelated CRTC's would get disabled. Am
I overlooking another case here that the basic refcounting in setplane
doesn't already handle?
Thanks.
Matt
>
> > +*/
> > + tmpfb = plane->fb;
> > + ret = crtc->funcs->set_config(&set);
> > + plane->fb = tmpfb;
> > +
> > + kfree(connector_list);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(drm_primary_helper_update);
> > +
> > +/**
> > + * drm_primary_helper_disable() - Helper for primary plane disable
> > + * @plane: plane to disable
> > + *
> > + * Provides a default plane disable handler for primary planes. This is
> > handler
> > + * is called in response to a userspace SetPlane operation on the plane
> > with a
> > + * NULL framebuffer parameter. We call the driver's modeset handler with
> > a NULL
> > + * framebuffer to disable the CRTC if no other planes are currently
> > enabled.
> > + * If other planes are still enabled on the same CRTC, we return -EBUSY.
> > + *
> > + * Note that some hardware may be able to disable the primary plane without
> > + * disabling the whole CRTC. Drivers for such hardware should provide
> > their
> > + * own disable handler that disables just the primary plane (and they'll
> > likely
> > + * need to provide their own update handler as well to properly re-enable a
> > + * disabled primary plane).
> > + *
> > + * RETURNS:
> > + * Zero on success, error code on failure
> > + */
> > +int drm_primary_helper_disable(struct drm_plane *plane)
> > +{
> > + struct drm_plane *p;
> > + struct drm_mode_set set = {
> > + .crtc = plane->crtc,
> > + .fb = NULL,
> > + };
> > +
> > + if (plane->crtc == NULL || plane->fb == NULL)
> > + /* Already disabled */
> > + return 0;
> > +
> > + list_for_each_entry(p, &plane->dev->mode_config.plane_list, head)
> > + if (p != plane && p->fb) {
> > + DRM_DEBUG_KMS("Cannot disable primary plane while other
> > planes are still active on CRTC.\n");
> > + return -EBUSY;
> > + }
> > +
> > + /*
> > +* N.B. We call set_config() directly here rather than
> > +* drm_mode_set_config_internal() since drm_mode_setplane() already
> > +* handles the basic refcounting and we don't need the special
> > +* cross-CRTC refcounting (no chance of stealing connectors from
> > +* other CRTC's with this update).
>
> Same comment as above applies. Calling ->set_config is considered harmful
> ... Maybe we need to add another wrapper here for the primary plane
> helpers to wrap this all up safely?
>
> > +*/
> > + return plane->crtc->funcs->set_config(&set);
> > +}
> > +EXPORT_SYMBOL(drm_primary_helper_disable);
> > +
> > +/**
> > + * drm_primary_helper_destroy() - Helper for primary plane destruction
> > + * @plane: plane to destroy
> > + *
> > + * Provides a default plane destroy handler for primary planes. This
> > handler
> > + * is called during CRTC destruction. We disable the primary plane, remove
> > + * it from the DRM plane list, and deallocate the plane structure.
> > + */
> > +void drm_primary_helper_destroy(struct drm_plane *plane)
> > +{
> > + plane->funcs->disable_plane(plane);
> > + drm_plane_cleanup(plane);
> > + kfree(plane);
> > +}
> > +EXPORT_SYMBOL(drm_primary_helper_destroy);
> > +
> > +const struct drm_plane_funcs drm_primary_helper_funcs = {
> > + .update_plane = drm_primary_helper_update,
> > + .disable_plane = drm_primary_helper_disable,
> > + .destroy = drm_primary_helper_destroy,
> > +};
> > +EXPORT_SYMBOL(drm_primary_helper_funcs);
> > +
> > +/**
> > + * drm_primary_helper_create_plane() - Create a generic primary plane
> > + * @dev: drm device
> > + * @formats: pixel formats supported, or NULL for a default safe list
> > + * @num_formats: size
[PATCHv4 06/13] drm: Add primary plane helpers (v2)
On Fri, Mar 28, 2014 at 4:32 AM, Daniel Vetter wrote:
>
>> + /*
>> + * set_config() adjusts crtc->primary->fb; however the DRM setplane
>> + * code that called us expects to handle the framebuffer update and
>> + * reference counting; save and restore the current fb before
>> + * calling it.
>> + *
>> + * N.B., we call set_config() directly here rather than using
>> + * drm_mode_set_config_internal. We're reprogramming the same
>> + * connectors that were already in use, so we shouldn't need the extra
>> + * cross-CRTC fb refcounting to accomodate stealing connectors.
>> + * drm_mode_setplane() already handles the basic refcounting for the
>> + * framebuffers involved in this operation.
>
> Wrong. The current crtc helper logic disables all disconnected connectors
> forcefully on each set_config. Nope, I didn't make those semantics ... So
> I think we need to think a bit harder here again.
Hmm, I'm not really seeing the problem. The worst setplane could do
is enable a crtc which otherwise already has an encoder+connector
pointing to it. Which would mean that encoder+connector could not be
pointing to another crtc.
So yeah, we'll end up calling dpms(OFF) on a bunch of stuff that is
already off.. is that a problem?
>
> See drm_helper_disable_unused_functions.
>
>> + */
>> + tmpfb = plane->fb;
>> + ret = crtc->funcs->set_config(&set);
>> + plane->fb = tmpfb;
>> +
>> + kfree(connector_list);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(drm_primary_helper_update);
>> +
>> +/**
>> + * drm_primary_helper_disable() - Helper for primary plane disable
>> + * @plane: plane to disable
>> + *
>> + * Provides a default plane disable handler for primary planes. This is
>> handler
>> + * is called in response to a userspace SetPlane operation on the plane
>> with a
>> + * NULL framebuffer parameter. We call the driver's modeset handler with a
>> NULL
>> + * framebuffer to disable the CRTC if no other planes are currently enabled.
>> + * If other planes are still enabled on the same CRTC, we return -EBUSY.
>> + *
>> + * Note that some hardware may be able to disable the primary plane without
>> + * disabling the whole CRTC. Drivers for such hardware should provide their
>> + * own disable handler that disables just the primary plane (and they'll
>> likely
>> + * need to provide their own update handler as well to properly re-enable a
>> + * disabled primary plane).
>> + *
>> + * RETURNS:
>> + * Zero on success, error code on failure
>> + */
>> +int drm_primary_helper_disable(struct drm_plane *plane)
>> +{
>> + struct drm_plane *p;
>> + struct drm_mode_set set = {
>> + .crtc = plane->crtc,
>> + .fb = NULL,
>> + };
>> +
>> + if (plane->crtc == NULL || plane->fb == NULL)
>> + /* Already disabled */
>> + return 0;
>> +
>> + list_for_each_entry(p, &plane->dev->mode_config.plane_list, head)
>> + if (p != plane && p->fb) {
>> + DRM_DEBUG_KMS("Cannot disable primary plane while
>> other planes are still active on CRTC.\n");
>> + return -EBUSY;
>> + }
>> +
>> + /*
>> + * N.B. We call set_config() directly here rather than
>> + * drm_mode_set_config_internal() since drm_mode_setplane() already
>> + * handles the basic refcounting and we don't need the special
>> + * cross-CRTC refcounting (no chance of stealing connectors from
>> + * other CRTC's with this update).
>
> Same comment as above applies. Calling ->set_config is considered harmful
> ... Maybe we need to add another wrapper here for the primary plane
> helpers to wrap this all up safely?
actually, again, I think calling .set_config() directly here is the
correct thing. There should be no connector/encoder changes. and the
drm_mode_set_config_internal() refcounting would be wrong for
drm_mode_setplane(). In the helpers he undoes the plane->fb update
done by the driver in .set_config() so that drm_mode_setplane() dtrt..
As an aside, that inconsistency between who updates the fb ptr between
setcrtc and setplane has been bothering me for a while now with the
atomic stuff. Maybe it's just the OCD talking, but I'd *really* like
to clean that up. The rough thinking I have, with the atomic stuff we
introduce a second fb pointer (and reference) in the state object. So
initially we have:
plane->fb--- current rules
plane->state->fb --- immutable, set to new incoming fb before
calling in to driver.. drm core manages the refcnt, read-only access
for the driver
what I'd like to do is request that all drivers add their own internal
scanout references, etc. And we eventually remove plane->fb when no
one still references it. The outgoing state object will hold a ref to
old_fb until after we return from calling in to the driver. The only
thing left is for each driver to (if it cannot cancel scanout
mid-frame)
[Intel-gfx] [PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list
On Fri, 21 Mar 2014 08:31:29 +0530
Vandana Kannan wrote:
> Populate PAR in infoframe structure. If there is a user setting for PAR, then
> that value is set. Else, value is taken from CEA mode list if VIC is found.
> Else, PAR is calculated from resolution. If none of these conditions are
> satisfied, PAR is NONE as per initialization.
>
> As a next step, create a property that would enable a user space app to set
> aspect ratio. (will be pushed as a separate patch)
>
> Signed-off-by: Vandana Kannan
> Cc: Jesse Barnes
> Cc: Vijay Purushothaman
> Cc: Ville Syrj?l?
> Cc: intel-gfx at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_edid.c | 34 ++
> include/drm/drm_crtc.h |1 +
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d4e3f9d..3db693f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2452,6 +2452,21 @@ u8 drm_match_cea_mode(const struct drm_display_mode
> *to_match)
> }
> EXPORT_SYMBOL(drm_match_cea_mode);
>
> +/**
> + * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
> + * the input VIC from the CEA mode list
> + *
> + * Returns picture aspect ratio
> + */
> +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
> +{
> + /* return picture aspect ratio for video_code - 1 to access the
> + * right array element
> + */
> + return edid_cea_modes[video_code-1].picture_aspect_ratio;
> +}
> +EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
> +
> /*
> * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
> * specific block).
> @@ -3613,6 +3628,25 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
> frame->video_code = drm_match_cea_mode(mode);
>
> frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> +
> + /* Populate picture aspect ratio from either CEA mode list or
> + * user input
> + */
> + if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
> + mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
> + frame->picture_aspect = mode->picture_aspect_ratio;
> + else if (frame->video_code > 0)
> + frame->picture_aspect = drm_get_cea_aspect_ratio(
> + frame->video_code);
> + else {
> + if (!(mode->vdisplay % 3) &&
> + (((mode->vdisplay * 4) / 3) == mode->hdisplay))
> + frame->picture_aspect = HDMI_PICTURE_ASPECT_4_3;
> + else if (!(mode->vdisplay % 9) &&
> + (((mode->vdisplay * 16) / 9) == mode->hdisplay))
> + frame->picture_aspect = HDMI_PICTURE_ASPECT_16_9;
> + }
> +
> frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 27f828c..50dc55a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -983,6 +983,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device
> *dev,
> extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> +extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8
> video_code);
> extern bool drm_detect_hdmi_monitor(struct edid *edid);
> extern bool drm_detect_monitor_audio(struct edid *edid);
> extern bool drm_rgb_quant_range_selectable(struct edid *edid);
Reviewed-by: Jesse Barnes
