Op vrijdag 12 april 2013 14:47 schreef Chris Wilson:
> On Fri, Apr 12, 2013 at 02:24:43PM +0200, Ben Mesman wrote:
> > Last year, a patch was made for the "HP t5740e Thin Client" (see
> > http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
> > This device reports an lvds panel, b
Hi Dave,
This pull request includes bug fixes, code cleanups and
one revert that removes the wrong bindings file for exynos
fimg2d device for code cleanup becasue correct one has already
been merged to Samsung next like below,
next/dt-exynos branch of
git://git.kernel.org/pub/scm/linux/ke
On Sun, Apr 14, 2013 at 12:29:46AM -0400, Rob Clark wrote:
> On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
[...]
> > I had been thinking about this on and off for a while, but I haven't
> > come up with anything concrete. Ideally we could just have some kind of
> > event that userspace would list
On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
> On pseries machines the detection for max_bus_speed should be done
> through an OpenFirmware property. This patch adds a function to perform this
> detection and a hook to perform dynamic adding of the function only for
> ps
On Sat, Apr 13, 2013 at 06:10:40PM +0100, Chris Wilson wrote:
> On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote:
> > Hi,
> >
> > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling
> > drm_modeset_lock_all() and later calls
> > drm_fb_helper_probe_connector_mo
Hi,
the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling
drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(),
which in case of i915 DRM driver effectively calls
intel_get_load_detect_pipe() that tries to lock crtc->mutex again.
This causes a deadlock, a
From: Paul Sokolovsky
An ifdef in drm.h expects to be compiled with full-fledged Linux
toolchain, but it's common to compile kernel with just bare-metal
toolchain which doesn't define __linux__. So, also add __KERNEL__
check.
[n...@ti.com: port forward to 3.9-rc6 and post to dri devel for feedba
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
>
> Please consider
>
> 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
> the per-process entries, 2012-08-24
>
> for application to the 3.4.y tree.
>
> Without this patch, Geoff Crompt
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
>
> Please consider
>
> 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
> the per-process entries, 2012-08-24
>
> for application to the 3.4.y tree.
Thanks, I'll queue this for 3.5 kern
Hi Greg,
Please consider
9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
the per-process entries, 2012-08-24
for application to the 3.4.y tree.
Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
The problem is reproducible on
* Debian's 3.2.y
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
>
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-night
2013/4/14 Alex Deucher :
> On Sun, Apr 14, 2013 at 11:55 AM, Rafa? Mi?ecki wrote:
>> 2013/4/14 Alex Deucher :
>>> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio
2013/4/14 Alex Deucher :
>> + /*
>> +* According to the commens above we should use !DCE41 ||
>> DCE5,
>> +* condition, however there isn't any DCE5 that is DCE41, so
>> +* DCE5 check is not needed.
>> +*/
>
> It would p
https://bugs.freedesktop.org/show_bug.cgi?id=63532
romula...@gmail.com changed:
What|Removed |Added
URL||http://www.heroesofnewerth.
2013/4/14 Alex Deucher :
> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> Can you confirm that this is actually needed on older chips? AFAIK,
> i
https://bugs.freedesktop.org/show_bug.cgi?id=63532
romula...@gmail.com changed:
What|Removed |Added
Attachment #77962|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=31667
romula...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Sun, Apr 14, 2013 at 1:58 PM, Rafa? Mi?ecki wrote:
> 2013/4/14 Alex Deucher :
>>> + /*
>>> +* According to the commens above we should use !DCE41 ||
>>> DCE5,
>>> +* condition, however there isn't any DCE5 that is DCE41, so
>>> +* D
https://bugs.freedesktop.org/show_bug.cgi?id=63532
--- Comment #1 from romula...@gmail.com ---
Created attachment 77963
--> https://bugs.freedesktop.org/attachment.cgi?id=77963&action=edit
screenshot of wrong rendering at middle
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=63532
Priority: medium
Bug ID: 63532
Assignee: dri-devel@lists.freedesktop.org
Summary: Heroes of Newerth Water renders Black instead of
transparent with reflections on Ultra [r600g]
Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.
Signed-off-by: Rafa? Mi?ecki
---
V2: typo in "sufficient"
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>
> Maybe use the following for a more descriptive summary:
>
> drm/radeon/evergreen: Set up audio and ACR packets after basic init
That extra message you can see in my patch:
> Driver fglrx setups audio and A
Signed-off-by: Rafa? Mi?ecki
---
V2: fix typo and add extra \n
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
drivers/gpu/drm/radeon/radeon_display.c |6 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/rade
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>
> Maybe for a more descriptive summary:
>
> drm/radeon: Add some HDMI (audio) comments about fglrx? reg reads
I also comment sth in radeon_display.c.
--
Rafa?
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>> Closed source driver fglrx seems to enable infoframes and audio packets
>> at the end, which makes sense, do the same.
>
> Any functionality change? Does not sound like it, but being unambiguous
> is better.
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafa? Mi?ecki:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> How should this be tested?
Just play some audio using different
On Sun, Apr 14, 2013 at 1:58 PM, Rafał Miłecki wrote:
> 2013/4/14 Alex Deucher :
>>> + /*
>>> +* According to the commens above we should use !DCE41 ||
>>> DCE5,
>>> +* condition, however there isn't any DCE5 that is DCE41, so
>>> +* D
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130414/f3e10ada/attachment-0001.html>
nts/20130414/f0601cff/attachment.html>
gt; - evergreen_hdmi_update_ACR(encoder, mode->clock);
>
> WREG32_OR(HDMI_INFOFRAME_CONTROL0 + offset,
> HDMI_AVI_INFO_SEND | /* enable AVI info frames */
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/56a0483e/attachment.pgp>
gt; +# define HDMI_AVI_INFO_LINE_MASK (0x3f << 0)
Is this in a data sheet?
> # define HDMI_AUDIO_INFO_LINE(x) (((x) & 0x3f) << 8)
> # define HDMI_MPEG_INFO_LINE(x)(((x) & 0x3f) << 16)
> #define HDMI_GENERIC_PACKET_CONTROL 0x704c
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/d41f1c20/attachment-0001.pgp>
--- next part ------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/b1b79a8f/attachment.pgp>
: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/529d48ac/attachment.pgp>
On Sun, Apr 14, 2013 at 11:55 AM, Rafa? Mi?ecki wrote:
> 2013/4/14 Alex Deucher :
>> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
>>> We need interrupts on format change for R6xx only, where hardware seems
>>> to be somehow bugged and requires setting audio info manually.
>>
>> Can you c
On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
>
> Signed-off-by: Rafa? Mi?ecki
> ---
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
> drivers/gpu/drm/radeon/radeon_display.c |5 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergr
On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
> We need interrupts on format change for R6xx only, where hardware seems
> to be somehow bugged and requires setting audio info manually.
Can you confirm that this is actually needed on older chips? AFAIK,
it shouldn't be required for any ch
2013/4/14 Alex Deucher :
> On Sun, Apr 14, 2013 at 11:55 AM, Rafał Miłecki wrote:
>> 2013/4/14 Alex Deucher :
>>> On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio
2013/4/14 Alex Deucher :
>> + /*
>> +* According to the commens above we should use !DCE41 ||
>> DCE5,
>> +* condition, however there isn't any DCE5 that is DCE41, so
>> +* DCE5 check is not needed.
>> +*/
>
> It would p
Hi Linus
one fix for a hotplug locking regressions, and one fix for an oops if you
unplug the monitor at an inopportune moment on the udl device.
Dave.
The following changes since commit cfb63bafdb87bbcdc5d6dbbca623d3f69475f118:
Merge branch 'fixes' of git://git.infradead.org/users/vkoul/sl
On Sun, Apr 14, 2013 at 11:55 AM, Rafał Miłecki wrote:
> 2013/4/14 Alex Deucher :
>> On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
>>> We need interrupts on format change for R6xx only, where hardware seems
>>> to be somehow bugged and requires setting audio info manually.
>>
>> Can you c
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
>
> Signed-off-by: Rafał Miłecki
> ---
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
> drivers/gpu/drm/radeon/radeon_display.c |5 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergr
2013/4/14 Alex Deucher :
> On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> Can you confirm that this is actually needed on older chips? AFAIK,
> i
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
> We need interrupts on format change for R6xx only, where hardware seems
> to be somehow bugged and requires setting audio info manually.
Can you confirm that this is actually needed on older chips? AFAIK,
it shouldn't be required for any ch
On Sat, Apr 13, 2013 at 06:10:40PM +0100, Chris Wilson wrote:
> On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote:
> > Hi,
> >
> > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling
> > drm_modeset_lock_all() and later calls
> > drm_fb_helper_probe_connector_mo
||
--
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/20130414/28f3e57f/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/d375fdcd/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/5fd278de/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/cf22e06f/attachment.html>
sts.freedesktop.org/archives/dri-devel/attachments/20130414/6458ae57/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=62959
Alex Deucher changed:
What|Removed |Added
CC||udo...@xs4all.nl
--- Comment #34 from Ale
https://bugs.freedesktop.org/show_bug.cgi?id=62997
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130414/d4a73db4/attachment.html>
Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.
Signed-off-by: Rafał Miłecki
---
V2: typo in "sufficient"
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
>
> Maybe use the following for a more descriptive summary:
>
> drm/radeon/evergreen: Set up audio and ACR packets after basic init
That extra message you can see in my patch:
> Driver fglrx setups audio and A
Signed-off-by: Rafał Miłecki
---
V2: fix typo and add extra \n
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
drivers/gpu/drm/radeon/radeon_display.c |6 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/rade
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
>
> Maybe for a more descriptive summary:
>
> drm/radeon: Add some HDMI (audio) comments about fglrx’ reg reads
I also comment sth in radeon_display.c.
--
Rafał
__
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
>> Closed source driver fglrx seems to enable infoframes and audio packets
>> at the end, which makes sense, do the same.
>
> Any functionality change? Does not sound like it, but being unambiguous
> is better.
2013/4/14 Paul Menzel :
> Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> How should this be tested?
Just play some audio using different
Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
Maybe use the following for a more descriptive summary:
drm/radeon/evergreen: Set up audio and ACR packets after basic init
> Driver fglrx setups audio and ACR packets after basic initialization,
> which sounds sane, do the same.
Co
Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
> Closed source driver fglrx seems to enable infoframes and audio packets
> at the end, which makes sense, do the same.
Any functionality change? Does not sound like it, but being unambiguous
is better.
> Signed-off-by: Rafał Miłecki
Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
Maybe for a more descriptive summary:
drm/radeon: Add some HDMI (audio) comments about fglrx’ reg reads
> Signed-off-by: Rafał Miłecki
> ---
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
> drivers/gpu/drm/radeon/
Am Sonntag, den 14.04.2013, 01:26 +0200 schrieb Rafał Miłecki:
> We need interrupts on format change for R6xx only, where hardware seems
> to be somehow bugged and requires setting audio info manually.
How should this be tested?
> Signed-off-by: Rafał Miłecki
> ---
> drivers/gpu/drm/radeon/ever
Hi Linus
one fix for a hotplug locking regressions, and one fix for an oops if you
unplug the monitor at an inopportune moment on the udl device.
Dave.
The following changes since commit cfb63bafdb87bbcdc5d6dbbca623d3f69475f118:
Merge branch 'fixes' of git://git.infradead.org/users/vkoul/sl
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 24d13ac..ed46dad 100644
--- a/drivers/gpu/drm/radeon/ever
Driver fglrx setups audio and ACR packets after basic initialization,
which sounds sane, do the same.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeo
Closed source driver fglrx seems to enable infoframes and audio packets
at the end, which makes sense, do the same.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 15 +++
drivers/gpu/drm/radeon/evergreend.h |1 +
2 files changed, 12 insertions(+)
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 14 ++
drivers/gpu/drm/radeon/radeon_display.c |5 +
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 4fdecc2..
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio info manually.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c | 127 +---
1 file changed, 1 insertion(+), 126 deletions(-)
Signed-off-by: Rafa? Mi?ecki
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/r600_hdmi.c | 16 ++--
drivers/gpu/drm/radeon/radeon.h|2 ++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_
I've managed to track fglrx operations on HDMI regs, so we can finally setup
everything in (hopefully) the correct way and order.
This changes HDMI setup on Evergreen to mostly match fglrx and was tested on:
1) AMD Radeon HD 6320 (PALM == DCE41)
2) AMD Radeon HD 6970M (BARTS == DCE5)
No regression
https://bugs.freedesktop.org/show_bug.cgi?id=63520
PJBrs changed:
What|Removed |Added
Attachment #77936|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #3 from PJBrs ---
Created attachment 77939
--> https://bugs.freedesktop.org/attachment.cgi?id=77939&action=edit
Good rendering screen 2
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #2 from PJBrs ---
Created attachment 77938
--> https://bugs.freedesktop.org/attachment.cgi?id=77938&action=edit
Bad rendering screen 2
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #1 from PJBrs ---
Created attachment 77937
--> https://bugs.freedesktop.org/attachment.cgi?id=77937&action=edit
Good rendering screen 1
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=63520
Priority: medium
Bug ID: 63520
Assignee: dri-devel@lists.freedesktop.org
Summary: r300g regression (RV380): Strange rendering of light
sources in Penumbra (bisected)
Severit
On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
wrote:
> On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote:
>> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren wrote:
>> >
>> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition
>> >> of `__mod_of_device_table'
>> >> dr
https://bugs.freedesktop.org/show_bug.cgi?id=62997
--- Comment #14 from udo ---
I guess the second patch also fixes the issue.
After 1 day, 15:11 of uptime I saw no GPU faults, hangs, etc.
Normally they occurred much sooner than that.
--
You are receiving this mail because:
You are the assigne
77 matches
Mail list logo
