[PATCH 19/19] drm/atomic-helpers: functions for state duplicate/destroy/reset

The atomic users and helpers assume that there is always a obj->state structure around. Which means drivers need to somehow create that at driver load time. Also it should obviously reset hardware state, so needs to be reset upon resume. Finally the destroy/duplicate_state functions are an awful l

[PATCH 18/19] drm: trylock modest locking for fbdev panics

In the fbdev code we want to do trylocks only to avoid deadlocks and other ugly issues. Thus far we've only grabbed the overall modeset lock, but that already failed to exclude a pile of potential concurrent operations. With proper atomic support this will be worse. So add a trylock mode to the mo

[PATCH 17/19] drm/atomic-helper: implement ->page_flip

Currently there is no way to implement async flips using atomic, that essentially requires us to be able to cancel pending requests mid-flight. To be able to do that (and I guess we want this since vblank synced updates whic opportunistically cancel still pending updates seem to be wanted) we'd ne

[PATCH 16/19] drm/atomic-helpers: document how to implement async commit

No helper function to do it all yet provided since no driver has support for driver core fences yet. Which we'd need to make the implementation really generic. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 37 + 1 file changed, 37 inse

[PATCH 15/19] drm/plane-helper: Add async mode to prepare_fb

Currently all helpers use ->prepare_fb for synchronous state updates, so we need the driver callback to wait for any outstanding rendering. But with async commit we really only want to reserve the framebuffer, but not stall for rendering. That should be done in the asynchronous worker. So add a b

[PATCH 14/19] drm/atomic-helper: implementatations for legacy interfaces

Well, except page_flip since that requires async commit, which isn't there yet. For the functions which changes planes there's a bit of trickery involved to keep the fb refcounting working. But otherwise fairly straight-forward atomic updates. The property setting functions are still a bit incomp

[PATCH 13/19] drm: Move ->old_fb from crtc to plane

Atomic implemenations for legacy ioctls must be able to drop locks. Which doesn't cause havoc since we only do that while constructing the new state, so no driver or hardware state change has happened. The only troubling bit is the fb refcounting the core does - if someone else has snuck in then i

[PATCH 12/19] drm: Atomic crtc/connector updates using crtc helper interfaces

So this is finally the integration of the crtc helper interfaces into the atomic helper functions. In the check function we now have a few steps: - First we update the output routing and figure out which crtcs need a full mode set. Suitable encoders are selected using ->best_encoder, with the

[PATCH 11/19] drm/crtc-helper: Transitional functions using atomic plane helpers

These two functions allow drivers to reuse their atomic plane helpers functions for the primary plane to implement the interfaces required by the crtc helpers for the legacy ->set_config callback. This is purely transitional and won't be used once the driver is fully converted. But it allows parti

[PATCH 10/19] drm/plane-helper: transitional atomic plane helpers

Converting a driver to the atomic interface can be a daunting undertaking. One of the prerequisites is to have full universal planes support. To make that transition a bit easier this pathc provides plane helpers which use the new atomic helper callbacks just only for the plane changes. This way t

[PATCH 09/19] drm/i915: Use generic vblank wait

This has the upside that it will no longer steal interrupts from the interrutp handler on pre-g4x. Furthermore this will now scream properly on all platforms if we don't have hw counters enabled. Not yet tested. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 41 +---

[PATCH 08/19] drm/irq: Implement a generic vblank_wait function

As usual in both a crtc index and a struct drm_crtc * version. The function assumes that no one drivers their display below 10Hz, and it will complain if the vblank wait takes longer than that. v2: Also check dev->max_vblank_counter since some drivers register a fake get_vblank_counter function.

[PATCH 07/19] drm: Add drm_crtc_vblank_waitqueue()

From: Ville Syrj?l? Add a small static inline helper to grab the vblank wait queue based on the drm_crtc. This is useful for drivers to do internal vblank waits using wait_event() & co. v2: Pimp commit message (Daniel) Add kernel doc (Daniel) Suggested-by: Daniel Vetter Signed-off-by: Vil

[PATCH 06/19] drm: Add atomic/plane helpers

