On 11/12/2010 06:36 PM, Daniel Vetter wrote:
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be do
Hi, Daniel,
My main concerns previously for embedding GEM objects as user-space
references for TTM has been twofold and implementation specific.
1) The locking has been using global mutexes where local spin- or RCU
locks have been more appropriate. It looks like this has finally been /
is fi
enable_vblank implementations should use negative result to indicate error.
radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL.
Signed-off-by: Vasiliy Kulikov
---
Compile tested.
drivers/gpu/drm/radeon/radeon_irq.c |4 ++--
1 files changed, 2 insertions(+), 2 delet
enable_vblank implementations should use negative result to indicate error.
radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL.
Signed-off-by: Vasiliy Kulikov
---
Compile tested.
drivers/gpu/drm/radeon/radeon_irq.c |4 ++--
1 files changed, 2 insertions(+), 2 delet
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up
>>
>> Could be a "big.diff" is needed,
Tiled buffers have the same alignment requirements regardless of
whether the surface is for db, cb, or textures. Previously, the
calculations where inconsistent for each buffer type.
- Unify the alignment calculations in a common function
- Standardize the alignment units (pixels for pitch/height
On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up
>
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 008
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/l
Found myself :-)
$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat D
On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.
Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:
commit d935cc61d46
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek
wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just
On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.
Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
Tiled buffers have the same alignment requirements regardless of
whether the surface is for db, cb, or textures. Previously, the
calculations where inconsistent for each buffer type.
- Unify the alignment calculations in a common function
- Standardize the alignment units (pixels for pitch/height
On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.
I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson
wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek googlemail.com> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #11 from Maximiliano Castañón 2010-11-14
15:23:12 PST ---
Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=31475
I believe it's another project related to that problem, probably xrandr with
the resize screen...
--
Conf
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #11 from Maximiliano Casta??n 2010-11-14
15:23:12 PST ---
Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=31475
I believe it's another project related to that problem, probably xrandr with
the resize screen...
--
Conf
[ Please CC me I am not subscribed to dri-devel ML ]
[ QUOTE ]
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocati
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
>
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up
>>
>> Could be a "big.diff" is needed,
On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up
>
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 008
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/l
Found myself :-)
$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat D
On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.
Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:
commit d935cc61d46
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #2 from Alex Deucher 2010-11-14 09:19:58 PST ---
This is due to the pm code holding a number of locks while waiting to update
the clocks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #2 from Alex Deucher 2010-11-14 09:19:58 PST
---
This is due to the pm code holding a number of locks while waiting to update
the clocks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.
Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #1 from Ernst Sjöstrand 2010-11-14 09:07:37 PST
---
It also happens with the drm-next kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2010-11-10-maverick/
It does not happen with Ubuntu Mavericks default 2.6.35 ker
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #1 from Ernst Sj?strand 2010-11-14 09:07:37
PST ---
It also happens with the drm-next kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2010-11-10-maverick/
It does not happen with Ubuntu Mavericks default 2.6.35 ker
On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.
I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my direct-gtt pat
https://bugs.freedesktop.org/show_bug.cgi?id=31619
Summary: Desktop freezes quickly every now and then with dynpm
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=31619
Summary: Desktop freezes quickly every now and then with dynpm
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
>
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
[ Please CC me I am not subscribed to dri-devel ML ]
[ QUOTE ]
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocati
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Summary: Radeon/Compiz: 'failed to attach dri2 front buffer',
error case not handled
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Sta
https://bugs.freedesktop.org/show_bug.cgi?id=31617
Summary: Radeon/Compiz: 'failed to attach dri2 front buffer',
error case not handled
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Sta
https://bugs.freedesktop.org/show_bug.cgi?id=31613
Daniel changed:
What|Removed |Added
CC||di...@betriebsdirektor.de
--- Comment #1 from D
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Daniel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Daniel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31613
Daniel changed:
What|Removed |Added
CC||direx at betriebsdirektor.de
--- Comment #1 fro
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Summary: Some textures broken on r600g
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Co
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Summary: Some textures broken on r600g
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Co
50 matches
Mail list logo
