mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/4fedb84c/attachment.html>
org/archives/dri-devel/attachments/20130226/d11e849c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/4da66d72/attachment.html>
||ken20001 at ukr.net
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/1f699592/attachment-0001.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/d3e9f45a/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #30 from Jakob Nixdorf ---
What do you mean by fixed, this bug or the one you linked?
Because I still get the same corruptions in Trine 2 and some textures in CS:S
with the newest git version of mesa.
--
You are receiving this mail
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/f587e6d5/attachment.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/74cb2d77/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/472bc2c7/attachment.html>
Thanks Sean,
On Tue, Feb 26, 2013 at 11:33 PM, Sean Paul wrote:
> On Fri, Feb 22, 2013 at 8:32 AM, Rahul Sharma
> wrote:
>> Exynos5 is already using drm_display_mode for timings parameters. Exynos4
>> is also modifed to use the same. List of supported resolutions and
>> corresponding timings ar
y ideas about this issue?
Thank you
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/f1e971d0/attachment.html>
Thanks Sean,
On Tue, Feb 26, 2013 at 10:55 PM, Sean Paul wrote:
> On Tue, Feb 26, 2013 at 7:16 AM, Rahul Sharma
> wrote:
>> Exynos hdmi driver is using drm_display_mode for setting timing values
>> for a supported resolution. Conversion to fb_videomode and then comparing
>> with the mixer/hdmi/
On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
> > > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH > > >
On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie wrote:
>
> If you want to just bump it so Ironlake isn't affected, (patch attached).
It works fine 95% of the time and isn't a hard failure when it
doesn't, so this isn't critical. I can wait for it to be fixed a
while.
> Is this external DP monitor o
On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie wrote:
>
> If you want to just bump it so Ironlake isn't affected, (patch attached).
It works fine 95% of the time and isn't a hard failure when it
doesn't, so this isn't critical. I can wait for it to be fixed a
while.
> Is this external DP monitor o
On Wed, Feb 27, 2013 at 11:39 AM, Linus Torvalds
wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>>
>> Highlights:
>>
>> i915: all over the map, haswell power well enhancements, valleyview macro
>> horrors cleaned up, killing lots of legacy GTT
>> code,
>
> Lowlight:
>
> There's som
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #29 from Alexandre Demers ---
I'm sure the rendering corruption comes from a wrongly set address for Cayman
(not shifted correctly at some point). It reminds me of bug 38173 and its
fixes.
--
You are receiving this mail because:
You
On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds
wrote:
>
> Lowlight:
>
> [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
Oh, forgot to mention - this is my trusty old Westmere chip (aka "Core
i5-670", aka Clarkdale, aka GMA-some-random-number).
On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds
wrote:
>
> Lowlight:
>
> [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
Oh, forgot to mention - this is my trusty old Westmere chip (aka "Core
i5-670", aka Clarkdale, aka GMA-some-random-number).
On 26 February 2013 17:35, Greg KH wrote:
> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
>> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH
>> > > wrote:
>> > >
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>
> Highlights:
>
> i915: all over the map, haswell power well enhancements, valleyview macro
> horrors cleaned up, killing lots of legacy GTT
> code,
Lowlight:
There's something wrong with i915 DP detection or whatever. I get
stuff like this:
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>
> Highlights:
>
> i915: all over the map, haswell power well enhancements, valleyview macro
> horrors cleaned up, killing lots of legacy GTT
> code,
Lowlight:
There's something wrong with i915 DP detection or whatever. I get
stuff like this:
On Mon, Feb 25, 2013 at 07:55:18PM -0300, Rodrigo Vivi wrote:
> From: Shobhit Kumar
>
> Signed-off-by: Shobhit Kumar
>
> v2: reuse of just created is_edp_psr and put it at right place.
>
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 +
On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #155 from Chris Wilson ---
(In reply to comment #154)
> These fixes are in the latest 3.8 kernel. Have the GPU hangs been fixed in
> earlier versions of the kernel?
The sna fixes work with any KMS/GEM (i.e. 2.6.29+) kernel. The ker
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #3 from Alex Deucher ---
Does setting the env var R600_HYPERZ=0 help? I suspect this might actually be
a bug in the 3D driver and you only see it with 3.8 since newer mesa features
require newer kernels.
--
You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #2 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.f
Am Dienstag, den 26.02.2013, 10:55 -0500 schrieb Christopher Harvey:
> A monitor or a user could request a resolution greater than the
> available VRAM for the backing framebuffer. This change checks the
> required framebuffer size against the max VRAM size and rejects modes
> if they are too big.
Am Dienstag, den 26.02.2013, 10:55 -0500 schrieb Christopher Harvey:
*assignments
> These two variables are set again immediately in 'mgag200_modeset_init'
The compiler would optimize this anyway I guess. Though now it can warn
us, if the code should ever change and these variable are not set
an
On Tue, 26 Feb 2013, Rodrigo Vivi wrote:
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
> This patch is hea
Am Dienstag, den 26.02.2013, 10:54 -0500 schrieb Christopher Harvey:
> Signed-off-by: Christopher Harvey
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
[…]
Acked-by: Paul Menzel
Thanks,
Paul
signature.asc
Description: This is
Dear Christopher,
thank you for your patches. Not sure if you should CC some maintainer
(or if you did already).
Am Dienstag, den 26.02.2013, 10:53 -0500 schrieb Christopher Harvey:
1. I guess you can remove Cleanup from the commit summary.
2. Why is it »pointless«? I guess a compiler warning
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #1 from Eugene ---
Created attachment 75606
--> https://bugs.freedesktop.org/attachment.cgi?id=75606&action=edit
syslog file with GPU lockups
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=61533
Eugene changed:
What|Removed |Added
Priority|medium |high
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=61533
Priority: medium
Bug ID: 61533
Assignee: dri-devel@lists.freedesktop.org
Summary: GPU lockups uccurs regularilly on kernel 3.8 caused by
Opera browser hardware accelerated rendering
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #154 from Trey Ramsay ---
These fixes are in the latest 3.8 kernel. Have the GPU hangs been fixed in
earlier versions of the kernel?
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
https://bugs.freedesktop.org/show_bug.cgi?id=61532
Binary-Synapse changed:
What|Removed |Added
Priority|medium |highest
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=61532
Binary-Synapse changed:
What|Removed |Added
Attachment #75604|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=61532
Priority: medium
Bug ID: 61532
Assignee: dri-devel@lists.freedesktop.org
Summary: Running any Media Player or Webcam App, hangs the GPU
Severity: critical
Classification: Unclassified
.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/16ad8f8e/attachment.html>
On Fri, Feb 22, 2013 at 8:32 AM, Rahul Sharma
wrote:
> Exynos5 is already using drm_display_mode for timings parameters. Exynos4
> is also modifed to use the same. List of supported resolutions and
> corresponding timings are removed which helps is enabling some extra
> resolutions. It also clean
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/01b1b4a3/attachment.html>
On Tue, Feb 26, 2013 at 7:16 AM, Rahul Sharma
wrote:
> Exynos hdmi driver is using drm_display_mode for setting timing values
> for a supported resolution. Conversion to fb_videomode and then comparing
> with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
> fields cane be di
VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
Signed-off-by: Jingoo Han
Cc: Steffen Trumtrar
---
drivers/video/fbmon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fb
>
> I did the fun conflict resolution, so my tree doesn't have the ordering
> changes.
>
> I also did some things slightly differently from you - you had left
> some direct ib[] accesses that I spotted (see for example "case 0x48"
> (aka "Copy L2T Frame to Field"), and yours apparently has a few c
On 25.02.2013 17:24, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jan 15, 2013 at 01:43:59PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
>> index e89fb2b..57680a6 100644
>> --- a/drivers/gpu/host1x/Kconfig
>> +
A monitor or a user could request a resolution greater than the
available VRAM for the backing framebuffer. This change checks the
required framebuffer size against the max VRAM size and rejects modes
if they are too big. This change can also remove a mode request passed
in via the video= parameter
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 70dd3c5
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index d3d99a2..3abf197 100644
--- a/drivers/gpu/drm/mgag200/mgag
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 5ea5033..4d932c4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 2f48648..d46bd2c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/
Patches 1 to 4 are just cleanup. Maybe these should should be rolled
into one patch?
Patch 5 is a bit more complicated.
On cards with very little video memory, (e.g 8MB) higher resolutions
at 32bit framebuffer depths will get corrupted because the required
memory is larger than what the framebuffe
On Tue, Feb 26, 2013 at 06:11:31PM +, James Courtier-Dutton wrote:
> On 26 February 2013 17:35, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> >> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> >> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie
On Tue, Feb 26, 2013 at 12:05:50PM +0900, Jingoo Han wrote:
> VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
> because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
>
> Signed-off-by: Jingoo Han
> Cc: Steffen Trumtrar
> ---
> drivers/video/fbmon.c |2 +-
> 1 f
On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH
> > > wrote:
> > > > Hi Ben,
> > > >
> > > > My Macbook Pro Retina fa
On Tue, Feb 26, 2013 at 7:16 AM, Rahul Sharma wrote:
> Exynos hdmi driver is using drm_display_mode for setting timing values
> for a supported resolution. Conversion to fb_videomode and then comparing
> with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
> fields cane be dir
Currently, mode_fixup code doesn't consider the limitations of mixer as it
is implemented inside the hdmi driver. Following fix, moves the mode_fixup
to common drm hdmi driver. To check the mode support, it calls both, mixer
and hdmi check_timing callbacks for a given resolution mode.
This patch i
Exynos hdmi driver is using drm_display_mode for setting timing values
for a supported resolution. Conversion to fb_videomode and then comparing
with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
fields cane be directly compared.
This patch is dependent on https://patchwork.
On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
> > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH wrote:
> > > Hi Ben,
> > >
> > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked this
> > > down to commit 6c5a0424
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index d3d99a2..3abf197 100644
--- a/drivers/gpu/drm/mgag200/mgag
Patches 1 to 4 are just cleanup. Maybe these should should be rolled
into one patch?
Patch 5 is a bit more complicated.
On cards with very little video memory, (e.g 8MB) higher resolutions
at 32bit framebuffer depths will get corrupted because the required
memory is larger than what the framebuffe
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 5ea5033..4d932c4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 70dd3c5
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 2f48648..d46bd2c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/
A monitor or a user could request a resolution greater than the
available VRAM for the backing framebuffer. This change checks the
required framebuffer size against the max VRAM size and rejects modes
if they are too big. This change can also remove a mode request passed
in via the video= parameter
Currently, mode_fixup code doesn't consider the limitations of mixer as it
is implemented inside the hdmi driver. Following fix, moves the mode_fixup
to common drm hdmi driver. To check the mode support, it calls both, mixer
and hdmi check_timing callbacks for a given resolution mode.
This patch i
Exynos hdmi driver is using drm_display_mode for setting timing values
for a supported resolution. Conversion to fb_videomode and then comparing
with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
fields cane be directly compared.
This patch is dependent on https://patchwork.
On Mon, Feb 25, 2013 at 07:55:18PM -0300, Rodrigo Vivi wrote:
> From: Shobhit Kumar
>
> Signed-off-by: Shobhit Kumar
>
> v2: reuse of just created is_edp_psr and put it at right place.
>
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 +
On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
https://bugs.freedesktop.org/show_bug.cgi?id=61470
Alex Deucher changed:
What|Removed |Added
Assignee|e...@pdx.freedesktop.org|dri-devel@lists.freedesktop
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/6909d369/attachment-0001.html>
On Tue, 26 Feb 2013, Rodrigo Vivi wrote:
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
> This patch is hea
On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
https://bugs.freedesktop.org/show_bug.cgi?id=30167
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Feb 26, 2013 at 12:05:50PM +0900, Jingoo Han wrote:
> VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
> because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
>
> Signed-off-by: Jingoo Han
> Cc: Steffen Trumtrar
> ---
> drivers/video/fbmon.c |2 +-
> 1 f
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130226/d9f9f79a/attachment.html>
Hi Linus,
This is the main drm pull for the 3.9-rc1 merge, and my chance to have my
email published verbatim as an article by the worst news site ever.
So up front, this has a massive merge conflict in
drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged
in the same tree,
78 matches
Mail list logo
