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 nu
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
>> 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 drm_d
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
bac
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140120/342f551e/attachment.html>
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 whe
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 de
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.
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 the
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
--- a/drivers/gpu/dr
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 +
d
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/f79bee29/attachment.html>
have 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>
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. no
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 th
ts.freedesktop.org/archives/dri-devel/attachments/20140120/6f845a39/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 can
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 followin
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>
https://bugzilla.kernel.org/show_bug.cgi?id=68701
--- Comment #2 from William ---
Created attachment 122741
--> https://bugzilla.kernel.org/attachment.cgi?id=122741&action=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
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
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 a/drivers/gpu/drm/r
his 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>
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>
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
> edi
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>
nownworlds.com/discussion/132731/linux-intel-hd-4000-opengl-3-1-core-profile
--
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/
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/08fe8044/attachment.html>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/dcbbc102/attachment.html>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/9a42fdc0/attachment.html>
de 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/20140120/b07acc67/attachment.html>
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
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 ou
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 a/drivers/gpu/drm/udl/udl_gem.c
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 b/drivers/gpu/drm/
Instead of rounding down to the next lower page-boundary, round up.
dma-buf guarantees that we can map buffers in multiples of a page, so if
an exporter does not page-align, do it ourselves.
This avoids issues if the exported buffer contains an unaligned size and
we crop it. In this case, the buff
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
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 insertio
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 hap
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 b/drivers/gpu/drm/drm_
(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>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/75d39f0d/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/52068d7c/attachment.html>
s 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/2fb4944b/attachment.html>
fine.
Thanks,
Paul
-- 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>
-- 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>
--
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>
-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: T
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/8d837238/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
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/7f662a22/attachment.html>
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
10:
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
> th
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...
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 ins
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>
- 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, 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
e there are tiling- and caching issues.
>
>
> /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>
59 matches
Mail list logo
