t;http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/7f662a22/attachment.html>
3.13 solves this issue.
Any chance you could bisect to see what the fix was?
--
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/20
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/8d837238/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/f957a097/attachment.pgp>
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/94b36a5a/attachment.pgp>
--
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/20140120/cdde2904/attachment-0001.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/2fb4944b/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/52068d7c/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/75d39f0d/attachment.html>
(132)
--
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/20140120/349bc139/attachment.html>
There is no need to initialize this variable, so drop it. Otherwise, the
compiler won't warn if we use it unintialized.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c
Lets make sure some basic expressions are always true:
bpp != NULL
width != NULL
height != NULL
stride = bpp * width < 2^32
size = stride * height < 2^32
PAGE_ALIGN(size) < 2^32
At least the udl driver doesn't check for multiplication-overflows, so
lets just make sure it will never
All drivers currently need to clean up the vma-node manually. There is no
fancy logic involved so lets just clean it up unconditionally. The
vma-manager correctly catches multiple calls so we are fine.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 2 ++
1 file changed, 2
Remove double-whitespace and wrong indentation.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bed5c3b..c1eaf35 100644
--- a/drivers/gpu/drm/drm_gem.c
Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c
On Mon, Dec 23, 2013 at 11:27:40AM +0530, Vandana Kannan wrote:
> Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
> CEA-861E Table 4. This is useful for filling up the detail in AVI
> infoframe.
>
> v2: Ville's inputs incorporated. Added picture aspect ratio as part of
>
Hi Dave,
New tree with the INFO ioctl merge fixed up. This also adds a couple
of additional minor fixes.
The following changes since commit cfd72a4c2089aa3938f37281a34d6eb3306d5fd8:
Merge branch 'drm-intel-next' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2014-01-20
pdated to present state)
Device:Cape Verde XT [Radeon HD 7770 GHz Edition] [683d]
--
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
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/9a42fdc0/attachment.html>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/dcbbc102/attachment.html>
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/08fe8044/attachment.html>
hives/dri-devel/attachments/20140120/b9a95590/attachment.html>
on other it always hang it there.
--
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/20140120/89f6df57/attachment.html>
oes it mean "the devs"?
The developers.
--
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/20140120/a7b647a5/attachment.html>
e devs"?
--
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/20140120/97fae92f/attachment.html>
Hi Dave,
Here's the vblank timestamp pull request you wanted.
I addressed the few bugs that Mario pointed out and added
the r-bs.
As it has been a while since I made the changes, I gave it a
quick spin on a few different i915 machines. Fortunately
everything still seems to be fine.
The
Hi Igor,
On 01/18/2014 09:54 PM, Igor Gnatenko wrote:
> From: Aaron Lu
>
> Some system's ACPI video backlight control interface is broken and the
> native backlight control interface should be used by default. This patch
> sets the use_native_backlight parameter to true for those systems so
>
https://bugzilla.kernel.org/show_bug.cgi?id=68701
--- Comment #2 from William ---
Created attachment 122741
--> https://bugzilla.kernel.org/attachment.cgi?id=122741=edit
successful dmesg for 3.13.0
Retested with 3.13.0 release, and the same kernel config as
I used with 3.13-rc8, and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Widawsky (3):
intel: squash unused variable 'bo_gem'
intel: Handle malloc fails in context create
intel: Merge latest i915_drm.h
Eric Anholt (2):
drm: Initialize or valgrind-clear modesetting ioctl arguments.
intel:
Hi
On Mon, Jan 20, 2014 at 3:00 AM, Dave Airlie wrote:
>>> Hi
>>>
>>> On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann
>>> wrote:
Hi
With 3.13-rc1 the required VFS core changes for anonymous backing inodes
in DRM
got merged. This series reworks the previous patches (I
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/20140120/bc7d62fe/attachment.html>
On 01/20/2014 02:10 PM, Rob Clark wrote:
> On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn wrote:
>> I am working on a client/server program, where the server creates (and has
>> access to a framebuffer), and then needs to share this framebuffer with a
>> client program so that this client program
org/archives/dri-devel/attachments/20140120/6f845a39/attachment.html>
We don't have to turn backlight on/off everytime a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
> 1 remove the win8 OSI check, I've seen win7 laptops that also needs to
> have only the GPU interface left and checking win8 doesn't make much
> sense now;
Are we sure that those aren't simply some other bug?
--
Matthew Garrett
We can't use "dev" after we freed it on the line before.
Fixes: b3f2333de8e8 ('drm: restrict the device list for shadow attached
drivers')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 5736aaa7e86c..f7af69bcf3f4 100644
---
the time to bisect the kernel.
--
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/20140120/5bbf5bab/attachment.html>
ions(+), 33 deletions(-)
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/bfe2c9a6/attachment-0001.pgp>
>> Hi
>>
>> On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann
>> wrote:
>>> Hi
>>>
>>> With 3.13-rc1 the required VFS core changes for anonymous backing inodes in
>>> DRM
>>> got merged. This series reworks the previous patches (I think from early
>>> August '13) and finally replaces the ugly
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/f79bee29/attachment.html>
Reported-by: Fengguang Wu
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |4 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 45 +--
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c |1 +
It seems this got dropped when we merged UVD support
last year. Add this back now.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_uvd.c | 1 +
drivers/gpu/drm/radeon/uvd_v2_2.c | 1 +
2 files changed, 2 insertions(+)
diff --git
On Sun, Jan 19, 2014 at 7:02 PM, Dave Airlie wrote:
> On Fri, Jan 17, 2014 at 2:34 AM, Alex Deucher
> wrote:
>> Hi Dave,
>>
>> A few more changes for 3.14, mostly just bug fixes. Note that:
>> drm/radeon: add query to fetch the max engine clock.
>> will conflict with 3.13 final, but the fix is
On 01/15/2014 12:38 AM, Eric Anholt wrote:
> I've seen a number of apps spending unreasonable amounts of time in
> drm_intel_bo_busy during the buffer mapping process.
>
> We can't track idleness in general, in the case of buffers shared
> across processes. But this should significantly reduce
On 12/28/2013 10:06 PM, Eric Anholt wrote:
> Fixes valgrind complaints in the modesetting driver. I tried to
> follow each ioctl's pattern for whether it was initializing just the
> in values, or both in and out values.
> ---
> Makefile.am | 2 ++
> xf86drmMode.c | 19 +++
> 2
David Herrmann's changes to use a pseudo filesystem for drm's shared
inodes requires this be exported for drm to build as a module.
I'd like to merge this via the drm tree, so please ack.
Signed-off-by: Dave Airlie
---
fs/dcache.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/dcache.c
On Sun, 19 Jan 2014 20:06:09 -0800
Olof Johansson wrote:
> Hi,
>
> On Sun, Jan 19, 2014 at 10:58 AM, Jean-Francois Moine
> wrote:
> > Signed-off-by: Jean-Francois Moine
> > ---
> > .../devicetree/bindings/drm/i2c/tda998x.txt| 24
> > ++
> > 1 file changed, 24
On Fri, Jan 17, 2014 at 2:34 AM, Alex Deucher wrote:
> Hi Dave,
>
> A few more changes for 3.14, mostly just bug fixes. Note that:
> drm/radeon: add query to fetch the max engine clock.
> will conflict with 3.13 final, but the fix is pretty obvious.
No it isn't obvious at all!
Since the info
Hi
On Mon, Jan 20, 2014 at 8:21 AM, Daniel Vetter
wrote:
> At least drm/i915 expects that the obj->dev pointer is set even in
> failure paths. Specifically when the shmem initialization fails we
> call i915_gem_object_free which needs to deref obj->base.dev to get at
> the slab pointer in the
On Mon, Jan 20, 2014 at 08:21:54AM +0100, Daniel Vetter wrote:
> At least drm/i915 expects that the obj->dev pointer is set even in
> failure paths. Specifically when the shmem initialization fails we
> call i915_gem_object_free which needs to deref obj->base.dev to get at
> the slab pointer in
https://bugzilla.kernel.org/show_bug.cgi?id=67631
--- Comment #1 from Vitaliy Filippov ---
The bug also reproduces on 3.13 from ubuntu-kernel PPA.
Anyone??
--
You are receiving this mail because:
You are watching the assignee of the bug.
At least drm/i915 expects that the obj->dev pointer is set even in
failure paths. Specifically when the shmem initialization fails we
call i915_gem_object_free which needs to deref obj->base.dev to get at
the slab pointer in the device private structure. And the shmem
allocation can easily fail
On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn wrote:
> I am working on a client/server program, where the server creates (and has
> access to a framebuffer), and then needs to share this framebuffer with a
> client program so that this client program can draw into the framebuffer
> directly (i.e.
ues.
>
>
> /Thomas
>
>
>>
>>
>>> Thanks,
>>> - Rian
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>>
>>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/be22e56d/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140120/342f551e/attachment.html>
- Rian
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/53a1370a/attachment.html>
On Mon, Jan 20, 2014 at 10:54:44AM +1000, Dave Airlie wrote:
> David Herrmann's changes to use a pseudo filesystem for drm's shared
> inodes requires this be exported for drm to build as a module.
>
> I'd like to merge this via the drm tree, so please ack.
Having looked through these patches...
58 matches
Mail list logo
