On 03/13/2013 11:36 AM, Jiri Slaby wrote:
> On 02/19/2013 11:32 PM, Marcin Slusarz wrote:
>> On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
>>> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> Tomorrow I'll post a
https://bugs.freedesktop.org/show_bug.cgi?id=65810
--- Comment #1 from Michel Dänzer ---
It looks like there's a drop shadow around the box, so it could just be a
window left behind by the games or something. What does xwininfo say when you
click on the box?
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #10 from Knut Andre Tidemann ---
I've tested the attached patch, and it fixes the crash in kerbal space program.
I've also run the piglit r600.tests before and after patching, but it seems the
results are somewhat mixed. I ran piglit
On Thu, Jun 13, 2013 at 3:17 AM, Christopher Harvey wrote:
> On Wed, Jun 05 2013, Christopher Harvey wrote:
>> G200 cards support, at best, 16 colour palleted images for the cursor
>> so we do a conversion in the cursor_set function, and reject cursors
>> with more than 16 colours, or cursors wit
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #11 from Krzysztof A. Sobiecki ---
Does this behavior also occurred before patching?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dr
https://bugs.freedesktop.org/show_bug.cgi?id=65810
Andreas Boll changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
--
You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #12 from Knut Andre Tidemann ---
Yeah, I ran the piglit tests multiple times again without the patch applied,
and the same result can be observed.
--
You are receiving this mail because:
You are the assignee for the bug.
___
This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.
The purpose of this framework is not only to couple cache operations,
and buffer access control to CPU and DMA but also to provide easy-
Op 17-06-13 13:15, Inki Dae schreef:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
> for lock mechanism.
>
> The purpose of this framework is not only to couple cache operations,
> and buffer access
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #65 from Marc Dietrich ---
regarding crash in comment 57, there seems to be something wrong with cosine:
https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/glsl/functions/glsl-function-cos.html
reproduces th
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #66 from Marc Dietrich ---
crash happens with firefox only, chrome reports test failed.
both browser pass the test with R600_LLVM=0
--
You are receiving this mail because:
You are the assignee for the bug.
__
"make headers_check" complains about include/uapi/drm/tegra_drm.h:
[...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type without
#include
So let's include linux/types.h in this header.
Signed-off-by: Paul Bolle
---
Tested only with "make headers_check". I don't actually build
https://bugzilla.kernel.org/show_bug.cgi?id=59761
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
> Sent: Monday, June 17, 2013 8:35 PM
> To: Inki Dae
> Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org;
> dan...@f
Most graphics cards nowadays have a multiple of this limit as their vram, so
limiting GART doesn't seem to make much sense.
Signed-off-by: Maarten >Lnkhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 3a5e19a..41ddecd 100644
--- a/drivers/
At the larger resolutions, the g200e series sometimes struggles with
maintaining a proper output. Problems like flickering or black bands appearing
on screen can occur. In order to avoid this, limitations regarding resolutions
and bandwidth have been added for the different variations of the g20
This code was ported from the old xorg mga driver. These limits were
implemented as a solution to a number of problems that were seen. These
problems were linked to the bandwidth limitations of the g200e series.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_drv.h |3 +-
Op 17-06-13 15:04, Inki Dae schreef:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
>> Sent: Monday, June 17, 2013 8:35 PM
>> To: Inki Dae
>> Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux-
>> arm-ker...@lists.infradead.o
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> It's just to implement a thin sync framework coupling cache operation. This
> approach is based on dma-buf for more generic implementation against android
> sync driver or KDS.
>
> The described steps may be summarized as:
> lock ->
At least on an IBM Power 720, this check passes, but several piglit
tests will reliably trigger GPU resets due to the ring buffer pointers
not being updated. There's probably a better way to limit this to just
affected machines though.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/radeon/r600
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (lik
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #67 from Marc Dietrich ---
ok, maybe cos, sin, tan, are all broken because of bug 50317.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing lis
2013/6/17 Russell King - ARM Linux
> On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> > It's just to implement a thin sync framework coupling cache operation.
> This
> > approach is based on dma-buf for more generic implementation against
> android
> > sync driver or KDS.
> >
> > The d
On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> At least on an IBM Power 720, this check passes, but several piglit
> tests will reliably trigger GPU resets due to the ring buffer pointers
> not being updated. There's probably a better way to limit this to just
> affected machines though.
2013/6/17 Maarten Lankhorst
> Op 17-06-13 15:04, Inki Dae schreef:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
> >> Sent: Monday, June 17, 2013 8:35 PM
> >> To: Inki Dae
> >> Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel
On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote:
> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> > At least on an IBM Power 720, this check passes, but several piglit
> > tests will reliably trigger GPU resets due to the ring buffer pointers
> > not being updated. There's probably
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> 2013/6/17 Russell King - ARM Linux
> Exactly right. But that is not definitely my point. Could you please see
> the below simple example?:
> (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> space as cachable)
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that
https://bugs.freedesktop.org/show_bug.cgi?id=65822
--- Comment #1 from Tom Stellard ---
I will take a look at this when I get a chance. In the mean time it would be
great if you could convert these into piglit tests. Here is a good example:
http://cgit.freedesktop.org/piglit/tree/tests/cl/progr
2013/6/18 Russell King - ARM Linux
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the b
On Sun, May 26, 2013 at 11:53:11PM +0800, Jiang Liu wrote:
> Enhance DRM drvier to use hotplug-safe iterators to walk PCI buses.
>
> Signed-off-by: Jiang Liu
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_fops.c | 6 --
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> It seems like that all pages of the scatterlist should be mapped with
> DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> function call), and the pages should be unmapped from DMA again every
> time DMA operation is
On Mon, Jun 17, 2013 at 01:58:14PM +0200, Paul Bolle wrote:
> "make headers_check" complains about include/uapi/drm/tegra_drm.h:
> [...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type
> without #include
>
> So let's include linux/types.h in this header.
>
> Signed-off-by: Pau
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
> That has already been fixed in linux-next.
This header was added in v3.10-rc1. The fix in linux-next will ship in
v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10
release candidate(s)?
Thanks,
Paul Bolle
__
https://bugs.freedesktop.org/show_bug.cgi?id=65822
--- Comment #2 from Aaron Watry ---
Created attachment 80967
--> https://bugs.freedesktop.org/attachment.cgi?id=80967&action=edit
Test Code from initial post converted to piglit tests
I've taken a shot at converting the original tests to pigli
On Mon, Jun 17, 2013 at 12:07 PM, Adam Jackson wrote:
> On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote:
>> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
>> > At least on an IBM Power 720, this check passes, but several piglit
>> > tests will reliably trigger GPU resets due to the r
https://bugs.freedesktop.org/show_bug.cgi?id=65822
--- Comment #3 from Aaron Watry ---
Created attachment 80969
--> https://bugs.freedesktop.org/attachment.cgi?id=80969&action=edit
Shader dumps from a radeon 7850 for test cases in attachment 80967
--
You are receiving this mail because:
You a
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_t
https://bugs.freedesktop.org/show_bug.cgi?id=65873
Priority: medium
Bug ID: 65873
Assignee: dri-devel@lists.freedesktop.org
Summary: R600/SI: Cannot select store with truncate to 32-bit
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=65873
--- Comment #1 from Aaron Watry ---
Created attachment 80971
--> https://bugs.freedesktop.org/attachment.cgi?id=80971&action=edit
LLVM assembly that is produced from the vload-int.cl test case
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=65873
--- Comment #2 from Aaron Watry ---
Created attachment 80972
--> https://bugs.freedesktop.org/attachment.cgi?id=80972&action=edit
Output from llc -debug-only=isel --march=r600 --mcpu=verde < vload-int.ll
--
You are receiving this mail because
> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> loaded.
> (Note, no X running on that box)
>
> Trace below shows trinity, but I can reproduce it with just cat
> /proc/dri/0/vma
How about this, lets just rip it all out.
Dave.From 54f9605737437272f440bbc6cc4adf805334
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
>
> > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> > loaded.
> > (Note, no X running on that box)
> >
> > Trace below shows trinity, but I can reproduce it with just cat
> > /proc/dri/0/vma
>
>
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_fb.c between commit b72447cdf129 ("drm/i915:
Drop bogus fbdev sprite disable code") from the drm tree and commit
b51b32cde175 ("drm/i915: s/drm_i915_private_t/struct drm_i915_private/")
from the drm
Hi Mr. Kukjin,
Kindly consider the following patches for review and integration.
regards,
Rahul Sharma.
On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K wrote:
> Hi,
> Tested this series on snow board and is working fine.
>
> Tested-by: Arun Kumar K
>
> Regards
> Arun
>
> On Mon, Jun 10, 2013 at
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (like the radeon
> re
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 3:21 AM
> To: Inki Dae
> Cc: Maarten Lankhorst; linux-fbdev; Kyungmin Park; DRI mailing list; Rob
> Clark; myungjoo.ham; YoungJun Cho; Daniel Vetter; linux-arm-
> ker...@li
Hi
On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote:
> On 06/16/2013 07:57 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> So I've taken a look again at the locking mess in our fbdev support and
>> cried.
>> Fixing up the console_lock mess around the fbdev notifier will be real work,
>> semanat
Hi all,
I'd like to discuss Exynos DRM TODO work.
There are features we have to solve and implement. The purpose of this email
is to share what we have to do so that other guys can be involved without
duplicated work.
1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
devi
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> So I've taken a look again at the locking mess in our fbdev support and
>> cried.
>> Fixing up the console_lock mess around the fbdev notifier will be re
Hi
On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter
wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (like th
. I hope.
--
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/20130617/ab2d4928/attachment.html>
On 06/15/2013 02:16 AM, Aaron Plattner wrote:
> On 06/12/2013 06:16 AM, Joonyoung Shim wrote:
>> This adds to call low-level mmap() from prime helpers.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/drm_prime.c | 5 -
>> include/drm/drmP.h | 2 ++
>> 2 files changed
Thanks Seung-Woo,
On Fri, Jun 14, 2013 at 12:23 PM, ??? wrote:
> Hello Rahul,
>
> On 2013? 06? 11? 23:11, Rahul Sharma wrote:
>> Exynos hdmi IP version is named after hdmi specification version i.e.
>> 1.3 and 1.4. This versioning mechanism is not sufficient to handle
>> the diversity in the hdmi
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Lan Tianyu changed:
What|Removed |Added
Component|Hibernation/Suspend |Video(DRI - non Intel)
AssignedTo|t
ribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/dabe6557/attachment-0001.html>
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/c3be2264/attachment.pgp>
on-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/18a635f4/attachment.pgp>
On 03/13/2013 11:36 AM, Jiri Slaby wrote:
> On 02/19/2013 11:32 PM, Marcin Slusarz wrote:
>> On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
>>> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> Tomorrow I'll post a
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/20130617/aedc978c/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/4308b490/attachment.html>
On Thu, Jun 13, 2013 at 3:17 AM, Christopher Harvey
wrote:
> On Wed, Jun 05 2013, Christopher Harvey wrote:
>> G200 cards support, at best, 16 colour palleted images for the cursor
>> so we do a conversion in the cursor_set function, and reject cursors
>> with more than 16 colours, or cursors wi
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/d9276e98/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/20130617/2b4b5225/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/0fa7d16c/attachment.html>
This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.
The purpose of this framework is not only to couple cache operations,
and buffer access control to CPU and DMA but also to provide easy-
Op 17-06-13 13:15, Inki Dae schreef:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
> for lock mechanism.
>
> The purpose of this framework is not only to couple cache operations,
> and buffer access
the crash.
--
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/20130617/1d578f97/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/7c157ba0/attachment.html>
"make headers_check" complains about include/uapi/drm/tegra_drm.h:
[...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type without
#include
So let's include linux/types.h in this header.
Signed-off-by: Paul Bolle
---
Tested only with "make headers_check". I don't actually build
https://bugzilla.kernel.org/show_bug.cgi?id=59761
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
> Sent: Monday, June 17, 2013 8:35 PM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org; linux-media at vger.kernel.
Most graphics cards nowadays have a multiple of this limit as their vram, so
limiting GART doesn't seem to make much sense.
Signed-off-by: Maarten >Lnkhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 3a5e19a..41ddecd 100644
--- a/drivers/
At the larger resolutions, the g200e series sometimes struggles with
maintaining a proper output. Problems like flickering or black bands appearing
on screen can occur. In order to avoid this, limitations regarding resolutions
and bandwidth have been added for the different variations of the g20
This code was ported from the old xorg mga driver. These limits were
implemented as a solution to a number of problems that were seen. These
problems were linked to the bandwidth limitations of the g200e series.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_drv.h |3 +-
Op 17-06-13 15:04, Inki Dae schreef:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
>> Sent: Monday, June 17, 2013 8:35 PM
>> To: Inki Dae
>> Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org;
>> linux-
>> arm-kernel at l
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> It's just to implement a thin sync framework coupling cache operation. This
> approach is based on dma-buf for more generic implementation against android
> sync driver or KDS.
>
> The described steps may be summarized as:
> lock ->
At least on an IBM Power 720, this check passes, but several piglit
tests will reliably trigger GPU resets due to the ring buffer pointers
not being updated. There's probably a better way to limit this to just
affected machines though.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/radeon/r600
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (lik
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/85ca878f/attachment.html>
On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> At least on an IBM Power 720, this check passes, but several piglit
> tests will reliably trigger GPU resets due to the ring buffer pointers
> not being updated. There's probably a better way to limit this to just
> affected machines though.
On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote:
> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> > At least on an IBM Power 720, this check passes, but several piglit
> > tests will reliably trigger GPU resets due to the ring buffer pointers
> > not being updated. There's probably
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> 2013/6/17 Russell King - ARM Linux
> Exactly right. But that is not definitely my point. Could you please see
> the below simple example?:
> (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> space as cachable)
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that
/program/execute/sha256-Ch.cl
Probably one file for each test would be good.
--
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/20130
On Sun, May 26, 2013 at 11:53:11PM +0800, Jiang Liu wrote:
> Enhance DRM drvier to use hotplug-safe iterators to walk PCI buses.
>
> Signed-off-by: Jiang Liu
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/gpu/drm/drm_fops.c | 6
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> It seems like that all pages of the scatterlist should be mapped with
> DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> function call), and the pages should be unmapped from DMA again every
> time DMA operation is
nux-next.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/e9f488c1/attachment.pgp>
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
> That has already been fixed in linux-next.
This header was added in v3.10-rc1. The fix in linux-next will ship in
v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10
release candidate(s)?
Thanks,
Paul Bolle
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/30699879/attachment.html>
On Mon, Jun 17, 2013 at 12:07 PM, Adam Jackson wrote:
> On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote:
>> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
>> > At least on an IBM Power 720, this check passes, but several piglit
>> > tests will reliably trigger GPU resets due to the r
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/8f7b4103/attachment.html>
next part --
A non-text attachment was scrubbed...
Name: 0001-drm-remove-vma-debug-code.patch
Type: text/x-patch
Size: 4047 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/f7441e61/attachment.bin>
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
>
> > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> > loaded.
> > (Note, no X running on that box)
> >
> > Trace below shows trinity, but I can reproduce it with just cat
> > /proc/dri/0/vma
>
>
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (like the radeon
> re
95 matches
Mail list logo
