date:20111110

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Wu Fengguang

On Thu, Nov 10, 2011 at 03:55:22PM +0800, Wu Fengguang wrote:
 On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
  Wow I reproduced the bug and got a very interesting dmesg:
  
  gfx =[ 4561.287980] [drm:intel_write_eld], ELD on 
  [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
  gfx =[ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
  gfx =[ 4561.293804] [drm:ironlake_write_eld], Audio directed to 
  unknown port
  gfx =[ 4561.295273] [drm:ironlake_write_eld],
alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 
  Presence_Detect=1 ELD_Valid=0
alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
  ELD_Valid=0
  gfx =[ 4561.300020] ELD size 13
alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 
  Presence_Detect=1 ELD_Valid=1
alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
  ELD_Valid=1
alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0

  Hey the two parts are interleaved!
  
  But still it should work all fine, since the gfx driver does
  
  set ELD_Valid = 0
  write ELD
  set ELD_Valid = 1
  
  So the audio driver would read the correct ELD unless the ELD content
  and flag writes are somehow _reordered_ underneath. Or the ELD content
  writes take some time to take effect?
 
 Just confirmed that adding 1s delay can fix it!

My test steps are

1) fresh boot
2) cat /proc/asound/card0/eld* == OK
3) startx
4) DISPLAY=:0.0 xrandr --output HDMI2 --mode 720x480
5) cat /proc/asound/card0/eld* == ZEROS before patch, OK after patch

I guess avoiding the extra ELD passing can also fix this problem,
since we never meet timing problems with the first HDMI hot plug event.