This is the first cut of atomic helper code. As-is it's only useful to implement a pure atomic interface for plane updates. Later patches will integrate this with the crtc helpers so that full atomic updates are possible. We also need a pile of helpers to aid drivers in transitioning from the lega

[PATCH 05/19] drm: Global atomic state handling

Some differences compared to Rob's patches again: - Dropped the committed and checked booleans. Checking will be internally enforced by always calling ->atomic_check before ->atomic_commit. And async handling needs to be solved differently because the current scheme completely side-steps ww m

[PATCH 04/19] drm: Handle legacy per-crtc locking with full acquire ctx

So drivers using the atomic interfaces expect that they can acquire additional locks internal to the driver as-needed. Examples would be locks to protect shared state like shared display PLLs. Unfortunately the legacy ioctls assume that all locking is fully done by the drm core. Now for those path

[PATCH 03/19] drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]

Somehow we've forgotten about this little bit of OCD. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 95 -- drivers/gpu/drm/drm_modeset_lock.c | 95 ++ include/drm/drm_crtc.h | 4 -- inclu

[PATCH 02/19] drm: Add drm_plane/connector_index

In the atomic state we'll have an array of states for crtcs, planes and connectors and need to be able to at them by their index. We already have a drm_crtc_index function so add the missing ones for planes and connectors. If it later on turns out that the list walking is too expensive we can add

[PATCH 01/19] drm: Add atomic driver interface definitions for objects

Heavily based upon Rob Clark's atomic series. - Dropped the connctor state from the crtc state, instead opting for a full-blown connector state. The only thing it has is the desired crtc, but drivers which have connector properties have now a data-structure to subclass. - Rename create_state

[PATCH 00/19] atomic, remixed

Hi all, So I've figured instead of just talking I should draw up my ideas for atomic helpers and related stuff in some draft patches. Major differences compared to Rob's series: - The software side state update is done synchronously, at least when using the helper code. Drivers are free to do w

[PATCH] drm/radeon: adjust default radeon_vm_block_size v2

On Sat, Jul 26, 2014 at 9:34 AM, Christian K?nig wrote: > Hey Alex, > > can you use this version instead of the one you already have in > drm-next-3.17-wip? It depends on a change from drm-fixes-3.16, so you need > to merge (or rebase) your -next branch to apply it. > > Apart from that I also have

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Hi Ajay, Am 25.07.2014 21:22, schrieb Ajay Kumar: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > I have tested this after adding few DT changes for exynos5250-snow, > exynos5420-peach-pit and exyno

[PATCH] drm: refcnt drm_display_mode

On Sun, Jul 27, 2014 at 6:20 PM, Rob Clark wrote: > On Sun, Jul 27, 2014 at 11:17 AM, Daniel Vetter wrote: >> On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark wrote: >>> We're going to need this for atomic. >>> >>> Signed-off-by: Rob Clark >> >> I disagree. Iiui correctly Rob's concern is that the a

[PATCH 8/8] freedreno: add Android build support

Cc: freedreno at lists.freedesktop.org Signed-off-by: Emil Velikov --- Android.mk | 1 + freedreno/Android.mk | 30 ++ 2 files changed, 31 insertions(+) create mode 100644 freedreno/Android.mk diff --git a/Android.mk b/Android.mk index eb54bf7..b3bf411 100

[PATCH 7/8] nouveau: add Android build support

Signed-off-by: Emil Velikov --- Android.mk | 1 + nouveau/Android.mk | 30 ++ 2 files changed, 31 insertions(+) create mode 100644 nouveau/Android.mk diff --git a/Android.mk b/Android.mk index b3fbb5b..eb54bf7 100644 --- a/Android.mk +++ b/Android.mk @@ -54,

[PATCH 6/8] radeon: add Android build support

Signed-off-by: Emil Velikov --- Android.mk| 1 + radeon/Android.mk | 30 ++ 2 files changed, 31 insertions(+) create mode 100644 radeon/Android.mk diff --git a/Android.mk b/Android.mk index ec340b4..b3fbb5b 100644 --- a/Android.mk +++ b/Android.mk @@ -54,3 +

[PATCH 5/8] libdrm,intel: rework android header handling

