rendering
with a quick reset. Iirc someone (from cros google team maybe) was even
looking into making llvmpipe run on top of vgem as a real dri/drm mesa
driver.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-
, no idea. We might need to revamp all that. But for a
userspace client that does nothing fancy (no multiple render buffer
targets in one bo, or vk style "I write to everything all the time,
perhaps" stuff) there should be 0 perf difference between implicit sync
through dma_resv and explicit sync through sync_file/syncobj/dma_fence
directly.
If there is I'd consider that a bit a driver bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
hristian gets to fix up amdgpu more,
at least for anything that has a dma-buf attached even if it's not shared
with anything !amdgpu.ko).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X
video experts. (I just do 3D)
dma_fence has an error state which you can set when things went south. The
fence still completes (to guarantee forward progress).
Currently that error code isn't really propagated anywhere (well i915 iirc
does something like that since it tracks the depedencies internally
are messy. In the old
> system the feedback loop was simple, we don't have admin time or money
> for servers we don't get the features, cloud allows us to get the
> features and enjoy them and at some point in the future the bill gets
> paid by someone else. Credit cards lifesty
On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
wrote:
>
> On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
> > wrote:
> > > Hi all,
> > >
> > > You might have read the short take in the X.org boar
On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > Th
On Fri, Feb 28, 2020 at 2:54 AM Carsten Haitzler wrote:
>
> On Thu, 27 Feb 2020 22:27:04 +0100 Daniel Vetter
> said:
>
> Might I suggest that given the kind of expenses detailed here, literally
> buying
> 1 - 4 reasonably specced boxes and hosting them at OSUOSL would be
sponsors, but
filling a shortfall of this magnitude is neither easy nor quick work,
and we therefore decided to give an early warning as soon as possible.
Any help in finding sponsors for fd.o is very much appreciated.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
is better since in
general there will be a bit of Q with organizers. The board plans to
make a final decision by end of July.
If you just have some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote:
> On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
&
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote:
> On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
&
On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > &g
On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > > wrote:
&
On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > > wrote:
&
On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > &g
nsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
nsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
comments in private, please send them to
both the x.org board and gpul - they want to know how to improve and
what to keep for the next conference they're going to organize too.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
to seeing you there. If you have any
> inquiries/questions, please send an email to xdc2...@gpul.org, adding on
> CC the X.org board (bo...@foundation.x.org).
>
> Best regards,
>
> Sam
> _______
> mesa-dev mailing list
> mesa-...@li
On Thu, Jun 21, 2018 at 11:16 PM, Daniel Vetter wrote:
> Hi all,
>
> The X.org board is soliciting proposals to host XDC in 2019. By the usual
> rotation a location in (North) America is preferred, but the board will also
> consider other locations, especially if there's an
questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel
On Mon, Jun 18, 2018 at 10:23:03AM -0700, Matt Turner wrote:
> On Mon, Jun 18, 2018 at 8:51 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 13, 2018 at 02:54:52PM -0700, Matt Turner wrote:
> > > On Fri, Mar 9, 2018 at 6:28 AM, Petri Latvala
> > > wrote:
>
s
useful to cut down a bit from the all the options, mostly they didn't
really work after a short while anyway)?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg@lists.x.org: X.Org support
Archives: http://lists.fr
On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote:
> On 24 April 2018 at 20:14, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com>
> > wrote:
> >> On 13 April 2018 at 11:00, D
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 13 April 2018 at 11:00, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive communit
i Latvala <petri.latv...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Reviewed-by: Keith Packard <kei...@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
If you wonder about the wide distribution list f
the X server and it can use that to enumerate the available displays
>>>> through the Vulkan API.
>>
>>
>> The thing is if you are running under X I don't think apps should be
>> bypassing
>> things and going straight to hw enumeration, it makes too many problems
>&
folks since 2-3 years now). Bunch of people decided not to do XDC this
year even, because too much travelling in one row. Plus Google's limit
in scheduling a room, plus Khr f2f. We'll try to do better next year,
but sometimes perfect scheduling is just not an option.
Thanks, Daniel
--
Daniel Vette
to this mail or send a mail to
bo...@foundation.x.org if you don't want the entire world to read it.
And if you want to send at pseudonymous feedback, drop a pastebin onto
the #xf-bod channel on the OFTC irc server.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79
h 6bpc panels really.
Right now userspace can't request a specific bpp for the sink/pipe,
that's fully under the kernel's control. It only gets to set the pixel
format of fbs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sun, Apr 02, 2017 at 12:58:33PM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > On that, I think we could just unconditionally hand leases all encoders.
> > Encoders turned out to be a bit an uapi mistake.
>
> Well, given the complexit
ll appear to be disconnected to
> + all clients other than the grabbing client.
> +
> +┌───
> +RRDestroyOutputGrab
> + outputgrab: OUTPUTGRAB
> +└───
> + Errors: OutputGrab
> +
> + Destroys the named OUTPUTGRAB.
> +
> + ❧❧❧
>
On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > The multi-seat thing sounds like vapourware, I think we should care about
> > the vr use-case for now, and only that one.
>
> Ok, I can live with
On Mon, Apr 03, 2017 at 09:41:34AM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > Hm, if you restrict getresources and getplanes, you'll get your leased
> > objects query api. Iirc that part was missing in your kernel patch. And it
> > g
On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > Also if this confuses VR, then another reason why we want to make leases
> > invariant and only allow pure revoke, not changing the list.
>
de which failed at 30 bpp, might still work at 18bpp and is
> > better going to a lower resolution.
>
> The question was whether the kernel will ever allow the same mode at the
> same bpp, since that's what this patch tries to do.
Yes, this can happen. Doing a full modeset with recomputing clocks and
everything behind userspace's back might not be something the kernel
driver can pull of with a reasonable amount of effort, hence why we punt
to userspace. The interface spec makes this a CAN, not WILL, to allow less
unreasonable hw to handle these cases directly in the kernel driver. E.g.
plain link-retraining is handled in i915.ko still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
On Thu, Feb 02, 2017 at 09:57:20AM -0800, Eric Anholt wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> >> Jani Nikula <jani.nik...@linux.intel.com> writes:
> >>
> >> > On
cussion
in the other thread.
-Daniel
>
> Regards
> Manasi
>
> >
> > Regards
> > Manasi
> >
> >
> > On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> > > Martin Peres <martin.pe...@linux.intel.com> writes:
> > >
>
Manasi
>
>
> On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> > Martin Peres <martin.pe...@linux.intel.com> writes:
> >
> > > On 06/02/17 17:50, Martin Peres wrote:
> > >> On 03/02/17 10:04, Daniel Vetter wrote:
> > >>> On F
e modes again based on new link
> > paarmeters and send a new mode list back.
>
> Seems like a bad behaviour from the kernel, isn't it? It should return
> immediatly
> if the mode is gonna be pruned :s
The mode list pruning isn't relevant for modeesets, the kernel doesn't
validat
ew times, and I'd like
that to be an orthogonal abi extension. Right now we just don't have the
required tracking even within the kernel to know which connector changed
(and the tracking we do have missed a few things, too). My idea is to push
the tracking into the leaves of the callchains with a functio
ils...\n", con_id);
> +}
> +drmModeFreeProperty(props);
> +}
> +drmModeFreeConnector(koutput);
> +}
> +
> mode_res = drmModeGetResources(drmmode->fd);
> if (!mode_res)
>
's the way I always make edits. Way nicer than a web
> GUI. :-)
And if you have a shell account, it's easy to resurrect your web wiki
account:
https://wiki.freedesktop.org/sitewranglers/wiki/401/
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
changed, 62 insertions(+), 26 deletions(-)
> >
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _
about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel
that.
Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.
Thanks,
Daniel, secretary of the board
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
) defined(_SC_AVPHYS_PAGES) /* Solaris */
long pagesize, npages;
pagesize = sysconf(_SC_PAGESIZE);
--
1.7.9.2
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org
aligned which would look funky for full-screen apps I guess.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg
On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote:
On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote:
On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@nvidia.com wrote:
I assume the TILE property described below would be per-connector?
It looks like this would
as a firmware image
which would contain the entire kms state, and which we'd apply in an
atomic modeset at driver load. Everyone else (boot splash, X, ...)
will then just inherit that config. That should give you even
flicker-free screen walls if you want to ;-)
Cheers, Daniel
--
Daniel Vetter
Software
. At least my minimal testing with a few X servers seemed to
indicate that that still worked ...
Or did you manage to get rid of the dummy console, too? That would be a
bug in the Kconfig logic we currently have.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
with i7 4770k (this machine, now
fixed).
I'll file it under stuff we need to fix before enabling fbc for real. And
we need a testcase for this, too. For now I guess you have to life with
disabling fbc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http
this :(
On the plus side our QA has started another try at running with nouveau
(last time around was just too much fallout from nouveau) to run our neat
seat of prime tests. So investing into a few good tests there should pay
of nicely.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79
On Wed, Jun 12, 2013 at 12:28 PM, Terje Bergström tbergst...@nvidia.com wrote:
On 11.06.2013 15:09, Daniel Vetter wrote:
Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
is used to restart the ioctl if we had to kick a thread (to make sure
it doesn't hold any locks), e.g
the reset handler would do (kernel work item currently), not any
userspace process doing an ioctl. But atm we don't resubmit victimized
workloads.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Jun 11, 2013 at 1:43 PM, Terje Bergström tbergst...@nvidia.com wrote:
On 11.06.2013 14:00, Daniel Vetter wrote:
We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
which blew up the gpu (that one has been submitted already in a
different ioctl call), but to be able
with
kms. Been a while though since I've last fired it up ... So going back
and trying to bisect could be really useful.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-driver-ati mailing
@@
#include sys/wait.h
#include limits.h
#include wordexp.h
+#include signal.h
#include i915_drm.h
#include intel_bufmgr.h
--
1.7.9.2
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel
helper functions.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
, right?
vmwgfx ...
Please bring on the flames.
Cheers, Daniel
Daniel Vetter (37):
drm: review locking rules in drm_crtc.c
drm/doc: integrate drm_crtc.c kerneldoc
drm: add drm_modeset_lock|unlock_all
drm/i915: rework locking for intel_dpio|sbi_read|write
drm/i915: use drm_modeset_lock_all
And do a quick pass to adjust them to the last few (years?) of changes
...
This time actually compile-tested ;-)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Documentation/DocBook/drm.tmpl |4 ++
drivers/gpu/drm/drm_crtc.c | 92 +++-
2
-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 105 ++--
include/drm/drmP.h |5 +++
2 files changed, 18 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d6d0072
as the shotgun solutions for all places
where a more fine-grained locking isn't (yet) implemented.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c| 147 +
drivers/gpu/drm/drm_crtc_helper.c |8 +-
drivers/gpu/drm
don't need that consistency. And
correctness of the dpio interface is ensured with the dpio_lock.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c |4 +--
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |2
Two exceptions:
- debugfs files only read information which is not related to crtc, so
can stay on the modeset_config lock.
- Same holds for the edp vdd work in intel_dp.c. Add a corresponding
WARN_ON and a comment next to the intel_dp struct fields for
documentation.
Signed-off-by: Daniel
Only two places:
- suspend/resume
- Some really strange mode validation tool with too much funny-lucking
hand-rolled conversion code.
Better safe than sorry, so convert both places to keep the locking
semantics as much as possible.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Just a call to drm_helper_resume_force_mode, obviously wants full
locking for that.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/ast/ast_drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast
Only a resume method to account for.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
figured I should be able to get away with
this in a few more places ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b
to initialize the new lock in crtc_init and lock it righ
away, for otherwise the modeset_unlock_all below will try to unlock a
not-locked mutex.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 12
include/drm/drm_crtc.h |9 +
2 files
Just refactoring to make the next patche simpler. Now all indirect register
access in the new modesetting driver should go through the r100_mm_(w|r)reg
fucntions.
RADEON_READ_MM from the old driver seems to be totally unused, so just kill
it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
spinlock. Otoh the pageflip completion happens
from the vblank irq handler ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/radeon/r100.c | 13 -
drivers/gpu/drm/radeon/radeon.h|2 ++
drivers/gpu/drm/radeon/radeon_device.c |1 +
3
intermingle.
The approach here is a bit overkill since the per-crtc channels used
to schedule the pageflips could probably be used without this pushbuf
locking, but I'm not familiar enough with the nouveau codebase to be
sure of that.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu
than the old code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/ast/ast_drv.h |2 ++
drivers/gpu/drm/drm_crtc.c |6 --
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 32 ++--
3 files changed, 32 insertions(+), 8 deletions
-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |6 ++
drivers/gpu/drm/radeon/radeon_cursor.c |8 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 13 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
cleanup the framebuffer, which is now moot since
the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
break anything (but it's refcount management only, so should be safe).
Signed-off-by: Daniel Vetter daniel.vet
isn't on a fpriv list any
more will fail for driver-private objects.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 113 ++--
drivers/gpu/drm/drm_fops.c |1 +
drivers/gpu/drm/i915/i915_debugfs.c|5
up stalling for a few frames in rmfb.
v2: Don't use kreg_get_unless_zero - Greg KH doesn't like that kind of
interface.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c| 109 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
prepares this by moving the modeset locks to nest
within fpriv-fbs_lock. Now the distinction between the fbs_lock and
the device-global fb_lock is clear, since we need to hold the fbs_lock
outside of any modeset_locks in fb_release.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu
framebuffer list. Both seem to have solid locking in place already.
Conclusion is that now it is no longer required to hold the
mode_config lock while freeing a framebuffer.
v2: Drop the corresponding mutex_lock WARN check from
drm_framebuffer_unreference.
Signed-off-by: Daniel Vetter daniel.vet
figured out
how the fbdev support in that driver works. It smells like it's
external though.
v2: The i915 driver creates another private framebuffer in the
load-detect code. Adjust its cleanup code, too.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/ast/ast_fb.c
we only need to fix up all other places to properly reference
count framebuffers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 118 ++--
1 file changed, 80 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm
registers from stolen memory
Note: This is just a quick hack to shut up a warning in the module
unload code, so that I can check again whether we don't leak any
framebuffers.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915
With refcounting we need to adjust framebuffer refcounts at each
callsite - much easier to do if they all call the same little helper
function.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 19 +--
drivers/gpu/drm
We need to hold bdev-fence_lock while grabbing a reference to
the fence, to prevent concurrent clearing/changing of the
ttm_bo-sync_obj field.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/radeon/radeon_display.c |4
1 file changed, 4 insertions(+)
diff --git
the sync_op waiter callback code in
omap_gem.c does not seem to take the right modeset locks. So looks a
bit racy already with the old locking, and no worse off with the new
per-crtc locks.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |7 ---
1
little in-between breakage
(essentially just the ability for userspace to pageflip on load-detect
crtcs when it shouldn't on the i915 driver) I figured I don't need to
bother.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |5 +++--
drivers/gpu/drm
Noticed while reviewing the fence locking in the radone pageflip
handler.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/ttm/ttm_bo_util.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
around.
Explain in a big comment why it is safe. Also update kerneldocs with
the new locking rules around drm_framebuffer_remove.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 72 +++-
1 file changed, 45 insertions(+), 27
check crtc-fb before calling into
driver callbacks, we can't really reduce the critical sections
protected by the mode_config locks.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 37 ++---
1 file changed, 30 insertions(+), 7
Afact vmwgfx already has all the right refcounting implemented on the
backing storage, and we only need to ensure that the drm fb doesn't
disappear untimely. So holding onto the fb reference from _lookup
until vmw_kms_present has completed should be enough.
Signed-off-by: Daniel Vetter daniel.vet
Useful for checking whether the new refcounting works as advertised.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm
protect
plane-fb/plane-crtc and the driver callback (i.e. hw state).
Everything either doesn't disappear (crtc, plane) or is refcounted
(fb), and all the data we check is invariant over the respective
object's lifetimes.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm
We only need to ensure that the fb stays around for long enough. While
at it, only grab the modeset locks when we need them (since most
drivers don't implement the dirty callback, this should help jitter
and stalls when using the generic modeset driver).
Signed-off-by: Daniel Vetter daniel.vet
with prime, but alas ...
- vmwgfx: This driver bothered with an implementation to return 0 as
the handle (which is the canonical nofb handle). Dunno what this is
for, but I've lost myself in vmwgfx too often. Just leave this
as-is.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 22 +++---
drivers/gpu/drm/nouveau/nouveau_bo.h |2 ++
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau
, and
any access through that table will do it's own refcounting.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33e95bb..9ad807d 100644
On Wed, Dec 12, 2012 at 02:06:40PM +0100, Daniel Vetter wrote:
Hi all,
First thing first: It works, I now no longer have a few dropped frames every
10s
on my testbox here with the pageflip i-g-t tests.
Random notes:
- New design has per-crtc locks to protect the crtc input-side
On Wed, Dec 12, 2012 at 3:48 PM, Jerome Glisse j.gli...@gmail.com wrote:
Instead of that i would just move the call to
ttm_buffer_object_transfer to happen before releasing the fence_lock
in ttm_bo_move_accel_cleanup , something like :
Yeah, looks better. Fixed up locally.
-Daniel
--
Daniel
1 - 100 of 131 matches
Mail list logo
