may flush page cache again.
>
> Does the code do some redundant flush, or there is some trick to these
> codes?
>
> Thanks for the answer in advance.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120319/6b818b39/attachment.html>
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120319/5088abcd/attachment.htm>
Can I do the optimization like:
if (ttm->caching_state == tt_cached)
-drm_clflush_pages(ttm->pages, ttm->num_pages);
+for (i = 0; i < ttm->num_pages; ++i)
+ if (PageHighMem(ttm->pages[i]))
+drm_clflush_pages(&ttm->pages[i], 1);
only do flush cache wh
> -Original Message-
> From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk]
> Sent: 19 March 2012 16:57
> To: Tom Cooksey
> Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri-
> devel at lists.freedesktop.org; linux-media at vger.kernel.org;
> rschultz at google.com; Rob Clark; sumit.
On 03/19/2012 05:56 PM, Alan Cox wrote:
>> display controller will be reading the front buffer, but the GPU
>> > might also need to read that front buffer. So perhaps adding
>> > "read-only"& "read-write" access flags to prepare could also be
>> > interpreted as shared& exclusive accesses, if
On 03/19/2012 09:25 PM, Dave Airlie wrote:
On Fri, Mar 16, 2012 at 9:47 AM, Inki Dae wrote:
From: Joonyoung Shim
The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X1
On Mon, Mar 19, 2012 at 04:41:55PM +0100, Daniel Vetter wrote:
> Otherwise subsystems will get this wrong and end up with a second
> export ioctl with the flag and O_CLOEXEC support added.
>
> v2: Fixup the function name and caution exporters to limit the flags
> to only O_CLOEXEC. Noted by Dave A
> If the API was to also be used for synchronization it would have to
> include an atomic "prepare multiple" ioctl which blocked until all
> the buffers listed by the application were available. In the same
Too slow already. You are now serializing stuff while what we want to do
really is
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #9 from Alex Deucher 2012-03-19
16:42:50 ---
Created an attachment (id=72654)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72654)
possible fix
Does this patch fix the issue?
--
Configure bugmail: https://bugzilla.kernel
From: Rob Clark
Otherwise subsystems will get this wrong and end up with a second
export ioctl with the flag and O_CLOEXEC support added.
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
---
Updated version of Daniel's original documentation patch with (hopefully)
improved wording, and a be
> -Original Message-
> From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk]
> Sent: 17 March 2012 20:17
> To: Tom Cooksey
> Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri-
> devel at lists.freedesktop.org; linux-media at vger.kernel.org;
> rschultz at google.com; Rob Clark; sumit.
Otherwise subsystems will get this wrong and end up with a second
export ioctl with the flag and O_CLOEXEC support added.
v2: Fixup the function name and caution exporters to limit the flags
to only O_CLOEXEC. Noted by Dave Airlie.
Cc: Dave Airlie
Signed-Off-by: Daniel Vetter
---
Documentation
https://bugzilla.kernel.org/show_bug.cgi?id=29842
--- Comment #17 from Igor Rudchenko 2012-03-19 16:35:11
---
To Matthew Garrett:
I agree about network cards, but current situation with video card worries me
much. Prior 3.0.20, 3.2.5 and 3.3 kernels, users of ThinkPads T60 can simply
add k
https://bugzilla.kernel.org/show_bug.cgi?id=29412
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
--- Comment
On Mon, Feb 27, 2012 at 01:42:43PM +0100, Stanislaw Gruszka wrote:
> I'm able to reproduce random memory corruption after hibernate.
> Corruption is not reproducible when I disable mode setting, what
> seems to blame i915 driver or generic DRM kernel code.
>
> I'm able to reproduce bug on Fedora 1
Big differences to other contenders in the field (like ion) is
that this also supports highmem, so we have to split up the cpu
access from the kernel side into a prepare and a kmap step.
Prepare is allowed to fail and should do everything required so that
the kmap calls can succeed (like swapin/ba
On Sun, 18 Mar 2012, Rafael J. Wysocki wrote:
> On Sunday, March 18, 2012, Hugh Dickins wrote:
> > On Sat, 17 Mar 2012, Keith Packard wrote:
> > > On Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins
> > > wrote:
> > > > I keep worrying about the sequence when the machine is powered on again
>
On Sat, 17 Mar 2012, Linus Torvalds wrote:
> On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins wrote:
> >
> > I've got to go out for an hour: I'll digest more and think more about
> > this when I get back. If someone could explain the original problem
> > with _MOVABLE, that would help me:
>
> I do
From: Rob Clark
Otherwise subsystems will get this wrong and end up with a second
export ioctl with the flag and O_CLOEXEC support added.
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
---
Updated version of Daniel's original documentation patch with (hopefully)
improved wording, and a be
https://bugzilla.kernel.org/show_bug.cgi?id=29842
Matthew Garrett changed:
What|Removed |Added
CC||mjg59-kernel at srcf.ucam.org
--- C
On Mon, 2012-03-19 at 23:11 +0800, Scott Fang wrote:
> In function ttm_tt_set_caching
> ,,,
>
> if (ttm->caching_state == tt_cached)
> drm_clflush_pages(ttm->pages, ttm->num_pages);
>
> for (i = 0; i < ttm->num_pages; ++i) {
> cur_page = ttm->pages[i];
> if (li
On Fri, Mar 16, 2012 at 9:47 AM, Inki Dae wrote:
> From: Joonyoung Shim
>
> The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
> This G2D driver is exynos drm specific and supports only G2D(version
> 4.1) of later Exynos series from Exynos4X12 because supporting DMA.
So just t
On Sat, 2012-03-17 at 14:14 -0700, Linus Torvalds wrote:
> On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie wrote:
> >
> > I did however get a flashback in google to this:
> >
> > http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
> >
> > Linus don't think we ever did work out
> -Original Message-
> From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk]
> Sent: 19 March 2012 16:57
> To: Tom Cooksey
> Cc: 'Rob Clark'; linaro-mm-...@lists.linaro.org; dri-
> de...@lists.freedesktop.org; linux-me...@vger.kernel.org;
> rschu...@google.com; Rob Clark; sumit.sem...@linaro.o
On Sat, Mar 17, 2012 at 1:03 PM, Julia Lawall wrote:
> From: Julia Lawall
>
> The function radeon_cs_parser_init is only called from two places, in
> drivers/gpu/drm/radeon/radeon_cs.c and drivers/gpu/drm/radeon/r600_cs.c.
> In each case, if the call fails another function is called that frees al
On Sun, 18 Mar 2012, Rafael J. Wysocki wrote:
> On Sunday, March 18, 2012, Hugh Dickins wrote:
> > On Sat, 17 Mar 2012, Keith Packard wrote:
> > > On Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins > > google.com> wrote:
> > > > I keep worrying about the sequence when the machine is powered on
On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter
wrote:
> Otherwise subsystems will get this wrong and end up with and second
> export ioctl with the flag and O_CLOEXEC support added.
Its not actually dma_buf_export that takes the O_CLOEXEC flag its dma_buf_fd
I'm not sure how blindly we should
On Sat, 17 Mar 2012, Linus Torvalds wrote:
> On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins wrote:
> >
> > I've got to go out for an hour: I'll digest more and think more about
> > this when I get back. ?If someone could explain the original problem
> > with _MOVABLE, that would help me:
>
> I do
https://bugzilla.kernel.org/show_bug.cgi?id=29842
--- Comment #15 from Igor Rudchenko 2012-03-19 10:50:43
---
Tested 3.3.0 kernel today and nothing changes. So I look deeper into ASPM
registers:
Windows XP and Linux kernel prior 2.6.38:
root complex
00:01.0 0xB0 == 0x03 (L1 and L0
Hi folks,
Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
on my card w/ nouveau is totally black (both at the console and in X).
Almost everything appears to work normally: DPMS works, modesetting
works, DDC works... all messages indicate that things are working --
just th
On Mon, 2012-03-19 at 23:11 +0800, Scott Fang wrote:
> In function ttm_tt_set_caching
> ,,,
>
> if (ttm->caching_state == tt_cached)
> drm_clflush_pages(ttm->pages, ttm->num_pages);
>
> for (i = 0; i < ttm->num_pages; ++i) {
> cur_page = ttm->pages[i];
> if (li
<#part sign=pgpmime>
On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka
wrote:
> Keith, is there a chance that this bug can be fixed by i915 team?
Yes, I'm working on figuring out how to actually reproduce this and then
work on a few work-arounds.
> If not, can we disable hibernate on i915
<#part sign=pgpmime>
On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka
wrote:
> Keith, is there a chance that this bug can be fixed by i915 team?
Yes, I'm working on figuring out how to actually reproduce this and then
work on a few work-arounds.
> If not, can we disable hibernate on i915
On 03/19/2012 05:56 PM, Alan Cox wrote:
display controller will be reading the front buffer, but the GPU
> might also need to read that front buffer. So perhaps adding
> "read-only"& "read-write" access flags to prepare could also be
> interpreted as shared& exclusive accesses, if we went do
On Mon, Feb 27, 2012 at 01:42:43PM +0100, Stanislaw Gruszka wrote:
> I'm able to reproduce random memory corruption after hibernate.
> Corruption is not reproducible when I disable mode setting, what
> seems to blame i915 driver or generic DRM kernel code.
>
> I'm able to reproduce bug on Fedora 1
> If the API was to also be used for synchronization it would have to
> include an atomic "prepare multiple" ioctl which blocked until all
> the buffers listed by the application were available. In the same
Too slow already. You are now serializing stuff while what we want to do
really is
https://bugs.freedesktop.org/show_bug.cgi?id=42622
--- Comment #6 from kowalski marcin 2012-03-19 02:56:24
PDT ---
i'll try this on another set of hardware soon to make sure. i might have been a
bit hasty with that comment.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
https://bugs.freedesktop.org/show_bug.cgi?id=42622
--- Comment #5 from kowalski marcin 2012-03-19 02:54:21
PDT ---
the problem does not exist anymore on current mesa git and current stable
kernel.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiv
> -Original Message-
> From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk]
> Sent: 17 March 2012 20:17
> To: Tom Cooksey
> Cc: 'Rob Clark'; linaro-mm-...@lists.linaro.org; dri-
> de...@lists.freedesktop.org; linux-me...@vger.kernel.org;
> rschu...@google.com; Rob Clark; sumit.sem...@linaro.o
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #9 from Alex Deucher 2012-03-19 16:42:50
---
Created an attachment (id=72654)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72654)
possible fix
Does this patch fix the issue?
--
Configure bugmail: https://bugzilla.kernel
https://bugzilla.kernel.org/show_bug.cgi?id=29842
--- Comment #17 from Igor Rudchenko 2012-03-19 16:35:11 ---
To Matthew Garrett:
I agree about network cards, but current situation with video card worries me
much. Prior 3.0.20, 3.2.5 and 3.3 kernels, users of ThinkPads T60 can simply
add ke
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
--- Comment #8
On Sat, 2012-03-17 at 14:14 -0700, Linus Torvalds wrote:
> On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie wrote:
> >
> > I did however get a flashback in google to this:
> >
> > http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html
> >
> > Linus don't think we ever did work out
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #7 from Jonathan Nieder 2012-03-19
08:54:19 ---
The painful memories are coming back to me: udev also requires v2.6.28-rc6~45
("reintroduce accept4") and dup3 and friends from 2.6.27.
--
Configure bugmail: https://bugzilla.kern
On Sun, Mar 18, 2012 at 10:09 PM, Marek Ol??k wrote:
> Signed-off-by: Marek Ol??k
For the series:
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/evergreen_cs.c | ? ?8
> ?1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #6 from Jonathan Nieder 2012-03-19
08:44:40 ---
udev should cope fine with kernels < 2.6.32 iirc as long as
CONFIG_SYSFS_DEPRECATED is not set.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Y
On Mon, Mar 19, 2012 at 04:41:55PM +0100, Daniel Vetter wrote:
> Otherwise subsystems will get this wrong and end up with a second
> export ioctl with the flag and O_CLOEXEC support added.
>
> v2: Fixup the function name and caution exporters to limit the flags
> to only O_CLOEXEC. Noted by Dave A
Otherwise subsystems will get this wrong and end up with a second
export ioctl with the flag and O_CLOEXEC support added.
v2: Fixup the function name and caution exporters to limit the flags
to only O_CLOEXEC. Noted by Dave Airlie.
Cc: Dave Airlie
Signed-Off-by: Daniel Vetter
---
Documentation
typo error. abundant=>redundant
2012/3/19 Scott Fang
> In function ttm_tt_set_caching
> ,,,
>
> if (ttm->caching_state == tt_cached)
> drm_clflush_pages(ttm->pages, ttm->num_pages);
>
> for (i = 0; i < ttm->num_pages; ++i) {
> cur_page = ttm->pages[i];
> if (l
On Sat, Mar 17, 2012 at 1:03 PM, Julia Lawall wrote:
> From: Julia Lawall
>
> The function radeon_cs_parser_init is only called from two places, in
> drivers/gpu/drm/radeon/radeon_cs.c and drivers/gpu/drm/radeon/r600_cs.c.
> In each case, if the call fails another function is called that frees al
In function ttm_tt_set_caching
,,,
if (ttm->caching_state == tt_cached)
drm_clflush_pages(ttm->pages, ttm->num_pages);
for (i = 0; i < ttm->num_pages; ++i) {
cur_page = ttm->pages[i];
if (likely(cur_page != NULL)) {
ret = ttm_tt_set_page_caching(cur
Hi folks,
Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
on my card w/ nouveau is totally black (both at the console and in X).
Almost everything appears to work normally: DPMS works, modesetting
works, DDC works... all messages indicate that things are working --
just th
https://bugzilla.kernel.org/show_bug.cgi?id=29842
Matthew Garrett changed:
What|Removed |Added
CC||mjg59-ker...@srcf.ucam.org
--- Comm
On Sun, Mar 18, 2012 at 10:09 PM, Marek Olšák wrote:
> Signed-off-by: Marek Olšák
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
On Fri, Mar 16, 2012 at 9:47 AM, Inki Dae wrote:
> From: Joonyoung Shim
>
> The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
> This G2D driver is exynos drm specific and supports only G2D(version
> 4.1) of later Exynos series from Exynos4X12 because supporting DMA.
So just t
On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter wrote:
> Otherwise subsystems will get this wrong and end up with and second
> export ioctl with the flag and O_CLOEXEC support added.
Its not actually dma_buf_export that takes the O_CLOEXEC flag its dma_buf_fd
I'm not sure how blindly we should b
https://bugzilla.kernel.org/show_bug.cgi?id=29842
--- Comment #15 from Igor Rudchenko 2012-03-19 10:50:43 ---
Tested 3.3.0 kernel today and nothing changes. So I look deeper into ASPM
registers:
Windows XP and Linux kernel prior 2.6.38:
root complex
00:01.0 0xB0 == 0x03 (L1 and L0s
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/r600_cs.c | 270 +-
1 files changed, 150 insertions(+), 120 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index d9ebec3..0ec3f20 100644
--- a/drivers/gpu/drm
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/r600_cs.c | 89 +-
1 files changed, 68 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index b3c40e0..d9ebec3 100644
--- a/drivers/gpu/drm/r
and document the other unused ones.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c | 58 +++--
drivers/gpu/drm/radeon/reg_srcs/cayman| 12 ++
drivers/gpu/drm/radeon/reg_srcs/evergreen | 12 ++
3 files changed, 30 insertions(+),
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c | 91 -
1 files changed, 66 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 0427b96..7327bc7 100644
--- a/driver
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c | 37 ++--
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index b39a089..0427b96 100644
--- a/drivers
There are also two fixes:
- In DRAW_INDEX_2, we read idx_value, but should have read idx+1.
- When correcting SQ_VTX_CONSTANT_WORD1_0.SIZE, we should subtract
the offset.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c | 130 ++---
1 files chan
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 8bf576a..4674a68 100644
--- a/drivers/gpu/drm/radeon/evergreen_
https://bugs.freedesktop.org/show_bug.cgi?id=42622
--- Comment #6 from kowalski marcin 2012-03-19 02:56:24
PDT ---
i'll try this on another set of hardware soon to make sure. i might have been a
bit hasty with that comment.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
https://bugs.freedesktop.org/show_bug.cgi?id=42622
--- Comment #5 from kowalski marcin 2012-03-19 02:54:21
PDT ---
the problem does not exist anymore on current mesa git and current stable
kernel.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiv
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #7 from Jonathan Nieder 2012-03-19 08:54:19
---
The painful memories are coming back to me: udev also requires v2.6.28-rc6~45
("reintroduce accept4") and dup3 and friends from 2.6.27.
--
Configure bugmail: https://bugzilla.kern
https://bugzilla.kernel.org/show_bug.cgi?id=29412
--- Comment #6 from Jonathan Nieder 2012-03-19 08:44:40
---
udev should cope fine with kernels < 2.6.32 iirc as long as
CONFIG_SYSFS_DEPRECATED is not set.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Y
https://bugs.freedesktop.org/show_bug.cgi?id=38471
Thomas Kowaliczek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Otherwise subsystems will get this wrong and end up with and second
export ioctl with the flag and O_CLOEXEC support added.
Signed-Off-by: Daniel Vetter
---
Documentation/dma-buf-sharing.txt |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/dma-buf-sharin
v2: Fix spelling issues noticed by Rob Clark.
Signed-off-by: Daniel Vetter
---
Documentation/dma-buf-sharing.txt | 102 +++-
1 files changed, 99 insertions(+), 3 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
ind
Big differences to other contenders in the field (like ion) is
that this also supports highmem, so we have to split up the cpu
access from the kernel side into a prepare and a kmap step.
Prepare is allowed to fail and should do everything required so that
the kmap calls can succeed (like swapin/ba
The mutex protects the attachment list and hence needs to be held
around the callbakc to the exporters (optional) attach/detach
functions.
Holding the mutex around the map/unmap calls doesn't protect any
dma_buf state. Exporters need to properly protect any of their own
state anyway (to protect ag
https://bugs.freedesktop.org/show_bug.cgi?id=46323
Ben Gouhier changed:
What|Removed |Added
Resolution|FIXED |WORKSFORME
--
Configure bugmail: https://
74 matches
Mail list logo
