Re: [Intel-gfx] Problems with Intel HD Graphics 3000 in Squeeze-based distro
On Sat, Feb 04, 2012 at 08:03:20PM +0400, Vitaliy Dovgan wrote: I have some problems with Intel HD Graphics 3000 video subsystem. I have found that video fails to display (while video's audio track goes on ok) in all the players I have (Totem, Xine, VLC and (S)Mplayer), leaving video area black during playback. However, Avidemux plays it back with no problems, and (S)Mplayer works too when using the x11 video output. Compiz don't work as well. I tried to uninstall the xserver-xorg-video-intel package, and it seemes like it solves the issue with video playback, but adds another one - losing in the dual-head functionality, leaving single screen for all the video heads. How can I solve this issue? Some details: Computer: Lenovo ThinkPad Edge E520 CPU: Intel Core i3-2330M Distro: AV Linux 5.0.2 (a custom shop modded and rodded 32bit multimedia system based on Debian Squeeze) Kernel: 3.0.16-avl-7-pae (custom-made for AV Linux) Packages: xserver-xorg-video-intel 2:2.13.0-6 This here is officially outdated (massively so) and it wouldn't be surprised that you'll experience tons of gpu hangs. Please upgrade to something modern. We generally fix so many bugs, especially for newer hw that anything than the latest released versions of libdrm, kernel, ddx and mesa is not advised. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't lock panel registers when downclocking
On Mon, Feb 13, 2012 at 10:13:02AM -0500, Sean Paul wrote: On Mon, Feb 13, 2012 at 5:08 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Feb 01, 2012 at 05:31:30PM -0500, Sean Paul wrote: This patch removes the locking from the downclock routines since we are no longer locking the registers at all. See ed10fca9 for the original commit changing this philosophy. Signed-off-by: Sean Paul seanp...@chromium.org I've thought this was due to paranoia because we don't trust our own code and because we don't trust the bios to randomly lock this again. Without any reasons to the contrary, I'll prefer to keep this. Thanks for the explanation, Daniel, however I'd ask that you reconsider this patch. The state coming into the downclock functions is unlocked and without this patch, the state coming out is locked. This causes at least one warning in the code from assert_panel_unlocked. Ah, that's a pretty important thing missing from the commit message. I've checked the code and we have indeed an issue there. Can you please: - Extend your commit message to mention that you're actually hitting the assert_panel_unlocked assert (and how this happens). Maybe explain that you need lvds downclocking, which is disabled by default. - Add an assert_panel_unlocked call instead of unlocking the panel in your patch (we do need to be paranoid about these things). Then I think your patch is good to go into -next. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] nasty suspend resume problem with sandybridge
On Mon, Feb 13, 2012 at 11:44:00AM +0100, Oleksij Rempel (Alexey Fisher) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.02.2012 11:18, schrieb Daniel Vetter: On Sat, Feb 04, 2012 at 07:17:01PM +0100, Oleksij Rempel (fishor) wrote: i do not know if this is really graphic related problem, so i need your help. even excluding some thing will help. Please take look at this bug: https://bugzilla.kernel.org/show_bug.cgi?id=42728 Judging from your ehci workaround I think your suspend/resume issue is not i915 related. You mention though somewhere that you also experience memory corruption issues after hibernat (assuming I've read the comments correctly). We are aware of memory corruptions issues due to i915.ko when hibernating, unfortunately no one has yet root-caused this. See e.g. https://bugs.freedesktop.org/show_bug.cgi?id=35648 thx, for the response. unfortunately this memory corruption appears not in S4, but after filed S3. Looks like some part entered S3 state and never come back, even after poweroff. I think it, because in some cases power-led blinking after poweroff - which indicate S3 state. Are there any thing to check to see what is misconfigured? I agree, that i915 is not the reason of this problem, but i915 make it impossible to get oops trace! Any chance to get it work? As already mentioned by Jesse in the bugzilla, just blacklist it. We don't really support nomodeset (because for things like suspend/resume it's actually impossible to properly support). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] nasty suspend resume problem with sandybridge
Am 13.02.2012 17:41, schrieb Daniel Vetter: On Mon, Feb 13, 2012 at 11:44:00AM +0100, Oleksij Rempel (Alexey Fisher) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.02.2012 11:18, schrieb Daniel Vetter: On Sat, Feb 04, 2012 at 07:17:01PM +0100, Oleksij Rempel (fishor) wrote: i do not know if this is really graphic related problem, so i need your help. even excluding some thing will help. Please take look at this bug: https://bugzilla.kernel.org/show_bug.cgi?id=42728 Judging from your ehci workaround I think your suspend/resume issue is not i915 related. You mention though somewhere that you also experience memory corruption issues after hibernat (assuming I've read the comments correctly). We are aware of memory corruptions issues due to i915.ko when hibernating, unfortunately no one has yet root-caused this. See e.g. https://bugs.freedesktop.org/show_bug.cgi?id=35648 thx, for the response. unfortunately this memory corruption appears not in S4, but after filed S3. Looks like some part entered S3 state and never come back, even after poweroff. I think it, because in some cases power-led blinking after poweroff - which indicate S3 state. Are there any thing to check to see what is misconfigured? I agree, that i915 is not the reason of this problem, but i915 make it impossible to get oops trace! Any chance to get it work? As already mentioned by Jesse in the bugzilla, just blacklist it. We don't really support nomodeset (because for things like suspend/resume it's actually impossible to properly support). -Daniel I did response on the bugzilla - blacklisting the module do not help. i get just black screen, no oops trace. Are there any way to get trace with modeset? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] nasty suspend resume problem with sandybridge
On Mon, Feb 13, 2012 at 17:53, Oleksij Rempel (fishor) bug-tr...@fisher-privat.net wrote: Am 13.02.2012 17:41, schrieb Daniel Vetter: On Mon, Feb 13, 2012 at 11:44:00AM +0100, Oleksij Rempel (Alexey Fisher) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.02.2012 11:18, schrieb Daniel Vetter: On Sat, Feb 04, 2012 at 07:17:01PM +0100, Oleksij Rempel (fishor) wrote: i do not know if this is really graphic related problem, so i need your help. even excluding some thing will help. Please take look at this bug: https://bugzilla.kernel.org/show_bug.cgi?id=42728 Judging from your ehci workaround I think your suspend/resume issue is not i915 related. You mention though somewhere that you also experience memory corruption issues after hibernat (assuming I've read the comments correctly). We are aware of memory corruptions issues due to i915.ko when hibernating, unfortunately no one has yet root-caused this. See e.g. https://bugs.freedesktop.org/show_bug.cgi?id=35648 thx, for the response. unfortunately this memory corruption appears not in S4, but after filed S3. Looks like some part entered S3 state and never come back, even after poweroff. I think it, because in some cases power-led blinking after poweroff - which indicate S3 state. Are there any thing to check to see what is misconfigured? I agree, that i915 is not the reason of this problem, but i915 make it impossible to get oops trace! Any chance to get it work? As already mentioned by Jesse in the bugzilla, just blacklist it. We don't really support nomodeset (because for things like suspend/resume it's actually impossible to properly support). -Daniel I did response on the bugzilla - blacklisting the module do not help. i get just black screen, no oops trace. Are there any way to get trace with modeset? Well, if you've checked that none of the i915, drm and intel-agp modules are loaded with lsmod there really shouldn't be any difference cause by modeset or nomodeset. I.e. if that's the case, your black screen is cause by a suspend/resume failure caused by another driver. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't lock panel registers when downclocking
This patch replaces the locking from the downclock routines with an assert
to ensure the registers are indeed unlocked. Without this patch, pre-SNB
devices would lock the registers when downclocking which would cause a
WARNING on suspend/resume with downclocking enabled.
Note: To hit this bug, you need to have lvds downclocking enabled.
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe71ed..33ef4f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6968,9 +6968,7 @@ static void intel_increase_pllclock(struct drm_crtc *crtc)
if (!HAS_PIPE_CXSR(dev) (dpll DISPLAY_RATE_SELECT_FPA1)) {
DRM_DEBUG_DRIVER(upclocking LVDS\n);
- /* Unlock panel regs */
- I915_WRITE(PP_CONTROL,
- I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+ assert_panel_unlocked(dev_priv, pipe);
dpll = ~DISPLAY_RATE_SELECT_FPA1;
I915_WRITE(dpll_reg, dpll);
@@ -6979,9 +6977,6 @@ static void intel_increase_pllclock(struct drm_crtc *crtc)
dpll = I915_READ(dpll_reg);
if (dpll DISPLAY_RATE_SELECT_FPA1)
DRM_DEBUG_DRIVER(failed to upclock LVDS!\n);
-
- /* ...and lock them again */
- I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) 0x3);
}
/* Schedule downclock */
@@ -7011,9 +7006,7 @@ static void intel_decrease_pllclock(struct drm_crtc *crtc)
if (!HAS_PIPE_CXSR(dev) intel_crtc-lowfreq_avail) {
DRM_DEBUG_DRIVER(downclocking LVDS\n);
- /* Unlock panel regs */
- I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) |
- PANEL_UNLOCK_REGS);
+ assert_panel_unlocked(dev_priv, pipe);
dpll |= DISPLAY_RATE_SELECT_FPA1;
I915_WRITE(dpll_reg, dpll);
@@ -7021,9 +7014,6 @@ static void intel_decrease_pllclock(struct drm_crtc *crtc)
dpll = I915_READ(dpll_reg);
if (!(dpll DISPLAY_RATE_SELECT_FPA1))
DRM_DEBUG_DRIVER(failed to downclock LVDS!\n);
-
- /* ...and lock them again */
- I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) 0x3);
}
}
--
1.7.7.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes
The git repo is right, but are you sure you are using the remotes/origin/interlaced branch? It is strange that you couldn't see any interlace mode without using the handmade modeline. On Mon, Feb 13, 2012 at 4:44 PM, Atechsystem atechsys...@freenet.de wrote: -Ursprüngliche Nachricht- Von: Atechsystem [mailto:atechsys...@freenet.de] Gesendet: Montag, 13. Februar 2012 19:44 An: 'Paulo Zanoni' Betreff: AW: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes Hi, thanks for your quick reply. Paulo Zanoni [mailto:przan...@gmail.com] Which git repo and which branch exactly? You may have a repo without the patches that fix interlaced modes. I compiled it from here: git://people.freedesktop.org/~danvet/drm Which line did you add to xorg.conf? What exactly did you do in this step? Please try to remove every xorg configuration file and test again with the default configuration I added for example: Modeline 1920x1080@50i 74.25 1920 2448 2492 2640 1080 1084 1094 1124 interlace +hsync +vsync Without a modeline I can't select interlace modes. Only 60Hz, 50Hz, 30Hz, 25Hz and 24Hz. Please attach the TV, then run xrandr --verbose and send us the output. Please also send the output of intel_reg_dumper: http://intellinuxgraphics.org/intel_reg_dumper.html Please find files attached. -Ursprüngliche Nachricht- Von: Paulo Zanoni [mailto:przan...@gmail.com] Gesendet: Montag, 13. Februar 2012 18:58 An: Atechsystem Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes Hi 2012/2/13 Atechsystem atechsys...@freenet.de: I compiled the kernel from your git repro to test interlaced output with my Clarkdale (H55) Chipset. Which git repo and which branch exactly? You may have a repo without the patches that fix interlaced modes. After installing and reboot I put the interlaced line to my xorg.conf and activate them (first by xorg.conf and after that by lxdm resolution set tool). Which line did you add to xorg.conf? What exactly did you do in this step? Please try to remove every xorg configuration file and test again with the default configuration I only get a screen full of colored stripes after switching from progressive to interlaced mode. My TV shows 1080i as input mode. After that I read all mode lines from my TV by using the xorg server log and tried every interlaced modeline I found but always the same striped screen. To get sure that I use correct modelines I checked them with an plugged in card from another brand and it works immediately. Please attach the TV, then run xrandr --verbose and send us the output. Please also send the output of intel_reg_dumper: http://intellinuxgraphics.org/intel_reg_dumper.html -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't lock panel registers when downclocking
On Mon, 13 Feb 2012 13:14:51 -0500
Sean Paul seanp...@chromium.org wrote:
This patch replaces the locking from the downclock routines with an assert
to ensure the registers are indeed unlocked. Without this patch, pre-SNB
devices would lock the registers when downclocking which would cause a
WARNING on suspend/resume with downclocking enabled.
Note: To hit this bug, you need to have lvds downclocking enabled.
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe71ed..33ef4f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6968,9 +6968,7 @@ static void intel_increase_pllclock(struct drm_crtc
*crtc)
if (!HAS_PIPE_CXSR(dev) (dpll DISPLAY_RATE_SELECT_FPA1)) {
DRM_DEBUG_DRIVER(upclocking LVDS\n);
- /* Unlock panel regs */
- I915_WRITE(PP_CONTROL,
-I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+ assert_panel_unlocked(dev_priv, pipe);
dpll = ~DISPLAY_RATE_SELECT_FPA1;
I915_WRITE(dpll_reg, dpll);
@@ -6979,9 +6977,6 @@ static void intel_increase_pllclock(struct drm_crtc
*crtc)
dpll = I915_READ(dpll_reg);
if (dpll DISPLAY_RATE_SELECT_FPA1)
DRM_DEBUG_DRIVER(failed to upclock LVDS!\n);
-
- /* ...and lock them again */
- I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) 0x3);
}
/* Schedule downclock */
@@ -7011,9 +7006,7 @@ static void intel_decrease_pllclock(struct drm_crtc
*crtc)
if (!HAS_PIPE_CXSR(dev) intel_crtc-lowfreq_avail) {
DRM_DEBUG_DRIVER(downclocking LVDS\n);
- /* Unlock panel regs */
- I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) |
-PANEL_UNLOCK_REGS);
+ assert_panel_unlocked(dev_priv, pipe);
dpll |= DISPLAY_RATE_SELECT_FPA1;
I915_WRITE(dpll_reg, dpll);
@@ -7021,9 +7014,6 @@ static void intel_decrease_pllclock(struct drm_crtc
*crtc)
dpll = I915_READ(dpll_reg);
if (!(dpll DISPLAY_RATE_SELECT_FPA1))
DRM_DEBUG_DRIVER(failed to downclock LVDS!\n);
-
- /* ...and lock them again */
- I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) 0x3);
}
}
Yeah, looks good.
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes
Von: Paulo Zanoni [mailto:przan...@gmail.com] Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued I will compile it now. Before I used the drm-intel-next branch. I downloaded the latest tar.gz file and didn't use git to checkout the branch. Rodrigo Vivi [mailto:rodrigo.v...@gmail.com] The git repo is right, but are you sure you are using the remotes/origin/interlaced branch? It is strange that you couldn't see any interlace mode without using the handmade modeline. No chance to select it directly. I 've no clue to select it by standard lxde dialog. -Ursprüngliche Nachricht- Von: Paulo Zanoni [mailto:przan...@gmail.com] Gesendet: Montag, 13. Februar 2012 19:56 An: Atechsystem Cc: Intel Graphics Development Betreff: Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes 2012/2/13 Atechsystem atechsys...@freenet.de: I compiled it from here: git://people.freedesktop.org/~danvet/drm Did you change to the interlaced branch? Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued (repository is drm-intel and branch is drm-intel-next-queued). I added for example: Modeline 1920x1080@50i 74.25 1920 2448 2492 2640 1080 1084 1094 1124 interlace +hsync +vsync Without a modeline I can't select interlace modes. Only 60Hz, 50Hz, 30Hz, 25Hz and 24Hz. This should not be needed. If you have the correct branch, you don't need any configuration tweak: just boot the machine, plug a monitor that supports interlaced modes, and xrandr --verbose will show you some interlaced modes. Please confirm that you are using the correct branch first. Use git log or git branch commands to check. -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add a force-dvi HDMI audio mode
On Wed, Feb 08, 2012 at 10:48:20AM +0800, Wu Fengguang wrote:
When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new force-dvi audio mode:
xrandr --output HDMI1 --set audio force-dvi
Note that most users won't need to set this and happily rely on the
EDID based DVI auto detection.
Reported-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
Jesse acked this patch on irc, but I've noticed a few little things. See
below for the details.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h|7 +++
drivers/gpu/drm/i915/intel_hdmi.c |8 +---
drivers/gpu/drm/i915/intel_modes.c |4 +++-
3 files changed, 15 insertions(+), 4 deletions(-)
--- linux-next.orig/drivers/gpu/drm/i915/i915_drv.h 2012-01-31
20:44:59.0 +0800
+++ linux-next/drivers/gpu/drm/i915/i915_drv.h2012-02-08
10:37:30.0 +0800
@@ -749,6 +749,13 @@ typedef struct drm_i915_private {
struct drm_property *force_audio_property;
} drm_i915_private_t;
+enum hdmi_force_audio {
+ HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
+ HDMI_AUDIO_OFF, /* force turn off HDMI audio */
+ HDMI_AUDIO_AUTO,/* trust EDID */
+ HDMI_AUDIO_ON, /* force turn on HDMI audio */
+};
+
enum i915_cache_level {
I915_CACHE_NONE,
I915_CACHE_LLC,
--- linux-next.orig/drivers/gpu/drm/i915/intel_hdmi.c 2012-01-07
20:47:34.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_hdmi.c 2012-02-08
10:37:30.0 +0800
@@ -339,7 +339,9 @@ intel_hdmi_detect(struct drm_connector *
if (edid) {
if (edid-input DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
- intel_hdmi-has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
+ if (intel_hdmi-force_audio != HDMI_AUDIO_OFF_DVI)
+ intel_hdmi-has_hdmi_sink =
+ drm_detect_hdmi_monitor(edid);
intel_hdmi-has_audio = drm_detect_monitor_audio(edid);
}
connector-display_info.raw_edid = NULL;
@@ -415,8 +417,8 @@ intel_hdmi_set_property(struct drm_conne
else
has_audio = i 0;
All these comparison with i use magic values instead of your new enum
definitions. Can you replace these with the enums like you've done below,
i.e. for the above if block:
if (i == HDMI_AUDIO_AUOT)
...
else if (i == HDMI_AUDIO_ON)
has_audio = true;
intel_hdmi_detect is also a place that checks these values (with
intel_hdmi-force_audio) - please use the enum values there, too. Also
please change the type of intel_hdmi-force_audio from int to the enum.
Another thing I've noticed is that in intel_hdmi_detect you don't force
has_hdmi_sink to false if the force_dvi option is set.
- if (has_audio == intel_hdmi-has_audio)
- return 0;
+ if (i == HDMI_AUDIO_OFF_DVI)
+ intel_hdmi-has_hdmi_sink = 0;
intel_hdmi-has_audio = has_audio;
goto done;
--- linux-next.orig/drivers/gpu/drm/i915/intel_modes.c2011-10-19
11:11:20.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_modes.c 2012-02-08
10:37:30.0 +0800
@@ -84,6 +84,7 @@ int intel_ddc_get_modes(struct drm_conne
}
static const char *force_audio_names[] = {
+ force-dvi,
off,
auto,
on,
@@ -106,7 +107,8 @@ intel_attach_force_audio_property(struct
return;
for (i = 0; i ARRAY_SIZE(force_audio_names); i++)
- drm_property_add_enum(prop, i, i-1,
force_audio_names[i]);
+ drm_property_add_enum(prop, i, i-2,
+ force_audio_names[i]);
dev_priv-force_audio_property = prop;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] nasty suspend resume problem with sandybridge
Am 13.02.2012 19:52, schrieb Daniel Vetter: On Mon, Feb 13, 2012 at 07:42:03PM +0100, Oleksij Rempel (Alexey Fisher) wrote: Am 13.02.2012 18:06, schrieb Daniel Vetter: Well, if you've checked that none of the i915, drm and intel-agp modules are loaded with lsmod there really shouldn't be any difference cause by modeset or nomodeset. I.e. if that's the case, your black screen is cause by a suspend/resume failure caused by another driver. -Daniel ufff... again not understood. i know this issue isn't fault of intel graphic with my older intel laptop i was able to get oops trace in such case. With new intel hardware i get blank screen with cursor in left top corner. Instead of cursor i expect oops trace! Is it possible? If not please say so. If yes, then is is a bug. Well, I'm not a suspend/resume expert, so I don't quite know whether you should get an oops. Also the bios might do funky stuff or the suspend/resume ordering changed meanwhile. So I have no idea :( -Daniel ok, thx. then i will need to look for other way to get some debug info. I have this port on my laptop: https://bugzilla.kernel.org/attachment.cgi?id=72351 do you accidental know some thing about it? -- Regards, Alexey ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] WG: Interlaced mode on intel Clarkdale only colored stripes
Hello, Von: Paulo Zanoni [mailto:przan...@gmail.com] Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued Thanks, compiling from this repro solved my problem. With my TV I have to use the xorg modeline, without it I can't select the interlaced modes. If I use my NEC monitor I can select the I modeline by using the lxde monitor setting tool. I think my TV don't report the I modelines. Thanks for this patch Regards Atech -Ursprüngliche Nachricht- Von: intel-gfx-bounces+atechsystem=freenet...@lists.freedesktop.org [mailto:intel-gfx-bounces+atechsystem=freenet...@lists.freedesktop.org] Im Auftrag von Atechsystem Gesendet: Montag, 13. Februar 2012 20:05 An: 'Paulo Zanoni' Cc: intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes Von: Paulo Zanoni [mailto:przan...@gmail.com] Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-que ued I will compile it now. Before I used the drm-intel-next branch. I downloaded the latest tar.gz file and didn't use git to checkout the branch. Rodrigo Vivi [mailto:rodrigo.v...@gmail.com] The git repo is right, but are you sure you are using the remotes/origin/interlaced branch? It is strange that you couldn't see any interlace mode without using the handmade modeline. No chance to select it directly. I 've no clue to select it by standard lxde dialog. -Ursprüngliche Nachricht- Von: Paulo Zanoni [mailto:przan...@gmail.com] Gesendet: Montag, 13. Februar 2012 19:56 An: Atechsystem Cc: Intel Graphics Development Betreff: Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes 2012/2/13 Atechsystem atechsys...@freenet.de: I compiled it from here: git://people.freedesktop.org/~danvet/drm Did you change to the interlaced branch? Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued (repository is drm-intel and branch is drm-intel-next-queued). I added for example: Modeline 1920x1080@50i 74.25 1920 2448 2492 2640 1080 1084 1094 1124 interlace +hsync +vsync Without a modeline I can't select interlace modes. Only 60Hz, 50Hz, 30Hz, 25Hz and 24Hz. This should not be needed. If you have the correct branch, you don't need any configuration tweak: just boot the machine, plug a monitor that supports interlaced modes, and xrandr --verbose will show you some interlaced modes. Please confirm that you are using the correct branch first. Use git log or git branch commands to check. -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] WG: Interlaced mode on intel Clarkdale only colored stripes
I'm glad that it is working for you now! Yes, the drm-intel-next-queued has all the interlaced patches that were in remotes/origin/interlaced. I don't think your tv doesn't report the interlaced modes, but the modes it reports are the CEA modes we aren't supporting yet. It is on my todo list take a carefully look at this modes. Cheers, Rodrigo. On Mon, Feb 13, 2012 at 6:44 PM, Atechsystem atechsys...@freenet.de wrote: Hello, Von: Paulo Zanoni [mailto:przan...@gmail.com] Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued Thanks, compiling from this repro solved my problem. With my TV I have to use the xorg modeline, without it I can't select the interlaced modes. If I use my NEC monitor I can select the I modeline by using the lxde monitor setting tool. I think my TV don't report the I modelines. Thanks for this patch Regards Atech -Ursprüngliche Nachricht- Von: intel-gfx-bounces+atechsystem=freenet...@lists.freedesktop.org [mailto:intel-gfx-bounces+atechsystem=freenet...@lists.freedesktop.org] Im Auftrag von Atechsystem Gesendet: Montag, 13. Februar 2012 20:05 An: 'Paulo Zanoni' Cc: intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes Von: Paulo Zanoni [mailto:przan...@gmail.com] Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-que ued I will compile it now. Before I used the drm-intel-next branch. I downloaded the latest tar.gz file and didn't use git to checkout the branch. Rodrigo Vivi [mailto:rodrigo.v...@gmail.com] The git repo is right, but are you sure you are using the remotes/origin/interlaced branch? It is strange that you couldn't see any interlace mode without using the handmade modeline. No chance to select it directly. I 've no clue to select it by standard lxde dialog. -Ursprüngliche Nachricht- Von: Paulo Zanoni [mailto:przan...@gmail.com] Gesendet: Montag, 13. Februar 2012 19:56 An: Atechsystem Cc: Intel Graphics Development Betreff: Re: [Intel-gfx] Interlaced mode on intel Clarkdale only colored stripes 2012/2/13 Atechsystem atechsys...@freenet.de: I compiled it from here: git://people.freedesktop.org/~danvet/drm Did you change to the interlaced branch? Maybe the best tree to test is this: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued (repository is drm-intel and branch is drm-intel-next-queued). I added for example: Modeline 1920x1080@50i 74.25 1920 2448 2492 2640 1080 1084 1094 1124 interlace +hsync +vsync Without a modeline I can't select interlace modes. Only 60Hz, 50Hz, 30Hz, 25Hz and 24Hz. This should not be needed. If you have the correct branch, you don't need any configuration tweak: just boot the machine, plug a monitor that supports interlaced modes, and xrandr --verbose will show you some interlaced modes. Please confirm that you are using the correct branch first. Use git log or git branch commands to check. -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add a force-dvi HDMI audio mode
On Mon, Feb 13, 2012 at 08:22:01PM +0100, Daniel Vetter wrote:
On Wed, Feb 08, 2012 at 10:48:20AM +0800, Wu Fengguang wrote:
When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new force-dvi audio mode:
xrandr --output HDMI1 --set audio force-dvi
Note that most users won't need to set this and happily rely on the
EDID based DVI auto detection.
Reported-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
Jesse acked this patch on irc, but I've noticed a few little things. See
below for the details.
OK, thanks!
--- linux-next.orig/drivers/gpu/drm/i915/intel_hdmi.c 2012-01-07
20:47:34.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_hdmi.c2012-02-08
10:37:30.0 +0800
@@ -339,7 +339,9 @@ intel_hdmi_detect(struct drm_connector *
if (edid) {
if (edid-input DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
- intel_hdmi-has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
+ if (intel_hdmi-force_audio != HDMI_AUDIO_OFF_DVI)
+ intel_hdmi-has_hdmi_sink =
+ drm_detect_hdmi_monitor(edid);
intel_hdmi-has_audio = drm_detect_monitor_audio(edid);
}
connector-display_info.raw_edid = NULL;
@@ -415,8 +417,8 @@ intel_hdmi_set_property(struct drm_conne
else
has_audio = i 0;
All these comparison with i use magic values instead of your new enum
definitions. Can you replace these with the enums like you've done below,
i.e. for the above if block:
if (i == HDMI_AUDIO_AUOT)
...
else if (i == HDMI_AUDIO_ON)
has_audio = true;
Done.
intel_hdmi_detect is also a place that checks these values (with
intel_hdmi-force_audio) - please use the enum values there, too. Also
please change the type of intel_hdmi-force_audio from int to the enum.
Done.
Another thing I've noticed is that in intel_hdmi_detect you don't force
has_hdmi_sink to false if the force_dvi option is set.
It's implicitly initialized to false at the beginning. Isn't that enough?
Updated patch follows. Compile tested.
Thanks,
Fengguang
---
Subject: drm/i915: add an force-dvi HDMI audio mode
Date: Fri Jan 06 11:04:00 CST 2012
When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new force-dvi audio mode:
xrandr --output HDMI1 --set audio force-dvi
Note that most users won't need to set this and happily rely on the EDID
based DVI auto detection.
Reported-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|7 +++
drivers/gpu/drm/i915/intel_hdmi.c | 21 -
drivers/gpu/drm/i915/intel_modes.c |4 +++-
3 files changed, 22 insertions(+), 10 deletions(-)
--- linux-next.orig/drivers/gpu/drm/i915/i915_drv.h 2012-02-08
18:44:59.0 +0800
+++ linux-next/drivers/gpu/drm/i915/i915_drv.h 2012-02-14 11:21:03.0
+0800
@@ -749,6 +749,13 @@ typedef struct drm_i915_private {
struct drm_property *force_audio_property;
} drm_i915_private_t;
+enum hdmi_force_audio {
+ HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
+ HDMI_AUDIO_OFF, /* force turn off HDMI audio */
+ HDMI_AUDIO_AUTO,/* trust EDID */
+ HDMI_AUDIO_ON, /* force turn on HDMI audio */
+};
+
enum i915_cache_level {
I915_CACHE_NONE,
I915_CACHE_LLC,
--- linux-next.orig/drivers/gpu/drm/i915/intel_hdmi.c 2012-02-08
18:44:59.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_hdmi.c2012-02-14
11:25:16.0 +0800
@@ -44,7 +44,7 @@ struct intel_hdmi {
uint32_t color_range;
bool has_hdmi_sink;
bool has_audio;
- int force_audio;
+ enum hdmi_force_audio force_audio;
void (*write_infoframe)(struct drm_encoder *encoder,
struct dip_infoframe *frame);
};
@@ -339,7 +339,9 @@ intel_hdmi_detect(struct drm_connector *
if (edid) {
if (edid-input DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
- intel_hdmi-has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
+ if (intel_hdmi-force_audio != HDMI_AUDIO_OFF_DVI)
+ intel_hdmi-has_hdmi_sink =
+
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable plain RC6 on Sandy Bridge by default
#part sign=pgpmime On Sun, 12 Feb 2012 22:34:48 -0200, Eugeni Dodonov eug...@dodonov.net wrote: what if we pick only the 1st patch in this series for -fixes? It won't change the defaults in any way, but it will allow the ones willing to enable it manually on SNB to prevent issues. That seems like too big a change at this point in the release cycle. We should be focused purely on fixing functionality bugs, not adding new features. So, instead of adding the ability to individually control RC6 levels, we should just change what RC6 does on SNB when it is enabled, then encourage people to test that and see if the shallowest RC6 states actually work. That will provide sufficient information to know whether it will be safe to turn that on by default in the next release, which is what we really want. The smallest change that gives us the data we need is what I'd like to have. -- keith.pack...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Television turns greenish after stand-by
-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: 13 February 2012 09:32 All interlaced patches including the TRANSCONF patch from Paulo have been merged to drm-intel-next-queued in my official drm-intel repo at: http://cgit.freedesktop.org/~danvet/drm-intel/ Hello Daniel I can't fetch from the repository. git remote -v daniel git://people.freedesktop.org/~danvet/drm (fetch) daniel git://people.freedesktop.org/~danvet/drm (push) drm-intel http://cgit.freedesktop.org/~danvet/drm-intel (fetch) drm-intel http://cgit.freedesktop.org/~danvet/drm-intel (push) origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch) origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push) git fetch drm-intel error: Unable to find 396ee23db6b76354e487fd2cfdacbd989442f81d under http://cgit.freedesktop.org/~danvet/drm-intel Cannot obtain needed object 396ee23db6b76354e487fd2cfdacbd989442f81d error: Fetch failed. And with git clone http://cgit.freedesktop.org/~danvet/drm-intel Cloning into drm-intel... warning: remote HEAD refers to nonexistent ref, unable to checkout. What is wrong ? Angela ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
