https://bugs.freedesktop.org/show_bug.cgi?id=41740
--- Comment #5 from Alexandre Demers 2011-11-02
22:23:54 PDT ---
Added Luca since he may have more info on the problem.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=41740
--- Comment #4 from Alexandre Demers 2011-11-02
22:21:25 PDT ---
Same problem over here. Many errors related to either missing
"STDMETHODCALLTYPE" in declarations or unneeded "STDMETHODCALLTYPE" in
associated files. Compiler doesn't like it beca
https://bugs.freedesktop.org/show_bug.cgi?id=42490
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at
lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=31943
--- Comment #18 from Kai-Uwe Behrmann 2011-11-02 14:27:16 PDT
---
Is this duplicate?
https://bugs.freedesktop.org/show_bug.cgi?id=32343
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=28426
--- Comment #9 from Francesco R 2011-11-02 12:39:09
PDT ---
sorry, I've switched to nvidia, cannot test
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
From: Jerome Glisse
Move the page allocation and freeing to driver callback and
provide ttm code helper function for those.
Most intrusive change, is the fact that we now only fully
populate an object this simplify some of code designed around
the page fault design.
Signed-off-by: Jerome Glisse
From: Jerome Glisse
ttm_backend will exist only and only with a ttm_tt, and ttm_tt
will be of interesting use only when bind to a backend. Thus to
avoid code & data duplication btw the two merge them.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 14 ++-
drivers/
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2dd45ca..58ea7dc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/
From: Jerome Glisse
Use the ttm_tt page ptr array for page allocation, move the list to
array unwinding into the page allocation functions.
V2 split the fix to use ttm put page as a separate fix
properly fill pages array when TTM_PAGE_FLAG_ZERO_ALLOC is not
set
Signed-off-by: Jerome Glisse
---
From: Jerome Glisse
On failure we need to make sure the page we free has wb cache
attribute. Do this pas call the proper ttm page helper function.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_tt.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/
From: Jerome Glisse
This field is not use by any of the driver just drop it.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_ttm.c |1 -
include/drm/ttm/ttm_bo_driver.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff
From: Jerome Glisse
Split btw highmem and lowmem page was rendered useless by the
pool code. Remove it. Note further cleanup would change the
ttm page allocation helper to actualy take an array instead
of relying on list this could drasticly reduce the number of
function call in the common case o
From: Jerome Glisse
This was never use in none of the driver, properly using userspace
page for bo would need more code (vma interaction mostly). Removing
this dead code in preparation of ttm_tt & backend merge.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/d
Hi,
So attached is last batch of patch, i split the ttm put page
fix and i fixed a bug in the pages alloc when clear flags
wasn't set. I tested them on a bunch of radeon and everythings
seems fine (several gl app, firefox, compositor ...). I will
do more testing on agp and nouveau tomorrow.
The l
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #7 from Mandeep Singh Baines 2011-11-02
19:15:33 PDT ---
I've tried 3.0.6, 3.1 and the drm-core-next branch from:
git://people.freedesktop.org/~airlied/linux
Is there a radeon linux kernel tree I could test? I'm also happy to test a
https://bugs.freedesktop.org/show_bug.cgi?id=35460
--- Comment #12 from Bruno 2011-11-02 11:24:34 PDT
---
(In reply to comment #10 with patch from comment #11)
> Created attachment 52920 [details] [review]
>
> Test-feedback highly appreciated.
Running now for two days with the patch, no negati
From: Alex Deucher
Bail if we hit the timeout limit.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ni.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 56afaff..722cfb3 100644
--- a/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=41592
Michel D?nzer changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #18 from Michel D?n
On 11/2/11 5:13 PM, Keith Packard wrote:
> On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
>
>> It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
>> following three values are supported. All other values are reserved."
>
> Yeah, if you look at the MAX_LINK_RATE field, we as
From: Jerome Glisse
Move the page allocation and freeing to driver callback and
provide ttm code helper function for those.
Most intrusive change, is the fact that we now only fully
populate an object this simplify some of code designed around
the page fault design.
Signed-off-by: Jerome Glisse
From: Jerome Glisse
ttm_backend will exist only and only with a ttm_tt, and ttm_tt
will be of interesting use only when bind to a backend. Thus to
avoid code & data duplication btw the two merge them.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 14 ++-
drivers/
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2dd45ca..58ea7dc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/
From: Jerome Glisse
Use the ttm_tt page ptr array for page allocation, move the list to
array unwinding into the page allocation functions.
V2 split the fix to use ttm put page as a separate fix
properly fill pages array when TTM_PAGE_FLAG_ZERO_ALLOC is not
set
Signed-off-by: Jerome Glisse
---
From: Jerome Glisse
On failure we need to make sure the page we free has wb cache
attribute. Do this pas call the proper ttm page helper function.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_tt.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/
From: Jerome Glisse
This field is not use by any of the driver just drop it.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_ttm.c |1 -
include/drm/ttm/ttm_bo_driver.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff
From: Jerome Glisse
Split btw highmem and lowmem page was rendered useless by the
pool code. Remove it. Note further cleanup would change the
ttm page allocation helper to actualy take an array instead
of relying on list this could drasticly reduce the number of
function call in the common case o
On 11/2/11 4:05 PM, Keith Packard wrote:
> On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
>
>> The VBT is going to be crap.
>
> The only question then is what to do with hardware that doesn't have the
> DPCD value -- that's "new" in revision 0x11, after all.
It is? The DP 1.1a text for
From: Jerome Glisse
This was never use in none of the driver, properly using userspace
page for bo would need more code (vma interaction mostly). Removing
this dead code in preparation of ttm_tt & backend merge.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/d
Hi,
So attached is last batch of patch, i split the ttm put page
fix and i fixed a bug in the pages alloc when clear flags
wasn't set. I tested them on a bunch of radeon and everythings
seems fine (several gl app, firefox, compositor ...). I will
do more testing on agp and nouveau tomorrow.
The l
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #13 from Mike Lothian 2011-11-02 09:02:00
PDT ---
Is there a way for switcheroo to detect a muxless laptop and automatically
switch it off (if it isn't already)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=e
On 11/2/11 1:31 PM, Keith Packard wrote:
> On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
>
>> Given the choice of trusting DPCD or the VBT, I'd definitely prefer
>> DPCD.
>
> Except that the DPCD is coded into the monitor while the VBT is done by
> the platform. And, it's the platform wh
On Wed, 2 Nov 2011 13:03:19 -0700
Jesse Barnes wrote:
> Planes are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
Accidentally left out the ->destroy hook in this one. The drm-overlays
branch at gi
ignature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/c77a8953/attachment-0001.pgp>
From: Alex Deucher
Bail if we hit the timeout limit.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ni.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 56afaff..722cfb3 100644
--- a/drivers/
On Wed, Nov 2, 2011 at 2:54 PM, Keith Packard wrote:
> On Tue, ?1 Nov 2011 23:20:26 -0700, Keith Packard
> wrote:
>
>> ? ? ? ? ? ? ? intel_dp = enc_to_intel_dp(encoder);
>> - ? ? ? ? ? ? if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
>> + ? ? ? ? ? ? if (intel_dp->base.type == INTEL_OUTP
https://bugs.freedesktop.org/show_bug.cgi?id=42490
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
From: Alex Deucher
Supposedly both NUTMEG and TRAVIS should use the same
panel mode, but switching the panel mode for TRAVIS
gets things working.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c |7 +--
1 fi
https://bugs.freedesktop.org/show_bug.cgi?id=31943
--- Comment #18 from Kai-Uwe Behrmann 2011-11-02 14:27:16 PDT ---
Is this duplicate?
https://bugs.freedesktop.org/show_bug.cgi?id=32343
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this ma
On 11/2/11 5:13 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
following three values are supported. All other values are reserved."
Yeah, if you look at the MAX_LINK_RATE field, we assume tha
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
> It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
> following three values are supported. All other values are reserved."
Yeah, if you look at the MAX_LINK_RATE field, we assume that it has a
useful value. I'll bet they w
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/77a12b47/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=42514
--- Comment #3 from Pavel Ondra?ka 2011-11-02
06:43:44 PDT ---
Forgot to mention, GPU is RV530.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=42514
--- Comment #2 from Pavel Ondra?ka 2011-11-02
06:42:30 PDT ---
Created attachment 53054
--> https://bugs.freedesktop.org/attachment.cgi?id=53054
RADEON_DEBUG=fp log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=42514
--- Comment #1 from Pavel Ondra?ka 2011-11-02
06:42:01 PDT ---
Created attachment 53053
--> https://bugs.freedesktop.org/attachment.cgi?id=53053
terminal output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=42514
Bug #: 42514
Summary: [r300g] EVE online: some shaders are failing
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
On 11/2/11 4:05 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.
It is? The DP 1.1a text for lane c
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #12 from Alex Deucher 2011-11-02 06:37:47 PDT
---
(In reply to comment #11)
>
> When no module is loaded is the card still drawing power?
It depends whether the bios turns it on by default or not. If it's off, you
are not drawing
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #11 from Mike Lothian 2011-11-02 06:29:06
PDT ---
I've removed the vgaswitcheroo and radeon options from my kernel and my boot
time has returned to normal, as I have a muxless laptop not having the card
available makes no difference
https://bugs.freedesktop.org/show_bug.cgi?id=38554
--- Comment #1 from Orion Poplawski 2011-11-02 13:14:53
UTC ---
I seem to be hitting exactly the same problem in Fedora 16 with
3.1.0-5.fc16.i686.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=38554
--- Comment #1 from Orion Poplawski 2011-11-02
13:14:53 UTC ---
I seem to be hitting exactly the same problem in Fedora 16 with
3.1.0-5.fc16.i686.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
On 11/2/11 12:20 PM, Jesse Barnes wrote:
> @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> continue;
>
> intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
> The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.
How about this:
commit 34ebe02cc78f20ae6b7865c5087c3b5ac7810185
Author: Keith
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers/gpu/drm/drm_drv.c |3
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
> > I don't know why it was done that way, but I wrote the TTM DMA code
> > to be optimized for that (and it has the code to reverse direction - b/c
> > the testcases I used initially had the a,b,c,d,e,f order when doing
> > get_pages
> > and put_pages) - but I can alter the code to do it in the f
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 123
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |
}
}
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/cb2a29b6/attachment.pgp>
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's conceivable that some metadata could be stored at the start
of a given buffer, and an offset[0] allows the client to skip past that.
Similarly
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 123
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers/gpu/drm/drm_drv.c |3
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's conceivable that some metadata could be stored at the start
of a given buffer, and an offset[0] allows the client to skip past that.
Similarly
On Wed, Nov 02, 2011 at 11:04:43AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 01, 2011 at 09:11:37PM -0400, Jerome Glisse wrote:
> > Hi,
> >
> > So attached is patch serie (sorry for that i am away of my normal mail
> > config) which ultimately merge ttm_backend & ttm_tt it allows to get
>
https://bugs.freedesktop.org/show_bug.cgi?id=28426
--- Comment #9 from Francesco R 2011-11-02 12:39:09 PDT
---
sorry, I've switched to nvidia, cannot test
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
On 11/2/11 1:31 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
Given the choice of trusting DPCD or the VBT, I'd definitely prefer
DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may ne
https://bugs.freedesktop.org/show_bug.cgi?id=40024
--- Comment #7 from Andrew Randrianasulu 2011-11-02
05:15:55 PDT ---
from #nouveau channel:
http://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&show_html=true&highlight_names=&date=2011-08-19
15:53 #nouveau: < Max
On Wed, Nov 2, 2011 at 2:54 PM, Keith Packard wrote:
> On Tue, 1 Nov 2011 23:20:26 -0700, Keith Packard wrote:
>
>> intel_dp = enc_to_intel_dp(encoder);
>> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
>> + if (intel_dp->base.type == INTEL_OUTPUT_
On Wed, Nov 2, 2011 at 10:27 AM, Jerome Glisse wrote:
> On Tue, Nov 01, 2011 at 05:27:26PM -0400, Alex Deucher wrote:
>> On Fri, Oct 28, 2011 at 5:52 PM, ? wrote:
>> > From: Jerome Glisse
>> >
>> > Polarity needs to be set accordingly to connector status (connected
>> > or disconnected). Set it u
On Tue, 1 Nov 2011 23:20:26 -0700, Keith Packard wrote:
> intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
> + if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT ||
> is_pch_edp(intel_dp)) {
>
7 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/a20227c9/attachment.pgp>
From: Alex Deucher
Supposedly both NUTMEG and TRAVIS should use the same
panel mode, but switching the panel mode for TRAVIS
gets things working.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c |7 +--
1 fi
From: Kyungmin Park
As Exynos DRM is merged at mainline. Also update the maintainer entry.
Signed-off-by: Kyungmin Park
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 5d6941f..1deeac9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2327,6 +2327,13 @@ S: Supported
F: drivers/gpu/drm/
https://bugs.freedesktop.org/show_bug.cgi?id=40024
--- Comment #6 from Andrew Randrianasulu 2011-11-02
04:31:12 PDT ---
for memtimings on radeon 7500 (changed via rovclock, while running proprietary
driver) see forum post here and down :
http://forums.gentoo.org/viewtopic-p-3687568.html#368756
On 11/2/11 2:20 AM, Keith Packard wrote:
> + if (intel_dp->link_configuration [1] &
> DP_LANE_COUNT_ENHANCED_FRAME_EN)
> + intel_dp->DP |= DP_ENHANCED_FRAMING;
> +
> + /*
> + * Check for DPCD version> 1.1 and enhanced framing support
> +
https://bugs.freedesktop.org/show_bug.cgi?id=35460
--- Comment #12 from Bruno 2011-11-02 11:24:34 PDT ---
(In reply to comment #10 with patch from comment #11)
> Created attachment 52920 [details] [review]
>
> Test-feedback highly appreciated.
Running now for two days with the patch, no negativ
On 31.10.2011 16:05, Jerome Glisse wrote:
> On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote:
>> Hello everybody,
>>
>> to support multiple compute rings, async DMA engines and UVD we need
>> to teach the radeon kernel module how to sync buffers between
>> different rings and make so
On Tue, Nov 01, 2011 at 09:11:37PM -0400, Jerome Glisse wrote:
> Hi,
>
> So attached is patch serie (sorry for that i am away of my normal mail
> config) which ultimately merge ttm_backend & ttm_tt it allows to get
> rid of data duplication btw the two, especialy btw ttm_tt and driver
> specific b
https://bugs.freedesktop.org/show_bug.cgi?id=41592
Michel Dänzer changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #18 from Michel Dän
https://bugs.freedesktop.org/show_bug.cgi?id=28426
--- Comment #8 from Michel D?nzer 2011-11-02 03:53:49
PDT ---
Kernel 3.0.7 has one HW cursor fix, 3.1 has more and other HW cursor changes.
Do any of those help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson
wrote:
> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
> -Chris
Here's that patch separated out:
commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard
Date: Wed Nov 2 10:17:5
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes
wrote:
> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...
Here's the new version of that chunk:
@@ -906,32 +905,56 @@ intel_dp_mode_
application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/97aa2748/attachment.pgp>
not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/89a2126d/attachment.pgp>
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson wrote:
> Redundant. You've already done the link_configuration |= above in the
> common code. You can drop the second if chunk altogether.
Here's the new version of that chunk of patch:
@@ -850,32 +864,45 @@ intel_dp_mode_set(struct drm_encode
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/23ce8d10/attachment-0001.pgp>
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
> Given the choice of trusting DPCD or the VBT, I'd definitely prefer
> DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of the wires. In an
s in both places?
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/8d2f4040/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=39272
--- Comment #1 from Andrew Randrianasulu 2011-11-02
03:28:48 PDT ---
Try patch from https://bugs.freedesktop.org/show_bug.cgi?id=38917 ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
On Tue, Nov 01, 2011 at 05:27:26PM -0400, Alex Deucher wrote:
> On Fri, Oct 28, 2011 at 5:52 PM, wrote:
> > From: Jerome Glisse
> >
> > Polarity needs to be set accordingly to connector status (connected
> > or disconnected). Set it up at module init so first hotplug works
> > reliably no matter
On Wed, Nov 02, 2011 at 11:12:42AM +0100, Christian K?nig wrote:
> On 31.10.2011 16:05, Jerome Glisse wrote:
> >On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote:
> >>Hello everybody,
> >>
> >>to support multiple compute rings, async DMA engines and UVD we need
> >>to teach the radeon
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson
wrote:
> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
Yeah, this got left in during some debugging; it might be a good thing
to do, but it's completely separate. I've pulled it out into a separ
ed it out into a separate
patch.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachment
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes
wrote:
> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...
Yeah, I'd like to understand why PP_READY isn't getting set; we should
have
ASK and IDLE_ON_VALUE.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2002/c8c9793d/attachment.pgp>
On 11/2/11 12:20 PM, Jesse Barnes wrote:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp = enc_to_intel_dp(encoder);
- if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
+
On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes
wrote:
> But I was curious about this hunk:
>
> @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> continue;
>
> intel_dp = enc_to_intel_dp(encoder);
> -
1 - 100 of 166 matches
Mail list logo
