I tested the patch and it fixed the problem.
Thanks,
Ari
2011/6/3 Alex Deucher :
> The PHY was not initialized correctly after
> ac89af1e1010640db072416c786f97391b85790f since
> the function bailed early as an encoder was not
> assigned. ?The encoder isn't necessary for PHY init
> so just assign
https://bugs.freedesktop.org/show_bug.cgi?id=37911
Summary: supertuxkart crashes with r300g
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=37911
Summary: supertuxkart crashes with r300g
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
I'm using ASUS EAH3650SILENTMG/HTDP.
I got the feeling that in my case, radeon_atom_encoder_prepare needed to be
called before radeon_atom_encoder_init (the call occurred during
radeon_fbdev_init). That ensured radeon_encoder->enc_priv->dig_encoder to have
a value other than -1 in the first call o
From: Harry Wei
When i compile kernel, it shows me two warnings
like below, so this patch can fix them.
[...]
CC [M] drivers/gpu/drm/i915/intel_dvo.o
CC [M] drivers/gpu/drm/i915/intel_ringbuffer.o
drivers/gpu/drm/i915/intel_ringbuffer.c:603: warning:
?ring_get_irq? defined but
On Fri, Jun 3, 2011 at 4:37 AM, Alan Cox wrote:
> I have GEM allocation working on the GMA 500 and I can scribble in a
> framebuffer (minus an odd 'last page' bug which is an off by one
> somewhere I imagine) and display it with nice modetest stripes.
>
> If I kill the program however it all goes
On Thu, 2 Jun 2011 19:42:03 +0100, Alan Cox wrote:
> On Sat, 28 May 2011 09:54:01 +0100
> Chris Wilson wrote:
>
> > On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin"
> > wrote:
> > > Hello gurus,
> > >
> > > I have two question mostly regarding libdrm_intel
> > >
> > > 1/ What is the d
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/c296ad8e/attachment.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=28622
--- Comment #10 from Daniel Poelzleithner
2011-06-04 00:36:02 ---
Created an attachment (id=60712)
--> (https://bugzilla.kernel.org/attachment.cgi?id=60712)
2.6.39 lockup
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab
https://bugzilla.kernel.org/show_bug.cgi?id=28622
--- Comment #9 from Daniel Poelzleithner
2011-06-04 00:34:36 ---
the 2.6.38 was sligthly more stable then the 2.6.39 is.
the current lockup shows:
[17052.294941] runnable tasks:
[17052.294942] task PID tree-key switc
Here's another handful of fixes that I had merged to
drm-intel-next. Once these are merged, I'll move drm-intel-fixes and
start putting stuff there for 3.0.
The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0:
drm/i915: initialize gen6 rps work queue on Sandy Bridge and
/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/df92d7d5/attachment.pgp>
The PHY was not initialized correctly after
ac89af1e1010640db072416c786f97391b85790f since
the function bailed early as an encoder was not
assigned. The encoder isn't necessary for PHY init
so just assign to 0 for init so that the table
is executed.
Reported-by: Ari Savolainen
Cc: Ari Savolaine
On Fri, Jun 3, 2011 at 4:03 PM, Ari Savolainen
wrote:
> I'm using ASUS EAH3650SILENTMG/HTDP.
>
> I got the feeling that in my case, radeon_atom_encoder_prepare needed to be
> called before radeon_atom_encoder_init (the call occurred during
> radeon_fbdev_init). That ensured radeon_encoder->enc_pri
On 03-06-2011 00:16, Alan Cox wrote:
>> The window system needs support for splitting rendering and display.
>> In X these are currently tied together. The only real obstacle is
>> fixing this in X. However, this is a lot of work. Dave Airlie has
>> started working on this, but it's not really u
https://bugs.freedesktop.org/show_bug.cgi?id=36812
--- Comment #9 from Sven Arvidsson 2011-06-03 13:54:28 PDT ---
I noticed that a few piglit tests causes GPU hang/resets when run with
MESA_GLSL=nopt. Is this to be expected or is it worth to file bugs?
The failing tests are glsl-fs-atan-2, glsl-
I tested the patch and it fixed the problem.
Thanks,
Ari
2011/6/3 Alex Deucher :
> The PHY was not initialized correctly after
> ac89af1e1010640db072416c786f97391b85790f since
> the function bailed early as an encoder was not
> assigned. The encoder isn't necessary for PHY init
> so just assign
https://bugs.freedesktop.org/show_bug.cgi?id=36812
--- Comment #9 from Sven Arvidsson 2011-06-03 13:54:28 PDT ---
I noticed that a few piglit tests causes GPU hang/resets when run with
MESA_GLSL=nopt. Is this to be expected or is it worth to file bugs?
The failing tests are glsl-fs-atan-2, glsl-
https://bugzilla.kernel.org/show_bug.cgi?id=30052
--- Comment #16 from Seth Forshee 2011-06-03
13:53:31 ---
Adding here some of the information that I added to the freedesktop.org
bugzilla here:
https://bugs.freedesktop.org/show_bug.cgi?id=36003
It seems to me that nothing being done curr
The PHY was not initialized correctly after
ac89af1e1010640db072416c786f97391b85790f since
the function bailed early as an encoder was not
assigned. The encoder isn't necessary for PHY init
so just assign to 0 for init so that the table
is executed.
Reported-by: Ari Savolainen
Cc: Ari Savolaine
On Fri, Jun 3, 2011 at 4:03 PM, Ari Savolainen
wrote:
> I'm using ASUS EAH3650SILENTMG/HTDP.
>
> I got the feeling that in my case, radeon_atom_encoder_prepare needed to be
> called before radeon_atom_encoder_init (the call occurred during
> radeon_fbdev_init). That ensured radeon_encoder->enc_pri
I'm using ASUS EAH3650SILENTMG/HTDP.
I got the feeling that in my case, radeon_atom_encoder_prepare needed to be
called before radeon_atom_encoder_init (the call occurred during
radeon_fbdev_init). That ensured radeon_encoder->enc_priv->dig_encoder to have
a value other than -1 in the first call o
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertion
On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen
wrote:
> Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors
> attached to a dual head radeon gpu to have inverted colors (until the first
> suspend/resume). Initializing dig phy a bit later fixes the problem.
Strange, I don't
https://bugs.freedesktop.org/show_bug.cgi?id=37785
Antti Lahtinen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=37785
Antti Lahtinen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, Jun 3, 2011 at 5:00 AM, Prasanna Kumar T S M
wrote:
> On 03-06-2011 00:16, Alan Cox wrote:
>>>
>>> The window system needs support for splitting rendering and display.
>>> In X these are currently tied together. ?The only real obstacle is
>>> fixing this in X. ?However, this is a lot of wo
https://bugs.freedesktop.org/show_bug.cgi?id=37220
--- Comment #4 from Jure Repinc 2011-06-03 10:52:24 PDT ---
I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI
Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg
server is 1.10.2, Linux kernel is 2.
https://bugs.freedesktop.org/show_bug.cgi?id=37220
--- Comment #4 from Jure Repinc 2011-06-03 10:52:24 PDT
---
I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI
Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg
server is 1.10.2, Linux kernel is 2
On Fri, 3 Jun 2011 21:09:39 +0800, Harry Wei wrote:
(process:18294): gmime-CRITICAL **: g_mime_stream_filter_add: assertion
`GMIME_IS_FILTER (filter)' failed
> From: Harry Wei
> When i compile kernel, it shows me two warnings
> like below, so this patch can fix them.
This fix is already upstre
as scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/5715ca05/attachment.pgp>
On Fri, 3 Jun 2011 02:28:47 -0700, Joe Perches wrote:
> drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
Acked-by: Keith Packard
Dave -- if you want to just merge this to your tree, that's fine with
me.
--
keith.pack...@intel.com
pgpfKcfQohl1E.pgp
Description: PGP signature
--
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/5f738a51/attachment.pgp>
On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen
wrote:
> Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors
> attached to a dual head radeon gpu to have inverted colors (until the first
> suspend/resume). Initializing dig phy a bit later fixes the problem.
Strange, I don't
On Fri, Jun 3, 2011 at 5:00 AM, Prasanna Kumar T S M
wrote:
> On 03-06-2011 00:16, Alan Cox wrote:
>>>
>>> The window system needs support for splitting rendering and display.
>>> In X these are currently tied together. The only real obstacle is
>>> fixing this in X. However, this is a lot of wo
https://bugzilla.kernel.org/show_bug.cgi?id=30052
--- Comment #16 from Seth Forshee 2011-06-03
13:53:31 ---
Adding here some of the information that I added to the freedesktop.org
bugzilla here:
https://bugs.freedesktop.org/show_bug.cgi?id=36003
It seems to me that nothing being done curr
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertion
Use the normal include style.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_ioctl.c |2 +-
drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c |6 +
Just neatening.
Joe Perches (5):
drbd: Use angle brackets for system includes
drm: Use angle brackets for system includes
aix94xx: Use angle brackets for system includes
ALSA: asihpi: Use angle brackets for system includes
staging: msm: Use angle brackets for system includes
drivers/bl
Use the normal include style.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_ioctl.c |2 +-
drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c |6 +
Just neatening.
Joe Perches (5):
drbd: Use angle brackets for system includes
drm: Use angle brackets for system includes
aix94xx: Use angle brackets for system includes
ALSA: asihpi: Use angle brackets for system includes
staging: msm: Use angle brackets for system includes
drivers/bl
On 03-06-2011 00:16, Alan Cox wrote:
The window system needs support for splitting rendering and display.
In X these are currently tied together. The only real obstacle is
fixing this in X. However, this is a lot of work. Dave Airlie has
started working on this, but it's not really usable yet.
Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors
attached to a dual head radeon gpu to have inverted colors (until the first
suspend/resume). Initializing dig phy a bit later fixes the problem.
---
drivers/gpu/drm/radeon/radeon_display.c |8
1 files changed,
43 matches
Mail list logo
