attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141102/a9e7ab54/attachment.html>
after booting.
--
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/20141102/34b2f6d0/attachment.html>
On Sun, Nov 02, 2014 at 02:19:16PM +0100, Daniel Vetter wrote:
> I've tried to cc all the people who have recently added new stuff
> but forgotten to update documentation.
>
> I've also decided not to bother documenting the massive property list
> in struct drm_mode_config. If that beast keeps on
While writing atomic docs I've noticed that I don't get any errors
for my screw-ups in drm_crtc.h. Fix this immediately.
This just does the bare minimum to get starts, lots of stuff isn't
properly documented yet unfortunately.
v2: Fix adjacent spelling error Sean noticed.
Reviewed-by: Sean Paul
Hi Linus,
drm fixes, nothing too astounding or major, radeon, i915
vmwgfx, armada and exynos.
biggest ones:
vmwgfx has one big locking regression fix,
i915 has come displayport fixes
radeon has some stability and a memory alloc failure
armada and exynos have some vblank fixes.
Dave.
The follow
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141102/4bafdaf9/attachment-0001.html>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141102/a3a54896/attachment.html>
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/20141102/fe829906/attachment.html>
So my original plan was that the drm core refcounts framebuffers like
with the legacy ioctls. But that doesn't work for a bunch of reasons:
- State objects might live longer than until the next fb change
happens for a plane. For example delayed cleanup work only happens
_after_ the pageflip io
In all cases the text requires that new drivers are converted to the
atomic interfaces.
v2: Add overview for state handling.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 20 +++-
drivers/gpu/drm/drm_atomic_helper.c | 36 +
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
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
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.
v2: Clarify async howto a bit per the discussion With Rob Clark.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_at
This patch is for enabling async commits. It replaces an earlier
approach which added an async boolean paramter to the ->prepare_fb
callbacks. The idea is that prepare_fb picks up the right fence to
synchronize against, which is then used by the synchronous commit
helper. For async commits drivers
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
So this is finally the integration of the crtc and plane 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,
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
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
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
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
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
I've forgotten to do this in:
commit cb597bb3a2fbfc871cc1c703fb330d247bd21394
Author: Daniel Vetter
Date: Sun Jul 27 19:09:33 2014 +0200
drm: trylock modest locking for fbdev panics
Oops, fix this asap.
In my defense kerneldoc is really awful and there's no way it can pick
up structured
I've tried to cc all the people who have recently added new stuff
but forgotten to update documentation.
I've also decided not to bother documenting the massive property list
in struct drm_mode_config. If that beast keeps on growing we might want
to extract it into a separate structure which we wo
While writing atomic docs I've noticed that I don't get any errors
for my screw-ups in drm_crtc.h. Fix this immediately.
This just does the bare minimum to get starts, lots of stuff isn't
properly documented yet unfortunately.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 4
Just a bit of OCD cleanup on headers - this function isn't the core
interface any more but just a helper for drivers who haven't yet
transitioned to universal planes. Put the declaration at the right
spot and sprinkle necessary #includes over all drivers.
Maybe this helps to encourage driver maint
Hi all,
So here's my atomic series, finally debugged. This is just the
core<->driver interface plus a big pile of helpers. Short recap of the main
ideas:
- There are essentially three helper libraries in this patch set:
* Transitional helpers to use the new plane callbacks for legacy plane
rchives/dri-devel/attachments/20141102/93eed0ee/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83461
Christian König changed:
What|Removed |Added
Attachment #155721|0 |1
is obsolete|
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141102/fcfd001a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=86891
--- Comment #21 from Michael Mair-Keimberger ---
Just to clarify - the screenshot was made with mesa-10.3.2 and cpu's frequency
set to performance.
With mesa git i got following results:
FPS: 20.0
Score: 838
Min FPS: 7.4
Max FPS: 30.5
Pretty nea
https://bugzilla.kernel.org/show_bug.cgi?id=86891
--- Comment #20 from Michael Mair-Keimberger ---
Created attachment 156161
--> https://bugzilla.kernel.org/attachment.cgi?id=156161&action=edit
vally screenshot
(In reply to Andy Furniss from comment #19)
> (In reply to Michael Mair-Keimberger
u 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/20141102/526e25d2/attachment.html>
never did it as often as it
does with llvm 3.5, current mesa, radeonsi.
--
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/20141102/
33 matches
Mail list logo
