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
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
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
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
>
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
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
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
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
>
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
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
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...
--
[ 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
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).
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
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
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:
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)
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=31615
Daniel di...@betriebsdirektor.de changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=31613
Daniel di...@betriebsdirektor.de changed:
What|Removed |Added
CC|
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)
[ 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
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek sedat.di...@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 direct-gtt patches (which are actually the reason for
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:
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek sedat.di...@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
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 5:13 PM, Daniel Vetter dan...@ffwll.ch 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
https://bugs.freedesktop.org/show_bug.cgi?id=31619
--- Comment #1 from Ernst Sjöstrand ern...@gmail.com 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
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 #2 from Alex Deucher ag...@yahoo.com 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
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter dan...@ffwll.ch 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,
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek sedat.di...@googlemail.com wrote:
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter dan...@ffwll.ch 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
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
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 dan...@ffwll.ch wrote:
On Sun, Nov 14, 2010 at 06:52:35PM
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter dan...@ffwll.ch 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
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 0081..0089
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter dan...@ffwll.ch 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
https://bugs.freedesktop.org/show_bug.cgi?id=31482
--- Comment #11 from Maximiliano Castañón maxim...@gmail.com 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
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
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
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
47 matches
Mail list logo