Contains the following patches squashed in: commit 99247a5bd724ddcf0f06a5518baad207c53f1e2b Author: Haitao Huang Date: Fri, 27 Apr 2012 13:20:53 -0500 Android.mk: use LOCAL_COPY_HEADERS to export headers. Export necessary header files used by other components for

[PATCH 4/8] libdrm,intel: Add Android build

Contains the following patches squashed in: commit f340a8b9f2b84d5762553bef046914e0bde20795 Author: Chad Versace Date: Wed, 21 Dec 2011 11:43:57 -0800 libdrm,intel: Add Android makefiles (v2) This enables libdrm.so and libdrm_intel.so to build on Android IceC

[PATCH 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. Signed-off-by: Emil Velikov --- Makefile.am | 13 - Makefile.sources |

[PATCH 2/8] libkms: remove explicit define _FILE_OFFSET_BITS 64

configure.ac has AC_SYS_LARGEFILE which provides the define and/or approapriate magic when required. Signed-off-by: Emil Velikov --- libkms/dumb.c| 1 - libkms/exynos.c | 1 - libkms/intel.c | 1 - libkms/nouveau.c | 1 - libkms/radeon.c | 1 - libkms/vmwgfx.c | 1 - 6 files changed, 6

[PATCH 1/8] all: include config.h only when available and use its defines

... rather than explicitly redefining HAVE_STDINT_H and _GNU_SOURCE. Signed-off-by: Emil Velikov --- intel/test_decode.c | 5 +++-- libkms/api.c | 2 ++ libkms/dumb.c | 4 +++- libkms/exynos.c | 4 +++- libkms/intel.c| 4 +++- libkms/linux.c

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

Hello list, Recently I've had a go at the Anroid builds and I felt ... inspired that there are (at least) two downstream repositories that have the relevant Android build, yet all of them use 6+month old libdrm. Making even builds a pain in the neck :'( Are there any objections if we get the andr

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

Can't we just make the accel2 info return 2 instead of 1? and have userspace know the difference. be careful to make userspace work so we can return 3 in future. Dave.

[PATCH] drm: refcnt drm_display_mode

On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark wrote: > We're going to need this for atomic. > > Signed-off-by: Rob Clark I disagree. Iiui correctly Rob's concern is that the additional stuff to keep track of mode lists (list_head and the idr stuff) could confuse driver writers into doing stupid st

[Bug 78453] [HAWAII] Get acceleration working

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

[Bug 78453] [HAWAII] Get acceleration working

Org 1.16.0 AFAIK. Maybe you want to try that instead of your development version? -- 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/attachment

[Bug 78453] [HAWAII] Get acceleration working

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

[Bug 78453] [HAWAII] Get acceleration working

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

[Bug 78453] [HAWAII] Get acceleration working

ed in bug #74250. Tried attachment #93015 from bug #73420 and i get a hard lock up, can't even ssh the machine. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://list

[PATCH] drm: refcnt drm_display_mode

On Sun, Jul 27, 2014 at 1:38 PM, Daniel Vetter wrote: > On Sun, Jul 27, 2014 at 6:20 PM, Rob Clark wrote: >> On Sun, Jul 27, 2014 at 11:17 AM, Daniel Vetter wrote: >>> On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark wrote: We're going to need this for atomic. Signed-off-by: Rob Clark

[Bug 78453] [HAWAII] Get acceleration working

happens only in fullscreen mode. -- 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/20140727/4aaa1a83/attachment.html>

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

I think the problem is the driver hasn't called radeon_cs_space_add_persistent_bo. Marek On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen wrote: > I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx > Playstation1 Emulator to the Powerpc-architecture. When running certain > games

[PATCH v2 15/25] amdkfd: Add kernel queue module

Am 27.07.2014 um 13:05 schrieb Oded Gabbay: > On 21/07/14 05:42, Jerome Glisse wrote: >> On Thu, Jul 17, 2014 at 04:29:22PM +0300, Oded Gabbay wrote: >>> From: Ben Goz >>> >>> The kernel queue module enables the amdkfd to establish kernel >>> queues, not exposed to user space. >>> >>> The kernel

[Bug 78453] [HAWAII] Get acceleration working

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140727/2f7d9e39/attachment.html>

[PATCH v2 10/25] amdkfd: Add topology module to amdkfd

On 21/07/14 01:37, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:17PM +0300, Oded Gabbay wrote: >> From: Evgeny Pinchuk >> >> This patch adds the topology module to the driver. The topology is exposed to >> userspace through the sysfs. >> >> The calls to add and remove a device to/from topo

[PATCH v2 10/25] amdkfd: Add topology module to amdkfd

On 21/07/14 01:37, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:17PM +0300, Oded Gabbay wrote: >> From: Evgeny Pinchuk >> >> This patch adds the topology module to the driver. The topology is exposed to >> userspace through the sysfs. >> >> The calls to add and remove a device to/from topo

[PATCH v2 12/25] amdkfd: Add binding/unbinding calls to amd_iommu driver

On 21/07/14 02:04, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:19PM +0300, Oded Gabbay wrote: >> This patch adds the functions to bind and unbind pasid from a device through >> the amd_iommu driver. >> >> The unbind function is called when the mm_struct of the process is released. >> >> T

[PATCH v2 13/25] amdkfd: Add queue module

On 21/07/14 02:06, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:20PM +0300, Oded Gabbay wrote: >> From: Ben Goz >> >> The queue module enables allocating and initializing queues uniformly. >> >> Signed-off-by: Ben Goz >> Signed-off-by: Oded Gabbay >> --- >> drivers/gpu/drm/radeon/amdkf

[PATCH v2 15/25] amdkfd: Add kernel queue module

On 21/07/14 05:42, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:22PM +0300, Oded Gabbay wrote: >> From: Ben Goz >> >> The kernel queue module enables the amdkfd to establish kernel queues, not >> exposed to user space. >> >> The kernel queues are used for HIQ (HSA Interface Queue) and DIQ

[PATCH v2 16/25] amdkfd: Add module parameter of scheduling policy

On 21/07/14 05:45, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:23PM +0300, Oded Gabbay wrote: >> From: Ben Goz >> >> This patch adds a new parameter to the amdkfd driver. This parameter enables >> the user to select the scheduling policy of the CP. The choices are: >> >> * CP Scheduling

[PATCH v2 21/25] amdkfd: Implement the create/destroy/update queue IOCTLs

On 21/07/14 02:09, Jerome Glisse wrote: > On Thu, Jul 17, 2014 at 04:29:28PM +0300, Oded Gabbay wrote: >> From: Ben Goz >> >> Signed-off-by: Ben Goz >> Signed-off-by: Oded Gabbay >> --- >> drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c | 133 >> +++- >> drivers/gpu/drm/r

[Bug 78453] [HAWAII] Get acceleration working

achment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140727/68c43566/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

nnamon uses as I couldn't find any settings related to opengl). -- 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/20140727/334ca839/attachment.html>

[PATCH] drm: refcnt drm_display_mode

On Sun, Jul 27, 2014 at 11:17 AM, Daniel Vetter wrote: > On Sat, Jul 26, 2014 at 12:51 AM, Rob Clark wrote: >> We're going to need this for atomic. >> >> Signed-off-by: Rob Clark > > I disagree. Iiui correctly Rob's concern is that the additional stuff > to keep track of mode lists (list_head an

[Bug 66963] Rv6xx dpm problems

power level 2sclk: 72500 mclk: 4 vddc: 1250 status: r -- 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/20140

[Bug 80584] XCOM: Eenemy Unknown incorrect hair rendering

|| -- 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/20140727/67b58dfd/attachment.html>

[Bug 80584] XCOM: Eenemy Unknown incorrect hair rendering

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

[Bug 66963] Rv6xx dpm problems

esume too or only with hibernate/resume. -- 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/20140727/0709c94a/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

rrectly. XRender never worked with GLAMOR since I've started using GLAMOR (IIRC it was something close to 0.3). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freede

[Bug 81644] Random crashes on RadeonSI with Chromium.

patch this can be closed? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2062afb4f804afef61cbe62a30cac9a46e58e067 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: