On Wed, 21 Oct 2015, Benjamin Gaignard wrote:
>
> The outcome of the previous RFC about how do secure data path was the need
> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>
Have you addressed all the questions raised by Alan here:
https://lkml.org/lkml/2015/5/8/629
Also,
On Wed, 21 Oct 2015, Benjamin Gaignard wrote:
> Secure Memory Allocation Framework goal is to be able
> to allocate memory that can be securing.
> There is so much ways to allocate and securing memory that SMAF
> doesn't do it by itself but need help of additional modules.
> To be sure to use the
Remove an unused variable that generates a compilation warning
introduced in commit 4e270f088011 ("drm/gem: Drop struct_mutex
requirement from drm_gem_mmap_obj").
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/g
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/20151022/65893220/attachment.html>
( like SSE4 test ) have been done by the application who uses
llvm libs
--
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/20151022/bee338ff/attachment.html>
On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:
> Hi Rafael,
>
> On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki
> wrote:
> > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki
> >> wrote:
> >> > ACPI uses
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous s
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/01648dbc/attachment-0001.html>
Hi Linus,
been a bit slow gathering these,
drm/mst: one mutex leak in a fail path
radeon: two oops fixes, one dpm fix
i915: one messy set of fixes, where we revert the original fix,
and pull back the proper set of fixes from -next on top.
nouveau: one fix for an illegal buffer placement.
Doesn'
https://bugzilla.kernel.org/show_bug.cgi?id=104791
Aaron Lu changed:
What|Removed |Added
Component|ACPICA-Core |Video(DRI - non Intel)
Assignee|lv.
On Wed, Oct 21, 2015 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 11:36:27AM +0200, Daniel Vetter wrote:
> > On Fri, Sep 11, 2015 at 04:10:10PM +0200, Lucas Stach wrote:
> > > Hey all,
> > >
> > > this is a new posting of the Etnaviv DRM driver for Vivante embedde
On Wed, Oct 21, 2015 at 10:04:15PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 10:37:27PM +0200, Takashi Iwai wrote:
> > On Wed, 21 Oct 2015 20:19:38 +0200,
> > Russell King - ARM Linux wrote:
> > >
> > > On Wed, Oct 21, 2015 at 07:59:06PM +0200, Takashi Iwai wrote:
> > > > On
On Wed, Oct 21, 2015 at 11:19:10PM +, Bish, Jim wrote:
> On Tue, 2015-10-20 at 18:04 +0530, Shashank Sharma wrote:
> > From DRM color management:
> >
> > DRM color manager supports these color properties:
> > 1. "ctm": Color transformation matrix property, where a
>
On Wed, Oct 21, 2015 at 5:14 PM, David Herrmann
wrote:
> On Wed, Oct 21, 2015 at 5:11 PM, Daniel Vetter wrote:
>> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
>>> In addition to the last-in/first-out stack for accessing drm_mm nodes,
>>> we occasionally and in the future often w
Am Donnerstag, den 22.10.2015, 09:12 +0200 schrieb Daniel Vetter:
> On Wed, Oct 21, 2015 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 11:36:27AM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 11, 2015 at 04:10:10PM +0200, Lucas Stach wrote:
> > > > Hey all,
> > >
Hi Dave,
Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work
from Ville in here since it's low-risk but lots of churn all over.
With this Jani will take over 4.4 from me.
Cheers, Daniel
The following changes since commit 80bea1897d7bc35e2b201847e12029a9d677cf12:
drm/i91
Am Donnerstag, den 22.10.2015, 09:12 +0200 schrieb Daniel Vetter:
[...]
> > > - all the array allocations aren't checked for integer overflows in
> > > gem_submit. Just use kmalloc_array or similar to get this right. That
> > > means you need to allocations in submit_create, but imo better saf
https://bugzilla.kernel.org/show_bug.cgi?id=105051
--- Comment #15 from Darren Hart ---
Thanks for reporting, we're following up on the platform-drivers-x86 mailing
list.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=105051
Darren Hart changed:
What|Removed |Added
Assignee|drivers_video-dri at kernel-bu |drivers_platform_x86 at
kernel
e does not belong into the discussion of this
particular bug here. Thanks for your patience :)
--
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/d
Hi, Dave,
I'm not sure whether this patch comes in too late, but it would be good to
have it in. It stabilizes command submission in case of command buffer errors.
The following changes since commit ed7d78b2da32198ca4c70172e3b63c6b3e2c570b:
drm/vmwgfx: Fix kernel NULL pointer dereference on ol
From: Tom St Denis
In the function amdgpu_vamgr_find_va() the function would return
without unlocking the mutex if the base_required offset was below
the va managers base offset.
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
---
amdgpu/amdgpu_vamgr.c | 4 +++-
1 file changed, 3 in
From: Tom St Denis
This patch fixes a use-after-free bug in the vamgr_deinit function.
Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
---
amdgpu/amdgpu_vamgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 22
From: Tom St Denis
Move the allocation of result prior to the IOCTL so we can cleanly
backtrack if the allocation fails.
Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
---
amdgpu/amdgpu_bo.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_b
I just realized that I've forgotten to update all the gem refcounting
docs. For pennance also add pretty docs for the overall drm_gem_object
structure, with a few links thrown in fore good.
As usually we need to make sure the kerneldoc reference is at most a
sect2 for otherwise it won't be listed.
It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.
The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.
While at it add a note in the create_mmap_offset kerneldoc that
dri
A bunch of things have been removed meanwhile and docs not fully
brought up to speed. And a few gaps closed where I noticed missing
kerneldoc while reading through the overview sections.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 33 -
drive
On Thu, Oct 8, 2015 at 5:54 PM, Pushpal Sidhu wrote:
> Comparing the imx6qdl-gw54xx.dtsi and imx6qdl-sabersd.dtsi, I couldn't
> see too many differences between HDMI and LVDS, so I'm a little
> surprised you don't see this exact same behavior there. Note that I've
On a imx6q-sabresd I get HDMI a
On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt wrote:
> Dave suggested it was time to just send a pull request on the driver, so
> here goes:
Why is that when the binding is still under discussion[1]? Even the
agreed changes never got reposted.
Rob
[1] https://lkml.org/lkml/2015/10/9/676
>
> The
On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter
wrote:
> I just realized that I've forgotten to update all the gem refcounting
> docs. For pennance also add pretty docs for the overall drm_gem_object
> structure, with a few links thrown in fore good.
>
> As usually we need to make sure the kerneld
ot;core2";
case 29: // Intel Xeon processor MP. All processors are manufactured
using
// the 45 nm process.
return "penryn";
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An
Hi Dave,
Few more drm-misc stragglers for 4.4. Big thing is the generic probe for
imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing).
Also the hdmi clocking fixes from Ville which was a lot of confusion about
which tree it should be applied to ;-)
Cheers, Daniel
The foll
On Fri, Oct 23, 2015 at 02:47:49AM +0800, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test WARNING on drm/drm-next -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Updat
On Thu, Oct 22, 2015 at 01:54:17PM -0400, Alex Deucher wrote:
> On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter
> wrote:
> > I just realized that I've forgotten to update all the gem refcounting
> > docs. For pennance also add pretty docs for the overall drm_gem_object
> > structure, with a few li
On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt wrote:
> > Dave suggested it was time to just send a pull request on the driver, so
> > here goes:
>
> Why is that when the binding is still under discussion[1]? Even the
> agreed changes n
Hello all,
For a while now, I've been working to fix tearing with PRIME. I have a working
solution that requires changes to DRM, libdrm, and the X server. I've also
implemented sink support in the modesetting driver, and source support in the
NVIDIA proprietary driver.
These DRM patches ultimatel
From: agoins
Factors contents of drm_mode_page_flip_ioctl() into drm_mode_page_flip(),
allowing it to be callable from the kernel within DRM. Replace contents of
drm_mode_page_flip_ioctl() with a call to drm_mode_page_flip().
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_crtc.c | 90 ++
From: agoins
Adds new struct drm_prime_fence_ctx as field of drm_prime_member, and
initializes it when member is created. Used for keeping track of context id
and seqno of fences to be generated by PRIME.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_prime.c | 12
1 file chang
From: agoins
Replace drm_prime_lookup_buf_by_handle() and drm_prime_lookup_buf_handle()
with more generalized drm_prime_lookup_member_by_handle() and
drm_prime_lookup_buf_member(), respectively. New implementations return the
member itself rather than extracting a specific field, allowing other
f
From: agoins
Adds drm_gem_prime_page_flip(), a helper implementation of
prime_page_flip() to be used by DRM drivers.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_prime.c | 147
include/drm/drmP.h | 3 +
2 files changed, 150 insertion
From: agoins
Adds prime_page_flip() to struct drm_driver, intended to be a function to
schedule a flip in response to a fence being signaled.
Makes drivers use drm_gem_prime_page_flip() helper implementation.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
dri
From: agoins
Adds DRM_IOCTL_PRIME_PAGE_FLIP, a new PRIME ioctl that uses DRM driver
function prime_page_flip() to request a DRM page flip in response to an
exclusive fence being signaled on a PRIME DMA-BUF's associated reservation
object.
drm_internal.h:
Add declaration for drm_prime_page_fl
On Thu, Oct 22, 2015 at 01:00:57PM -0700, Alex Goins wrote:
> From: agoins
>
> Adds drm_gem_prime_page_flip(), a helper implementation of
> prime_page_flip() to be used by DRM drivers.
>
> Signed-off-by: Alex Goins
> ---
> drivers/gpu/drm/drm_prime.c | 147
> ++
Thanks for the quick feedback, Daniel!
>This looks really strange - you force-complete the fence already attached
>(which might be from any driver attached to this dma-buf)?
>The creator of the fence is supposed to complete it when whatever async
>operation that is scheduled and which is using t
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/05c22ce0/attachment.html>
uot;-sse41");
+#endif
+ }
--
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/20151022/d6cd6ee0/attachment.html>
've updated the llvm bug accordingly.
--
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/20151022/0e542ef6/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/3ebd4533/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/23275697/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/533e7233/attachment.html>
e subject lines matching the style for the
subsystem.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/1d27045b/attachment-0001.sig>
.
It's very easy to just discard old serieses and never even look at them,
we have to do that all the time anyway when other people help out with
review and identify issues.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: applicati
On Tue, Jul 28, 2015 at 6:37 PM, Bjorn Andersson
wrote:
> From: Werner Johansson
>
> This adds support for the Sharp panel found on the Qualcomm
> Snapdragon 800 Dragonboard (APQ8074)
>
> Signed-off-by: Werner Johansson
> Signed-off-by: Bjorn Andersson
Anything holding this back from being mer
Recent Intel platforms (SKL+) support a background canvas color below the
hardware planes. This background color can be seen on areas not covered by a
plane, or if we program the hardware with various plane blending modes.
Chandra Konduru previously took a stab at writing i915 patches to support
To support CRTC background color, we need a way of communicating RGB
color values to the DRM. However there is often a mismatch between how
userspace wants to represent the color value vs how it must be
programmed into the hardware; this mismatch can easily lead to
non-obvious bugs. Let's create
SKL and BXT allow CRTC's to be programmed with a background/canvas color
below the programmable planes. Let's expose this as a property to allow
userspace to program a desired value.
This patch is based on earlier work by Chandra Konduru; unfortunately
the driver has evolved so much since his pat
Now that we've added an RGBA property type to the kernel that handles
RGBA values with a specific bit layout, let's add a userspace helper to
allow userspace to easily build values in the proper format.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper
---
xf86drmMode.c | 36 +
On 22 October 2015 at 02:54, Rafael J. Wysocki wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > F
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8afda45..613bee2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -789,6 +789,8 @@ struct intel_device_info {
> > u8 num_sprites[I915_MAX_PIPES];
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> But that's moot currently because Greg believes that the time spent
> probing devices at boot time could be reduced enough so that the order
> in which devices are probed becomes irrelevant. IME that would have to
> be under 200ms so
Hi Russell,
On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >
> >
> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >> But that's moot currently because Greg believes that the time spent
> >> probing devices at boot time cou
On 21 October 2015 at 23:50, Frank Rowand wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand
>> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tom
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand
> >> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
>
>
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>
>
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>> But that's moot currently because Greg believes that the time spent
>> probing devices at boot time could be reduced enough so that the order
>> in which devices are probed beco
pass in err twice to get it logged. That's
not a thing of beauty but it gets the job done... but perhaps your
original interface is better, it's a bit cleaner.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
This patch introduces the module_drm_i2c_encoder_driver macro which is
a convenience macro for I2C encoder driver modules similar to others
such as module_platform_driver.
To help with this we also add the drm_i2c_encoder_register macro
that gets THIS_MODULE without include chaining or adding it t
t;>> Best regards
>>> Andreas
>
> No I never tested anything on an imac 5K.
>
> Can you boot with drm.debug=6 radeon.mst=1 and post the
> dmesg logfile?
>
> I'm not sure if the 5K mode on these would need to be reverse engineered
> there is definite
Hi Dave,
A bit smaller pull this time. Few minor things, plus initial support
for msm8996 (snapdragon 820).. Sorry, a bit latish, was hoping to get
some 8960/8064 DSI stuff included. But still waiting on the v2 of the
patchset (just pending some minor review comments). It would be nice
to get
rchives/dri-devel/attachments/20151022/1d1bd5fc/attachment-0001.obj>
71 matches
Mail list logo
