Move rotation property to drm core mode_config. This allows us to ditch
the driver-private lastclose logic.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_drv.c | 20 ---
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/ace2b7ab/attachment.html>
Hi all,
some small bug fixes for some small bugs i saw
when looking at the current drm vblank handling code.
All patches are rather simple, all compile-tested against
drm-next, but only the drm_vblank_off() one (patch 2)
tested in "real life" so far.
thanks,
-mario
drm_vblank_cleanup() would operate on non-existent dev->vblank
data structure, as failure to allocate that data structure is
what triggers the error path in the first place.
Signed-off-by: Mario Kleiner
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 inserti
Move the query for vblank count and time before the
vblank_disable_and_save(), because the disable fn
will invalidate the vblank timestamps, so all emitted
events would carry an invalid zero timestamp instead of
the timestamp of the vblank of vblank disable. This could
confuse clients.
Signed-off-
Calling vblank_disable_fn() will cause that function to no-op
if !dev->vblank_disable_allowed for some kms drivers, e.g.,
on nouveau-kms. This can cause the gpu vblank irq's to not get
disabled before freeing the dev->vblank array, so if a
vblank irq fires and calls into drm_handle_vblank() after
d
On Tuesday, August 05, 2014 8:08 PM, Sonika Jindal wrote:
>
> From: Sonika Jindal
>
> Renaming defines to have levels instead of nominal values.
(+cc Daniel Vetter)
Hi Sonika Jindal,
Thank you for sending the patch. However, please add the reason
to this commit message, as you said at '[PATCH
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/a076db01/attachment.html>
breakpoint triggers.
--
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/20140806/074fd9be/attachment.html>
lists.freedesktop.org
--
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/20140806/225b5625/attachment.html>
ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/b7e70e79/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #29 from Dan Merillat ---
(In reply to Christian K?nig from comment #28)
> Created attachment 142281 [details]
> Possible fix v3.
>
> How about this one? Does it fixes the issue as well?
Sorry for the long delay in getting back to yo
On Tue, Aug 5, 2014 at 7:32 PM, Christian K?nig
wrote:
>>> Christian wrote some patches to validate the interfaces, but I'm not sure
>>> he ever sent them out. We haven't yet done a full implementation in the
>>> usermode drivers to take advantage of this yet.
>>
>> Well right now I've consisten
On Wed, Aug 6, 2014 at 3:22 AM, Mario Kleiner
wrote:
> some small bug fixes for some small bugs i saw
> when looking at the current drm vblank handling code.
>
> All patches are rather simple, all compile-tested against
> drm-next, but only the drm_vblank_off() one (patch 2)
> tested in "real life
Am 06.08.2014 um 00:13 schrieb Jerome Glisse:
> On Tue, Aug 05, 2014 at 07:45:21PM +0200, Christian K?nig wrote:
>> Am 05.08.2014 um 19:39 schrieb Jerome Glisse:
>>> On Tue, Aug 05, 2014 at 06:05:29PM +0200, Christian K?nig wrote:
From: Christian K?nig
Avoid problems with writeback
Hi Dave
A bunch of cleanups that are all reviewed by Daniel and Alex. Has survived the
compile/runtime test bots for some weeks now, so should all be fine. Nothing
critical, though.
This series includes:
* hide ctxbitmap harder so newer drivers don't use it
* drop redundant drm_file->is_master
Thanks for comments.
On 2014? 08? 05? 20:12, Thierry Reding wrote:
> On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote:
>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>> This patch adds below two flags for LPM transfer, and it attaches LPM flags
>>> to a msg in accordance with master's
On 6 August 2014 16:58, David Herrmann wrote:
> Hi Dave
>
> A bunch of cleanups that are all reviewed by Daniel and Alex. Has survived the
> compile/runtime test bots for some weeks now, so should all be fine. Nothing
> critical, though.
>
> This series includes:
> * hide ctxbitmap harder so newe
the problem, but I'm not sure it's the
proper fix.
--
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/20140806/50b41cdb/attachment.html>
messages are indeed sent in low power mode by default.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/d3ed859e/attachment-0001.sig>
From: Chris Wilson
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulatio
On Wed, Aug 06, 2014 at 01:26:00PM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal
>
> Reset rotation property to 0.
>
> v2: Resetting after disabling the plane
>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Sonika Jindal
> Reviewed-by: Ville Syrj?l?
I've pulled i
This allows us to ditch the driver-private lastclose logic.
Cc: Tomi Valkeinen
Cc: Rob Clark
Signed-off-by: Daniel Vetter
--
Untested and atm only applies on top of drm-intel-nightly.
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_drv.c | 9 ++---
drive
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these
Hi Dave,
Here's the radeon userptr patches. If you and Jerome are
ok with them for 3.17, please pull.
The following changes since commit 21d70354bba9965a098382fc4d7fb17e138111f3:
drm: move drm_stub.c to drm_drv.c (2014-08-06 19:10:44 +1000)
are available in the git repository at:
git://pe
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140806/36db2b37/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/e25750ba/attachment.html>
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/20140806/169d2c35/attachment.html>
On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter
wrote:
> In drm/i915 we want to get at the video= cmdline modes even when we
> don't have fbdev support enabled, so that users can always override
> the kernel's initial mode selection.
>
> But that gives us a direct depency upon the parsing code in
t here
is my dmesg output (sorry about the quality)
--
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/20140806/8ef3b3b0/attachment.html>
On Wed, Aug 06, 2014 at 03:22:46AM +0200, Mario Kleiner wrote:
> Calling vblank_disable_fn() will cause that function to no-op
> if !dev->vblank_disable_allowed for some kms drivers, e.g.,
> on nouveau-kms. This can cause the gpu vblank irq's to not get
> disabled before freeing the dev->vblank arr
On Wed, Aug 06, 2014 at 03:22:44AM +0200, Mario Kleiner wrote:
> drm_vblank_cleanup() would operate on non-existent dev->vblank
> data structure, as failure to allocate that data structure is
> what triggers the error path in the first place.
>
> Signed-off-by: Mario Kleiner
> Cc: stable at vger.
On Wed, Aug 06, 2014 at 03:22:45AM +0200, Mario Kleiner wrote:
> Move the query for vblank count and time before the
> vblank_disable_and_save(), because the disable fn
> will invalidate the vblank timestamps, so all emitted
> events would carry an invalid zero timestamp instead of
> the timestamp
From: Ville Syrj?l?
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv->event_list, but that
may be too late and file_priv->event_list has already been cleaned up
From: Ville Syrj?l?
Warn when there are events on the file_priv->event_list just before
file_priv gets freed. This can occur if the driver doesn't clean up
pending page flip events in ->preclose().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_fops.c | 2 ++
1 file changed, 2 insertions
On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter wrote:
> The current refcounting scheme is that the fb lookup idr also holds a
> reference. This works out nicely bacause thus far we've always
> explicitly cleaned up idr entries for framebuffers:
> - Userspace fbs get removed in the rmfb ioctl or whe
From: Ville Syrj?l?
This is mostly a repost of the earlier series [1]. Most of the patches
have been reviewed, but I have added quite a few new ones to the end to
fix various issues.
[1] http://lists.freedesktop.org/archives/dri-devel/2014-May/060518.html
Ville Syrj?l? (19):
drm: Always rejec
From: Ville Syrj?l?
Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().
When drm_vblank_get() encou
From: Ville Syrj?l?
v2: Drop the drm_vblank_off() (Daniel)
Use drm_crtc_vblank_{get,put}()
Reviewed-by: Matt Roper
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/
From: Ville Syrj?l?
Clearing the timestamps causes us to send zeroed timestamps to userspace
if they get sent out in response to the drm_vblank_off(). It's better
to send the very latest timestamp and count instead.
Testcase: igt/kms_flip/modeset-vs-vblank-race
Reviewed-by: Matt Roper
Reviewed-
From: Ville Syrj?l?
Move drm_update_vblank_count() to avoid forward a declaration.
No functional change.
Reviewed-by: Matt Roper
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 128 +++---
1 file changed, 64 insertions(+), 64 deletions(-)
From: Ville Syrj?l?
If the vblank irq has already been disabled (via the disable timer) when
we call drm_vblank_off() sample the counter and timestamp one last time.
This will make the sure that the user space visible counter will account
for time between vblank irq disable and drm_vblank_off().
From: Ville Syrj?l?
Declare a local struct drm_vblank_crtc * and use that
instead of having to do dig it out via 'dev->vblank[crtc]'
everywhere.
Performed with the following coccinelle incantation,
and a few manual whitespace cleanups:
@@
identifier func,member;
expression num_crtcs;
struct drm
From: Ville Syrj?l?
Currently it's possible that the following will happen:
1. drm_wait_vblank() calls drm_vblank_get()
2. drm_vblank_off() gets called
3. drm_wait_vblank() calls drm_queue_vblank_event() which
adds the event to the queue event though vblank interrupts
are currently disabled
From: Ville Syrj?l?
Make drm_vblank_put() disable the vblank interrupt immediately when the
refcount drops to zero and drm_vblank_offdelay<0.
v2: Preserve the current drm_vblank_offdelay==0 'never disable' behaviur
Reviewed-by: Matt Roper
Signed-off-by: Ville Syrj?l?
---
Documentation/DocBoo
From: Ville Syrj?l?
Currently both drm_irq.c and several drivers call drm_vblank_put()
while holding event_lock. Now that drm_vblank_put() can disable the
vblank interrupt directly it may need to grab vbl_lock and
vblank_time_lock. That causes deadlocks since we take the locks
in the opposite ord
From: Ville Syrj?l?
When drm_vblank_on() is called the hardware vblank counter may have
been reset, so we can't trust that the old values sampled prior to
drm_vblank_off() have anything to do with the new values.
So update the .last count in drm_vblank_on() to make the first
drm_vblank_enable()
From: Ville Syrj?l?
Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.
v2: Add some notes about the flag to the kernel doc
Reviewed-by: Matt Roper
Reviewed-by: Daniel Vett
From: Ville Syrj?l?
If the user is interested in getting accurate vblank sequence
numbers all the time they may disable the vblank disable timer
entirely. In that case it seems appropriate to kick start the
vblank interrupts already from drm_vblank_on().
v2: Adapt to the drm_vblank_offdelay ==0
From: Ville Syrj?l?
If we already have a timestamp for the current vblank counter, don't
update it with a new timestmap. Small errors can creep in between two
timestamp queries for the same vblank count, which could be confusing to
userspace when it queries the timestamp for the same vblank seque
From: Ville Syrj?l?
During vblank disable the code tries to guess based on the
timestamps whether we just missed one vblank or not. And if so
it increments the counter. However it forgets to store the new
timestamp to the approriate slot in our timestamp ring buffer.
So anyone querying the timest
From: Ville Syrj?l?
Now that the vblank races are plugged, we can opt out of using
the vblank disable timer and just let vblank interrupts get
disabled immediately when the last reference is dropped.
Gen2 is the exception since it has no hardware frame counter.
Reviewed-by: Matt Roper
Reviewed
From: Ville Syrj?l?
We should update the last in drm_update_vblank_count() to avoid applying
the diff more than once. This could occur eg. if drm_vblank_off() gets
called multiple times for the crtc.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 2 ++
1 file changed, 2 insertion
From: Ville Syrj?l?
We call drm_vblank_off() during crtc sanitation to make sure the
software and hardware states agree. However drm_vblank_off() will
try to update the vblank timestamp and sequence number which lands
us in some trouble.
As the pipe is disabled the hardware frame counter query w
From: Ville Syrj?l?
The kernel might mistakenly send out a zeroed vblank timestamp when
the vblank wait gets terminated early due to crtc disable. Add an
assertion to catch that.
Signed-off-by: Ville Syrj?l?
---
tests/kms_flip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/kms_
From: Ville Syrj?l?
Now that drm_update_vblank_count() can be called even when we're not
about to enable the vblank interrupts we shouldn't print debug messages
stating otherwise.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrj?l?
update_scanline_offset() in intel_sanitize_crtc() was supposed to
be called only for active crtcs. But due to some underrun patches it
now gets updated for all crtcs on gmch platforms.
Move the update_scanline_offset() to the very beginning of
intel_sanitize_crtc() where we u
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these
dri-devel/attachments/20140806/ed83531e/attachment.html>
On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote:
> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter
> wrote:
> > The current refcounting scheme is that the fb lookup idr also holds a
> > reference. This works out nicely bacause thus far we've always
> > explicitly cleaned up idr entries fo
On Wed, Aug 06, 2014 at 12:27:32PM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter
> wrote:
> > In drm/i915 we want to get at the video= cmdline modes even when we
> > don't have fbdev support enabled, so that users can always override
> > the kernel's initial mo
On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> If there are pending page flips when the fd gets closed those page
> flips may have events associated to them. When the page flip eventually
> completes it will queue the event to file_pri
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these
From: Chris Wilson
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line
On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> If we already have a timestamp for the current vblank counter, don't
> update it with a new timestmap. Small errors can creep in between two
> timestamp queries for the same vblank count,
On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> We should update the last in drm_update_vblank_count() to avoid applying
> the diff more than once. This could occur eg. if drm_vblank_off() gets
> called multiple times for the crtc.
>
>
On Wed, Aug 06, 2014 at 02:56:14PM +0200, Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > If we already have a timestamp for the current vblank counter, don't
> > update it with a new timestmap. Small erro
On Wed, Aug 06, 2014 at 02:49:59PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> During vblank disable the code tries to guess based on the
> timestamps whether we just missed one vblank or not. And if so
> it increments the counter. However it forgets to store the new
On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote:
>> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter
>> wrote:
>> > The current refcounting scheme is that the fb lookup idr also holds a
>> > reference. This works out nicely bacause th
From: Ville Syrj?l?
kms_flip_event_leak will issue a page flip and close the file
descriptor before the flip has finished. This may cause the kernel
to leak the page flip event. The test itself won't actually fail but
if the kernel notices the leak and WARNs piglit will report a failure.
Signed-
On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Currently it's possible that the following will happen:
> 1. drm_wait_vblank() calls drm_vblank_get()
> 2. drm_vblank_off() gets called
> 3. drm_wait_vblank() calls drm_queue_vblank_event(
On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> We call drm_vblank_off() during crtc sanitation to make sure the
> software and hardware states agree. However drm_vblank_off() will
> try to update the vblank timestamp and sequence numbe
On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > We should update the last in drm_update_vblank_count() to avoid applying
> > the diff more than once. This could oc
On Wed, Aug 06, 2014 at 03:23:01PM +0200, Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > Currently it's possible that the following will happen:
> > 1. drm_wait_vblank() calls drm_vblank_get()
> > 2. drm_
On Wed, Aug 06, 2014 at 03:30:17PM +0200, Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > We call drm_vblank_off() during crtc sanitation to make sure the
> > software and hardware states agree. However dr
On Wed, Aug 06, 2014 at 01:51:41PM +0300, Ville Syrj?l? wrote:
> On Wed, Aug 06, 2014 at 03:22:46AM +0200, Mario Kleiner wrote:
> > Calling vblank_disable_fn() will cause that function to no-op
> > if !dev->vblank_disable_allowed for some kms drivers, e.g.,
> > on nouveau-kms. This can cause the gp
On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote:
> On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote:
> > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote:
> >> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter
> >> wrote:
> >> > The current refcounting scheme is that the fb loo
On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> If there are pending page flips when the fd gets closed those page
> flips may have events associated to them. When the page flip eventually
> completes it will queue the event to file_pri
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/078cdbef/attachment.html>
On Wed, Aug 06, 2014 at 04:30:29PM +0300, Ville Syrj?l? wrote:
> On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrj?l?
> > >
> > > We should update the last in drm_update_
-
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/20140806/b6976766/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/77f5502b/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/5b571254/attachment.html>
/dri-devel/attachments/20140806/bde0754e/attachment-0001.html>
e 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/20140806/a55853eb/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/4fbffa31/attachment.html>
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/a29aa51f/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140806/44138098/attachment.html>
On Tue, Aug 05, 2014 at 06:05:31PM +0200, Christian K?nig wrote:
> From: Christian K?nig
>
> Whenever userspace mapping related to our userptr change
> we wait for it to become idle and unmap it from GTT.
>
> v2: rebased, fix mutex unlock in error path
> v3: improve commit message
Why in hell d
Am 06.08.2014 um 17:16 schrieb Jerome Glisse:
> On Tue, Aug 05, 2014 at 06:05:31PM +0200, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> Whenever userspace mapping related to our userptr change
>> we wait for it to become idle and unmap it from GTT.
>>
>> v2: rebased, fix mutex unlock in er
hat case, but we might want to figure out why it happened in the first place.
--
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/attachmen
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/063bc9d6/attachment.html>
:fa78380797 +
patch from attachment 104101.
--
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/20140806/3f940f6f/attachment-0001.html>
On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote:
> Am 06.08.2014 um 00:13 schrieb Jerome Glisse:
> >On Tue, Aug 05, 2014 at 07:45:21PM +0200, Christian K?nig wrote:
> >>Am 05.08.2014 um 19:39 schrieb Jerome Glisse:
> >>>On Tue, Aug 05, 2014 at 06:05:29PM +0200, Christian K?nig wrote
After spending slightly more time than I'd care to admit debugging the
various and presumably spectacular way things fail when you pass too low
a value to drm_vblank_init() (thanks console-lock for not letting me see
the carnage!), I decided it might be a good idea to add some sanity
checking.
Sig
Am 06.08.2014 um 18:08 schrieb Jerome Glisse:
> On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote:
>> Am 06.08.2014 um 00:13 schrieb Jerome Glisse:
>>> On Tue, Aug 05, 2014 at 07:45:21PM +0200, Christian K?nig wrote:
Am 05.08.2014 um 19:39 schrieb Jerome Glisse:
> On Tue, Aug
On Sat, Jul 26, 2014 at 01:39:58PM +0200, Fran?ois Tigeot wrote:
> For the sake of simplicity, KMS support can always be considered
> present on DragonFly.
>
> If some particular version doesn't support KMS yet, appropriate
> checks are already done in Dports's x11-drivers/ Makefiles and
> KMS-ena
On Wed, Aug 06, 2014 at 01:16:59PM -0400, Rob Clark wrote:
> After spending slightly more time than I'd care to admit debugging the
> various and presumably spectacular way things fail when you pass too low
> a value to drm_vblank_init() (thanks console-lock for not letting me see
> the carnage!),
On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote:
> On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote:
> > Am 06.08.2014 um 18:08 schrieb Jerome Glisse:
> > >On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote:
> > >>Am 06.08.2014 um 00:13 schrieb Jerome Gliss
1 - 100 of 133 matches
Mail list logo
