https://bugzilla.kernel.org/show_bug.cgi?id=22022
Zhang Rui changed:
What|Removed |Added
Component|Hibernation/Suspend |Video(DRI - non Intel)
AssignedTo|po
Hi All,
On 4 April 2013 11:58, Sumit Semwal wrote:
> The patch series adds a much-missed support for debugfs to dma-buf framework.
>
> Based on the feedback received on v1 of this patch series, support is also
> added to allow exporters to provide name-strings that will prove useful
> while debu
Hi Kero
> 4) when using modules, initialization from hibernation is not good enough:
>my screen stays black; without using modules, the kernel boots normally,
> and everything is fine.
> 5) initialization from suspend is not good enough: my Asus stays in
>some text mode (80x25?), but show
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index ed46dad..81db8b9 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/dr
Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.
---
V2: fix commit message
return
On 2013?04?07? 19:24, Paul Menzel wrote:
> do you know if this cause any problems? Did you find this reading the
> code or by using some tools?
sorry, I do not know if this can cause any problems.
for this issue, I did not find it by reading code.
I find it by using compiler warnings with
On Sun, Apr 07, 2013 at 12:52:57PM +0200, Rafa? Mi?ecki wrote:
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardware/firmware does the rest. In such a cases we need to read info
> from SAD blocks and put them i
https://bugzilla.kernel.org/show_bug.cgi?id=55941
--- Comment #6 from Alex Deucher 2013-04-07
16:30:00 ---
(In reply to comment #4)
> I have been very puzzled when reading your last message Alex, since I got (on
> debian) the exact same problem with a Mux system intel Ironlake/radeon Hd565
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130407/2803ad18/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=56311
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
ves/dri-devel/attachments/20130407/1aeb60cc/attachment.html>
---
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_hdmi.c
index 21ecc0e..91582a5 100644
--- a/drivers/gpu/drm
On 2013年04月07日 19:24, Paul Menzel wrote:
> do you know if this cause any problems? Did you find this reading the
> code or by using some tools?
sorry, I do not know if this can cause any problems.
for this issue, I did not find it by reading code.
I find it by using compiler warnings with
From: Xiong Zhou
This patch fixes build failure of v3.9-rc5.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
gma5/600 needs acpi_video just like nouveau.
Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340:
thank you very much for your reply, firstly.
On 2013年04月07日 12:09, Joe Perches wrote:
> On Sun, 2013-04-07 at 11:57 +0800, Chen Gang wrote:
>> > On 2013年04月07日 11:49, Greg KH wrote:
>>> > > On Sun, Apr 07, 2013 at 09:03:55AM +0800, Chen Gang wrote:
> >> Hello Greg KH:
> >> when you
On 2013年04月07日 11:49, Greg KH wrote:
> On Sun, Apr 07, 2013 at 09:03:55AM +0800, Chen Gang wrote:
>> Hello Greg KH:
>>
>> when you have time, can you help to check this patch whether OK ?
>
> No.
>
>
Why ? does it also need a test ??
--
Chen Gang
Asianux Corporation
On Sun, Apr 07, 2013 at 09:03:55AM +0800, Chen Gang wrote:
> Hello Greg KH:
>
> when you have time, can you help to check this patch whether OK ?
No.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
Hello Greg KH:
when you have time, can you help to check this patch whether OK ?
thanks.
gchen.
On 2013年04月03日 16:01, Chen Gang wrote:
> Hello maintainers:
>
> when you have time, please help to check this patch whether is OK.
>
> thanks.
>
> gchen.
>
>
> On 2013年03月27日 15:23, Chen
Thanks for all your efforts. It is really fun to see such an immediate response.
Daniel Vetter wrote:
>On Sat, Apr 6, 2013 at 6:24 PM, George Amanakis wrote:
>> Indeed, I set explicitly drm_kms_helper.poll=0 since 2.35.x. See here:
>> http://souriguha.wordpress.com/2011/03/08/how-to-solve-probl
Indeed, I set explicitly drm_kms_helper.poll=0 since 2.35.x. See here:
http://souriguha.wordpress.com/2011/03/08/how-to-solve-problem-with-thinkpadkslowd-kworker-on-linux-kernel-2-35-2-36/
Mouse and keyboard freezes intermittently some time after boot up. Actually the
problem has to do with the G
I mean that I can type, move the mouse pointer, open new windows but there is a
lag until these changes are displayed. Stuttering like.
I ended up not reverting the aforementioned commit but modifying it. This also
solves the issue. Here is the patch:
diff -rupN a/drivers/gpu/drm/drm_crtc_help
Every day or so, I'll click something and my screens go blank for a
second or two. dmesg complains about a lockup, and afterwards
everything is painfully slow. (Even switching focus to other emacs
windows takes a second or two.) Once this happens, if I restart X, I
get a blank screen, although t
From: Xiong Zhou
This patch fixes build failure of v3.9-rc5.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
gma5/600 needs acpi_video just like nouveau.
Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340:
s "+" sign at a
> beginning of line and \t can look different when viewing patch. Please
> apply a patch and check drm_edid.h then - it'll be OK.
Thanks. Sorry for not checking that myself.
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/20130407/d4f707db/attachment.pgp>
Thanks for comments!
2013/4/7 Paul Menzel :
> Am Sonntag, den 07.04.2013, 12:52 +0200 schrieb Rafa? Mi?ecki:
>> +struct cea_sad *drm_edid_to_sad(struct edid *edid)
>> +{
>> + struct cea_sad *sads = NULL;
>
> No need to set it NULL, as it gets assigned later on? Looks like in the
> end there is
truct cea_sad *drm_edid_to_sad(struct edid *edid);
> int drm_av_sync_delay(struct drm_connector *connector,
> struct drm_display_mode *mode);
> struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
Otherwise this looks good.
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/20130407/69c27bfd/attachment.pgp>
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/20130407/dd7a6db4/attachment.pgp>
2013/4/7 Rafa? Mi?ecki :
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardware/firmware does the rest. In such a cases we need to read info
> from SAD blocks and put them in the correct registers.
If you wish
2013/4/7 Boszormenyi Zoltan :
> will there be a followup patch where this function is actually used?
Sure :) It's just early patch post, with RFC, to see if I'm doing it
the right way.
--
Rafa?
Hi,
will there be a followup patch where this function is actually used?
Best regards,
Zolt?n B?sz?rm?nyi
2013-04-07 12:52 keltez?ssel, Rafa? Mi?ecki ?rta:
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardwa
Some devices (ATI/AMD cards) don't want passing ELD struct to the
hardware but just require filling specific registers and then
hardware/firmware does the rest. In such a cases we need to read info
from SAD blocks and put them in the correct registers.
---
drivers/gpu/drm/drm_edid.c | 55 +++
Hi Kero
> 4) when using modules, initialization from hibernation is not good enough:
>my screen stays black; without using modules, the kernel boots normally,
> and everything is fine.
> 5) initialization from suspend is not good enough: my Asus stays in
>some text mode (80x25?), but show
thank you very much for your reply, firstly.
On 2013?04?07? 12:09, Joe Perches wrote:
> On Sun, 2013-04-07 at 11:57 +0800, Chen Gang wrote:
>> > On 2013?04?07? 11:49, Greg KH wrote:
>>> > > On Sun, Apr 07, 2013 at 09:03:55AM +0800, Chen Gang wrote:
> >> Hello Greg KH:
> >> when you
On 2013?04?07? 11:49, Greg KH wrote:
> On Sun, Apr 07, 2013 at 09:03:55AM +0800, Chen Gang wrote:
>> Hello Greg KH:
>>
>> when you have time, can you help to check this patch whether OK ?
>
> No.
>
>
Why ? does it also need a test ??
--
Chen Gang
Asianux Corporation
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index ed46dad..81db8b9 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/dr
Some devices (ATI/AMD cards) don't support passing ELD struct to the
hardware but just require filling specific registers and then the
hardware/firmware does the rest. In such cases we need to read the info
from SAD blocks and put them in the correct registers.
---
V2: fix commit message
return
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130407/5f039811/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=55941
--- Comment #6 from Alex Deucher 2013-04-07 16:30:00
---
(In reply to comment #4)
> I have been very puzzled when reading your last message Alex, since I got (on
> debian) the exact same problem with a Mux system intel Ironlake/radeon Hd565
https://bugs.freedesktop.org/show_bug.cgi?id=63236
Priority: medium
Bug ID: 63236
Assignee: dri-devel@lists.freedesktop.org
Summary: kwin crashes when some desktop effects are used
Severity: normal
Classification: Unclassified
https://bugzilla.kernel.org/show_bug.cgi?id=56311
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugs.freedesktop.org/show_bug.cgi?id=59521
Laurent carlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hello Greg KH:
when you have time, can you help to check this patch whether OK ?
thanks.
gchen.
On 2013?04?03? 16:01, Chen Gang wrote:
> Hello maintainers:
>
> when you have time, please help to check this patch whether is OK.
>
> thanks.
>
> gchen.
>
>
> On 2013?03?27? 15:23, Chen
On Sun, Apr 07, 2013 at 12:52:57PM +0200, Rafał Miłecki wrote:
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardware/firmware does the rest. In such a cases we need to read info
> from SAD blocks and put them i
---
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_hdmi.c
index 21ecc0e..91582a5 100644
--- a/drivers/gpu/drm
11 surfplank2 rsyslogd: [origin software="rsyslogd"
swVersion="5.8.10" x-pid="3041" x-info="http://www.rsyslog.com";] start
--
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/20130407/c7d09a30/attachment.html>
Am Sonntag, den 07.04.2013, 14:11 +0200 schrieb Rafał Miłecki:
> Thanks for comments!
>
> 2013/4/7 Paul Menzel :
> > Am Sonntag, den 07.04.2013, 12:52 +0200 schrieb Rafał Miłecki:
> >> +struct cea_sad *drm_edid_to_sad(struct edid *edid)
> >> +{
> >> + struct cea_sad *sads = NULL;
> >
> > No ne
Thanks for comments!
2013/4/7 Paul Menzel :
> Am Sonntag, den 07.04.2013, 12:52 +0200 schrieb Rafał Miłecki:
>> +struct cea_sad *drm_edid_to_sad(struct edid *edid)
>> +{
>> + struct cea_sad *sads = NULL;
>
> No need to set it NULL, as it gets assigned later on? Looks like in the
> end there is
Am Sonntag, den 07.04.2013, 12:52 +0200 schrieb Rafał Miłecki:
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
want to pass
> hardware but just require filling specific registers and then
at end: »then *the* hardware«
(I think)
> hardware/firmware does the rest. In such a c
Dear Chen,
Am Mittwoch, den 27.03.2013, 15:23 +0800 schrieb Chen Gang:
> need remove semicolon, or always return true.
do you know if this cause any problems? Did you find this reading the
code or by using some tools?
> Signed-off-by: Chen Gang
> ---
> drivers/gpu/drm/nouveau/nv50_display.c
2013/4/7 Rafał Miłecki :
> Some devices (ATI/AMD cards) don't want passing ELD struct to the
> hardware but just require filling specific registers and then
> hardware/firmware does the rest. In such a cases we need to read info
> from SAD blocks and put them in the correct registers.
If you wish
2013/4/7 Boszormenyi Zoltan :
> will there be a followup patch where this function is actually used?
Sure :) It's just early patch post, with RFC, to see if I'm doing it
the right way.
--
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Hi,
will there be a followup patch where this function is actually used?
Best regards,
Zoltán Böszörményi
2013-04-07 12:52 keltezéssel, Rafał Miłecki írta:
Some devices (ATI/AMD cards) don't want passing ELD struct to the
hardware but just require filling specific registers and then
hardware/f
Some devices (ATI/AMD cards) don't want passing ELD struct to the
hardware but just require filling specific registers and then
hardware/firmware does the rest. In such a cases we need to read info
from SAD blocks and put them in the correct registers.
---
drivers/gpu/drm/drm_edid.c | 55 +++
https://bugs.freedesktop.org/show_bug.cgi?id=62997
--- Comment #6 from udo ---
FWIW: Another lockup..
[ 9912.997377] nf_conntrack: automatic helper assignment is deprecated and it
will be removed soon. Use the iptables CT target to attach helpers instead.
[16500.596325] radeon :00:01.0: GPU
digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130407/1c4bddb8/attachment.pgp>
ay be useful.
Jacobo
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130407/f52f4687/attachment.html>
I was surprised that my BARTS in a Samsung notebook doesn't have a
RADEON_IS_IGP flag.
Are there any DCE5 devices that are IGP?
Btw. who does set that "flags" anyway? Flags are passed to the
radeon_driver_load_kms function from drm_pci.c:
dev->driver->load(dev, ent->driver_data);
(so driver_data
57 matches
Mail list logo
