On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann wrote:
> Hi
>
> On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote:
>> Hi David,
>>
>> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote:
>>> On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann
>>> wrote:
Attached are two patches. The first on
Hi David,
On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann wrote:
> Hi
>
> On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote:
>> Hi
>>
>> With the upcoming 3.12 merge-window, I thought people might find themselves
>> with
>> nothing to do, so here's a new SimpleDRM series. Comments welcome!
>>
On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote:
> Just for consistency.
>
> Signed-off-by: Damien Lespiau
Afaik kernel coding style is to echew typdefs for normal structures as
much as possible. The only exception is for truly opaque types used in
abstractions, like dma_addr_t or
On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson wrote:
> On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote:
>> Follow up of:
>> http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html
>>
>> Let's try again! This time, intead of a magic connector property to select if
Here are a couple of patches that get kexec working with radeon devices.
I've tested this on my RS780.
Comments or flames are welcome.
Thanks.
Markus Trippelsdorf (3):
kexec: get rid of late printk
drm/radeon: Implement radeon_pci_shutdown
drm/radeon: get rid of r100_restore_sanity hack
d
kexec calls:
printk(KERN_EMERG "Starting new kernel\n");
late before calling machine_shutdown().
However at this point the underlying fb device may have already been
shutdown. This causes the kernel to hang.
Fix by simply getting rid of the printk call.
Signed-off-by: Markus Trippelsdorf
---
ke
Currently radeon devices are not properbly shutdown during kexec. This
cases a varity of issues, e.g. dpm initialization failures.
Fix this by implementing a radeon_pci_shutdown function, that unloads
the driver cleanly.
Signed-off-by: Markus Trippelsdorf
---
drivers/gpu/drm/radeon/radeon_drv.c
Now that radeon devices are properly shutdown during kexec, we can get
rid of r100_restore_sanity.
Signed-off-by: Markus Trippelsdorf
---
drivers/gpu/drm/radeon/r100.c| 27 ---
drivers/gpu/drm/radeon/r300.c| 2 --
drivers/gpu/drm/radeon/r420.c| 2
https://bugs.freedesktop.org/show_bug.cgi?id=67800
Kertesz Laszlo changed:
What|Removed |Added
Summary|Computer freezes after idle |Computer freezes several
Hi
On Sun, Sep 8, 2013 at 1:33 PM, Tom Gundersen wrote:
> Hi David,
>
> On Wed, Sep 4, 2013 at 7:34 PM, David Herrmann wrote:
>> Hi
>>
>> On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote:
>>> Hi
>>>
>>> With the upcoming 3.12 merge-window, I thought people might find themselves
>>> with
>>
Hi
On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau wrote:
> It's a tiny bit more logical to find the different capabilities you can
> use with the GET_CAP ioctl next to the structure rather than putting
> them at the end of the file.
>
> Signed-off-by: Damien Lespiau
> ---
> include/uapi/drm/drm
Hi
On Sun, Sep 8, 2013 at 1:59 PM, Daniel Vetter wrote:
> On Fri, Sep 6, 2013 at 9:11 PM, Chris Wilson wrote:
>> On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote:
>>> Follow up of:
>>> http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html
>>>
>>> Let's try aga
Hi
On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau wrote:
> This capability allows user space to control the delivery of modes with
> the 3D flags set. This is to not play games with current user space
> users not knowing anything about stereo 3D flags and that could try
> to set a mode with one o
On Sun, Sep 08, 2013 at 03:50:29PM +0200, David Herrmann wrote:
> Hi
>
> On Fri, Sep 6, 2013 at 8:57 PM, Damien Lespiau
> wrote:
> > This capability allows user space to control the delivery of modes with
> > the 3D flags set. This is to not play games with current user space
> > users not knowi
On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote:
> The series implements SET_CAP as a per _file_ capability set, not per
> master. I like it this way. Note that with SET_VERSION, we already
> have a per _master_ capability set. Compared to SET_CAP it only allows
> incremental capabil
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #17 from Brian Hall ---
Fixed it!
The problem was in atom.c, my bisect was correct. Starting with the bad 3.10.5
atom.c, I copied it into the good 3.10.4 tree, commented out the reset data
block part, rebuilt, and that fixed it. Comme
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #18 from Brian Hall ---
Created attachment 107621
--> https://bugzilla.kernel.org/attachment.cgi?id=107621&action=edit
fixes radeon DVI display corruption
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=61011
Bug ID: 61011
Summary: Radeon Screen Corruption since merged patch of Bug
60639
Product: Drivers
Version: 2.5
Kernel Version: 3.10.5
Hardware: All
OS: Li
https://bugzilla.kernel.org/show_bug.cgi?id=61011
--- Comment #1 from hams...@freenet.de ---
Created attachment 107651
--> https://bugzilla.kernel.org/attachment.cgi?id=107651&action=edit
dmesg output from working kernel
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=61011
--- Comment #2 from hams...@freenet.de ---
Created attachment 107661
--> https://bugzilla.kernel.org/attachment.cgi?id=107661&action=edit
Xorg0.log output from working kernel
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=61011
--- Comment #3 from hams...@freenet.de ---
Created attachment 107671
--> https://bugzilla.kernel.org/attachment.cgi?id=107671&action=edit
dmesg output from non working kernel
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=61011
--- Comment #4 from hams...@freenet.de ---
Created attachment 107681
--> https://bugzilla.kernel.org/attachment.cgi?id=107681&action=edit
Xorg0.log output from non working kernel
--
You are receiving this mail because:
You are watching the assi
https://bugzilla.kernel.org/show_bug.cgi?id=61011
hams...@freenet.de changed:
What|Removed |Added
See Also||https://bugzilla.kernel.org
On Sun, Sep 08, 2013 at 01:58:29PM +0200, Daniel Vetter wrote:
> On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote:
> > Just for consistency.
> >
> > Signed-off-by: Damien Lespiau
>
> Afaik kernel coding style is to echew typdefs for normal structures as
> much as possible. The only
On Sun, Sep 8, 2013 at 9:36 PM, Damien Lespiau wrote:
> On Sun, Sep 08, 2013 at 01:58:29PM +0200, Daniel Vetter wrote:
>> On Fri, Sep 06, 2013 at 07:57:19PM +0100, Damien Lespiau wrote:
>> > Just for consistency.
>> >
>> > Signed-off-by: Damien Lespiau
>>
>> Afaik kernel coding style is to echew
On Sun, Sep 8, 2013 at 5:03 PM, Damien Lespiau wrote:
> On Sun, Sep 08, 2013 at 03:46:43PM +0200, David Herrmann wrote:
>> The series implements SET_CAP as a per _file_ capability set, not per
>> master. I like it this way. Note that with SET_VERSION, we already
>> have a per _master_ capability s
On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf
wrote:
> kexec calls:
> printk(KERN_EMERG "Starting new kernel\n");
> late before calling machine_shutdown().
> However at this point the underlying fb device may have already been
> shutdown. This causes the kernel to hang.
> Fix by simply gett
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #16 from Peter Kraus ---
Hi there,
any update on this one? Can I / do I need to test anything? It's a bit of a
bummer...
Or is this a bug in Dota?
The behaviour is there also with linux-3.11.
Peter
--
You are receiving this mail
On Sun, 08 September 2013 Daniel Vetter wrote:
> On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf
> wrote:
> > kexec calls:
> > printk(KERN_EMERG "Starting new kernel\n");
> > late before calling machine_shutdown().
> > However at this point the underlying fb device may have already been
> >
https://bugzilla.kernel.org/show_bug.cgi?id=61011
--- Comment #5 from Alex Deucher ---
This is a duplicate of bug 60791.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freed
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #19 from Alex Deucher ---
Please attach a copy of your vbios.
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
--
You are receiving this mail because:
You are watchi
https://bugs.freedesktop.org/show_bug.cgi?id=69120
Priority: medium
Bug ID: 69120
Assignee: dri-devel@lists.freedesktop.org
Summary: With dpm=1 vdpau is not usable
Severity: normal
Classification: Unclassified
OS: Linux (All)
https://bugzilla.kernel.org/show_bug.cgi?id=60791
--- Comment #20 from Brian Hall ---
Created attachment 107711
--> https://bugzilla.kernel.org/attachment.cgi?id=107711&action=edit
copy of video bios
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #1 from Dieter Nützel ---
Hello John,
I see nearly the same with all 3.11-rcX and final plus 3.12-next.
Only diffence with dpm=0 I get partially mosaic with bigger videos (1280x720
H.264 and 1920x1080 H.264) from time to time.
But m
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #2 from Dieter Nützel ---
Created attachment 85467
--> https://bugs.freedesktop.org/attachment.cgi?id=85467&action=edit
dmesg-3.11-dmp-1-two-displays.log
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #3 from Dieter Nützel ---
Created attachment 85468
--> https://bugs.freedesktop.org/attachment.cgi?id=85468&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #4 from Dieter Nützel ---
Created attachment 85469
--> https://bugs.freedesktop.org/attachment.cgi?id=85469&action=edit
copy of video bios
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #5 from Dieter Nützel ---
# radeontool regmatch 0x0718
0x0718 0x20010002 (536936450)
# radeontool regmatch 0x071c
0x071c 0x021f2111 (35594513)
# radeontool regmatch 0x0720
0x0720 0x102774da (271021274)
01:00.0 VGA compatible con
https://bugs.freedesktop.org/show_bug.cgi?id=67800
Kertesz Laszlo changed:
What|Removed |Added
Summary|Computer freezes several|Computer freezes after
https://bugs.freedesktop.org/show_bug.cgi?id=67800
--- Comment #13 from Kertesz Laszlo ---
The freezes are still happening, both with kernel 3.11 stable or the later git
versions, mesa 9.2 stable or with the 9.3 devel git.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #45 from Aaron Watry ---
(In reply to comment #43)
> I patched llvm with
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184089.
> html
>
> using
>
> patch -N -p1 -i p2.patch
>
> But still got lock-ups.
>
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #46 from Aaron Watry ---
Autocorrect got the best of me... s/radeonsi/radeon/g
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-dev
On Sun, Sep 8, 2013 at 9:25 PM, Pali Rohár wrote:
> On Wednesday 21 August 2013 02:24:01 Ben Skeggs wrote:
>> On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár
> wrote:
>> > On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
>> >> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> >> introduced
https://bugzilla.kernel.org/show_bug.cgi?id=61011
hams...@freenet.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=60791
hams...@freenet.de changed:
What|Removed |Added
CC||hams...@freenet.de
--- Comment #21 fr
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #6 from John ---
Hello Dieter,
thanks for the suggestions.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #7 from John ---
Created attachment 85476
--> https://bugs.freedesktop.org/attachment.cgi?id=85476&action=edit
John's vbios
--
You are receiving this mail because:
You are the assignee for the bug.
On Sun, Sep 8, 2013 at 10:33 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> This has received light testing on NV18 and NV34 cards, using the modetest
> tool. Userspace support to use this for xv is not yet ready.
>
> I decided against creating a new "pvideo" engine -- that just se
On Wed, Sep 4, 2013 at 10:37 PM, Maarten Lankhorst
wrote:
> Op 04-09-13 05:21, Ben Skeggs schreef:
>> On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
>> wrote:
>>> This increases the chance slightly that recovery from lockup can happen
>>> succesfully.
>> I'd *really* love to see proof of this
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #20 from Weber K. ---
Here is what Ive got!
If this dont help, please give me more details and I will try my best!
Thanks in advance!
xf86-video-ati 6.14.4
xorg-server 1.12.4
Program received signal SIGSEGV, Segmentation fault.
0x000
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #7 from Pinak Ahuja ---
Is there anything i can do to check that my BIOS is buggy.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing li
51 matches
Mail list logo
