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://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://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://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://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
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
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 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=29842
Matthew Garrett changed:
What|Removed |Added
CC||mjg59-ker...@srcf.ucam.org
--- Comm
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
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
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
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
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
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
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
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
--- Comment #8
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
--- 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
> -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
> 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
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
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
<#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 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
> -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
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
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
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
>
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 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
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=46323
Ben Gouhier changed:
What|Removed |Added
Resolution|FIXED |WORKSFORME
--
Configure bugmail: https://
https://bugs.freedesktop.org/show_bug.cgi?id=38471
Thomas Kowaliczek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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_
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 | 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/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/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
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://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://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://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://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
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 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 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=29842
Matthew Garrett changed:
What|Removed |Added
CC||mjg59-kernel at srcf.ucam.org
--- C
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
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120319/5088abcd/attachment.htm>
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
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>
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
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
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
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
--- Comment
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
--- 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
> -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.
> 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
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
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
<#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 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
> -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.
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
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
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
74 matches
Mail list logo
