[PATCH] drm/exynos/fbdev: set smem_len for fbdev

Commit [0] stopped setting fix.smem_start and fix.smem_len when creating the fbdev. [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3 drm/exynos/fbdev: don't set fix.smem/mmio_{start,len} However, smem_len is used by some userland applications to calculate the size for mmap. In particular, it is

[Bug 83022] New: memory leak

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140824/9609d870/attachment.html>

drm_mode_create_dumb_ioctl: divide error

22.8.2014 13.38 kirjoitti "David Herrmann" : > > Hi > > On Thu, Aug 21, 2014 at 8:18 PM, Tommi Rantala > wrote: > > Hello, > > > > Triggered this while fuzzing v3.17-rc1-51-g372b1db with Trinity. > > > > Tommi > > > > > > [drm:drm_mode_legacy_fb_format] *ERROR* bad bpp, assuming x8r8g8b8 pixel

[PATCHv2 0/8] Upstreaming the Android build and misc fixes

Hi Tim, Gave the series another try, and there was some minor issues caused by commit 5d8357976a8 (configure: Support symbol visibility when available). Did not see any of the originally mentioned issues. Are you sure that you've tried it on top of fd.o/drm/master ? Do you have any comments,

[PATCHv3 3/8] libdrm, freedreno, intel, nouveau, radeon: add Makefile.sources

Will be used to consolidate the required sources lists as well as the install-able headers. This is turn will help us to avoid the duplication with the upcoming Android build support. v2: Rename the headers variable to *_H_FILES. v3: Rebase on top of symbol visibility patches. Signed-off-by:

[PATCH] drm: fix division-by-zero on dumb_create()

Kinda unexpected, but DIV_ROUND_UP() can overflow if passed an argument bigger than UINT_MAX - DIVISOR. Fix this by testing for "!cpp" before using it in the following division. Note that DIV_ROUND_UP() is defined as: #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) ..this will

drm_mode_create_dumb_ioctl: divide error

Hi On Sun, Aug 24, 2014 at 7:12 PM, Tommi Rantala wrote: > (gdb) info locals > cpp = 0 > stride = 0 > size = > > (gdb) print /x *(struct drm_mode_create_dumb *)data > $13 = { > height = 0x, > width = 0x, > bpp = 0x, > flags = 0x, > handle = 0x,

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

-devel/attachments/20140824/36464a75/attachment.html>

[PATCH] drm: fix division-by-zero on dumb_create()

On Sun, Aug 24, 2014 at 1:23 PM, David Herrmann wrote: > Kinda unexpected, but DIV_ROUND_UP() can overflow if passed an argument > bigger than UINT_MAX - DIVISOR. Fix this by testing for "!cpp" before > using it in the following division. > > Note that DIV_ROUND_UP() is defined as: >

[PATCH 6/6] drm/radeon: add UVD fw names for older asic

From: Christian K?nig Activating the UVD support. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_uvd.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c

[PATCH 5/6] drm/radeon: implement UVD hw workarounds for R6xx v3

From: Christian K?nig Only the essentials, cause this hw generation is really buggy. v2: start supporting RV670,RV620 and RV635 as well v3: activate more workarounds Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/r600d.h| 3 +++

[PATCH 4/6] drm/radeon: add UVD support for older asics v4

From: Christian K?nig v2: cleanup R600 support v3: rebased on current drm-fixes-3.12 v4: rebased on drm-next-3.14 Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/r600.c| 31 +++ drivers/gpu/drm/radeon/r600d.h | 8

[PATCH 3/6] drm/radeon: add set_uvd_clocks callback for r6xx v4

From: Alex Deucher v2: wake up PLL, set [VD]CLK_SRC, cleanup code v3: handle RV670,RV635,RV620 as well v4: merge rv6xx and rs780/rs880 code, fix ref divider mask Signed-off-by: Alex Deucher Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/r600.c | 88

[PATCH 2/6] drm/radeon: properly init UVD MC bits on R600

From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/r600.c | 4 drivers/gpu/drm/radeon/r600d.h | 4 +++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index

[PATCH 1/6] drm/radeon: force UVD buffers into VRAM on RS[78]80 v2

From: Christian K?nig v2: only necessary on RS[78]80 Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c

No subject

Hello everyone, the following patches add UVD support for older ASICs (RV6xx, RS[78]80, RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release Additionally to the patches you need UVD firmware as

[PATCH] drm/radeon: move the IB test after the AGP fallback

From: Christian K?nig Otherwise we won't test if the fallback to PCIe GART really worked. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_device.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[no subject]

seems to work perfectly fine. > > Happy testing, > Christian. > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/ed04d510/attachment.html>

[Bug 66352] GPU lockup in L4D2 on TURKS with HyperZ

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/c3c07bed/attachment.html>

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/d0cae9d4/attachment.html>

[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ

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/20140824/901dc97e/attachment.html>

[Bug 58660] CAYMAN broken with HyperZ on

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140824/e9ef3882/attachment.html>

Lenovo IdeaPad y510p requires i915.invert_brightness

Hi all, according to you request I would like to report that my Lenovo IdeaPad y510p requires i915.invert_brightness=1 parameter to not dim screen right after booting. I'm using 3.17.0-rc1. PCI device ID, subsystem vendor and subsystem device ID data: [12:39:34] pietrushnic:~ $ lspci -s 00:02.0

[Bug 38917] [patch] Radeon clocks should not be limited to defaults

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140824/3c90bd30/attachment.html>

[Bug 83012] New: horrible performance with vblank_mode=1 which is the default

dri-devel/attachments/20140824/e5080ba2/attachment.html>

[Bug 38917] [patch] Radeon clocks should not be limited to defaults

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140824/22f9aa02/attachment.html>

[Bug 79980] Random radeonsi crashes

'm willing to open a new bug for this. -- 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/20140824/119cd86b/attachment.html>

[Bug 79980] Random radeonsi crashes

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/c6e3614f/attachment.html>

[git pull] drm intel and radeon fixes

Hi Linus, post KS/LC git requests from i915 and radeon stacked up, they are all fixes along with some new pci ids for radeon, and one maintainers file entry. i915: display fixes and irq fixes radeon: pci ids, and misc gpuvm, dpm and hdp cache Dave. The following changes since commit

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #18 from t3st3r at mail.ru --- This is getting even more interesting. After some investigation I got idea why bisect never succeeds. It looks like there was no stable kernels at all: 3.15 is also broken. However it takes "almost