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
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,
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
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
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 the
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
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
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>;
>> +
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
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
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
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
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.
Regards
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=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 bec
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 al
https://bugs.freedesktop.org/show_bug.cgi?id=49110
Mike Mestnik changed:
What|Removed |Added
See Also||http://llvm.org/bugs/show_b
https://bugs.freedesktop.org/show_bug.cgi?id=49484
Michal Suchanek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
ata.
>
> So it appears that the full data is being read by both systems, but the
> behavior of xrandr (or presumably whatever API xrandr uses to get the
> EDID data that it displays) differs between the two drivers. Fun.
Well thankfully that's just the X nouveau driver being broken, and
shouldn't affect actual output setup. I could have sworn I'd fixed
nouveau for this before. I'll send the fix along, thanks for catching
it.
- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120507/67406281/attachment.pgp>
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
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:
>>
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
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.
>>
>> Te
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=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" bei
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
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=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
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
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
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
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
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
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:
>>
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
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 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 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 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
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
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
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
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
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
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|
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
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
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
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
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
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
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
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
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
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
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
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: 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
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 ++--
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
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
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
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
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=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 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
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 */
>
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
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 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 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 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 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
https://bugs.freedesktop.org/show_bug.cgi?id=49484
Michal Suchanek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> 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=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
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 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
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
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 ham
On 05/07/2012 02:50 AM, Terje Bergstr?m wrote:
> On 25.04.2012 12:45, Thierry Reding wrote:
>
>> +/ {
>> + ...
>> +
>> + /* host1x */
>> + host1x: host1x at 5000 {
>> + compatible = "nvidia,tegra20-host1x";
>> + reg = <0x5000 0x00024000>;
>> +
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
> +
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=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 #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
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
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
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 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 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.
>
>
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 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
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 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
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
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
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
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
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
1 - 100 of 133 matches
Mail list logo
