re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140131/47477f8c/attachment-0001.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140131/dca6f006/attachment.html>
|--- |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/20140131/fcfa6e9f/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140131/5097856a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #28 from Alex Deucher ---
Created attachment 124051
--> https://bugzilla.kernel.org/attachment.cgi?id=124051&action=edit
return IRQ_NONE if we don't have any interrupts
Does the attached patch help? Dave suggested it might be inter
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #27 from Christoph Haag ---
It does get to the end of radeon_pmops_runtime_idle every time (checked right
before the return) and crtc->enabled is never true.
--
You are receiving this mail because:
You are watching the assignee of th
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #26 from Alex Deucher ---
Can you see how far it's getting in runtime_idle()? Does it get all the way to
the end or does it think a crtc is active?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #25 from Christoph Haag ---
Created attachment 124041
--> https://bugzilla.kernel.org/attachment.cgi?id=124041&action=edit
just some printk to easily see what's going on
Well, I don't really know how it is supposed to work. I figure
ting this from!
--
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/20140131/4bc8a0e9/attachment-0001.html>
The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE.
While at it, add a #define for MAX_DSLP and make the message a bit more
informative.
v2: use DRM_INFO_ONCE, add MAX_DSLP, pimp the message.
Suggested-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregio
Just like DRM_INFO(), but only do it once.
Signed-off-by: Jani Nikula
---
include/drm/drmP.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 04086c5be930..04a7f31301f8 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -199,6 +199,
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #11 from Jan Outhuis ---
Took a linux-master.zip from here: https://github.com/torvalds/linux.
That was as close as I could get to 3.14.0-rc1. Don't know if this is
the right place.
Anyhow, can't report any improvement with this new c
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #24 from Alex Deucher ---
The kernel runtime pm infrastructure is used. See radeon_drv.c in the kernel.
The driver registers a struct dev_pm_ops structure with the pm core. The pm
core will then suspend and resume the device on dema
On Fri, Jan 31, 2014 at 03:49:08PM +0200, Jani Nikula wrote:
> The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE.
>
> While at it, add a #define for MAX_DSLP and make the message a bit more
> informative.
>
> v2: use DRM_INFO_ONCE, add MAX_DSLP, pimp the message.
>
> Suggested-by: Chri
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140131/b5f1be49/attachment-0001.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140131/30f071e8/attachment-0001.html>
ng 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/20140131/f7a00706/attachment-0001.html>
Hi Josh,
On 30 January 2014 22:17, Josh Boyer wrote:
> Hi All,
>
> After the DRM merge, the exynos_hdmi.c file fails to build with our
> ARM config. The error is:
>
> drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe'
> defined as wrong kind of tag
> struct hdmi_infoframe {
>
?hdmi_infoframe? is already defined in include/linux/hdmi.h.
Rename the local variable to avoid the following build error:
drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: ?hdmi_infoframe? defined as
wrong kind of tag
struct hdmi_infoframe {
Signed-off-by: Sachin Kamat
Reported-by: Josh Boyer
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #17 from kilobug at kilobug.org ---
I have a PCIExpress 2.0 board (and the lockups), but I have an Intel CPU. Not
sure it could be linked to Intel CPU vs AMD CPU, or something else related to
the motherboard. I can include a dmidecode o
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #16 from perry3d at gmail.com ---
I forgot to say: the problem started after i switched my board & CPU a week
ago.
Now i use a gigabyte h87-hd3 board with an intel xeon e3-1230v3 CPU. Before it
was an AMD CPU with an Foxconn A7DA-S boar
On Fri, Jan 31, 2014 at 1:09 AM, Sachin Kamat
wrote:
> 'hdmi_infoframe' is already defined in include/linux/hdmi.h.
> Rename the local variable to avoid the following build error:
> drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe' defined
> as wrong kind of tag
> struct hdmi_
On Thu, Jan 30, 2014 at 6:46 PM, Stefan Demharter
wrote:
> Saves the current state of the mux and restores it upon resume from
> hibernation.
> This is needed for muxed systems because the state of the mux doesn't survive
> a
> hibernation-resume cycle. Furthermore also restores the power state
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140131/0e6a8d0b/attachment.html>
Saves the current state of the mux and restores it upon resume from hibernation.
This is needed for muxed systems because the state of the mux doesn't survive a
hibernation-resume cycle. Furthermore also restores the power state of a GPU
to OFF after resume from hibernation if it was OFF before hib
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #15 from perry3d at gmail.com ---
Created attachment 123901
--> https://bugzilla.kernel.org/attachment.cgi?id=123901&action=edit
dmesg with two gpu lockups
Hi,
i think i got the same problem with kernel 3.13 on an arch distro and dp
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #23 from Christoph Haag ---
Created attachment 123891
--> https://bugzilla.kernel.org/attachment.cgi?id=123891&action=edit
quitting steam after some time
So maybe radeon-profile shows garbage, but in the steam client I have found on
27 matches
Mail list logo