Thanks,
Fengguang

 New dmesg is:
 
 [   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set 
 [MODE:34:]
 [   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
 [   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], 
 [ENCODER:11:TMDS-11]
 [   48.571728] [drm:ironlake_write_eld], ELD on pipe B
 [   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
 [   48.575252] [drm:ironlake_write_eld], 
 [   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 
 ELD_Valid=0
 [   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
 [   48.580116] ELD size 13
 [   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 
 ELD_Valid=1
 [   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
 [   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
 [   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
 [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 
 5, cursor: 6
 [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 
 5, cursor: 6
 [   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 
 42, cursor: 6
 [   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
 [   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
 [   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
 [   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
 [   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
 [   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
 [   48.809426] [drm:ironlake_fdi_link_train], FDI train done
 [   48.813960] [drm:intel_update_fbc], 
 [   48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state 
 to on
 [   48.818093] [drm:drm_crtc_helper_set_config],
 [CONNECTOR:12:HDMI-A-2] set DPMS on
 [   48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin 
 work?
 [   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
 [   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
 [   49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 
 44100 48000 96000 176400 192000 384000, bits = 16 20 24
 [   49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 
 44100 48000 96000 176400 192000 384000, bits = 16 20 24
 [   49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 
 44100 48000, max bitrate = 64
 [   49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 
 44100 48000 96000 176400, max bitrate = 1536000
 [   49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, 
 rates = 44100
 [   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): 
 channels = 8, rates = 44100 48000
 [   49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, 
 rates = 48000 176400 384000
 [   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 
 176400 384000
 
 Thanks,
 Fengguang
 

 Subject: 
 Date: Thu Nov 10 15:41:11 CST 2011
 
 
 Signed-off-by: Wu Fengguang fengguang...@intel.com
 ---
  sound/pci/hda/hda_eld.c |3 +++
  1 file

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Christopher White


On 11/10/11 8:55 AM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:

Wow I reproduced the bug and got a very interesting dmesg:

gfx = [ 4561.287980] [drm:intel_write_eld], ELD on 
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to 
unknown port
gfx = [ 4561.295273] [drm:ironlake_write_eld],
   alsa =  [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 
Presence_Detect=1 ELD_Valid=0
   alsa =  [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
ELD_Valid=0
gfx = [ 4561.300020] ELD size 13
   alsa =  [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 
Presence_Detect=1 ELD_Valid=1
   alsa =  [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
ELD_Valid=1
   alsa =  [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0

Hey the two parts are interleaved!

But still it should work all fine, since the gfx driver does

 set ELD_Valid = 0
 write ELD
 set ELD_Valid = 1

So the audio driver would read the correct ELD unless the ELD content
and flag writes are somehow _reordered_ underneath. Or the ELD content
writes take some time to take effect?

Just confirmed that adding 1s delay can fix it!

New dmesg is:

[   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set 
[MODE:34:]
[   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
[   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], 
[ENCODER:11:TMDS-11]
[   48.571728] [drm:ironlake_write_eld], ELD on pipe B
[   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
[   48.575252] [drm:ironlake_write_eld],
[   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
[   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
[   48.580116] ELD size 13
[   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
[   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
[   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, 
cursor: 6
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, 
cursor: 6
[   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, 
cursor: 6
[   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
[   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
[   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
[   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
[   48.809426] [drm:ironlake_fdi_link_train], FDI train done
[   48.813960] [drm:intel_update_fbc],
[   48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state 
to on
[   48.818093] [drm:drm_crtc_helper_set_config],[CONNECTOR:12:HDMI-A-2] 
set DPMS on
[   48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work?
[   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
[   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
[   49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 
44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 
44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 
44100 48000, max bitrate = 64
[   49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 
44100 48000 96000 176400, max bitrate = 1536000
[   49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, 
rates = 44100
[   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): 
channels = 8, rates = 44100 48000
[   49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, 
rates = 48000 176400 384000
[   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 
176400 384000

Thanks,
Fengguang
Wow, you were able to reproduce it! That's the best news ever. I will be 
applying this patch and rebuilding now to see what happens. So it was 
some sort of timing issue after all.


Expect me to reply within 1h, but rebuild takes some time.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Honor SSC quirk table over the default, unless set by user

2011-11-10 Thread Michel Alexandre Salim

On Wed, 2011-11-09 at 10:07 -0800, Keith Packard wrote:
 On Wed, 09 Nov 2011 17:30:29 +0100, Michel Alexandre Salim 
 sali...@fedoraproject.org wrote:
  Additional note: while I've not touched the line since it does not
  affect me, it seems that i915_panel_use_ssc *cannot* be less than 0
  since that variable is declared as unsigned.
 
 Oops. That's the bug here -- we're supposed to make it so that the
 command line can override the quirks, but there's no way to use a quirk
 given the mis-declared parameter.
Ah, now everything makes sense.
 
 This is untested...
 
Tested and it works fine:
- without extra parameter, the blacklist is used
- with i915.lvds_use_ssc=1, SSC use is enforced and the display turns
black on my unsupported hardware
- with i915.lvds_use_ssc=0, SSC is disabled

(ps the PGP/MIME signature made it hard to just extract the
git-formatted email; I ended up just editing the message by hand before
'git am')

 From e64ecadef40e3c2035cd4e9b967ffd83489bdea0 Mon Sep 17 00:00:00 2001
 From: Keith Packard kei...@keithp.com
 Date: Wed, 9 Nov 2011 09:57:50 -0800
 Subject: [PATCH] drm/i915: Module parameters using '-1' as default must be
  signed type
 
 Testing i915_panel_use_ssc for the default value was broken, so the
 driver would never autodetect the correct value.
 
 Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by:   Michel Alexandre Salim sali...@fedoraproject.org
Tested-by: Michel Alexandre Salim sali...@fedoraproject.org

Should I send the patch that I applied with those added lines? Probably
not necessary.

Thanks,

-- 
Michel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Christopher White


On 11/10/11 12:22 PM, Takashi Iwai wrote:

At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:

On 11/10/11 9:55 AM, Christopher White wrote:

On 11/10/11 8:55 AM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:

Wow I reproduced the bug and got a very interesting dmesg:

gfx =  [ 4561.287980] [drm:intel_write_eld], ELD on
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
gfx =  [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
gfx =  [ 4561.293804] [drm:ironlake_write_eld], Audio
directed to unknown port
gfx =  [ 4561.295273] [drm:ironlake_write_eld],
alsa =   [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
alsa =   [ 4561.295564] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
gfx =  [ 4561.300020] ELD size 13
alsa =   [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
alsa =   [ 4561.303322] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
alsa =   [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD
version 0

Hey the two parts are interleaved!

But still it should work all fine, since the gfx driver does

  set ELD_Valid = 0
  write ELD
  set ELD_Valid = 1

So the audio driver would read the correct ELD unless the ELD content
and flag writes are somehow _reordered_ underneath. Or the ELD content
writes take some time to take effect?

Just confirmed that adding 1s delay can fix it!

New dmesg is:

[   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
set [MODE:34:]
[   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
[   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
[ENCODER:11:TMDS-11]
[   48.571728] [drm:ironlake_write_eld], ELD on pipe B
[   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
[   48.575252] [drm:ironlake_write_eld],
[   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=0
[   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
[   48.580116] ELD size 13
[   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=1
[   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
[   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
plane 42, cursor: 6
[   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
[   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
[   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
[   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
[   48.809426] [drm:ironlake_fdi_link_train], FDI train done
[   48.813960] [drm:intel_update_fbc],
[   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
DPMS state to on
[   48.818093] [drm:drm_crtc_helper_set_config],
[CONNECTOR:12:HDMI-A-2] set DPMS on
[   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
unpin work?
[   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
[   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
[   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
32000 44100 48000, max bitrate = 64
[   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
32000 44100 48000 96000 176400, max bitrate = 1536000
[   49.633148] HDMI: supports coding type DSD (One Bit Audio):
channels = 6, rates = 44100
[   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
Plus): channels = 8, rates = 44100 48000
[   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
channels = 8, rates = 48000 176400 384000
[   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
= 48000 176400 384000

Thanks,
Fengguang

Wow, you were able to reproduce it! That's the best news ever. I will
be applying this patch and rebuilding now to see what happens. So it
was some sort of timing issue after all.

Expect me to reply within 1h, but rebuild takes some time.

I still had the old build directory and only had to rebuild one module
which only took 5 minutes. The rest of the delay was me doing an hour of
tests as well as being on a 45 minute phone call. Anyway, now the result:

Success!

So we know it's a timing issue somewhere.

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Takashi Iwai

At Thu, 10 Nov 2011 12:50:11 +0100,
Christopher White wrote:
 
 On 11/10/11 12:22 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 12:00:53 +0100,
  Christopher White wrote:
  On 11/10/11 9:55 AM, Christopher White wrote:
  On 11/10/11 8:55 AM, Wu Fengguang wrote:
  On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
  Wow I reproduced the bug and got a very interesting dmesg:
 
  gfx =  [ 4561.287980] [drm:intel_write_eld], ELD on
  [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
  gfx =  [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
  gfx =  [ 4561.293804] [drm:ironlake_write_eld], Audio
  directed to unknown port
  gfx =  [ 4561.295273] [drm:ironlake_write_eld],
  alsa =   [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
  alsa =   [ 4561.295564] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
  gfx =  [ 4561.300020] ELD size 13
  alsa =   [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
  alsa =   [ 4561.303322] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
  alsa =   [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD
  version 0
 
  Hey the two parts are interleaved!
 
  But still it should work all fine, since the gfx driver does
 
set ELD_Valid = 0
write ELD
set ELD_Valid = 1
 
  So the audio driver would read the correct ELD unless the ELD content
  and flag writes are somehow _reordered_ underneath. Or the ELD content
  writes take some time to take effect?
  Just confirmed that adding 1s delay can fix it!
 
  New dmesg is:
 
  [   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
  set [MODE:34:]
  [   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
  [   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
  [ENCODER:11:TMDS-11]
  [   48.571728] [drm:ironlake_write_eld], ELD on pipe B
  [   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
  [   48.575252] [drm:ironlake_write_eld],
  [   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=0
  [   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
  [   48.580116] ELD size 13
  [   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=1
  [   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
  [   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
  plane 42, cursor: 6
  [   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
  [   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
  [   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
  [   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
  [   48.809426] [drm:ironlake_fdi_link_train], FDI train done
  [   48.813960] [drm:intel_update_fbc],
  [   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
  DPMS state to on
  [   48.818093] [drm:drm_crtc_helper_set_config],
  [CONNECTOR:12:HDMI-A-2] set DPMS on
  [   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
  unpin work?
  [   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
  [   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
  [   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
  32000 44100 48000, max bitrate = 64
  [   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
  32000 44100 48000 96000 176400, max bitrate = 1536000
  [   49.633148] HDMI: supports coding type DSD (One Bit Audio):
  channels = 6, rates = 44100
  [   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
  Plus): channels = 8, rates = 44100 48000
  [   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
  channels = 8, rates = 48000 176400 384000
  [   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
  = 48000 176400 384000
 
  Thanks,
  Fengguang
  Wow, you were able to reproduce it! That's the best news ever. I will
  be applying this patch and rebuilding now to see what happens. So it
  was some sort of timing issue after all.
 
  Expect me to reply within 1h, but rebuild takes some time.
  I still had the

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Christopher White


On 11/10/11 12:53 PM, Takashi Iwai wrote:

At Thu, 10 Nov 2011 12:50:11 +0100,
Christopher White wrote:

On 11/10/11 12:22 PM, Takashi Iwai wrote:

At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:

On 11/10/11 9:55 AM, Christopher White wrote:

On 11/10/11 8:55 AM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:

Wow I reproduced the bug and got a very interesting dmesg:

gfx =   [ 4561.287980] [drm:intel_write_eld], ELD on
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
gfx =   [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
gfx =   [ 4561.293804] [drm:ironlake_write_eld], Audio
directed to unknown port
gfx =   [ 4561.295273] [drm:ironlake_write_eld],
 alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
gfx =   [ 4561.300020] ELD size 13
 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD
version 0

Hey the two parts are interleaved!

But still it should work all fine, since the gfx driver does

   set ELD_Valid = 0
   write ELD
   set ELD_Valid = 1

So the audio driver would read the correct ELD unless the ELD content
and flag writes are somehow _reordered_ underneath. Or the ELD content
writes take some time to take effect?

Just confirmed that adding 1s delay can fix it!

New dmesg is:

[   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
set [MODE:34:]
[   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
[   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
[ENCODER:11:TMDS-11]
[   48.571728] [drm:ironlake_write_eld], ELD on pipe B
[   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
[   48.575252] [drm:ironlake_write_eld],
[   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=0
[   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
[   48.580116] ELD size 13
[   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=1
[   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
[   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
plane 42, cursor: 6
[   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
[   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
[   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
[   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
[   48.809426] [drm:ironlake_fdi_link_train], FDI train done
[   48.813960] [drm:intel_update_fbc],
[   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
DPMS state to on
[   48.818093] [drm:drm_crtc_helper_set_config],
[CONNECTOR:12:HDMI-A-2] set DPMS on
[   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
unpin work?
[   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
[   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
[   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
32000 44100 48000, max bitrate = 64
[   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
32000 44100 48000 96000 176400, max bitrate = 1536000
[   49.633148] HDMI: supports coding type DSD (One Bit Audio):
channels = 6, rates = 44100
[   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
Plus): channels = 8, rates = 44100 48000
[   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
channels = 8, rates = 48000 176400 384000
[   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
= 48000 176400 384000

Thanks,
Fengguang

Wow, you were able to reproduce it! That's the best news ever. I will
be applying this patch and rebuilding now to see what happens. So it
was some sort of timing issue after all.

Expect me to reply within 1h, but rebuild takes some time.

I still had the old build directory and only had to rebuild one module
which only took 5 minutes. The rest of the delay was me doing an hour of

[Intel-gfx] [PATCH] drm/i915: prevent division by zero when asking for chipset power

2011-11-10 Thread Eugeni Dodonov

This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.

The issue can be reproduced easily via the following command:
while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done

This is particularly dangerous because it can be triggered by
a non-privileged user by just reading the debugfs entry.

This issue was also found independently by Konstantin Belousov
kostik...@gmail.com, who proposed a similar patch.

Reported-by: Konstantin Belousov kostik...@gmail.com
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
Acked-by: Keith Packard kei...@keithp.com
Cc: sta...@vger.kernel.org
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
 drivers/gpu/drm/i915/i915_dma.c |   10 ++
 drivers/gpu/drm/i915/i915_drv.h |1 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8a3942c..de199e7 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1453,6 +1453,14 @@ unsigned long i915_chipset_val(struct drm_i915_private 
*dev_priv)
 
diff1 = now - dev_priv-last_time1;
 
+   /* Prevent division-by-zero if we are asking too fast.
+* Also, we don't get interesting results in we are polling
+* faster than once in 10ms, so just return the saved value
+* in such cases.
+*/
+   if (diff1 = 10)
+   return dev_priv-chipset_power;
+
count1 = I915_READ(DMIEC);
count2 = I915_READ(DDREC);
count3 = I915_READ(CSIEC);
@@ -1483,6 +1491,8 @@ unsigned long i915_chipset_val(struct drm_i915_private 
*dev_priv)
dev_priv-last_count1 = total_count;
dev_priv-last_time1 = now;
 
+   dev_priv-chipset_power = ret;
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..1a2a2d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -707,6 +707,7 @@ typedef struct drm_i915_private {
 
u64 last_count1;
unsigned long last_time1;
+   unsigned long chipset_power;
u64 last_count2;
struct timespec last_time2;
unsigned long gfx_power;
-- 
1.7.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Wu Fengguang

On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
 On 11/10/11 12:22 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 12:00:53 +0100,
  Christopher White wrote:
  On 11/10/11 9:55 AM, Christopher White wrote:
  On 11/10/11 8:55 AM, Wu Fengguang wrote:
  On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
  Wow I reproduced the bug and got a very interesting dmesg:
 
  gfx =  [ 4561.287980] [drm:intel_write_eld], ELD on
  [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
  gfx =  [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
  gfx =  [ 4561.293804] [drm:ironlake_write_eld], Audio
  directed to unknown port
  gfx =  [ 4561.295273] [drm:ironlake_write_eld],
  alsa =   [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
  alsa =   [ 4561.295564] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
  gfx =  [ 4561.300020] ELD size 13
  alsa =   [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
  alsa =   [ 4561.303322] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
  alsa =   [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD
  version 0
 
  Hey the two parts are interleaved!
 
  But still it should work all fine, since the gfx driver does
 
set ELD_Valid = 0
write ELD
set ELD_Valid = 1
 
  So the audio driver would read the correct ELD unless the ELD content
  and flag writes are somehow _reordered_ underneath. Or the ELD content
  writes take some time to take effect?
  Just confirmed that adding 1s delay can fix it!
 
  New dmesg is:
 
  [   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
  set [MODE:34:]
  [   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
  [   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
  [ENCODER:11:TMDS-11]
  [   48.571728] [drm:ironlake_write_eld], ELD on pipe B
  [   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
  [   48.575252] [drm:ironlake_write_eld],
  [   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=0
  [   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
  [   48.580116] ELD size 13
  [   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=1
  [   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
  [   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
  plane 42, cursor: 6
  [   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
  [   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
  [   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
  [   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
  [   48.809426] [drm:ironlake_fdi_link_train], FDI train done
  [   48.813960] [drm:intel_update_fbc],
  [   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
  DPMS state to on
  [   48.818093] [drm:drm_crtc_helper_set_config],
  [CONNECTOR:12:HDMI-A-2] set DPMS on
  [   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
  unpin work?
  [   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
  [   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
  [   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
  32000 44100 48000, max bitrate = 64
  [   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
  32000 44100 48000 96000 176400, max bitrate = 1536000
  [   49.633148] HDMI: supports coding type DSD (One Bit Audio):
  channels = 6, rates = 44100
  [   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
  Plus): channels = 8, rates = 44100 48000
  [   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
  channels = 8, rates = 48000 176400 384000
  [   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
  = 48000 176400 384000
 
  Thanks,
  Fengguang
  Wow, you were able to reproduce it! That's the best news ever. I will
  be applying this patch and rebuilding now to see what happens. So it
  was some sort of timing issue after all.
 
  Expect me to reply within 1h, but rebuild takes some time.
  I still had

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Christopher White


On 11/10/11 1:56 PM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:

On 11/10/11 12:22 PM, Takashi Iwai wrote:

At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:

On 11/10/11 9:55 AM, Christopher White wrote:

On 11/10/11 8:55 AM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:

Wow I reproduced the bug and got a very interesting dmesg:

gfx =   [ 4561.287980] [drm:intel_write_eld], ELD on
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
gfx =   [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
gfx =   [ 4561.293804] [drm:ironlake_write_eld], Audio
directed to unknown port
gfx =   [ 4561.295273] [drm:ironlake_write_eld],
 alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
gfx =   [ 4561.300020] ELD size 13
 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD
version 0

Hey the two parts are interleaved!

But still it should work all fine, since the gfx driver does

   set ELD_Valid = 0
   write ELD
   set ELD_Valid = 1

So the audio driver would read the correct ELD unless the ELD content
and flag writes are somehow _reordered_ underneath. Or the ELD content
writes take some time to take effect?

Just confirmed that adding 1s delay can fix it!

New dmesg is:

[   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
set [MODE:34:]
[   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
[   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
[ENCODER:11:TMDS-11]
[   48.571728] [drm:ironlake_write_eld], ELD on pipe B
[   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
[   48.575252] [drm:ironlake_write_eld],
[   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=0
[   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
[   48.580116] ELD size 13
[   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=1
[   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
[   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
plane 42, cursor: 6
[   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
[   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
[   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
[   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
[   48.809426] [drm:ironlake_fdi_link_train], FDI train done
[   48.813960] [drm:intel_update_fbc],
[   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
DPMS state to on
[   48.818093] [drm:drm_crtc_helper_set_config],
[CONNECTOR:12:HDMI-A-2] set DPMS on
[   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
unpin work?
[   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
[   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
[   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
32000 44100 48000, max bitrate = 64
[   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
32000 44100 48000 96000 176400, max bitrate = 1536000
[   49.633148] HDMI: supports coding type DSD (One Bit Audio):
channels = 6, rates = 44100
[   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
Plus): channels = 8, rates = 44100 48000
[   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
channels = 8, rates = 48000 176400 384000
[   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
= 48000 176400 384000

Thanks,
Fengguang

Wow, you were able to reproduce it! That's the best news ever. I will
be applying this patch and rebuilding now to see what happens. So it
was some sort of timing issue after all.

Expect me to reply within 1h, but rebuild takes some time.

I still had the old build directory and only had to rebuild one module
which only took 5 minutes. The rest of the delay was me doing an hour of

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Takashi Iwai

At Thu, 10 Nov 2011 13:39:00 +0100,
Christopher White wrote:
 
 On 11/10/11 12:53 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 12:50:11 +0100,
  Christopher White wrote:
  On 11/10/11 12:22 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 12:00:53 +0100,
  Christopher White wrote:
  On 11/10/11 9:55 AM, Christopher White wrote:
  On 11/10/11 8:55 AM, Wu Fengguang wrote:
  On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
  Wow I reproduced the bug and got a very interesting dmesg:
 
  gfx =   [ 4561.287980] [drm:intel_write_eld], ELD on
  [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
  gfx =   [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe 
  B
  gfx =   [ 4561.293804] [drm:ironlake_write_eld], Audio
  directed to unknown port
  gfx =   [ 4561.295273] [drm:ironlake_write_eld],
   alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
   alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
  gfx =   [ 4561.300020] ELD size 13
   alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
   alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
   alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown 
  ELD
  version 0
 
  Hey the two parts are interleaved!
 
  But still it should work all fine, since the gfx driver does
 
 set ELD_Valid = 0
 write ELD
 set ELD_Valid = 1
 
  So the audio driver would read the correct ELD unless the ELD content
  and flag writes are somehow _reordered_ underneath. Or the ELD content
  writes take some time to take effect?
  Just confirmed that adding 1s delay can fix it!
 
  New dmesg is:
 
  [   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
  set [MODE:34:]
  [   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
  [   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
  [ENCODER:11:TMDS-11]
  [   48.571728] [drm:ironlake_write_eld], ELD on pipe B
  [   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
  [   48.575252] [drm:ironlake_write_eld],
  [   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=0
  [   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
  [   48.580116] ELD size 13
  [   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=1
  [   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
  [   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
  plane 42, cursor: 6
  [   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
  [   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
  [   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
  [   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
  [   48.809426] [drm:ironlake_fdi_link_train], FDI train done
  [   48.813960] [drm:intel_update_fbc],
  [   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
  DPMS state to on
  [   48.818093] [drm:drm_crtc_helper_set_config],
  [CONNECTOR:12:HDMI-A-2] set DPMS on
  [   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
  unpin work?
  [   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
  [   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
  [   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
  32000 44100 48000, max bitrate = 64
  [   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
  32000 44100 48000 96000 176400, max bitrate = 1536000
  [   49.633148] HDMI: supports coding type DSD (One Bit Audio):
  channels = 6, rates = 44100
  [   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
  Plus): channels = 8, rates = 44100 48000
  [   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
  channels = 8, rates = 48000 176400 384000
  [   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
  = 48000 176400 384000
 
  Thanks,
  Fengguang
  Wow, you were able to reproduce it! That's the best news ever. I will
  be applying this patch and rebuilding now to see what

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Wu Fengguang

On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote:
 On 11/10/11 1:56 PM, Wu Fengguang wrote:
  On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
  On 11/10/11 12:22 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 12:00:53 +0100,
  Christopher White wrote:
  On 11/10/11 9:55 AM, Christopher White wrote:
  On 11/10/11 8:55 AM, Wu Fengguang wrote:
  On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
  Wow I reproduced the bug and got a very interesting dmesg:
 
  gfx =   [ 4561.287980] [drm:intel_write_eld], ELD on
  [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
  gfx =   [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe 
  B
  gfx =   [ 4561.293804] [drm:ironlake_write_eld], Audio
  directed to unknown port
  gfx =   [ 4561.295273] [drm:ironlake_write_eld],
   alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
   alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=0
  gfx =   [ 4561.300020] ELD size 13
   alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
   alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6
  Presence_Detect=1 ELD_Valid=1
   alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown 
  ELD
  version 0
 
  Hey the two parts are interleaved!
 
  But still it should work all fine, since the gfx driver does
 
 set ELD_Valid = 0
 write ELD
 set ELD_Valid = 1
 
  So the audio driver would read the correct ELD unless the ELD content
  and flag writes are somehow _reordered_ underneath. Or the ELD content
  writes take some time to take effect?
  Just confirmed that adding 1s delay can fix it!
 
  New dmesg is:
 
  [   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
  set [MODE:34:]
  [   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
  [   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
  [ENCODER:11:TMDS-11]
  [   48.571728] [drm:ironlake_write_eld], ELD on pipe B
  [   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
  [   48.575252] [drm:ironlake_write_eld],
  [   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=0
  [   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
  [   48.580116] ELD size 13
  [   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
  ELD_Valid=1
  [   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
  [   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
  plane 5, cursor: 6
  [   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
  plane 42, cursor: 6
  [   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
  [   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
  [   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
  [   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
  [   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
  [   48.809426] [drm:ironlake_fdi_link_train], FDI train done
  [   48.813960] [drm:intel_update_fbc],
  [   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
  DPMS state to on
  [   48.818093] [drm:drm_crtc_helper_set_config],
  [CONNECTOR:12:HDMI-A-2] set DPMS on
  [   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
  unpin work?
  [   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
  [   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
  [   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
  32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
  [   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
  32000 44100 48000, max bitrate = 64
  [   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
  32000 44100 48000 96000 176400, max bitrate = 1536000
  [   49.633148] HDMI: supports coding type DSD (One Bit Audio):
  channels = 6, rates = 44100
  [   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
  Plus): channels = 8, rates = 44100 48000
  [   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
  channels = 8, rates = 48000 176400 384000
  [   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
  = 48000 176400 384000
 
  Thanks,
  Fengguang
  Wow, you were able to reproduce it! That's the best news ever. I will
  be applying this patch and rebuilding now to see what

[Intel-gfx] [PATCH 0/9] gpu hang and swizzle patches

2011-11-10 Thread Daniel Vetter

Hi all,

This is a bit a mixed pile, but I've used all the earlier patches to test
the gen6+ swizzling patch and I like to send out patch series somewhat
resembling the setup I've tested them in.

Patches 1-2 refactor our debugfs code a bit.
Patches 3-5 implement a debugfs interface to simulate a gpu hang Patch 6
fixes the swizzle detection on i915G/i945G. This one is for stable and
independent of the previous patches.
Patches 7-8 add a debugfs file with information to debug swizzle issues
Patch 9 implements swizzle support for snb/ivb when in dual-channel mode

Benchmarking on my snb is notoriously difficult, but swizzling seems to
yield a few percent in some workloads, topping out at 5% for padman.

Review highly welcome.

Cheers, Daniel

Daniel Vetter (9):
  drm/i915: refactor debugfs open function
  drm/i915: refactor debugfs create functions
  drm/i915: add interface to simulate gpu hangs
  drm/i915: rework dev-first_error locking
  drm/i915: destroy existing error_state when simulating a gpu hang
  drm/i915: fix swizzle detection for gen3
  drm/i915: add debugfs file for swizzling information
  drm/i915: add gen6+ registers to i915_swizzle_info
  drm/i915: swizzling support for snb/ivb

 drivers/gpu/drm/i915/i915_debugfs.c |  212 ++-
 drivers/gpu/drm/i915/i915_dma.c |4 +-
 drivers/gpu/drm/i915/i915_drv.c |7 +-
 drivers/gpu/drm/i915/i915_drv.h |8 +-
 drivers/gpu/drm/i915/i915_gem.c |   23 +++-
 drivers/gpu/drm/i915/i915_gem_tiling.c  |   20 +++-
 drivers/gpu/drm/i915/i915_irq.c |7 +-
 drivers/gpu/drm/i915/i915_reg.h |   33 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |4 +
 9 files changed, 249 insertions(+), 69 deletions(-)

-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/9] drm/i915: refactor debugfs open function

2011-11-10 Thread Daniel Vetter

Only forcewake has an open with special semantics, the other r/w
debugfs only assign the file private pointer.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |   26 +-
 1 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 51b21eb..f37b3ab 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1332,8 +1332,8 @@ static int i915_gen6_forcewake_count_info(struct seq_file 
*m, void *data)
 }
 
 static int
-i915_wedged_open(struct inode *inode,
-struct file *filp)
+i915_debugfs_common_open(struct inode *inode,
+struct file *filp)
 {
filp-private_data = inode-i_private;
return 0;
@@ -1389,20 +1389,12 @@ i915_wedged_write(struct file *filp,
 
 static const struct file_operations i915_wedged_fops = {
.owner = THIS_MODULE,
-   .open = i915_wedged_open,
+   .open = i915_debugfs_common_open,
.read = i915_wedged_read,
.write = i915_wedged_write,
.llseek = default_llseek,
 };
 
-static int
-i915_max_freq_open(struct inode *inode,
-  struct file *filp)
-{
-   filp-private_data = inode-i_private;
-   return 0;
-}
-
 static ssize_t
 i915_max_freq_read(struct file *filp,
   char __user *ubuf,
@@ -1459,20 +1451,12 @@ i915_max_freq_write(struct file *filp,
 
 static const struct file_operations i915_max_freq_fops = {
.owner = THIS_MODULE,
-   .open = i915_max_freq_open,
+   .open = i915_debugfs_common_open,
.read = i915_max_freq_read,
.write = i915_max_freq_write,
.llseek = default_llseek,
 };
 
-static int
-i915_cache_sharing_open(struct inode *inode,
-  struct file *filp)
-{
-   filp-private_data = inode-i_private;
-   return 0;
-}
-
 static ssize_t
 i915_cache_sharing_read(struct file *filp,
   char __user *ubuf,
@@ -1538,7 +1522,7 @@ i915_cache_sharing_write(struct file *filp,
 
 static const struct file_operations i915_cache_sharing_fops = {
.owner = THIS_MODULE,
-   .open = i915_cache_sharing_open,
+   .open = i915_debugfs_common_open,
.read = i915_cache_sharing_read,
.write = i915_cache_sharing_write,
.llseek = default_llseek,
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/9] drm/i915: refactor debugfs create functions

2011-11-10 Thread Daniel Vetter

All r/w debugfs files are created equal.

v2: Add some newlines to make the code easier on the eyes as requested
by Ben Widawsky.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |   55 +++---
 1 files changed, 18 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f37b3ab..648fd64 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1551,21 +1551,6 @@ drm_add_fake_info_node(struct drm_minor *minor,
return 0;
 }
 
-static int i915_wedged_create(struct dentry *root, struct drm_minor *minor)
-{
-   struct drm_device *dev = minor-dev;
-   struct dentry *ent;
-
-   ent = debugfs_create_file(i915_wedged,
- S_IRUGO | S_IWUSR,
- root, dev,
- i915_wedged_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-
-   return drm_add_fake_info_node(minor, ent, i915_wedged_fops);
-}
-
 static int i915_forcewake_open(struct inode *inode, struct file *file)
 {
struct drm_device *dev = inode-i_private;
@@ -1627,34 +1612,22 @@ static int i915_forcewake_create(struct dentry *root, 
struct drm_minor *minor)
return drm_add_fake_info_node(minor, ent, i915_forcewake_fops);
 }
 
-static int i915_max_freq_create(struct dentry *root, struct drm_minor *minor)
-{
-   struct drm_device *dev = minor-dev;
-   struct dentry *ent;
-
-   ent = debugfs_create_file(i915_max_freq,
- S_IRUGO | S_IWUSR,
- root, dev,
- i915_max_freq_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-
-   return drm_add_fake_info_node(minor, ent, i915_max_freq_fops);
-}
-
-static int i915_cache_sharing_create(struct dentry *root, struct drm_minor 
*minor)
+static int i915_debugfs_create(struct dentry *root,
+  struct drm_minor *minor,
+  const char *name,
+  const struct file_operations *fops)
 {
struct drm_device *dev = minor-dev;
struct dentry *ent;
 
-   ent = debugfs_create_file(i915_cache_sharing,
+   ent = debugfs_create_file(name,
  S_IRUGO | S_IWUSR,
  root, dev,
- i915_cache_sharing_fops);
+ fops);
if (IS_ERR(ent))
return PTR_ERR(ent);
 
-   return drm_add_fake_info_node(minor, ent, i915_cache_sharing_fops);
+   return drm_add_fake_info_node(minor, ent, fops);
 }
 
 static struct drm_info_list i915_debugfs_list[] = {
@@ -1703,17 +1676,25 @@ int i915_debugfs_init(struct drm_minor *minor)
 {
int ret;
 
-   ret = i915_wedged_create(minor-debugfs_root, minor);
+   ret = i915_debugfs_create(minor-debugfs_root, minor,
+ i915_wedged,
+ i915_wedged_fops);
if (ret)
return ret;
 
ret = i915_forcewake_create(minor-debugfs_root, minor);
if (ret)
return ret;
-   ret = i915_max_freq_create(minor-debugfs_root, minor);
+
+   ret = i915_debugfs_create(minor-debugfs_root, minor,
+ i915_max_freq,
+ i915_max_freq_fops);
if (ret)
return ret;
-   ret = i915_cache_sharing_create(minor-debugfs_root, minor);
+
+   ret = i915_debugfs_create(minor-debugfs_root, minor,
+ i915_cache_sharing,
+ i915_cache_sharing_fops);
if (ret)
return ret;
 
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/9] drm/i915: add interface to simulate gpu hangs

2011-11-10 Thread Daniel Vetter

gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang detection
- error capture
- actual gpu reset
- reset of all the gem bookkeeping
- reinitialition of the entire gpu

This patch adds a debugfs to selectively stopping rings by ceasing to
update the hw tail pointer, which will result in the gpu no longer
updating it's head pointer and eventually to the hangcheck firing.
This way we can exercise the gpu hang code under controlled conditions
without a dying gpu taking down the entire systems.

Patch motivated by me forgetting to properly reinitialize ppgtt after
a gpu reset.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |   63 +++
 drivers/gpu/drm/i915/i915_drv.c |3 +
 drivers/gpu/drm/i915/i915_drv.h |2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |4 ++
 4 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 648fd64..e1c5aa1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1396,6 +1396,64 @@ static const struct file_operations i915_wedged_fops = {
 };
 
 static ssize_t
+i915_ring_stop_read(struct file *filp,
+   char __user *ubuf,
+   size_t max,
+   loff_t *ppos)
+{
+   struct drm_device *dev = filp-private_data;
+   drm_i915_private_t *dev_priv = dev-dev_private;
+   char buf[80];
+   int len;
+
+   len = snprintf(buf, sizeof(buf),
+  %d\n, dev_priv-stop_rings);
+
+   if (len  sizeof(buf))
+   len = sizeof(buf);
+
+   return simple_read_from_buffer(ubuf, max, ppos, buf, len);
+}
+
+static ssize_t
+i915_ring_stop_write(struct file *filp,
+const char __user *ubuf,
+size_t cnt,
+loff_t *ppos)
+{
+   struct drm_device *dev = filp-private_data;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   char buf[20];
+   int val = 0;
+
+   if (cnt  0) {
+   if (cnt  sizeof(buf) - 1)
+   return -EINVAL;
+
+   if (copy_from_user(buf, ubuf, cnt))
+   return -EFAULT;
+   buf[cnt] = 0;
+
+   val = simple_strtoul(buf, NULL, 0);
+   }
+
+   DRM_DEBUG_DRIVER(Stopping rings %u\n, val);
+
+   mutex_lock(dev-struct_mutex);
+   dev_priv-stop_rings = val;
+   mutex_unlock(dev-struct_mutex);
+
+   return cnt;
+}
+
+static const struct file_operations i915_ring_stop_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_debugfs_common_open,
+   .read = i915_ring_stop_read,
+   .write = i915_ring_stop_write,
+   .llseek = default_llseek,
+};
+static ssize_t
 i915_max_freq_read(struct file *filp,
   char __user *ubuf,
   size_t max,
@@ -1697,6 +1755,11 @@ int i915_debugfs_init(struct drm_minor *minor)
  i915_cache_sharing_fops);
if (ret)
return ret;
+   ret = i915_debugfs_create(minor-debugfs_root, minor,
+ i915_ring_stop,
+ i915_ring_stop_fops);
+   if (ret)
+   return ret;
 
return drm_debugfs_create_files(i915_debugfs_list,
I915_DEBUGFS_ENTRIES,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bab4e08..e8e4cd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -616,6 +616,9 @@ int i915_reset(struct drm_device *dev, u8 flags)
if (!mutex_trylock(dev-struct_mutex))
return -EBUSY;
 
+   printk(reenabling rings\n);
+   dev_priv-stop_rings = 0;
+
i915_gem_reset(dev);
 
ret = -ENODEV;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25036f5..8bb83c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -336,6 +336,8 @@ typedef struct drm_i915_private {
uint32_t last_instdone;
uint32_t last_instdone1;
 
+   unsigned int stop_rings;
+
unsigned long cfb_size;
unsigned int cfb_fb;
enum plane cfb_plane;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2d476a9..cf6e159 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1179,7 +1179,11 @@ int intel_ring_begin(struct intel_ring_buffer *ring,
 
 void intel_ring_advance(struct intel_ring_buffer *ring)
 {
+   struct drm_i915_private *dev_priv =

[Intel-gfx] [PATCH 4/9] drm/i915: rework dev-first_error locking

2011-11-10 Thread Daniel Vetter

- reduce the irq disabled section, even for a debugfs file this was
  way too long.
- protect readers of the captured error state from concurrent freeing
  of the same by holding dev-struct_mutex.
- always disable irqs when taking the lock.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |9 ++---
 drivers/gpu/drm/i915/i915_dma.c |2 ++
 drivers/gpu/drm/i915/i915_drv.h |3 +++
 drivers/gpu/drm/i915/i915_irq.c |7 +--
 4 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e1c5aa1..63e1c36 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -768,13 +768,16 @@ static int i915_error_state(struct seq_file *m, void 
*unused)
unsigned long flags;
int i, page, offset, elt;
 
+   mutex_lock(dev-struct_mutex);
spin_lock_irqsave(dev_priv-error_lock, flags);
-   if (!dev_priv-first_error) {
+   error = dev_priv-first_error;
+   spin_unlock_irqrestore(dev_priv-error_lock, flags);
+
+   if (!error) {
seq_printf(m, no error state collected\n);
goto out;
}
 
-   error = dev_priv-first_error;
 
seq_printf(m, Time: %ld s %ld us\n, error-time.tv_sec,
   error-time.tv_usec);
@@ -846,7 +849,7 @@ static int i915_error_state(struct seq_file *m, void 
*unused)
intel_display_print_error_state(m, dev, error-display);
 
 out:
-   spin_unlock_irqrestore(dev_priv-error_lock, flags);
+   mutex_unlock(dev-struct_mutex);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab3a3fd..0034c6a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2153,7 +2153,9 @@ int i915_driver_unload(struct drm_device *dev)
/* Free error state after interrupts are fully disabled. */
del_timer_sync(dev_priv-hangcheck_timer);
cancel_work_sync(dev_priv-error_work);
+   mutex_lock(dev-struct_mutex);
i915_destroy_error_state(dev);
+   mutex_unlock(dev-struct_mutex);
 
if (dev-pdev-msi_enabled)
pci_disable_msi(dev-pdev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8bb83c0..660b62c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -386,6 +386,9 @@ typedef struct drm_i915_private {
unsigned int fsb_freq, mem_freq, is_ddr3;
 
spinlock_t error_lock;
+   /* Protected by dev-error_lock. To ensure that the error_state obtained
+* through this pointer doesn't disappear, you also need to hold
+* dev-struct_mutex */
struct drm_i915_error_state *first_error;
struct work_struct error_work;
struct completion error_completion;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a04d606..c9b0766 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1024,11 +1024,14 @@ void i915_destroy_error_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_error_state *error;
+   unsigned long flags;
+
+   WARN_ON(!mutex_is_locked(dev_priv-dev-struct_mutex));
 
-   spin_lock(dev_priv-error_lock);
+   spin_lock_irqsave(dev_priv-error_lock, flags);
error = dev_priv-first_error;
dev_priv-first_error = NULL;
-   spin_unlock(dev_priv-error_lock);
+   spin_unlock_irqrestore(dev_priv-error_lock, flags);
 
if (error)
i915_error_state_free(dev, error);
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/9] drm/i915: destroy existing error_state when simulating a gpu hang

2011-11-10 Thread Daniel Vetter

This way we can simulate a bunch of gpu hangs and run the error_state
capture code every time (without the need to reload the module).

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 63e1c36..2ad2237 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1443,6 +1443,8 @@ i915_ring_stop_write(struct file *filp,
DRM_DEBUG_DRIVER(Stopping rings %u\n, val);
 
mutex_lock(dev-struct_mutex);
+   i915_destroy_error_state(dev);
+
dev_priv-stop_rings = val;
mutex_unlock(dev-struct_mutex);
 
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/9] drm/i915: fix swizzle detection for gen3

2011-11-10 Thread Daniel Vetter

It looks like the desktop variants of i915 and i945 also have the DCC
register to control dram channel interleave and cpu side bit6
swizzling.

Unfurnately internal Cspec/ConfigDB documentation for these ancient chips
have already been dropped and there seem to be no archives. Also
somebody thought the swizzling behaviour is surely a worthy secret to
keep and redacted any mention of these fields from the published Intel
datasheets.

I suspect the hw engineers were really proud of the page coloring
they've achieved in their first dual channel dram controller with
bit17 - after all Bspec explains in great length the optimal layout of
page frame numbers modulo 4 for the color and depth buffers, too.
Later on when they've started to work on VT-d they shamefully
discoverd their stupidity and tried to cover the tracks ...

Tested-by: Daniel Vetter daniel.vet...@ffwll.ch (i915g)
Tested-by: Pavel Ondračka pavel.ondra...@email.cz (i945g)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42625
Cc: sta...@kernel.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_gem_tiling.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 31d334d..861223b 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -107,10 +107,10 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
 */
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
-   } else if (IS_MOBILE(dev)) {
+   } else if (IS_MOBILE(dev) || (IS_GEN3(dev)  !IS_G33(dev))) {
uint32_t dcc;
 
-   /* On mobile 9xx chipsets, channel interleave by the CPU is
+   /* On 9xx chipsets, channel interleave by the CPU is
 * determined by DCC.  For single-channel, neither the CPU
 * nor the GPU do swizzling.  For dual channel interleaved,
 * the GPU's interleave is bit 9 and 10 for X tiled, and bit
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 8/9] drm/i915: add gen6+ registers to i915_swizzle_info

2011-11-10 Thread Daniel Vetter

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |   13 +
 drivers/gpu/drm/i915/i915_reg.h |   31 +++
 2 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d5bc92b..41b455b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1377,6 +1377,19 @@ static int i915_swizzle_info(struct seq_file *m, void 
*data)
   I915_READ16(C0DRB3));
seq_printf(m, C1DRB3 = 0x%04x\n,
   I915_READ16(C1DRB3));
+   } else if (IS_GEN6(dev) || IS_GEN7(dev)) {
+   seq_printf(m, MAD_DIMM_C0 = 0x%08x\n,
+  I915_READ(MAD_DIMM_C0));
+   seq_printf(m, MAD_DIMM_C1 = 0x%08x\n,
+  I915_READ(MAD_DIMM_C1));
+   seq_printf(m, MAD_DIMM_C2 = 0x%08x\n,
+  I915_READ(MAD_DIMM_C2));
+   seq_printf(m, TILECTL = 0x%08x\n,
+  I915_READ(TILECTL));
+   seq_printf(m, ARB_MODE = 0x%08x\n,
+  I915_READ(ARB_MODE));
+   seq_printf(m, DISP_ARB_CTL = 0x%08x\n,
+  I915_READ(DISP_ARB_CTL));
}
mutex_unlock(dev-struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cbf5f9f..0a0b6b1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -295,6 +295,12 @@
 #define FENCE_REG_SANDYBRIDGE_00x10
 #define   SANDYBRIDGE_FENCE_PITCH_SHIFT32
 
+/* control register for cpu gtt access */
+#define TILECTL0x101000
+#define   TILECTL_SWZCTL   (1  0)
+#define   TILECTL_TLB_PREFETCH_DIS (1  2)
+#define   TILECTL_BACKSNOOP_DIS(1  3)
+
 /*
  * Instruction and interrupt control regs
  */
@@ -318,6 +324,9 @@
 #define RING_MAX_IDLE(base)((base)+0x54)
 #define RING_HWS_PGA(base) ((base)+0x80)
 #define RING_HWS_PGA_GEN6(base)((base)+0x2080)
+#define ARB_MODE   0x04030
+#define   ARB_MODE_SWIZZLE_SNB (14)
+#define   ARB_MODE_SWIZZLE_IVB (15)
 #define RENDER_HWS_PGA_GEN7(0x04080)
 #define BSD_HWS_PGA_GEN7   (0x04180)
 #define BLT_HWS_PGA_GEN7   (0x04280)
@@ -1034,6 +1043,28 @@
 #define C0DRB3 0x10206
 #define C1DRB3 0x10606
 
+/** snb MCH registers for reading the DRAM channel configuration */
+#define MAD_DIMM_C0(MCHBAR_MIRROR_BASE_SNB + 0x5004)
+#define   MAD_DIMM_C1  (MCHBAR_MIRROR_BASE_SNB + 0x5008)
+#define   MAD_DIMM_C2  (MCHBAR_MIRROR_BASE_SNB + 0x500C)
+#define   MAD_DIMM_ECC_MASK(0x3  24)
+#define   MAD_DIMM_ECC_OFF (0x0  24)
+#define   MAD_DIMM_ECC_IO_ON_LOGIC_OFF (0x1  24)
+#define   MAD_DIMM_ECC_IO_OFF_LOGIC_ON (0x2  24)
+#define   MAD_DIMM_ECC_ON  (0x3  24)
+#define   MAD_DIMM_ENH_INTERLEAVE  (0x1  22)
+#define   MAD_DIMM_RANK_INTERLEAVE (0x1  21)
+#define   MAD_DIMM_B_WIDTH_X16 (0x1  20) /* X8 chips if unset */
+#define   MAD_DIMM_A_WIDTH_X16 (0x1  19) /* X8 chips if unset */
+#define   MAD_DIMM_B_DUAL_RANK (0x1  18)
+#define   MAD_DIMM_A_DUAL_RANK (0x1  17)
+#define   MAD_DIMM_A_SELECT(0x1  16)
+#define   MAD_DIMM_B_SIZE_MASK (0xff  8) /* in multiples of 256mb */
+#define   MAD_DIMM_B_SIZE_SHIFT8
+#define   MAD_DIMM_A_SIZE_MASK (0xff  0) /* in multiples of 256mb */
+#define   MAD_DIMM_A_SIZE_SHIFT8
+
+
 /* Clocking configuration register */
 #define CLKCFG 0x10c00
 #define CLKCFG_FSB_400 (5  0)/* 
hrawclk 100 */
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 7/9] drm/i915: add debugfs file for swizzling information

2011-11-10 Thread Daniel Vetter

This will also come handy for the gen6+ swizzling support, where the
driver is supposed to control swizzling depending upon dram
configuration.

v2: CxDRB3 are 16 bit regs! Noticed by Chris Wilson.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |   50 +++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ad2237..d5bc92b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1334,6 +1334,55 @@ static int i915_gen6_forcewake_count_info(struct 
seq_file *m, void *data)
return 0;
 }
 
+static const char *swizzle_string(unsigned swizzle)
+{
+   switch(swizzle) {
+   case I915_BIT_6_SWIZZLE_NONE:
+   return none;
+   case I915_BIT_6_SWIZZLE_9:
+   return bit9;
+   case I915_BIT_6_SWIZZLE_9_10:
+   return bit9/bit10;
+   case I915_BIT_6_SWIZZLE_9_11:
+   return bit9/bit11;
+   case I915_BIT_6_SWIZZLE_9_10_11:
+   return bit9/bit10/bit11;
+   case I915_BIT_6_SWIZZLE_9_17:
+   return bit9/bit17;
+   case I915_BIT_6_SWIZZLE_9_10_17:
+   return bit9/bit10/bit17;
+   case I915_BIT_6_SWIZZLE_UNKNOWN:
+   return unkown;
+   }
+
+   return bug;
+}
+
+static int i915_swizzle_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m-private;
+   struct drm_device *dev = node-minor-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   mutex_lock(dev-struct_mutex);
+   seq_printf(m, bit6 swizzle for X-tiling = %s\n,
+  swizzle_string(dev_priv-mm.bit_6_swizzle_x));
+   seq_printf(m, bit6 swizzle for Y-tiling = %s\n,
+  swizzle_string(dev_priv-mm.bit_6_swizzle_y));
+
+   if (IS_GEN3(dev) || IS_GEN4(dev)) {
+   seq_printf(m, DDC = 0x%08x\n,
+  I915_READ(DCC));
+   seq_printf(m, C0DRB3 = 0x%04x\n,
+  I915_READ16(C0DRB3));
+   seq_printf(m, C1DRB3 = 0x%04x\n,
+  I915_READ16(C1DRB3));
+   }
+   mutex_unlock(dev-struct_mutex);
+
+   return 0;
+}
+
 static int
 i915_debugfs_common_open(struct inode *inode,
 struct file *filp)
@@ -1732,6 +1781,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_gem_framebuffer, i915_gem_framebuffer_info, 0},
{i915_context_status, i915_context_status, 0},
{i915_gen6_forcewake_count, i915_gen6_forcewake_count_info, 0},
+   {i915_swizzle_info, i915_swizzle_info, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
 
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 9/9] drm/i915: swizzling support for snb/ivb

2011-11-10 Thread Daniel Vetter

We have to do this manually. Somebody had a Great Idea.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_dma.c|2 +-
 drivers/gpu/drm/i915/i915_drv.c|4 +++-
 drivers/gpu/drm/i915/i915_drv.h|3 ++-
 drivers/gpu/drm/i915/i915_gem.c|   23 +--
 drivers/gpu/drm/i915/i915_gem_tiling.c |   16 ++--
 drivers/gpu/drm/i915/i915_reg.h|2 ++
 6 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0034c6a..a2a107d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1201,7 +1201,7 @@ static int i915_load_gem_init(struct drm_device *dev)
i915_gem_do_init(dev, 0, mappable_size, gtt_size - PAGE_SIZE);
 
mutex_lock(dev-struct_mutex);
-   ret = i915_gem_init_ringbuffer(dev);
+   ret = i915_gem_init_hw(dev);
mutex_unlock(dev-struct_mutex);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e8e4cd0..8ce04b7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -472,7 +472,7 @@ static int i915_drm_thaw(struct drm_device *dev)
mutex_lock(dev-struct_mutex);
dev_priv-mm.suspended = 0;
 
-   error = i915_gem_init_ringbuffer(dev);
+   error = i915_gem_init_hw(dev);
mutex_unlock(dev-struct_mutex);
 
if (HAS_PCH_SPLIT(dev))
@@ -669,6 +669,8 @@ int i915_reset(struct drm_device *dev, u8 flags)
!dev_priv-mm.suspended) {
dev_priv-mm.suspended = 0;
 
+   i915_gem_init_swizzling(dev);
+
dev_priv-ring[RCS].init(dev_priv-ring[RCS]);
if (HAS_BSD(dev))
dev_priv-ring[VCS].init(dev_priv-ring[VCS]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 660b62c..9170463 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1177,7 +1177,8 @@ int __must_check i915_gem_object_set_domain(struct 
drm_i915_gem_object *obj,
uint32_t read_domains,
uint32_t write_domain);
 int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj);
-int __must_check i915_gem_init_ringbuffer(struct drm_device *dev);
+int __must_check i915_gem_init_hw(struct drm_device *dev);
+void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 void i915_gem_do_init(struct drm_device *dev,
  unsigned long start,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a838597..c9d9b62 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3739,12 +3739,31 @@ i915_gem_idle(struct drm_device *dev)
return 0;
 }
 
+void i915_gem_init_swizzling(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = dev-dev_private;
+
+   if (INTEL_INFO(dev)-gen  6 ||
+   dev_priv-mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
+   return;
+
+   I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_SWZCTL);
+   if (IS_GEN6(dev))
+   I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_SNB));
+   else
+   I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_IVB));
+   I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
+DISP_TILE_SURFACE_SWIZZLING);
+
+}
 int
-i915_gem_init_ringbuffer(struct drm_device *dev)
+i915_gem_init_hw(struct drm_device *dev)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
int ret;
 
+   i915_gem_init_swizzling(dev);
+
ret = intel_init_render_ring_buffer(dev);
if (ret)
return ret;
@@ -3800,7 +3819,7 @@ i915_gem_entervt_ioctl(struct drm_device *dev, void *data,
mutex_lock(dev-struct_mutex);
dev_priv-mm.suspended = 0;
 
-   ret = i915_gem_init_ringbuffer(dev);
+   ret = i915_gem_init_hw(dev);
if (ret != 0) {
mutex_unlock(dev-struct_mutex);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 861223b..af0a2fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -93,8 +93,20 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
 
if (INTEL_INFO(dev)-gen = 6) {
-   swizzle_x = I915_BIT_6_SWIZZLE_NONE;
-   swizzle_y = I915_BIT_6_SWIZZLE_NONE;
+   uint32_t dimm_c0, dimm_c1;
+   dimm_c0 = I915_READ(MAD_DIMM_C0);
+   dimm_c1 = I915_READ(MAD_DIMM_C1);
+   dimm_c0 =

Re: [Intel-gfx] [PATCH] drm/i915: prevent division by zero when asking for chipset power

2011-11-10 Thread Chris Wilson

On Thu, 10 Nov 2011 10:51:26 -0200, Eugeni Dodonov eugeni.dodo...@intel.com 
wrote:
 This prevents an in-kernel division by zero which happens when we are
 asking for i915_chipset_val too quickly, or within a race condition
 between the power monitoring thread and userspace accesses via debugfs.
 
 The issue can be reproduced easily via the following command:
 while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done
 
 This is particularly dangerous because it can be triggered by
 a non-privileged user by just reading the debugfs entry.
 
 This issue was also found independently by Konstantin Belousov
 kostik...@gmail.com, who proposed a similar patch.
 
 Reported-by: Konstantin Belousov kostik...@gmail.com
 Acked-by: Jesse Barnes jbar...@virtuousgeek.org
 Acked-by: Keith Packard kei...@keithp.com
 Cc: sta...@vger.kernel.org
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Just spotted a typo...
 ---
  drivers/gpu/drm/i915/i915_dma.c |   10 ++
  drivers/gpu/drm/i915/i915_drv.h |1 +
  2 files changed, 11 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 8a3942c..de199e7 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -1453,6 +1453,14 @@ unsigned long i915_chipset_val(struct drm_i915_private 
 *dev_priv)
  
   diff1 = now - dev_priv-last_time1;
  
 + /* Prevent division-by-zero if we are asking too fast.
 +  * Also, we don't get interesting results in we are polling
s/in/if/
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Christopher White


On 11/10/11 2:17 PM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote:

On 11/10/11 1:56 PM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:

On 11/10/11 12:22 PM, Takashi Iwai wrote:

At Thu, 10 Nov 2011 12:00:53 +0100,
Christopher White wrote:

On 11/10/11 9:55 AM, Christopher White wrote:

On 11/10/11 8:55 AM, Wu Fengguang wrote:

On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:

Wow I reproduced the bug and got a very interesting dmesg:

gfx =[ 4561.287980] [drm:intel_write_eld], ELD on
[CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
gfx =[ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B
gfx =[ 4561.293804] [drm:ironlake_write_eld], Audio
directed to unknown port
gfx =[ 4561.295273] [drm:ironlake_write_eld],
  alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
  alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=0
gfx =[ 4561.300020] ELD size 13
  alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
  alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6
Presence_Detect=1 ELD_Valid=1
  alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD
version 0

Hey the two parts are interleaved!

But still it should work all fine, since the gfx driver does

set ELD_Valid = 0
write ELD
set ELD_Valid = 1

So the audio driver would read the correct ELD unless the ELD content
and flag writes are somehow _reordered_ underneath. Or the ELD content
writes take some time to take effect?

Just confirmed that adding 1s delay can fix it!

New dmesg is:

[   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
set [MODE:34:]
[   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B
[   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
[ENCODER:11:TMDS-11]
[   48.571728] [drm:ironlake_write_eld], ELD on pipe B
[   48.572882] [drm:ironlake_write_eld], Audio directed to unknown port
[   48.575252] [drm:ironlake_write_eld],
[   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=0
[   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0
[   48.580116] ELD size 13
[   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
ELD_Valid=1
[   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1
[   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
plane 5, cursor: 6
[   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
plane 42, cursor: 6
[   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
[   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
[   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
[   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
[   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
[   48.809426] [drm:ironlake_fdi_link_train], FDI train done
[   48.813960] [drm:intel_update_fbc],
[   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
DPMS state to on
[   48.818093] [drm:drm_crtc_helper_set_config],
[CONNECTOR:12:HDMI-A-2] set DPMS on
[   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
unpin work?
[   49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI
[   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
[   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
[   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
32000 44100 48000, max bitrate = 64
[   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
32000 44100 48000 96000 176400, max bitrate = 1536000
[   49.633148] HDMI: supports coding type DSD (One Bit Audio):
channels = 6, rates = 44100
[   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
Plus): channels = 8, rates = 44100 48000
[   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
channels = 8, rates = 48000 176400 384000
[   49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates
= 48000 176400 384000

Thanks,
Fengguang

Wow, you were able to reproduce it! That's the best news ever. I will
be applying this patch and rebuilding now to see what happens. So it
was some sort of timing issue after all.

Expect me to reply within 1h, but rebuild takes some time.

I still had the

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Takashi Iwai

At Thu, 10 Nov 2011 21:17:53 +0800,
Wu Fengguang wrote:
 
 On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote:
  On 11/10/11 1:56 PM, Wu Fengguang wrote:
   On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote:
   On 11/10/11 12:22 PM, Takashi Iwai wrote:
   At Thu, 10 Nov 2011 12:00:53 +0100,
   Christopher White wrote:
   On 11/10/11 9:55 AM, Christopher White wrote:
   On 11/10/11 8:55 AM, Wu Fengguang wrote:
   On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
   Wow I reproduced the bug and got a very interesting dmesg:
  
   gfx =   [ 4561.287980] [drm:intel_write_eld], ELD on
   [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11]
   gfx =   [ 4561.291730] [drm:ironlake_write_eld], ELD on 
   pipe B
   gfx =   [ 4561.293804] [drm:ironlake_write_eld], Audio
   directed to unknown port
   gfx =   [ 4561.295273] [drm:ironlake_write_eld],
alsa =[ 4561.295486] HDMI hot plug event: Codec=3 
   Pin=6
   Presence_Detect=1 ELD_Valid=0
alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6
   Presence_Detect=1 ELD_Valid=0
   gfx =   [ 4561.300020] ELD size 13
alsa =[ 4561.300697] HDMI hot plug event: Codec=3 
   Pin=6
   Presence_Detect=1 ELD_Valid=1
alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6
   Presence_Detect=1 ELD_Valid=1
alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown 
   ELD
   version 0
  
   Hey the two parts are interleaved!
  
   But still it should work all fine, since the gfx driver does
  
  set ELD_Valid = 0
  write ELD
  set ELD_Valid = 1
  
   So the audio driver would read the correct ELD unless the ELD 
   content
   and flag writes are somehow _reordered_ underneath. Or the ELD 
   content
   writes take some time to take effect?
   Just confirmed that adding 1s delay can fix it!
  
   New dmesg is:
  
   [   48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11]
   set [MODE:34:]
   [   48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on 
   pipe B
   [   48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2],
   [ENCODER:11:TMDS-11]
   [   48.571728] [drm:ironlake_write_eld], ELD on pipe B
   [   48.572882] [drm:ironlake_write_eld], Audio directed to unknown 
   port
   [   48.575252] [drm:ironlake_write_eld],
   [   48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
   ELD_Valid=0
   [   48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
   ELD_Valid=0
   [   48.580116] ELD size 13
   [   48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1
   ELD_Valid=1
   [   48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
   ELD_Valid=1
   [   48.632514] [drm:intel_wait_for_vblank], vblank wait timed out
   [   48.685322] [drm:intel_wait_for_vblank], vblank wait timed out
   [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
   plane 5, cursor: 6
   [   48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A -
   plane 5, cursor: 6
   [   48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B -
   plane 42, cursor: 6
   [   48.745204] [drm:intel_wait_for_vblank], vblank wait timed out
   [   48.798035] [drm:intel_wait_for_vblank], vblank wait timed out
   [   48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
   [   48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done.
   [   48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
   [   48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done.
   [   48.809426] [drm:ironlake_fdi_link_train], FDI train done
   [   48.813960] [drm:intel_update_fbc],
   [   48.814782] [drm:drm_crtc_helper_set_config], Setting connector
   DPMS state to on
   [   48.818093] [drm:drm_crtc_helper_set_config],
   [CONNECTOR:12:HDMI-A-2] set DPMS on
   [   48.828633] [drm:intel_prepare_page_flip], preparing flip with no
   unpin work?
   [   49.618962] HDMI: detected monitor RX-V1800 at connection type 
   HDMI
   [   49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC 
   RLC/RRC
   [   49.622304] HDMI: supports coding type LPCM: channels = 2, rates =
   32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
   [   49.625069] HDMI: supports coding type LPCM: channels = 8, rates =
   32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24
   [   49.628535] HDMI: supports coding type AC-3: channels = 6, rates =
   32000 44100 48000, max bitrate = 64
   [   49.630810] HDMI: supports coding type DTS: channels = 7, rates =
   32000 44100 48000 96000 176400, max bitrate = 1536000
   [   49.633148] HDMI: supports coding type DSD (One Bit Audio):
   channels = 6, rates = 44100
   [   49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital
   Plus): channels = 8, rates = 44100 48000
   [   49.637130] HDMI: supports coding type MLP (Dolby TrueHD):
   channels = 8, rates = 48000 176400 384000
   [   49.639172] HDMI: supports coding type

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Wu Fengguang

  Got the delay - it's 72.986623-72.747632 = 239ms.
 
   [   72.739944] HDMI hot plug event: Codec=3 Pin=6 
  Presence_Detect=1 ELD_Valid=0
   [   72.742541] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
  ELD_Valid=0
   [   72.745082] HDMI hot plug event: Codec=3 Pin=6 
  Presence_Detect=1 ELD_Valid=1
   [   72.747632] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
  ELD_Valid=1
   [   72.794240] [drm:intel_wait_for_vblank], vblank wait timed out
   [   72.848099] [drm:intel_wait_for_vblank], vblank wait timed out
   [   72.850507] [drm:ironlake_update_wm], FIFO watermarks For pipe 
  A - plane 5, cursor: 6
   [   72.853244] [drm:ironlake_update_wm], FIFO watermarks For pipe 
  B - plane 42, cursor: 6
   [   72.907937] [drm:intel_wait_for_vblank], vblank wait timed out
   [   72.960790] [drm:intel_wait_for_vblank], vblank wait timed out
   [   72.962757] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
   [   72.964880] [drm:ironlake_fdi_link_train], FDI train 1 done.
   [   72.968341] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
   [   72.970274] [drm:ironlake_fdi_link_train], FDI train 2 done.
   [   72.972535] [drm:ironlake_fdi_link_train], FDI train done
   [   72.976751] [drm:intel_update_fbc],
   [   72.977558] [drm:drm_crtc_helper_set_config], Setting connector 
  DPMS state to on
  ==  [   72.981550] [drm:drm_crtc_helper_set_config],
  [CONNECTOR:12:HDMI-A-2] set DPMS on
   [   72.986623] HDMI: detected monitor RX-V1800 at connection type 
  HDMI
   [   72.988260] HDMI: available speakers: FL/FR LFE FC RL/RR RC 
  RLC/RRC
 
  I wonder if the DPMS line has anything to do with the delay...
 
  Thanks,
  Fengguang
 
 Nice find! It does seem likely since the ELD read worked right after
 that. Hmm. I am not familiar with the event order for the Intel
 hardware, and what's calling your edid_to_eld code, etc. Is it possible
 to move the EDID read call to after the DPMS state is ready?

I added a dump_stack() at the very beginning of drm_crtc_helper_set_config().

Judging from drm_crtc_helper_set_config()'s comment and the below dmesg, it's
called by user space.
 
[   84.470633] Pid: 2893, comm: Xorg Tainted: GW3.2.0-rc1-eld+ #244
[   84.472188] Call Trace:
[   84.472795]  [8195dfba] ? printk+0x41/0x43
[   84.474011]  [8148aa04] drm_crtc_helper_set_config+0x24/0x852
[   84.476342]  [81493e52] ? drm_ut_debug_printk+0x57/0x5e
[   84.477743]  [8196052d] ? mutex_unlock+0xe/0x10
[   84.479015]  [8149a403] ? drm_mode_object_find+0x61/0x70
[   84.481326]  [8149b632] drm_mode_setcrtc+0x35d/0x38e
[   84.482679]  [8196052d] ? mutex_unlock+0xe/0x10
[   84.483934]  [8148efc6] drm_ioctl+0x2c0/0x38c
[   84.486033]  [8149b2d5] ? drm_mode_getencoder+0x9b/0x9b
[   84.487463]  [811567b0] do_vfs_ioctl+0x490/0x4d1
[   84.489657]  [81156838] sys_ioctl+0x47/0x6b
[   84.490780]  [8149a3cf] ? drm_mode_object_find+0x2d/0x70
[   84.492235]  [81968a82] system_call_fastpath+0x16/0x1b
[   84.495536] [drm:drm_crtc_helper_set_config], 
[   84.496561] [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:31] #connectors=1 
(x y) (0 0)
[   84.498323] [drm:drm_crtc_helper_set_config], modes are different, full mode 
set
[   84.499958] [drm:drm_mode_debug_printmodeline], Modeline 27:720x576 50 
27000 720 732 796 864 576 581 586 625 0x40 0xa
[   84.502454] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 
736 798 858 480 489 495 525 0x0 0xa
[   84.504672] [drm:drm_crtc_helper_set_config], [CONNECTOR:5:VGA-1] to [CRTC:3]
[   84.506205] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] to 
[CRTC:4]
[   84.507869] [drm:drm_crtc_helper_set_config], attempting to set mode from 
userspace
[   84.509699] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 
736 798 858 480 489 495 525 0x0 0xa
[   84.511903] [drm:drm_crtc_helper_set_mode], [CRTC:4]
[   84.521961] [drm:intel_prepare_page_flip], preparing flip with no unpin work?
[   84.564804] [drm:intel_wait_for_vblank], vblank wait timed out
[   84.603175] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, 
cursor: 6
[   84.606681] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, 
cursor: 6
[   84.610472] [drm:intel_update_fbc], 
[   84.611501] [drm:intel_choose_pipe_bpp_dither], forcing bpc to 8 for HDMI
[   84.613791] [drm:intel_choose_pipe_bpp_dither], setting pipe bpc to 8 (max 
display bpc 8)
[   84.616531] [drm:ironlake_crtc_mode_set], Mode for pipe 1:
[   84.617884] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 
736 798 858 480 489 495 525 0x0 0xa
[   84.622337] [drm:ironlake_crtc_mode_set], disabling CxSR downclocking
[   84.676554] [drm:intel_wait_for_vblank], vblank wait timed out
[   84.678981] [drm:ironlake_update_plane], Writing base 00343000

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Wu Fengguang

On Thu, Nov 10, 2011 at 09:47:46PM +0800, Wu Fengguang wrote:
   Got the delay - it's 72.986623-72.747632 = 239ms.
  
[   72.739944] HDMI hot plug event: Codec=3 Pin=6 
   Presence_Detect=1 ELD_Valid=0
[   72.742541] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
   ELD_Valid=0
[   72.745082] HDMI hot plug event: Codec=3 Pin=6 
   Presence_Detect=1 ELD_Valid=1
[   72.747632] HDMI status: Codec=3 Pin=6 Presence_Detect=1 
   ELD_Valid=1
[   72.794240] [drm:intel_wait_for_vblank], vblank wait timed out
[   72.848099] [drm:intel_wait_for_vblank], vblank wait timed out
[   72.850507] [drm:ironlake_update_wm], FIFO watermarks For 
   pipe A - plane 5, cursor: 6
[   72.853244] [drm:ironlake_update_wm], FIFO watermarks For 
   pipe B - plane 42, cursor: 6
[   72.907937] [drm:intel_wait_for_vblank], vblank wait timed out
[   72.960790] [drm:intel_wait_for_vblank], vblank wait timed out
[   72.962757] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100
[   72.964880] [drm:ironlake_fdi_link_train], FDI train 1 done.
[   72.968341] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600
[   72.970274] [drm:ironlake_fdi_link_train], FDI train 2 done.
[   72.972535] [drm:ironlake_fdi_link_train], FDI train done
[   72.976751] [drm:intel_update_fbc],
[   72.977558] [drm:drm_crtc_helper_set_config], Setting 
   connector DPMS state to on
   ==  [   72.981550] [drm:drm_crtc_helper_set_config],
   [CONNECTOR:12:HDMI-A-2] set DPMS on
[   72.986623] HDMI: detected monitor RX-V1800 at connection 
   type HDMI
[   72.988260] HDMI: available speakers: FL/FR LFE FC RL/RR RC 
   RLC/RRC
  
   I wonder if the DPMS line has anything to do with the delay...
  
   Thanks,
   Fengguang
  
  Nice find! It does seem likely since the ELD read worked right after
  that. Hmm. I am not familiar with the event order for the Intel
  hardware, and what's calling your edid_to_eld code, etc. Is it possible
  to move the EDID read call to after the DPMS state is ready?
 
 I added a dump_stack() at the very beginning of drm_crtc_helper_set_config().
 
 Judging from drm_crtc_helper_set_config()'s comment and the below dmesg, it's
 called by user space.
  
 [   84.470633] Pid: 2893, comm: Xorg Tainted: GW3.2.0-rc1-eld+ 
 #244
 [   84.472188] Call Trace:
 [   84.472795]  [8195dfba] ? printk+0x41/0x43
 [   84.474011]  [8148aa04] drm_crtc_helper_set_config+0x24/0x852
 [   84.476342]  [81493e52] ? drm_ut_debug_printk+0x57/0x5e
 [   84.477743]  [8196052d] ? mutex_unlock+0xe/0x10
 [   84.479015]  [8149a403] ? drm_mode_object_find+0x61/0x70
 [   84.481326]  [8149b632] drm_mode_setcrtc+0x35d/0x38e
 [   84.482679]  [8196052d] ? mutex_unlock+0xe/0x10
 [   84.483934]  [8148efc6] drm_ioctl+0x2c0/0x38c
 [   84.486033]  [8149b2d5] ? drm_mode_getencoder+0x9b/0x9b
 [   84.487463]  [811567b0] do_vfs_ioctl+0x490/0x4d1
 [   84.489657]  [81156838] sys_ioctl+0x47/0x6b
 [   84.490780]  [8149a3cf] ? drm_mode_object_find+0x2d/0x70
 [   84.492235]  [81968a82] system_call_fastpath+0x16/0x1b
 [   84.495536] [drm:drm_crtc_helper_set_config], 
 [   84.496561] [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:31] 
 #connectors=1 (x y) (0 0)
 [   84.498323] [drm:drm_crtc_helper_set_config], modes are different, full 
 mode set
 [   84.499958] [drm:drm_mode_debug_printmodeline], Modeline 27:720x576 50 
 27000 720 732 796 864 576 581 586 625 0x40 0xa
 [   84.502454] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 
 736 798 858 480 489 495 525 0x0 0xa
 [   84.504672] [drm:drm_crtc_helper_set_config], [CONNECTOR:5:VGA-1] to 
 [CRTC:3]
 [   84.506205] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] to 
 [CRTC:4]
 [   84.507869] [drm:drm_crtc_helper_set_config], attempting to set mode from 
 userspace
 [   84.509699] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 
 736 798 858 480 489 495 525 0x0 0xa
 [   84.511903] [drm:drm_crtc_helper_set_mode], [CRTC:4]
 [   84.521961] [drm:intel_prepare_page_flip], preparing flip with no unpin 
 work?
 [   84.564804] [drm:intel_wait_for_vblank], vblank wait timed out
 [   84.603175] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 
 5, cursor: 6
 [   84.606681] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 
 42, cursor: 6
 [   84.610472] [drm:intel_update_fbc], 
 [   84.611501] [drm:intel_choose_pipe_bpp_dither], forcing bpc to 8 for HDMI
 [   84.613791] [drm:intel_choose_pipe_bpp_dither], setting pipe bpc to 8 (max 
 display bpc 8)
 [   84.616531] [drm:ironlake_crtc_mode_set], Mode for pipe 1:
 [   84.617884] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 
 736 798 858 480 489 495 525 0x0 0xa
 [   84.622337] [drm:ironlake_crtc_mode_set],

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Takashi Iwai

At Thu, 10 Nov 2011 21:51:50 +0800,
Wu Fengguang wrote:
 
 So maybe the hardware is in some state that is unable to provide the
 real ELD content?
That's my guess as well. I think the hardware may still be doing some 
form of data negotiation with the HDMI display device at that stage, 
and 
doesn't have the copy of the EDID+ELD buffer until a tiny bit later. 
Possibly?
   
   Look at the below dmesg. The ELD seem to available immediately after the 
   DPMS
   state setting..
  
  Interesting.  Does HDMI audio work at all while HDMI DPMS off?
  It clears SDVO_ENABLE bit, so this might turn off both video and
  audio?
 
 We normally see transient blank screen and silence of audio when
 switching the video mode.

Well, what I suspected is that ELD won't be transferred while
SDVO_ENABLE is cleared.  And I'm not sure whether HDMI audio is played
while DPMS is off.  I haven't tested it.

Unfortunately I can't test it right now since my colleague is using a
desk where the HDMI monitor is on...


Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: prevent division by zero when asking for chipset power

2011-11-10 Thread Eugeni Dodonov

This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.

The issue can be reproduced easily via the following command:
while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done

This is particularly dangerous because it can be triggered by
a non-privileged user by just reading the debugfs entry.

This issue was also found independently by Konstantin Belousov
kostik...@gmail.com, who proposed a similar patch.

Reported-by: Konstantin Belousov kostik...@gmail.com
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
Acked-by: Keith Packard kei...@keithp.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@vger.kernel.org
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
 drivers/gpu/drm/i915/i915_dma.c |   10 ++
 drivers/gpu/drm/i915/i915_drv.h |1 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8a3942c..c72b590 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1453,6 +1453,14 @@ unsigned long i915_chipset_val(struct drm_i915_private 
*dev_priv)
 
diff1 = now - dev_priv-last_time1;
 
+   /* Prevent division-by-zero if we are asking too fast.
+* Also, we don't get interesting results if we are polling
+* faster than once in 10ms, so just return the saved value
+* in such cases.
+*/
+   if (diff1 = 10)
+   return dev_priv-chipset_power;
+
count1 = I915_READ(DMIEC);
count2 = I915_READ(DDREC);
count3 = I915_READ(CSIEC);
@@ -1483,6 +1491,8 @@ unsigned long i915_chipset_val(struct drm_i915_private 
*dev_priv)
dev_priv-last_count1 = total_count;
dev_priv-last_time1 = now;
 
+   dev_priv-chipset_power = ret;
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..1a2a2d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -707,6 +707,7 @@ typedef struct drm_i915_private {
 
u64 last_count1;
unsigned long last_time1;
+   unsigned long chipset_power;
u64 last_count2;
struct timespec last_time2;
unsigned long gfx_power;
-- 
1.7.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: fix swizzle detection for gen3

2011-11-10 Thread Daniel Vetter

It looks like the desktop variants of i915 and i945 also have the DCC
register to control dram channel interleave and cpu side bit6
swizzling.

Unfortunately internal Cspec/ConfigDB documentation for these ancient chips
have already been dropped and there seem to be no archives. Also
somebody thought the swizzling behaviour is surely a worthy secret to
keep and redacted any mention of these fields from the published Intel
datasheets.

I suspect the hw engineers were really proud of the page coloring
they've achieved in their first dual channel dram controller with
bit17 - after all Bspec explains in great length the optimal layout of
page frame numbers modulo 4 for the color and depth buffers, too.
Later on when they've started to work on VT-d they shamefully
discoverd their stupidity and tried to cover the tracks ...

Tested-by: Daniel Vetter daniel.vet...@ffwll.ch (i915g)
Tested-by: Pavel Ondračka pavel.ondra...@email.cz (i945g)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42625
Cc: sta...@kernel.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---

v2: Spelling fix in the commit msg.

 drivers/gpu/drm/i915/i915_gem_tiling.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 31d334d..861223b 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -107,10 +107,10 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
 */
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
-   } else if (IS_MOBILE(dev)) {
+   } else if (IS_MOBILE(dev) || (IS_GEN3(dev)  !IS_G33(dev))) {
uint32_t dcc;
 
-   /* On mobile 9xx chipsets, channel interleave by the CPU is
+   /* On 9xx chipsets, channel interleave by the CPU is
 * determined by DCC.  For single-channel, neither the CPU
 * nor the GPU do swizzling.  For dual channel interleaved,
 * the GPU's interleave is bit 9 and 10 for X tiled, and bit
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: add debugfs file for swizzling information

2011-11-10 Thread Daniel Vetter

This will also come handy for the gen6+ swizzling support, where the
driver is supposed to control swizzling depending upon dram
configuration.

v2: CxDRB3 are 16 bit regs! Noticed by Chris Wilson.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---

v3: align case blocks with the switch statement.

 drivers/gpu/drm/i915/i915_debugfs.c |   50 +++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ad2237..a0659f9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1334,6 +1334,55 @@ static int i915_gen6_forcewake_count_info(struct 
seq_file *m, void *data)
return 0;
 }
 
+static const char *swizzle_string(unsigned swizzle)
+{
+   switch(swizzle) {
+   case I915_BIT_6_SWIZZLE_NONE:
+   return none;
+   case I915_BIT_6_SWIZZLE_9:
+   return bit9;
+   case I915_BIT_6_SWIZZLE_9_10:
+   return bit9/bit10;
+   case I915_BIT_6_SWIZZLE_9_11:
+   return bit9/bit11;
+   case I915_BIT_6_SWIZZLE_9_10_11:
+   return bit9/bit10/bit11;
+   case I915_BIT_6_SWIZZLE_9_17:
+   return bit9/bit17;
+   case I915_BIT_6_SWIZZLE_9_10_17:
+   return bit9/bit10/bit17;
+   case I915_BIT_6_SWIZZLE_UNKNOWN:
+   return unkown;
+   }
+
+   return bug;
+}
+
+static int i915_swizzle_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m-private;
+   struct drm_device *dev = node-minor-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   mutex_lock(dev-struct_mutex);
+   seq_printf(m, bit6 swizzle for X-tiling = %s\n,
+  swizzle_string(dev_priv-mm.bit_6_swizzle_x));
+   seq_printf(m, bit6 swizzle for Y-tiling = %s\n,
+  swizzle_string(dev_priv-mm.bit_6_swizzle_y));
+
+   if (IS_GEN3(dev) || IS_GEN4(dev)) {
+   seq_printf(m, DDC = 0x%08x\n,
+  I915_READ(DCC));
+   seq_printf(m, C0DRB3 = 0x%04x\n,
+  I915_READ16(C0DRB3));
+   seq_printf(m, C1DRB3 = 0x%04x\n,
+  I915_READ16(C1DRB3));
+   }
+   mutex_unlock(dev-struct_mutex);
+
+   return 0;
+}
+
 static int
 i915_debugfs_common_open(struct inode *inode,
 struct file *filp)
@@ -1732,6 +1781,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_gem_framebuffer, i915_gem_framebuffer_info, 0},
{i915_context_status, i915_context_status, 0},
{i915_gen6_forcewake_count, i915_gen6_forcewake_count_info, 0},
+   {i915_swizzle_info, i915_swizzle_info, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
 
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/9] drm/i915: refactor debugfs create functions

2011-11-10 Thread Ben Widawsky

On Thu, Nov 10, 2011 at 02:18:00PM +0100, Daniel Vetter wrote:
 All r/w debugfs files are created equal.
 
 v2: Add some newlines to make the code easier on the eyes as requested
 by Ben Widawsky.
 
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ben Widawsky b...@bwidawsk.net
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Intel black screen

2011-11-10 Thread James M. Leddy

On 11/10/2011 09:12 AM, Paulo J. Matos wrote:
 Hi,
 
 I got a new PC DELL Vostro 360. This is an all-in-one which uses the
 Optimus setup. An intel GT1 (Sandybridge) couples with an Nvidia 525m.
 Ubuntu out of the box shows a black screen unless I add nomodeset to
 kernel options.

That sounds a lot like this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=42278

It can be worked around by using vesafb instead of i915.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/9] gpu hang and swizzle patches

2011-11-10 Thread Chris Wilson

On Thu, 10 Nov 2011 14:17:58 +0100, Daniel Vetter daniel.vet...@ffwll.ch 
wrote:
 Hi all,
 
 This is a bit a mixed pile, but I've used all the earlier patches to test
 the gen6+ swizzling patch and I like to send out patch series somewhat
 resembling the setup I've tested them in.
 
 Patches 1-2 refactor our debugfs code a bit.
 Patches 3-5 implement a debugfs interface to simulate a gpu hang Patch 6
 fixes the swizzle detection on i915G/i945G. This one is for stable and
 independent of the previous patches.
 Patches 7-8 add a debugfs file with information to debug swizzle issues
 Patch 9 implements swizzle support for snb/ivb when in dual-channel mode
 
 Benchmarking on my snb is notoriously difficult, but swizzling seems to
 yield a few percent in some workloads, topping out at 5% for padman.
 
 Review highly welcome.

I've had a play and could barely detect any improvement above the noise.
However, I've read through all the patches and passed on my comments and
I don't see anything fundamentally wrong with them (though I see enough
GPU hangs not to need to manually trigger one ;-).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drivers: i915: Fix BLC PWM register setup

2011-11-10 Thread Simon Que

There is an error in i915_read_blc_pwm_ctl, where the register values
are not being copied correctly.  BLC_PWM_CTL and BLC_PWM_CTL2 are
getting mixed up.  This patch fixes that so that saveBLC_PWM_CTL2 and
not saveBLC_PWM_CTL is copied to the BLC_PWM_CTL2 register.

Signed-off-by: Simon Que s...@chromium.org
---
 drivers/gpu/drm/i915/intel_panel.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index a9e0c7b..f15388c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -141,8 +141,8 @@ static u32 i915_read_blc_pwm_ctl(struct drm_i915_private 
*dev_priv)
dev_priv-saveBLC_PWM_CTL2 = val;
} else if (val == 0) {
I915_WRITE(BLC_PWM_PCH_CTL2,
-  dev_priv-saveBLC_PWM_CTL);
-   val = dev_priv-saveBLC_PWM_CTL;
+  dev_priv-saveBLC_PWM_CTL2);
+   val = dev_priv-saveBLC_PWM_CTL2;
}
} else {
val = I915_READ(BLC_PWM_CTL);
-- 
1.7.3.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drivers: i915: Default backlight PWM frequency

2011-11-10 Thread Olof Johansson

Hi,

On Thu, Nov 10, 2011 at 5:50 PM, Simon Que s...@chromium.org wrote:
 If the firmware did not initialize the backlight PWM registers, set up a
 default PWM frequency of 200 Hz.  This is determined using the following
 formula:

  freq = refclk / (128 * pwm_max)

 The PWM register allows the max PWM value to be set.  So we want to use
 the formula, where freq = 200:

  pwm_max = refclk / (128 * freq)

 This patch will, in the case of missing PWM register initialization
 values, look for the reference clock frequency.  Based on that, it sets
 an appropriate max PWM value for a frequency of 200 Hz.

 If no refclk frequency is found, the max PWM will be zero, which results
 in no change to the PWM registers.

I think the general approach of finding a suitable PWM setting is
better this way, but you're attacking the problem at the wrong level.

There is already a place to hook in this in
intel_panel_get_max_backlight(): Do it there in the XXX add code
case, have the helper update the dev_priv fields to the calculated max
and call i915_read_blc_pwm_ctl() again to program said fields.


-Olof
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Wu Fengguang

On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote:
 At Thu, 10 Nov 2011 21:51:50 +0800,
 Wu Fengguang wrote:
  
  So maybe the hardware is in some state that is unable to provide the
  real ELD content?
 That's my guess as well. I think the hardware may still be doing some 
 form of data negotiation with the HDMI display device at that stage, 
 and 
 doesn't have the copy of the EDID+ELD buffer until a tiny bit later. 
 Possibly?

Look at the below dmesg. The ELD seem to available immediately after 
the DPMS
state setting..
   
   Interesting.  Does HDMI audio work at all while HDMI DPMS off?
   It clears SDVO_ENABLE bit, so this might turn off both video and
   audio?
  
  We normally see transient blank screen and silence of audio when
  switching the video mode.
 
 Well, what I suspected is that ELD won't be transferred while
 SDVO_ENABLE is cleared.

It's not about SDVO_ENABLE. The transient ELD invalid state I see in
dmesg is caused by the graphics driver doing

ELD_Valid = 0   = trigger 1st unsolicited event
write ELD contents
ELD_Valid = 1   = trigger 2nd unsolicited event

The two unsolicited events are described in Figure 72. PD and ELDV
unsolicited responses flow for digital display codecs of the High
Definition Audio Specification Rev. 1.0a.

[  467.574207] [drm:ironlake_write_eld], ELD on pipe B
[  467.579346] [drm:ironlake_write_eld], Audio directed to 
unknown port
[  467.584724] [drm:ironlake_write_eld], ELD: DisplayPort 
detected
1st event =[  467.586540] HDMI hot plug event: Codec=3 Pin=7 
Presence_Detect=1 ELD_Valid=0
[  467.599608] [drm:ironlake_write_eld], 
1st event =[  467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 
ELD_Valid=0
[  467.605834] ELD size 9
[  467.610434] [drm:sandybridge_update_wm], FIFO watermarks For 
pipe A - plane 7, cursor: 6
2nd event =[  467.612365] HDMI hot plug event: Codec=3 Pin=7 
Presence_Detect=1 ELD_Valid=1
[  467.620654] [drm:sandybridge_update_wm], 
2nd event =[  467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 
ELD_Valid=1

Depending on the timing, the 1st unsolicited event may see
ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event
handling is delayed after the graphics driver sets ELD_Valid=1).

I know that because I literally saw both cases happening in dmesg.
The 1st hot plug event itself will send ELD_Valid=0, however the audio
driver is not trusting this and always do a status query (the HDMI
status line) whose result depends on the timing.

 And I'm not sure whether HDMI audio is played
 while DPMS is off.  I haven't tested it.

It will go silence on DPMS. I noticed this while doing long term HDMI
audio playback tests.  This should better be fixed in future on the
graphics side.

 Unfortunately I can't test it right now since my colleague is using a
 desk where the HDMI monitor is on...

I'm always borrowing HDMI/DP monitors and test boxes, too ;-)

Thanks,
Fengguang
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drivers: i915: Default backlight PWM frequency

2011-11-10 Thread Simon Que

If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz.  This is determined using the following
formula:

  freq = refclk / (128 * pwm_max)

The PWM register allows the max PWM value to be set.  So we want to use
the formula, where freq = 200:

  pwm_max = refclk / (128 * freq)

This patch will, in the case of missing PWM register initialization
values, look for the reference clock frequency.  Based on that, it sets
an appropriate max PWM value for a frequency of 200 Hz.

If no refclk frequency is found, the max PWM will be zero, which results
in no change to the PWM registers.

Signed-off-by: Simon Que s...@chromium.org
---
 drivers/gpu/drm/i915/i915_reg.h|1 +
 drivers/gpu/drm/i915/intel_panel.c |   37 +--
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5d5def7..a832028 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3275,6 +3275,7 @@
 #define  PWM_POLARITY_ACTIVE_HIGH2 (0  28)
 
 #define BLC_PWM_PCH_CTL2   0xc8254
+#define BLC_PWM_PCH_FREQ_SHIFT 16
 
 #define PCH_PP_STATUS  0xc7200
 #define PCH_PP_CONTROL 0xc7204
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index f15388c..f865e52 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,6 +32,10 @@
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
 
+/* For computing default PWM settings */
+#define DEFAULT_BACKLIGHT_PWM_FREQ   200
+#define BACKLIGHT_REFCLK_DIVISOR 128
+
 void
 intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
   struct drm_display_mode *adjusted_mode)
@@ -129,12 +133,31 @@ static int is_backlight_combination_mode(struct 
drm_device *dev)
return 0;
 }
 
+static u32 i915_get_default_max_backlight(struct drm_i915_private *dev_priv)
+{
+   u32 refclk_freq_mhz = 0;
+   u32 max_pwm = 0;
+   if (HAS_PCH_SPLIT(dev_priv-dev))
+   refclk_freq_mhz = I915_READ(PCH_RAWCLK_FREQ)  RAWCLK_FREQ_MASK;
+   else if (dev_priv-lvds_use_ssc)
+   refclk_freq_mhz = dev_priv-lvds_ssc_freq;
+
+   max_pwm = refclk_freq_mhz * 100 /
+   (BACKLIGHT_REFCLK_DIVISOR * DEFAULT_BACKLIGHT_PWM_FREQ);
+
+   if (HAS_PCH_SPLIT(dev_priv-dev))
+   dev_priv-saveBLC_PWM_CTL2 = max_pwm  BLC_PWM_PCH_FREQ_SHIFT;
+   else
+   dev_priv-saveBLC_PWM_CTL = max_pwm 
+   BACKLIGHT_MODULATION_FREQ_SHIFT;
+   return max_pwm;
+}
+
 static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
 {
u32 val;
 
-   /* Restore the CTL value if it lost, e.g. GPU reset */
-
+   /* Restore the CTL value if it was lost, e.g. GPU reset */
if (HAS_PCH_SPLIT(dev_priv-dev)) {
val = I915_READ(BLC_PWM_PCH_CTL2);
if (dev_priv-saveBLC_PWM_CTL2 == 0) {
@@ -168,11 +191,11 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
 
max = i915_read_blc_pwm_ctl(dev_priv);
if (max == 0) {
-   /* XXX add code here to query mode clock or hardware clock
-* and program max PWM appropriately.
-*/
-   printk_once(KERN_WARNING fixme: max PWM is zero.\n);
-   return 1;
+   /* If backlight PWM registers have not been set, set them to */
+   /* default backlight PWM settings. */
+   max = i915_get_default_max_backlight(dev_priv);
+   i915_read_blc_pwm_ctl(dev_priv);
+   return max;
}
 
if (HAS_PCH_SPLIT(dev)) {
-- 
1.7.2.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] i915 visual artifacts with Firefox and Thunderbird under Wine

2011-11-10 Thread Alex Henrie

Hello,

I recently reported a graphics bug that occurs when running the
Windows versions of Firefox and Thunderbird under Wine. The Wine
developers think that this is probably a bug in the i915 driver. Could
the i915 developers take a look?
http://bugs.winehq.org/show_bug.cgi?id=29027

-Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-10 Thread Takashi Iwai

At Fri, 11 Nov 2011 10:29:25 +0800,
Wu Fengguang wrote:
 
 On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 21:51:50 +0800,
  Wu Fengguang wrote:
   
   So maybe the hardware is in some state that is unable to provide 
   the
   real ELD content?
  That's my guess as well. I think the hardware may still be doing 
  some 
  form of data negotiation with the HDMI display device at that 
  stage, and 
  doesn't have the copy of the EDID+ELD buffer until a tiny bit 
  later. 
  Possibly?
 
 Look at the below dmesg. The ELD seem to available immediately after 
 the DPMS
 state setting..

Interesting.  Does HDMI audio work at all while HDMI DPMS off?
It clears SDVO_ENABLE bit, so this might turn off both video and
audio?
   
   We normally see transient blank screen and silence of audio when
   switching the video mode.
  
  Well, what I suspected is that ELD won't be transferred while
  SDVO_ENABLE is cleared.
 
 It's not about SDVO_ENABLE. The transient ELD invalid state I see in
 dmesg is caused by the graphics driver doing
 
 ELD_Valid = 0   = trigger 1st unsolicited event

But why this triggers at *plugging*?  Wasn't it zero beforehand?
If I understand correctly, changing AUD_CNTL_ST register triggers the
HD-audio codec unsol event.  Writing even the same value matters?


 write ELD contents
 ELD_Valid = 1   = trigger 2nd unsolicited event
 
 The two unsolicited events are described in Figure 72. PD and ELDV
 unsolicited responses flow for digital display codecs of the High
 Definition Audio Specification Rev. 1.0a.
 
 [  467.574207] [drm:ironlake_write_eld], ELD on pipe B
 [  467.579346] [drm:ironlake_write_eld], Audio directed to 
 unknown port
 [  467.584724] [drm:ironlake_write_eld], ELD: DisplayPort 
 detected
 1st event =[  467.586540] HDMI hot plug event: Codec=3 Pin=7 
 Presence_Detect=1 ELD_Valid=0
 [  467.599608] [drm:ironlake_write_eld], 
 1st event =[  467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 
 ELD_Valid=0
 [  467.605834] ELD size 9
 [  467.610434] [drm:sandybridge_update_wm], FIFO watermarks 
 For pipe A - plane 7, cursor: 6
 2nd event =[  467.612365] HDMI hot plug event: Codec=3 Pin=7 
 Presence_Detect=1 ELD_Valid=1
 [  467.620654] [drm:sandybridge_update_wm], 
 2nd event =[  467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 
 ELD_Valid=1
 
 Depending on the timing, the 1st unsolicited event may see
 ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event
 handling is delayed after the graphics driver sets ELD_Valid=1).
 
 I know that because I literally saw both cases happening in dmesg.
 The 1st hot plug event itself will send ELD_Valid=0, however the audio
 driver is not trusting this and always do a status query (the HDMI
 status line) whose result depends on the timing.

The problem in this procedure is that this looks as if you are
re-connecting the HDMI from the audio-codec POV.
We might end up with some delayed probe with a dedicated work_struct
(because it's bad to have a too long delay in unsol event handler
 that run on a single workq).


  And I'm not sure whether HDMI audio is played
  while DPMS is off.  I haven't tested it.
 
 It will go silence on DPMS. I noticed this while doing long term HDMI
 audio playback tests.  This should better be fixed in future on the
 graphics side.

Hm, but I wonder what could be done alternatively.
Hopefully there is a register for video-only control...


thanks,

Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

39 matches

Mail list logo