Hi Linus,
Not a huge amount happening, some MAINTAINERS updates, radeon, vmwgfx and
tegra fixes,
Dave.
The following changes since commit 75936c65dda54a08d9124f24f8725f86a4adc286:
Merge tag 'ttm-fixes-3.14-2014-02-18' of
git://people.freedesktop.org/~thomash/linux into drm-fixes (2014-02-1
On Sat, Mar 1, 2014 at 5:10 AM, Francois Tigeot wrote:
> On Mon, Feb 17, 2014 at 10:07:54AM +0100, Fran?ois Tigeot wrote:
>> Signed-off-by: Fran?ois Tigeot
>> ---
>> configure.ac | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/configure.ac b/configure.ac
>> index d2d19d6..b7eef96 100
?? ?
???QQ: 1908029728
??? 1908029728 at qq.com
Two possible solutions, depending upon what you actually want to do:
a) You have a static set of buffers shared between a static set of
devices (e.g. a bunch of yuv frames in a picture pipeline), and you
only want to cut down the (re-)import overhead: Just make your
userspace more intelligent and
On Fri, Feb 28, 2014 at 5:40 PM, Russell King
wrote:
> Add a maintainers entry for the TDA998x driver. Rob Clark has handed
> this driver over to me to look after.
>
> Signed-off-by: Russell King
Acked-by: Rob Clark
> ---
> Rob,
>
> I'd appreciate an Ack for this hand-over of maintainership o
The GEM CMA helpers uses a custom mmap implementation based on
remap_pfn_range(). While this works when the buffer DMA and physical
addresses are identical, it fails to take IOMMU into account and tries
to mmap the buffer to userspace using the DMA virtual address instead of
the physical address. T
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140302/9875b5de/attachment.html>
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/20140302/5e8aa6c5/attachment-0001.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140302/3439ba85/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140302/693e989a/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140302/24011274/attachment.html>
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/20140302/aca60b24/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140302/957b4cee/attachment.html>
On Sat, Mar 1, 2014 at 5:29 AM, Christian K?nig
wrote:
> Am 01.03.2014 10:15, schrieb Lauri Kasanen:
>
>> On Sat, 1 Mar 2014 06:47:41 +1000
>> Dave Airlie wrote:
>>
>>> On Sat, Mar 1, 2014 at 5:56 AM, Christian K?nig
>>> wrote:
Am 28.02.2014 19:50, schrieb Lauri Kasanen:
> Wi
Dave,
A couple of minor fixes.
The following changes since commit b0447888dc29f4fb91c3b3b02e3f1f0bfc6e1222:
MAINTAINERS: update drm git tree entry (2014-02-27 14:49:55 +1000)
are available in the git repository at:
git://people.freedesktop.org/~thomash/linux tags/vmwgfx-fixes-3.14-2014-03-
desktop.org/archives/dri-devel/attachments/20140302/0284f1ad/attachment-0001.html>
From: Marek Ol??k
Signed-off-by: Marek Ol??k
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 88 +++---
drivers/gpu/drm/radeon/radeon_object.h | 3 +-
3 files changed, 85 insertions(+), 8 del
From: Marek Ol??k
Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
a number from 0 to 15. The higher the number, the higher the priority,
which means a buffer with a higher number will be validated sooner.
The old behavior is preserved: Buffers used for write are prioritize
From: Marek Ol??k
Signed-off-by: Marek Ol??k
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index f28a8d8..d49a3f7 100644
-
From: Marek Ol??k
Signed-off-by: Marek Ol??k
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 9863ca7..d09650c
From: Marek Ol??k
The statistics are:
- VRAM usage in bytes
- GTT usage in bytes
- number of bytes moved by TTM
The last one is actually a counter, so you need to sample it before and after
command submission and take the difference.
This is useful for finding performance bottlenecks. Userspace
From: Marek Ol??k
When passing buffers between processes, the receiving process needs to know
the original buffer domain, so that it doesn't accidentally move the buffer.
v2: reserve the buffer
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon.h| 3 +++
drivers/gpu/drm/rad
While updating "[PATCH 5/6] drm/radeon: validate relocations in the order
determined by userspace" based on feedback, which should have been a harmless
change, I discovered that the performance dropped. The problem was that
list_add/move from one list to another reversed the list of relocations
re 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/20140302/6c769218/attachment.html>
24 matches
Mail list logo
