[Bug 86089] [r600g] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/776f3daf/attachment.html>

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/1b3709ca/attachment.html>

[Bug 86038] [radeonsi] Dreamfall Chapters: heavy visual corruption, large parts of the screen are black in some scenes

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/814b1537/attachment-0001.html>

[PATCH] drm: More specific locking for get* ioctls

Motivated by the per-plane locking I've gone through all the get* ioctls and reduced the locking to the bare minimum required. v2: Rebase and make it compile ... v3: Review from Sean: - Simplify return handling in getplane_res. - Add a comment to getplane_res that the plane list is invariant and

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Tue, Nov 11, 2014 at 03:31:20PM -0800, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Thu, 06 Nov 2014 17:28:41 + bugzilla-daemon at bugzilla.kernel.org > wrote: > > >

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote: > But anyway - Luke, please attach your .config to > https://bugzilla.kernel.org/show_bug.cgi?id=87891? Done: https://bugzilla.kernel.org/attachment.cgi?id=157381 Luke

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote: > On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr wrote: > > > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote: > > > But anyway - Luke, please attach your .config to > > >

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > wrote: > > > On Tue, 11 Nov 2014, Andrew Morton wrote: > > > > > There's no point in doing > > > > > > #define GFP_SLAB_BUG_MASK

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > linux.com> wrote: > > > > > On Tue, 11 Nov 2014, Andrew Morton wrote: > > > > > > > There's no

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Tue, Nov 11, 2014 at 05:56:03PM -0800, Andrew Morton wrote: > On Wed, 12 Nov 2014 03:47:03 +0200 "Kirill A. Shutemov" shutemov.name> wrote: > > > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote: > > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > > > > On

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > linux.com> wrote: > > > > > On Tue, 11 Nov 2014, Andrew Morton wrote: > > > > > > > There's no

[PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote: > > Now that we have moved to generic phy based bindings, > we don't need to have any code related to older dptx-phy. > Nobody is using this dptx-phy anymore, so removing the > same. Right, older dptx-phy was replaced long time ago.

[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote: > > DP PHY now require pmu-system-controller to handle PMU register > to control PHY's power isolation. Adding the same to dp-phy > node. > > Signed-off-by: Vivek Gautam > Cc: Jingoo Han Reviewed-by: Jingoo Han Best regards, Jingoo

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

Andrew Morton wrote: > Poor ttm guys - this is a bit of a trap we set for them. Commit a91576d7916f6cce (\"drm/ttm: Pass GFP flags in order to avoid deadlock.\") changed to use sc->gfp_mask rather than GFP_KERNEL. - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), -

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Wed, Nov 12, 2014 at 04:37:46AM +0200, Kirill A. Shutemov wrote: > On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote: > > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote: > > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > > > > On Tue, 11 Nov

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Tue, Nov 11, 2014 at 05:44:12PM -0800, Andrew Morton wrote: > On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim > wrote: > > > On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote: > > > On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr wrote: > > > > > > > On Wednesday, November 12,

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote: > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > > linux.com> wrote: > > > > > >

[PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

On Wed, Nov 12, 2014 at 9:38 AM, Jingoo Han wrote: > On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote: >> >> Now that we have moved to generic phy based bindings, >> we don't need to have any code related to older dptx-phy. >> Nobody is using this dptx-phy anymore, so removing the >>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

r this patch. -- 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/20141112/b3931c4a/attachment.html>

[PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

The same kind of issue has been fixed in v4l2: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/media/v4l2-core/videobuf2-core.c?id=c1b96a236e94d49d9396d0bbceb5524519c5c66e I'm ok to add a DRM_RDWR flag, just do not remove the code from sti driver until I have been

[PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

On 12/11/14 09:41, Benjamin Gaignard wrote: > The same kind of issue has been fixed in v4l2: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/media/v4l2-core/videobuf2-core.c?id=c1b96a236e94d49d9396d0bbceb5524519c5c66e > > I'm ok to add a DRM_RDWR flag, just do

[PATCH] drm/dp/mst: Handle invalid link bandwidth from DPCD gracefully

Don't BUG out if the link reports an invalid (or plain unknown) bandwidth value, but report the failure and fail gracefully. Fixes a trivial compiler warning in case the BUG is ever compiled away. Link: http://lkml.kernel.org/p/1415785566-12758-1-git-send-email-geert at linux-m68k.org

[PATCH] drm: Simplify return value handling in drm_crtc.c

While looking through drm_crtc.c to double-check make locking changes I've noticed that there's a few other places that would now benefit from simplified return value handling. So let's flatten the control flow and replace and always 0 ret with 0 where possible. Signed-off-by: Daniel Vetter ---

[PATCH v2 v3.18-rc4 0/4] drm: prime: Allow exported dma-bufs to be mapped

This patch set started out as a single patch with a trivial bit of boilerplate to add dmabuf mmap support to the msm driver. Each of the change remains fairly trivial but I've split it out by topic. Patches 1, 2 and 3 in this series should be good to go but please don't take patch 4 (which has a

[PATCH v2 v3.18-rc4 2/4] drm: prime: Document gem_prime_mmap

gem_prime_map is not currently described in the DRM manual, lets document it. Signed-off-by: Daniel Thompson --- drivers/gpu/drm/drm_prime.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index

[PATCH v2 v3.18-rc4 3/4] drm: msm: Allow exported dma-bufs to be mapped

Currently msm does not implement gem_prime_mmap. Without this it is not possible to draw onto a dma-buf from userspace (making its very hard to implement the Android rendering model). Fixing this is just a matter of adding a little boilerplate. Signed-off-by: Daniel Thompson ---

[PATCH v2 v3.18-rc4 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd

Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except (DRM|O)_CLOEXEC making it hard for the userspace to generate a file descriptor that can be used by mmap(). It is easy to relax the restriction and allow read/write permissions. This should be safe because the flags are seldom touched

[PATCH v2 v3.18-rc4 4/4] drm: sti: Honour O_RDWR during prime-handle-to-fd

Currently the sti drm driver forcible applies O_RDWR when it exports a prime handle. This is because it was not previously possible for user requests to create the fd with O_RDWR passed into drivers. This is a cleanup to remove this code. This change has obvious impact upon the userspace which

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote: > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > > As a side note if someone is looking for stuff to do, then the pin/unpin > > logic might be good thing to look at. We're currently a bit inconsistent > > whether we

[RFC PATCH] drm/gem: Warn on illegal use of the dumb buffer interface

It happens on occasion that developers of generic user-space applications abuse the dumb buffer API to get hold of drm buffers that they can both mmap() and use for GPU acceleration, using the assumptions that dumb buffers and buffers available for GPU are a) The same type and can be aribtrarily

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

From: Thierry Reding dma_alloc_coherent() returns a kernel virtual address that is part of the linear range. Passing such an address to virt_to_page() is illegal on non-coherent architectures. This causes the kernel to oops on 64-bit ARM because the struct page * obtained

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote: > +static inline void clwb(volatile void *__p) > +{ > + alternative_io_2(".byte " __stringify(NOP_DS_PREFIX) "; clflush %P0", > + ".byte 0x66; clflush %P0", > + X86_FEATURE_CLFLUSHOPT, > +

[Bug 86196] Massive Chalice crashes on startup

rs and it worked for them. -- 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/20141112/1b49d535/attachment.html>

[PATCH v2 v3.18-rc4 2/4] drm: prime: Document gem_prime_mmap

On Wed, Nov 12, 2014 at 11:38:13AM +, Daniel Thompson wrote: > gem_prime_map is not currently described in the DRM manual, lets document > it. > > Signed-off-by: Daniel Thompson Patches 1&2 are Reviewed-by: Daniel Vetter Nit: Since this fixes an oversight in an earlier patch I usally cc

[PATCH 3/6] x86: Add support for the clwb instruction

On Wed, Nov 12, 2014 at 01:38:45PM +, Anvin, H Peter wrote: > No, it doesn't. x86 requires 3.4+ at a minimum. The only test I see is: #if GCC_VERSION < 30200 # error Sorry, your compiler is too old - please upgrade it. #endif And even if we do require 3.4, the build fails with 4.1+ so...

[PATCH 1/9] drm/exynos: remove uneeded declaration of struct dma_iommu_mapping

Hi Inki, 2014-11-06 Inki Dae : > > Hi Gustavo, > > On 2014년 11월 06일 21:38, Gustavo Padovan wrote: > > > > Hi Inki, > > > > Could you please give a review to this series? > > It looks good to me. This patch series is just cleanup but not test so I > will merge them next week after

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote: > On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote: > > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > > > As a side note if someone is looking for stuff to do, then the pin/unpin > > > logic might be

[PATCH v2 v3.18-rc4 3/4] drm: msm: Allow exported dma-bufs to be mapped

On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson wrote: > Currently msm does not implement gem_prime_mmap. Without this it is not > possible to draw onto a dma-buf from userspace (making its very hard to > implement the Android rendering model). > > Fixing this is just a matter of adding a little

[RFC PATCH] drm/gem: Warn on illegal use of the dumb buffer interface

On Wed, Nov 12, 2014 at 12:55:32PM +0100, Thomas Hellstrom wrote: > It happens on occasion that developers of generic user-space applications > abuse the dumb buffer API to get hold of drm buffers that they can both > mmap() and use for GPU acceleration, using the assumptions that dumb buffers >

[PATCH v2 v3.18-rc4 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd

On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson wrote: > Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except > (DRM|O)_CLOEXEC making it hard for the userspace to generate a file > descriptor that can be used by mmap(). > > It is easy to relax the restriction and allow read/write

[PATCH v2 v3.18-rc4 2/4] drm: prime: Document gem_prime_mmap

On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson wrote: > gem_prime_map is not currently described in the DRM manual, lets document > it. > > Signed-off-by: Daniel Thompson Reviewed-by: Rob Clark > --- > drivers/gpu/drm/drm_prime.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) >

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

On Wed, Nov 12, 2014 at 03:22:07PM +0100, Daniel Vetter wrote: > On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote: > > On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote: > > > On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > > > > As a side note if

[Bug 72701] Screen freeze when using radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=72701 EmanueL Czirai changed: What|Removed |Added Attachment #143031|0 |1 is obsolete|

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

it is related to that branch only. -- 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/20141112/ef84ee94/attachment.html>

[pull] radeon drm-fixes-3.18

Hi Dave, Just your atom scratch buffer locking fix. The following changes since commit 03dca708521d30153fc5c7e2ff136f780a7372c9: Merge tag 'drm-intel-fixes-2014-11-07' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-11-10 10:05:37 +1000) are available in the git repository

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote: > From: Thierry Reding > > dma_alloc_coherent() returns a kernel virtual address that is part of > the linear range. Passing such an address to virt_to_page() is illegal > on non-coherent architectures. This causes the kernel to

[Bug 72701] Screen freeze when using radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=72701 --- Comment #22 from EmanueL Czirai --- In order to avoid any freezes, with the caveat that the DIScrete card won't ever be turned off (even by # echo 'OFF' > /sys/kernel/debug/vgaswitcheroo/switch which would have no effect) I am using:

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote: > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote: > > From: Thierry Reding > > > > dma_alloc_coherent() returns a kernel virtual address that is part of > > the linear range. Passing such an address to

[RFC] drm/msm: select REGULATOR

Fixes a potential error, spotted by Felipe with randconfig: - drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ‘mdp4_kms_init’: drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \ of function ‘devm_regulator_get_exclusive’

[PATCH v3 1/2] drm/exynos: dp: Remove support for unused dptx-phy

On Wednesday, November 12, 2014 6:28 PM, Vivek Gautam wrote: > > Now that we have moved to generic phy based bindings, > we don't need to have any code related to older dptx-phy. > Nobody is using this dptx-phy anymore, so removing the > same. > > Signed-off-by: Vivek Gautam > Cc: Inki Dae >

[PATCH v8 1/9] staging: imx-drm: imx-hdmi: make checkpatch happy

CHECK: Alignment should match open parenthesis + if ((hdmi->vic == 10) || (hdmi->vic == 11) || + (hdmi->vic == 12) || (hdmi->vic == 13) || CHECK: braces {} should be used on all arms of this statement + if (hdmi->hdmi_data.video_mode.mdvi) [...] + else { [...]

[PATCH v8 3/9] staging: imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width, 4K support, clk useage, and the crtc mux configuration is also platform specific. To reuse the imx

[PATCH v8 4/9] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

the original imx hdmi driver is under staging/imx-drm, which depends on imx-drm, so move the imx hdmi driver out to drm/bridge and rename imx-hdmi to dw_hdmi Signed-off-by: Andy Yan --- Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes

[PATCH v8 7/9] drm: bridge/dw_hdmi: convert dw-hdmi to drm_bridge mode

From: Yakir Yang keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c, as most of the encoder operation are platform specific such as crtc select and panel format set Signed-off-by: Andy Yan Signed-off-by: Yakir Yang --- Changes in v8: None Changes

[PATCH v8 8/9] dt-bindings: Add documentation for rockchip dw hdmi

Signed-off-by: Andy Yan --- Changes in v8: - Add documentation for rockchip dw hdmi Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++ 1 file

[PATCH 3/6] x86: Add support for the clwb instruction

No, it doesn't. x86 requires 3.4+ at a minimum. From: Borislav Petkov Sent: Wednesday, November 12, 2014 4:39:09 AM To: Ross Zwisler Cc: linux-kernel at vger.kernel.org; Anvin, H Peter; Ingo Molnar; Thomas Gleixner; David Airlie; dri-devel at

[PATCH v8 6/9] drm: bridge/dw_hdmi: add support for multi byte register width access

On rockchip rk3288, only word(32-bit) accesses are permitted for hdmi registers. Byte width accesses (writeb, readb) generate an imprecise external abort. Signed-off-by: Andy Yan --- Changes in v8: None Changes in v7: None Changes in v6: - move some modification to patch#6 - refactor

[PATCH v8 9/9] drm: bridge/dw_hdmi: add rockchip rk3288 support

rk3288 hdmi is compatible with Designware hdmi this patch is depend on patch by Mark Yao Add drm driver for Rockchip Socs see https://lkml.org/lkml/2014/10/8/201 Signed-off-by: Andy Yan Signed-off-by: Yakir Yang --- Changes in v8: - add support for rockchip rk3288 hdmi Changes in v7: None

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote: > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote: > > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > > linux.com> wrote: > > > > > >

[PATCH v8 0/9] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only access

[PATCH v8 5/9] dt-bindings: add document for dw_hdmi

Signed-off-by: Andy Yan --- Changes in v8: - correct some spelling mistake - modify ddc-i2c-bus and interrupt description Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None .../devicetree/bindings/drm/bridge/dw_hdmi.txt

[PATCH v3 RESEND 1/2] drm/exynos: dp: Remove support for unused dptx-phy

Now that we have moved to generic phy based bindings, we don't need to have any code related to older dptx-phy. Nobody is using this dptx-phy anymore, so removing the same. Signed-off-by: Vivek Gautam Acked-by: Jingoo Han Cc: Inki Dae --- Problem with my mail client caused change in author's

[PATCH v8 2/9] staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter

drm driver may probe before the i2c bus, so the driver should defer probing until it is available Signed-off-by: Andy Yan --- Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: - defer probe ddc i2c adapter Changes in v3: None Changes in v2: None

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

e: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/784e3274/attachment-0001.html>

[Bug 86043] Optimus issue with libdrm 2.4.58

ts.freedesktop.org/archives/dri-devel/attachments/20141112/a0eab350/attachment.html>

[Bug 85376] Dolphin emulator has bad colors

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/04637e64/attachment.html>

[pull] radeon drm-next-3.19

Hi Dave, Radeon patches for 3.19. Christian has a number of GPUVM improvements slated as well, but I'd like to wait until he gets back to work next week to pull those in. Highlights of this pull: - ttm performance improvements - CI dpm fixes The following changes since commit

[Bug 85842] Radeon HD 7750 random GPU lockup

org/archives/dri-devel/attachments/20141112/2c0b4422/attachment.html>

[PATCH 1/2] drm/udl: add cache flags definitions for udl_gem_object

By default set udl_gem_object as cacheable, but set WC flag when attaching dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar to exynos_drm_gem_mmap(). Change-Id: I00e5e67f2285d66adcf2ae652a9d59f12af64541 Signed-off-by: Haixia Shi Reviewed-by: Sonny Rao Reviewed-by:

[PATCH 2/2] drm/udl: add support to export a handle to a FD on UDL.

Only importing an FD to a handle is currently supported on UDL, but the exporting functionality is equally useful. Change-Id: If4983041875ebf3bd2ecf996d0771eb77b0cf1dc Signed-off-by: Haixia Shi Reviewed-by: Stéphane Marchesin --- drivers/gpu/drm/udl/Makefile | 2 +-

[PATCH 2/2] drm/udl: add support to export a handle to a FD on UDL.

return -ENOMEM; > - } > - > - drm_prime_sg_to_page_addr_arrays(sg, obj->pages, NULL, npages); > - > - *obj_p = obj; > - return 0; > -} > - > -struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev, > - struct dma_buf *dma_buf) > -{ > - struct dma_buf_attachment *attach; > - struct sg_table *sg; > - struct udl_gem_object *uobj; > - int ret; > - > - /* need to attach */ > - get_device(dev->dev); > - attach = dma_buf_attach(dma_buf, dev->dev); > - if (IS_ERR(attach)) { > - put_device(dev->dev); > - return ERR_CAST(attach); > - } > - > - get_dma_buf(dma_buf); > - > - sg = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); > - if (IS_ERR(sg)) { > - ret = PTR_ERR(sg); > - goto fail_detach; > - } > - > - ret = udl_prime_create(dev, dma_buf->size, sg, ); > - if (ret) { > - goto fail_unmap; > - } > - > - uobj->base.import_attach = attach; > - uobj->flags = UDL_BO_WC; > - > - return >base; > - > -fail_unmap: > - dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > -fail_detach: > - dma_buf_detach(dma_buf, attach); > - dma_buf_put(dma_buf); > - put_device(dev->dev); > - return ERR_PTR(ret); > -} > -- > 2.1.0.rc2.206.gedb03e5 > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141112/33ab09b9/attachment-0001.html>

[PATCH 1/6] x86: Add support for the pcommit instruction

On 11/11/2014 10:43 AM, Ross Zwisler wrote: > Add support for the new pcommit instruction. This instruction was > announced in the document "Intel Architecture Instruction Set Extensions > Programming Reference" with reference number 319433-022. > >

[PATCH 6/6] x86: Use clwb in drm_clflush_virt_range

On 11/11/2014 10:43 AM, Ross Zwisler wrote: > If clwb is available on the system, use it in drm_clflush_virt_range. > If clwb is not available, fall back to clflushopt if you can. > If clflushopt is not supported, fall all the way back to clflush. I don't know exactly what drm_clflush_virt_range