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 jg1@samsung.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
https://bugs.freedesktop.org/show_bug.cgi?id=30167
Tomasz P. son_of_the_osi...@interia.pl changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, 26 Feb 2013, Rodrigo Vivi rodrigo.v...@gmail.com 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 ag...@yahoo.com changed:
What|Removed |Added
Assignee|e...@pdx.freedesktop.org
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.
On Mon, Feb 25, 2013 at 07:55:18PM -0300, Rodrigo Vivi wrote:
From: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
v2: reuse of just created is_edp_psr and put it at right place.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewed-by:
Signed-off-by: Christopher Harvey char...@matrox.com
---
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
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
Signed-off-by: Christopher Harvey char...@matrox.com
---
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
---
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
Signed-off-by: Christopher Harvey char...@matrox.com
---
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
---
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 gre...@linuxfoundation.org wrote:
Hi Ben,
My Macbook Pro Retina fails to resume properly on 3.8. I tracked this
down to
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
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
On Tue, Feb 26, 2013 at 7:16 AM, Rahul Sharma rahul.sha...@samsung.com 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,
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
https://bugs.freedesktop.org/show_bug.cgi?id=61532
Binary-Synapse temp.email...@gmail.com changed:
What|Removed |Added
Attachment #75604|0 |1
is
https://bugs.freedesktop.org/show_bug.cgi?id=61532
Binary-Synapse temp.email...@gmail.com changed:
What|Removed |Added
Priority|medium |highest
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #154 from Trey Ramsay tram...@linux.vnet.ibm.com ---
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
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=61533
Eugene ken20...@ukr.net changed:
What|Removed |Added
Priority|medium |high
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #1 from Eugene ken20...@ukr.net ---
Created attachment 75606
-- https://bugs.freedesktop.org/attachment.cgi?id=75606action=edit
syslog file with GPU lockups
--
You are receiving this mail because:
You are the assignee for the bug.
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
Am Dienstag, den 26.02.2013, 10:54 -0500 schrieb Christopher Harvey:
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
[…]
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
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
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.
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=61533
--- Comment #3 from Alex Deucher ag...@yahoo.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #155 from Chris Wilson ch...@chris-wilson.co.uk ---
(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.
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie 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
On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds
torva...@linux-foundation.org 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
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #29 from Alexandre Demers alexandre.f.dem...@gmail.com ---
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
On Wed, Feb 27, 2013 at 11:39 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie wrote:
Highlights:
i915: all over the map, haswell power well enhancements, valleyview macro
horrors cleaned up, killing lots of legacy GTT
On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie airl...@gmail.com 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
Thanks Sean,
On Tue, Feb 26, 2013 at 10:55 PM, Sean Paul seanp...@chromium.org wrote:
On Tue, Feb 26, 2013 at 7:16 AM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Exynos hdmi driver is using drm_display_mode for setting timing values
for a supported resolution. Conversion to fb_videomode
Thanks Sean,
On Tue, Feb 26, 2013 at 11:33 PM, Sean Paul seanp...@google.com wrote:
On Fri, Feb 22, 2013 at 8:32 AM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Exynos5 is already using drm_display_mode for timings parameters. Exynos4
is also modifed to use the same. List of supported
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #30 from Jakob Nixdorf flo...@shadowice.org ---
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
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130226/d9f9f79a/attachment.html>
>
> 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
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
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, 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
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
>>
|--- |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 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.
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
.
--
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 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.
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
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=
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
+++
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
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
+++
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
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
---
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
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
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
his 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>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/472bc2c7/attachment.html>
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/74cb2d77/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/f587e6d5/attachment.html>
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/d3e9f45a/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>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130226/4da66d72/attachment.html>
org/archives/dri-devel/attachments/20130226/d11e849c/attachment.html>
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/4fedb84c/attachment.html>
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
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
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
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
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
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 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
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 > >
76 matches
Mail list logo
