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
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
On 8/5/2014 6:00 PM, Daniel Vetter wrote:
> On Tue, Aug 5, 2014 at 1:33 PM, Jindal, Sonika
> wrote:
>>
>>
>> On 8/5/2014 4:45 PM, Daniel Vetter wrote:
>>>
>>> On Tue, Aug 05, 2014 at 04:38:17PM +0530, sonika.jindal at intel.com wrote:
From: Sonika Jindal
Renaming defines to
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
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>
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 ---
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
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
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
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>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/e25750ba/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140806/36db2b37/attachment.html>
From: Sonika Jindal
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Sonika Jindal
Reviewed-by: Ville Syrj?l?
---
include/drm/drm_crtc.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0..62f73bd 100644
--- a/include/drm/
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>
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
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
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
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
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
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
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>
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
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
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
ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/b7e70e79/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>
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
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-
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
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
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>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/a076db01/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/ace2b7ab/attachment.html>
101 - 133 of 133 matches
Mail list logo
