On Son, 2012-05-06 at 18:29 +0200, Rafał Miłecki wrote:
> 2012/5/6 Dave Airlie :
> > On Sun, May 6, 2012 at 5:19 PM, Rafał Miłecki wrote:
> >> 2012/5/6 Rafał Miłecki :
> >>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> >>> b/drivers/gpu/drm/radeon/r600_hdmi.c
> >>> index c308432..b14c90a 10
Hi Dave,
2 little patches:
- One regression fix to disable sdvo hotplug on broken hw.
- One patch to upconvert the snb hang workaround from patch v1 to patch
v2.
Yours, Daniel
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -07
On 25.04.2012 12:45, Thierry Reding wrote:
> +/ {
> + ...
> +
> + /* host1x */
> + host1x: host1x@5000 {
> + compatible = "nvidia,tegra20-host1x";
> + reg = <0x5000 0x00024000>;
> + interrupts = <0 64 0x04 /* cop syncpt */
> +
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #55 from Michel Dänzer 2012-05-07 03:07:07 PDT
---
(In reply to comment #54)
> On latest git (3cd7bee48f7caf7850ea64d40f43875d4c975507), in
> src/gallium/drivers/r600/r66_hw_context.c, on line 194, shouldn't it be:
> - int offset
> +
Two fixes from Intel, one a regression, one because I merged an early
version of a fix.
Also the nouveau revert of the i2c code that was tested on the list.
Dave.
The following changes since commit febb72a6e4cc6c8cffcc1ea649a3fb364f1ea432:
IA32 emulation: Fix build problem for modular ia32
Hi Jerome & everybody on the list,
this gathers together every patch we developed over the last week or so and
which is not already in drm-next.
I've run quite some tests with them yesterday and today and as far as I can
see hammered out every known bug. For the SA allocator I reverted to trackin
From: Jerome Glisse
We need to sync with the GFX ring as ttm might have schedule bo move
on it and new command scheduled for other ring need to wait for bo
data to be in place.
Signed-off-by: Jerome Glisse
Reviewed by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c | 12 ++--
A single global mutex for ring submissions seems sufficient.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_device.c|3 +-
drivers/gpu/drm/radeon/radeon_pm.c| 10 +-
drivers/gpu/drm/radeon/radeon_ring.c
From: Jerome Glisse
This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.
Tested with and without writeback using 0xF000 as initial
fence sequence and thus allowing to test the wrap around from
From: Jerome Glisse
Using 64bits fence sequence we can directly compare sequence
number to know if a fence is signaled or not. Thus the fence
list became useless, so does the fence lock that mainly
protected the fence list.
Things like ring.ready are no longer behind a lock, this should
be ok as
Some callers illegal called fence_wait_next/empty
while holding the ring emission mutex. So don't
relock the mutex in that cases, and move the actual
locking into the fence code.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|4 +-
drivers/gpu/drm/radeon/radeon_de
Instead of hacking the calculation multiple times.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gart.c |6 ++
drivers/gpu/drm/radeon/radeon_object.h| 11 +++
drivers/gpu/drm/radeon/radeon_ring.c |6 ++
drivers/gpu/drm/radeon/radeon_sema
From: Alex Deucher
Use family rather than DCE check for clarity, also always use
wb on APUs, there will never be AGP variants.
Signed-off-by: Alex Deucher
Reviewed by: Christian König
---
drivers/gpu/drm/radeon/radeon_device.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
dif
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
v3: remove some unreleated changes.
Sig-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c |6 ++
2 files changed, 7 insertions(+), 0 de
Dumping the current allocations.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_sa.c | 14 ++
3 files changed, 41 insertions(+), 0 deleti
Instead of offset + size keep start and end offset directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|4 ++--
drivers/gpu/drm/radeon/radeon_cs.c |4 ++--
drivers/gpu/drm/radeon/radeon_object.h |4 ++--
drivers/gpu/drm/radeon/radeon_sa.c | 1
Allocating and freeing it seperately.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 ++--
drivers/gpu/drm/radeon/radeon_cs.c|4 ++--
drivers/gpu/drm/radeon/radeon_gart.c |4 ++--
drivers/gpu/drm/radeon/radeon_object.h|4 ++--
dri
Define the interface without modifying the allocation
algorithm in any way.
v2: rebase on top of fence new uint64 patch
v3: add ring to debugfs output
Signed-off-by: Jerome Glisse
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/rade
From: Jerome Glisse
Use one wait queue for all rings. When one ring progress, other
likely does to and we are not expecting to have a lot of waiter
anyway.
Also add a fence_wait_any that will wait until the first fence
in the fence array (one fence per ring) is signaled. This allow
to wait on al
From: Jerome Glisse
Directly use the suballocator to get small chunks of memory.
It's equally fast and doesn't crash when we encounter a GPU reset.
v2: rebased on new SA interface.
Signed-off-by: Christian König
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c|
We can now protected the semaphore ram by a
fence, so free it immediately.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_tt
A startover with a new idea for a multiple ring allocator.
Should perform as well as a normal ring allocator as long
as only one ring does somthing, but falls back to a more
complex algorithm if more complex things start to happen.
We store the last allocated bo in last, we always try to allocate
From: Jerome Glisse
It isn't necessary any more and the suballocator seems to perform
even better.
Signed-off-by: Christian König
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 17 +--
drivers/gpu/drm/radeon/radeon_device.c|1 -
drivers/gpu/drm/radeon/r
From: Jerome Glisse
It never really belonged there in the first place.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 16
drivers/gpu/drm/radeon/radeon_cs.c|4 ++--
drivers/gpu/drm/radeon/radeon_fence.c |3 ---
drivers/gpu/drm/radeon/r
If we don't store local data into global variables
it isn't necessary to lock anything.
v2: rebased on new SA interface
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |1 -
drivers/gpu/drm/radeon/r600.c | 13 +---
drivers/gpu/drm/radeon/r600_b
From: Jerome Glisse
No need to malloc it any more.
Signed-off-by: Jerome Glisse
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen_cs.c | 10 +++---
drivers/gpu/drm/radeon/r100.c | 38 ++--
drivers/gpu/drm/radeon/r200.c |2 +-
drivers/g
Hi Dave,
As discussed on irc&mail, here's the pull request for the manual merge to
unconfuse git about the changes in intel_display.c. Note that I've
manually frobbed the shortlog to exclude all the changes merge through
Linus' tree.
Yours, Daniel
The following changes since commit 5bc69bf9aeb73
Hi Tomasz,
Sorry for the late reply, this one slipped through the cracks.
On Thursday 19 April 2012 12:42:12 Tomasz Stanislawski wrote:
> On 04/17/2012 04:08 PM, Laurent Pinchart wrote:
> > On Tuesday 10 April 2012 15:10:39 Tomasz Stanislawski wrote:
> >> This patch adds support for exporting a d
https://bugs.freedesktop.org/show_bug.cgi?id=49567
--- Comment #2 from Tom Stellard 2012-05-07 07:18:45 PDT
---
If you re-run autogen.sh and configure does that fix the problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail becau
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
> Hi Jerome & everybody on the list,
>
> this gathers together every patch we developed over the last week or so and
> which is not already in drm-next.
>
> I've run quite some tests with them yesterday and today and as far as I can
> see hamm
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
> From: Jerome Glisse
>
> This convert fence to use uint64_t sequence number intention is
> to use the fact that uin64_t is big enough that we don't need to
> care about wrap around.
>
> Tested with and without writeback using 0xF000 as i
On 07.05.2012 16:39, Jerome Glisse wrote:
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
From: Jerome Glisse
This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.
Tested with and without
Hi Subash,
Could you provide a detailed description of a test case
that causes a failure of vb2_dc_pages_to_sgt?
Regards,
Tomasz Stanislawski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-dev
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
> A startover with a new idea for a multiple ring allocator.
> Should perform as well as a normal ring allocator as long
> as only one ring does somthing, but falls back to a more
> complex algorithm if more complex things start to happen.
>
>
On Mon, May 7, 2012 at 11:04 AM, Christian König
wrote:
> On 07.05.2012 16:39, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 7:42 AM, Christian König
>> wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> This convert fence to use uint64_t sequence number intention is
>>> to use the fact that uin64_t
On Mon, May 7, 2012 at 10:34 AM, Jerome Glisse wrote:
> On Mon, May 7, 2012 at 7:42 AM, Christian König
> wrote:
>> Hi Jerome & everybody on the list,
>>
>> this gathers together every patch we developed over the last week or so and
>> which is not already in drm-next.
>>
>> I've run quite some
On 07.05.2012 17:23, Jerome Glisse wrote:
On Mon, May 7, 2012 at 7:42 AM, Christian König wrote:
A startover with a new idea for a multiple ring allocator.
Should perform as well as a normal ring allocator as long
as only one ring does somthing, but falls back to a more
complex algorithm if mor
https://bugs.freedesktop.org/show_bug.cgi?id=49484
--- Comment #3 from Michal Suchanek 2012-05-07 09:55:15
PDT ---
I get no mesa warnings, only warnings from wine about Mesa returning
GL_INVALID*
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=49567
--- Comment #3 from Mike Mestnik
2012-05-07 09:58:45 PDT ---
Tom,
The short of it: I'm already doing that.
The long:
I took a look at that script and it eventually just calls "autoreconf -v
--install" my log clearly shows "autoreconf -vfi" be
https://bugs.freedesktop.org/show_bug.cgi?id=49484
--- Comment #4 from Michal Suchanek 2012-05-07 10:02:05
PDT ---
invalid value:
Breakpoint 1, _mesa_error (ctx=0xccba90, error=1281, fmtString=0x74706278
"glTexImage%dD(internalFormat=%s)") at main/errors.c:996
996main/errors.c: No such
https://bugs.freedesktop.org/show_bug.cgi?id=49484
--- Comment #5 from Henri Verbeet 2012-05-07 10:37:29 PDT
---
That generally happens when an application tries to use a (D3D) format (e.g.
DXT/s3tc) even though it's not available. A WINEDEBUG=+d3d,+d3d_surface log
should show which format, alth
https://bugs.freedesktop.org/show_bug.cgi?id=49567
--- Comment #4 from Tom Stellard 2012-05-07 10:43:27 PDT
---
Created attachment 61159
--> https://bugs.freedesktop.org/attachment.cgi?id=61159
Possible fix
Does it build with this patch?
--
Configure bugmail: https://bugs.freedesktop.org/us
> On 07.05.2012 17:23, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 7:42 AM, Christian König
>> wrote:
>>>
>>> A startover with a new idea for a multiple ring allocator.
>>> Should perform as well as a normal ring allocator as long
>>> as only one ring does somthing, but falls back to a more
https://bugs.freedesktop.org/show_bug.cgi?id=49484
Michal Suchanek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, May 7, 2012 at 3:38 AM, Michel Dänzer wrote:
> On Son, 2012-05-06 at 18:29 +0200, Rafał Miłecki wrote:
>> 2012/5/6 Dave Airlie :
>> > On Sun, May 6, 2012 at 5:19 PM, Rafał Miłecki wrote:
>> >> 2012/5/6 Rafał Miłecki :
>> >>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
>> >>> b/driver
On Sat, May 5, 2012 at 6:22 AM, Dave Airlie wrote:
> On Sat, May 5, 2012 at 11:19 AM, wrote:
>> Hi Dave,
>>
>> 2012. 4. 25. 오후 7:15 Dave Airlie 작성:
>>
>>> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote:
this feature could be used to use memory region allocated by malloc() in
user
>
On Mon, May 7, 2012 at 1:59 PM, Jerome Glisse wrote:
>> On 07.05.2012 17:23, Jerome Glisse wrote:
>>>
>>> On Mon, May 7, 2012 at 7:42 AM, Christian König
>>> wrote:
A startover with a new idea for a multiple ring allocator.
Should perform as well as a normal ring allocator as long
https://bugs.freedesktop.org/show_bug.cgi?id=49567
--- Comment #5 from Mike Mestnik
2012-05-07 11:59:39 PDT ---
This patch worked for me and got me to the next undefined reference.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail be
On 05/03/2012 02:42 PM, Adam Jackson wrote:
> This looks good, thank you for taking it on.
It was either that or give up on my big display, so ... you're welcome.
> I'd like to see documentation for the bit values of the quirks as well.
> And, ideally, this would also have some runtime API for ma
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #28 from Jerome Glisse 2012-05-07 12:57:34
PDT ---
Does people here have better luck with the patch mentioned previously:
drm/radeon/kms: need to set up ss on DP bridges as well
--
Configure bugmail: https://bugs.freedesktop.org/u
https://bugs.freedesktop.org/show_bug.cgi?id=49603
Bug #: 49603
Summary: [regression] Fullscreen video no longer smooth with
GPU in low power mode
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: Other
On 07.05.2012 20:52, Jerome Glisse wrote:
On Mon, May 7, 2012 at 1:59 PM, Jerome Glisse wrote:
On 07.05.2012 17:23, Jerome Glisse wrote:
On Mon, May 7, 2012 at 7:42 AM, Christian König
wrote:
A startover with a new idea for a multiple ring allocator.
Should perform as well as a normal ring
On Mon, May 7, 2012 at 4:38 PM, Christian König wrote:
> On 07.05.2012 20:52, Jerome Glisse wrote:
>>
>> On Mon, May 7, 2012 at 1:59 PM, Jerome Glisse wrote:
On 07.05.2012 17:23, Jerome Glisse wrote:
>
> On Mon, May 7, 2012 at 7:42 AM, Christian
> König
> wrote:
>>
On Mon, 2012-05-07 at 14:50 -0500, Ian Pilcher wrote:
> On 05/03/2012 02:42 PM, Adam Jackson wrote:
> > I'd like to see documentation for the bit values of the quirks as well.
> > And, ideally, this would also have some runtime API for manipulating the
> > quirk list, so that way you can test new q
https://bugs.freedesktop.org/show_bug.cgi?id=49110
--- Comment #5 from Mike Mestnik
2012-05-07 16:50:36 PDT ---
Commit c425c3823fbd475dc83211fef47f7ea58421ed17 should have fixed this, but it
don't. I've looked at the llvm headers and it looks like a number of
preprocessor macros will include th
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
See Also||http://llvm.org/bugs/show_b
series applied to ACPI next branch
thanks,
Len Brown, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hello Thomasz, Laurent,
I found an issue in the function vb2_dc_pages_to_sgt() below. I saw that
during the attach, the size of the SGT and size requested mis-matched
(by atleast 8k bytes). Hence I made a small correction to the code as
below. I could then attach the importer properly.
Regar
On 05/07/2012 02:50 AM, Terje Bergström wrote:
> On 25.04.2012 12:45, Thierry Reding wrote:
>
>> +/ {
>> + ...
>> +
>> + /* host1x */
>> + host1x: host1x@5000 {
>> + compatible = "nvidia,tegra20-host1x";
>> + reg = <0x5000 0x00024000>;
>> +
While investing some Sandy Bridge rendering corruption, I found out
that all physical memory pages below 1MiB were returning garbage when
read through the GTT. This has been causing graphics corruption (when
it's used for textures, render targets and pixmaps) and GPU hangups
(when it's used for GPU
Stéphane Marchesin writes:
> While investing some Sandy Bridge rendering corruption, I found out
> that all physical memory pages below 1MiB were returning garbage when
> read through the GTT. This has been causing graphics corruption (when
> it's used for textures, render targets and pixmaps) an
Hi Thomasz,
I have extended the MFC-FIMC testcase posted by Kamil sometime ago to
sanity test the UMM patches. This test is multi-threaded(further
explanation for developers who may not have seen it yet), where thread
one parses the encoded stream and feeds into the codec IP driver(aka
MFC d
Hi Dave,
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Saturday, May 05, 2012 7:23 PM
> To: daei...@gmail.com
> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH v2 3/4] drm/exynos: added
On Tue, May 8, 2012 at 12:13 AM, Stéphane Marchesin
wrote:
> While investing some Sandy Bridge rendering corruption, I found out
> that all physical memory pages below 1MiB were returning garbage when
> read through the GTT. This has been causing graphics corruption (when
> it's used for textures,
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #29 from diego.abele...@gmail.com 2012-05-07 23:54:17 PDT ---
Well considering the commit pointed is exactly the patch proposed in comment 14
( https://bugs.freedesktop.org/attachment.cgi?id=60707 ) it is pretty clear
that it doesn't d
https://bugs.freedesktop.org/show_bug.cgi?id=49567
Bug #: 49567
Summary: No rule to make target libradeon.a, needed by
libr600.a.
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
Blocks||49567
--
Configure bugmail: https://bugs
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
Summary|AMDILCFGStructurizer.cpp:17 |debug build:
|51:3: err
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
Priority|medium |low
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=49567
Mike Mestnik changed:
What|Removed |Added
Depends on|49110 |
--
Configure bugmail: https://bugs.free
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
Blocks|49567 |
--
Configure bugmail: https://bugs.free
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=49110
--- Comment #4 from Mike Mestnik 2012-05-06 20:44:15 PDT ---
This bug cloned to: https://bugs.freedesktop.org/show_bug.cgi?id=49567
No rule to make target libradeon.a, needed by libr600.a.
--
Configure bugmail: https://bugs.freedesktop.org/use
https://bugs.freedesktop.org/show_bug.cgi?id=49567
--- Comment #1 from Mike Mestnik 2012-05-06 20:47:52 PDT ---
I got this same error with llvm1.3-rc1 and rc2.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
On Son, 2012-05-06 at 18:29 +0200, Rafa? Mi?ecki wrote:
> 2012/5/6 Dave Airlie :
> > On Sun, May 6, 2012 at 5:19 PM, Rafa? Mi?ecki wrote:
> >> 2012/5/6 Rafa? Mi?ecki :
> >>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> >>> b/drivers/gpu/drm/radeon/r600_hdmi.c
> >>> index c308432..b14c90a 10
Hi Dave,
2 little patches:
- One regression fix to disable sdvo hotplug on broken hw.
- One patch to upconvert the snb hang workaround from patch v1 to patch
v2.
Yours, Daniel
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -07
On 25.04.2012 12:45, Thierry Reding wrote:
> +/ {
> + ...
> +
> + /* host1x */
> + host1x: host1x at 5000 {
> + compatible = "nvidia,tegra20-host1x";
> + reg = <0x5000 0x00024000>;
> + interrupts = <0 64 0x04 /* cop syncpt */
>
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #55 from Michel D?nzer 2012-05-07 03:07:07
PDT ---
(In reply to comment #54)
> On latest git (3cd7bee48f7caf7850ea64d40f43875d4c975507), in
> src/gallium/drivers/r600/r66_hw_context.c, on line 194, shouldn't it be:
> - int offset
> +
Two fixes from Intel, one a regression, one because I merged an early
version of a fix.
Also the nouveau revert of the i2c code that was tested on the list.
Dave.
The following changes since commit febb72a6e4cc6c8cffcc1ea649a3fb364f1ea432:
IA32 emulation: Fix build problem for modular ia32
Hi Jerome & everybody on the list,
this gathers together every patch we developed over the last week or so and
which is not already in drm-next.
I've run quite some tests with them yesterday and today and as far as I can
see hammered out every known bug. For the SA allocator I reverted to trackin
From: Jerome Glisse
We need to sync with the GFX ring as ttm might have schedule bo move
on it and new command scheduled for other ring need to wait for bo
data to be in place.
Signed-off-by: Jerome Glisse
Reviewed by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 12 ++--
A single global mutex for ring submissions seems sufficient.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_device.c|3 +-
drivers/gpu/drm/radeon/radeon_pm.c| 10 +-
drivers/gpu/drm/radeon/radeon_ring.c
From: Jerome Glisse
This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.
Tested with and without writeback using 0xF000 as initial
fence sequence and thus allowing to test the wrap around from
From: Jerome Glisse
Using 64bits fence sequence we can directly compare sequence
number to know if a fence is signaled or not. Thus the fence
list became useless, so does the fence lock that mainly
protected the fence list.
Things like ring.ready are no longer behind a lock, this should
be ok as
Some callers illegal called fence_wait_next/empty
while holding the ring emission mutex. So don't
relock the mutex in that cases, and move the actual
locking into the fence code.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|4 +-
drivers/gpu/drm/radeon/radeon_de
Instead of hacking the calculation multiple times.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c |6 ++
drivers/gpu/drm/radeon/radeon_object.h| 11 +++
drivers/gpu/drm/radeon/radeon_ring.c |6 ++
drivers/gpu/drm/radeon/radeon_sema
From: Alex Deucher
Use family rather than DCE check for clarity, also always use
wb on APUs, there will never be AGP variants.
Signed-off-by: Alex Deucher
Reviewed by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
dif
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
v3: remove some unreleated changes.
Sig-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c |6 ++
2 files changed, 7 insertions(+), 0 de
Dumping the current allocations.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_sa.c | 14 ++
3 files changed, 41 insertions(+), 0 deleti
Instead of offset + size keep start and end offset directly.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|4 ++--
drivers/gpu/drm/radeon/radeon_cs.c |4 ++--
drivers/gpu/drm/radeon/radeon_object.h |4 ++--
drivers/gpu/drm/radeon/radeon_sa.c | 1
Allocating and freeing it seperately.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 ++--
drivers/gpu/drm/radeon/radeon_cs.c|4 ++--
drivers/gpu/drm/radeon/radeon_gart.c |4 ++--
drivers/gpu/drm/radeon/radeon_object.h|4 ++--
dri
Define the interface without modifying the allocation
algorithm in any way.
v2: rebase on top of fence new uint64 patch
v3: add ring to debugfs output
Signed-off-by: Jerome Glisse
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/rade
From: Jerome Glisse
Use one wait queue for all rings. When one ring progress, other
likely does to and we are not expecting to have a lot of waiter
anyway.
Also add a fence_wait_any that will wait until the first fence
in the fence array (one fence per ring) is signaled. This allow
to wait on al
From: Jerome Glisse
Directly use the suballocator to get small chunks of memory.
It's equally fast and doesn't crash when we encounter a GPU reset.
v2: rebased on new SA interface.
Signed-off-by: Christian K?nig
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c|
We can now protected the semaphore ram by a
fence, so free it immediately.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_ttm.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_tt
A startover with a new idea for a multiple ring allocator.
Should perform as well as a normal ring allocator as long
as only one ring does somthing, but falls back to a more
complex algorithm if more complex things start to happen.
We store the last allocated bo in last, we always try to allocate
From: Jerome Glisse
It isn't necessary any more and the suballocator seems to perform
even better.
Signed-off-by: Christian K?nig
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 17 +--
drivers/gpu/drm/radeon/radeon_device.c|1 -
drivers/gpu/drm/radeon/r
From: Jerome Glisse
It never really belonged there in the first place.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 16
drivers/gpu/drm/radeon/radeon_cs.c|4 ++--
drivers/gpu/drm/radeon/radeon_fence.c |3 ---
drivers/gpu/drm/radeon/r
If we don't store local data into global variables
it isn't necessary to lock anything.
v2: rebased on new SA interface
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |1 -
drivers/gpu/drm/radeon/r600.c | 13 +---
drivers/gpu/drm/radeon/r600_b
From: Jerome Glisse
No need to malloc it any more.
Signed-off-by: Jerome Glisse
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen_cs.c | 10 +++---
drivers/gpu/drm/radeon/r100.c | 38 ++--
drivers/gpu/drm/radeon/r200.c |2 +-
drivers/g
1 - 100 of 133 matches
Mail list logo
