* bad panel power sequencing delays, disabling panel
@ 2012-10-13 5:28 Daniel J Blueman
2012-10-16 13:26 ` Daniel J Blueman
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2012-10-13 5:28 UTC (permalink / raw)
To: intel-gfx
On my Macbook Retina 2012, after a recent firmware update, i915 fails
to use the eDP-1 panel [1], which goes blank when switched to. Nouveau
works correctly though [2]. I see this behaviour on 3.6-rc to 3.6.2.
Full boot and IGD switch (see end) kernel logs at
http://quora.org/2012/mbp-i915-panel.txt with drm.debug=0x6. What
additional information is needed to diagnose this?
Thanks,
Daniel
--- [1]
nouveau 0000:01:00.0: enabling device (0006 -> 0007)
[drm] nouveau 0000:01:00.0: Detected an NVe0 generation card (0x0e7150a2)
[drm] nouveau 0000:01:00.0: acceleration disabled by default, pass
noaccel=0 to force enable
checking generic (90020000 1c20000) vs hw (90000000 10000000)
fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
ACPI: Invalid Power Resource to register!
Console: switching to colour dummy device 80x25
[drm] nouveau 0000:01:00.0: Checking PRAMIN for VBIOS
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: Using VBIOS from PRAMIN
[drm] nouveau 0000:01:00.0: BIT BIOS found
[drm] nouveau 0000:01:00.0: Bios version 80.07.26.04
[drm] nouveau 0000:01:00.0: TMDS table version 2.0
[drm] nouveau 0000:01:00.0: MXM: no VBIOS data, nothing to do
[drm] nouveau 0000:01:00.0: DCB version 4.0
[drm] nouveau 0000:01:00.0: DCB outp 00: 048101b6 0f230010
[drm] nouveau 0000:01:00.0: DCB outp 01: 018212d6 0f220020
[drm] nouveau 0000:01:00.0: DCB outp 02: 01021212 00020020
[drm] nouveau 0000:01:00.0: DCB outp 03: 088324c6 0f220010
[drm] nouveau 0000:01:00.0: DCB outp 04: 08032402 00020010
[drm] nouveau 0000:01:00.0: DCB outp 05: 02843862 00020010
[drm] nouveau 0000:01:00.0: DCB conn 00: 00020047
[drm] nouveau 0000:01:00.0: DCB conn 01: 02208146
[drm] nouveau 0000:01:00.0: DCB conn 02: 01104246
[drm] nouveau 0000:01:00.0: DCB conn 03: 00410361
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0x86B5
[drm] nouveau 0000:01:00.0: 0x853A: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0x8EFC
[drm] nouveau 0000:01:00.0: 0x8F0A: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: 0x8F9B: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0x66E1
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xAAA0
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xAAA1
[drm] nouveau 0000:01:00.0: 0x85E7: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 5 at offset 0xAB59
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xABBE
[TTM] Zone kernel: Available graphics memory: 4043308 kiB
[TTM] Zone dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] nouveau 0000:01:00.0: Detected 1024MiB VRAM (GDDR5)
[drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] nouveau 0000:01:00.0: ACPI backlight interface available, not
registering our own
[drm] nouveau 0000:01:00.0: voltage table 0x50 unknown
[drm] nouveau 0000:01:00.0: 4 available performance level(s)
[drm] nouveau 0000:01:00.0: 1: core 209MHz shader 419MHz memory 405MHz
voltage 520mV
[drm] nouveau 0000:01:00.0: 2: core 390MHz shader 780MHz memory
1080MHz voltage 610mV
[drm] nouveau 0000:01:00.0: 3: core 1000MHz shader 2000MHz memory
1080MHz voltage 630mV
[drm] nouveau 0000:01:00.0: 4: core 1254MHz shader 2508MHz memory
1080MHz voltage 630mV
[drm] nouveau 0000:01:00.0: c:
[drm] nouveau 0000:01:00.0: allocated 2880x1800 fb: 0xe0000, bo ffff88026311b800
fbcon: nouveaufb (fb0) is primary device
Console: switching to colour frame buffer device 240x81
fb0: nouveaufb frame buffer device
drm: registered panic notifier
[drm] Initialized nouveau 1.0.0 20120316 for 0000:01:00.0 on minor 0
pci 0000:00:00.0: Intel Ivybridge Chipset
pci 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable
pci 0000:00:00.0: detected 65536K stolen memory
i915 0000:00:02.0: setting latency timer to 64
i915 0000:00:02.0: irq 53 for MSI/MSI-X
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
i915 0000:00:02.0: Invalid ROM contents
[drm] failed to find VBIOS tables
vgaarb: device changed decodes:
PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=none
vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[drm] bad panel power sequencing delays, disabling panel
[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2
No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
fb1: inteldrmfb frame buffer device
[Firmware Bug]: ACPI(GFX0) defines _DOD but not _DOS
ACPI: Video Device [GFX0] (multi-head: yes rom: yes post: no)
ACPI: Video Device [IGPU] (multi-head: yes rom: no post: no)
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 1
vga_switcheroo: enabled
--- [2] xrandr
Screen 0: minimum 320 x 200, current 2880 x 1800, maximum 8192 x 8192
eDP-1 connected 2880x1800+0+0 (normal left inverted right x axis y
axis) 331mm x 207mm
2880x1800 60.0*+
1920x1200 59.9
1920x1080 60.0
1600x1200 59.9
1680x1050 60.0
1400x1050 60.0
1280x1024 59.9
1280x960 59.9
1152x864 60.0
1024x768 59.9
800x600 59.9
640x480 59.4
720x400 59.6
640x400 60.0
640x350 59.8
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 12+ messages in thread
* bad panel power sequencing delays, disabling panel
2012-10-13 5:28 bad panel power sequencing delays, disabling panel Daniel J Blueman
@ 2012-10-16 13:26 ` Daniel J Blueman
2012-10-16 14:43 ` Daniel Vetter
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2012-10-16 13:26 UTC (permalink / raw)
To: intel-gfx
On my Macbook Retina 2012, after a recent firmware update, i915 fails
to use the eDP-1 panel [1], which goes blank when switched to. Nouveau
works correctly though [2]. I see this behaviour on 3.6-rc to 3.7-rc1.
Full boot and IGD switch (see end) kernel logs at
http://quora.org/2012/mbp-i915-panel.txt with drm.debug=0x6. What
additional information is needed to diagnose this?
Thanks,
Daniel
--- [1]
nouveau 0000:01:00.0: enabling device (0006 -> 0007)
[drm] nouveau 0000:01:00.0: Detected an NVe0 generation card (0x0e7150a2)
[drm] nouveau 0000:01:00.0: acceleration disabled by default, pass
noaccel=0 to force enable
checking generic (90020000 1c20000) vs hw (90000000 10000000)
fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
ACPI: Invalid Power Resource to register!
Console: switching to colour dummy device 80x25
[drm] nouveau 0000:01:00.0: Checking PRAMIN for VBIOS
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: Using VBIOS from PRAMIN
[drm] nouveau 0000:01:00.0: BIT BIOS found
[drm] nouveau 0000:01:00.0: Bios version 80.07.26.04
[drm] nouveau 0000:01:00.0: TMDS table version 2.0
[drm] nouveau 0000:01:00.0: MXM: no VBIOS data, nothing to do
[drm] nouveau 0000:01:00.0: DCB version 4.0
[drm] nouveau 0000:01:00.0: DCB outp 00: 048101b6 0f230010
[drm] nouveau 0000:01:00.0: DCB outp 01: 018212d6 0f220020
[drm] nouveau 0000:01:00.0: DCB outp 02: 01021212 00020020
[drm] nouveau 0000:01:00.0: DCB outp 03: 088324c6 0f220010
[drm] nouveau 0000:01:00.0: DCB outp 04: 08032402 00020010
[drm] nouveau 0000:01:00.0: DCB outp 05: 02843862 00020010
[drm] nouveau 0000:01:00.0: DCB conn 00: 00020047
[drm] nouveau 0000:01:00.0: DCB conn 01: 02208146
[drm] nouveau 0000:01:00.0: DCB conn 02: 01104246
[drm] nouveau 0000:01:00.0: DCB conn 03: 00410361
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0x86B5
[drm] nouveau 0000:01:00.0: 0x853A: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0x8EFC
[drm] nouveau 0000:01:00.0: 0x8F0A: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: 0x8F9B: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0x66E1
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xAAA0
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xAAA1
[drm] nouveau 0000:01:00.0: 0x85E7: Condition still not met after
20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 5 at offset 0xAB59
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xABBE
[TTM] Zone kernel: Available graphics memory: 4043308 kiB
[TTM] Zone dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] nouveau 0000:01:00.0: Detected 1024MiB VRAM (GDDR5)
[drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] nouveau 0000:01:00.0: ACPI backlight interface available, not
registering our own
[drm] nouveau 0000:01:00.0: voltage table 0x50 unknown
[drm] nouveau 0000:01:00.0: 4 available performance level(s)
[drm] nouveau 0000:01:00.0: 1: core 209MHz shader 419MHz memory 405MHz
voltage 520mV
[drm] nouveau 0000:01:00.0: 2: core 390MHz shader 780MHz memory
1080MHz voltage 610mV
[drm] nouveau 0000:01:00.0: 3: core 1000MHz shader 2000MHz memory
1080MHz voltage 630mV
[drm] nouveau 0000:01:00.0: 4: core 1254MHz shader 2508MHz memory
1080MHz voltage 630mV
[drm] nouveau 0000:01:00.0: c:
[drm] nouveau 0000:01:00.0: allocated 2880x1800 fb: 0xe0000, bo ffff88026311b800
fbcon: nouveaufb (fb0) is primary device
Console: switching to colour frame buffer device 240x81
fb0: nouveaufb frame buffer device
drm: registered panic notifier
[drm] Initialized nouveau 1.0.0 20120316 for 0000:01:00.0 on minor 0
pci 0000:00:00.0: Intel Ivybridge Chipset
pci 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable
pci 0000:00:00.0: detected 65536K stolen memory
i915 0000:00:02.0: setting latency timer to 64
i915 0000:00:02.0: irq 53 for MSI/MSI-X
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
i915 0000:00:02.0: Invalid ROM contents
[drm] failed to find VBIOS tables
vgaarb: device changed decodes:
PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=none
vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[drm] bad panel power sequencing delays, disabling panel
[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2
No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
fb1: inteldrmfb frame buffer device
[Firmware Bug]: ACPI(GFX0) defines _DOD but not _DOS
ACPI: Video Device [GFX0] (multi-head: yes rom: yes post: no)
ACPI: Video Device [IGPU] (multi-head: yes rom: no post: no)
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 1
vga_switcheroo: enabled
--- [2] xrandr
Screen 0: minimum 320 x 200, current 2880 x 1800, maximum 8192 x 8192
eDP-1 connected 2880x1800+0+0 (normal left inverted right x axis y
axis) 331mm x 207mm
2880x1800 60.0*+
1920x1200 59.9
1920x1080 60.0
1600x1200 59.9
1680x1050 60.0
1400x1050 60.0
1280x1024 59.9
1280x960 59.9
1152x864 60.0
1024x768 59.9
800x600 59.9
640x480 59.4
720x400 59.6
640x400 60.0
640x350 59.8
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-16 13:26 ` Daniel J Blueman
@ 2012-10-16 14:43 ` Daniel Vetter
2012-10-16 15:15 ` Daniel J Blueman
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2012-10-16 14:43 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: intel-gfx
On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman <daniel@quora.org> wrote:
> On my Macbook Retina 2012, after a recent firmware update, i915 fails
> to use the eDP-1 panel [1], which goes blank when switched to. Nouveau
> works correctly though [2]. I see this behaviour on 3.6-rc to 3.7-rc1.
I'm working on this, since when I plug in a 2nd screen in my own edp
machine, the bios doesn't light up the internal panel and our code
can't light it up, too. Unfortunately progress is slow, but you can
try my current wip state at
http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
Please attach dmesg with drm.debug=0xe if you try this kernel.
Backlight works now for me, but I still have issues with edp link
training here.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-16 14:43 ` Daniel Vetter
@ 2012-10-16 15:15 ` Daniel J Blueman
2012-10-16 15:16 ` Daniel Vetter
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2012-10-16 15:15 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
On 16 October 2012 22:43, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman <daniel@quora.org> wrote:
>> On my Macbook Retina 2012, after a recent firmware update, i915 fails
>> to use the eDP-1 panel [1], which goes blank when switched to. Nouveau
>> works correctly though [2]. I see this behaviour on 3.6-rc to 3.7-rc1.
>
> I'm working on this, since when I plug in a 2nd screen in my own edp
> machine, the bios doesn't light up the internal panel and our code
> can't light it up, too. Unfortunately progress is slow, but you can
> try my current wip state at
>
> http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
>
> Please attach dmesg with drm.debug=0xe if you try this kernel.
> Backlight works now for me, but I still have issues with edp link
> training here.
Thanks Daniel; I'm happy to collect local information/debug etc, sure.
Alas, it looks like that repo is in an unexpected state:
$ git clone git://people.freedesktop.org/~danvet/drm
Cloning into 'drm'...
remote: Counting objects: 2631581, done.
remote: Compressing objects: 100% (395986/395986), done.
remote: Total 2631581 (delta 2211094), reused 2630318 (delta 2209899)
Receiving objects: 100% (2631581/2631581), 615.36 MiB | 1.77 MiB/s, done.
Resolving deltas: 100% (2211094/2211094), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ cd drm && $ git branch
$
When it's in shape, I can try again.
Daniel
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-16 15:15 ` Daniel J Blueman
@ 2012-10-16 15:16 ` Daniel Vetter
2012-10-16 16:10 ` Daniel J Blueman
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2012-10-16 15:16 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: intel-gfx
On Tue, Oct 16, 2012 at 5:15 PM, Daniel J Blueman <daniel@quora.org> wrote:
> On 16 October 2012 22:43, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman <daniel@quora.org> wrote:
>>> On my Macbook Retina 2012, after a recent firmware update, i915 fails
>>> to use the eDP-1 panel [1], which goes blank when switched to. Nouveau
>>> works correctly though [2]. I see this behaviour on 3.6-rc to 3.7-rc1.
>>
>> I'm working on this, since when I plug in a 2nd screen in my own edp
>> machine, the bios doesn't light up the internal panel and our code
>> can't light it up, too. Unfortunately progress is slow, but you can
>> try my current wip state at
>>
>> http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
>>
>> Please attach dmesg with drm.debug=0xe if you try this kernel.
>> Backlight works now for me, but I still have issues with edp link
>> training here.
>
> Thanks Daniel; I'm happy to collect local information/debug etc, sure.
>
> Alas, it looks like that repo is in an unexpected state:
>
> $ git clone git://people.freedesktop.org/~danvet/drm
> Cloning into 'drm'...
> remote: Counting objects: 2631581, done.
> remote: Compressing objects: 100% (395986/395986), done.
> remote: Total 2631581 (delta 2211094), reused 2630318 (delta 2209899)
> Receiving objects: 100% (2631581/2631581), 615.36 MiB | 1.77 MiB/s, done.
> Resolving deltas: 100% (2211094/2211094), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
That thing is totally in the expected shape, it simply does not have a
HEAD, but only branches
$ git branch -r
will list them all, and
$ git checkout -t remote-branchname
will check out origin/remote-branchname and create a branch
remote-branchname tracking it.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-16 15:16 ` Daniel Vetter
@ 2012-10-16 16:10 ` Daniel J Blueman
2012-10-16 16:43 ` Daniel Vetter
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2012-10-16 16:10 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
On 16 October 2012 23:16, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Oct 16, 2012 at 5:15 PM, Daniel J Blueman <daniel@quora.org> wrote:
>> On 16 October 2012 22:43, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman <daniel@quora.org> wrote:
>>>> On my Macbook Retina 2012, after a recent firmware update, i915 fails
>>>> to use the eDP-1 panel [1], which goes blank when switched to. Nouveau
>>>> works correctly though [2]. I see this behaviour on 3.6-rc to 3.7-rc1.
>>>
>>> I'm working on this, since when I plug in a 2nd screen in my own edp
>>> machine, the bios doesn't light up the internal panel and our code
>>> can't light it up, too. Unfortunately progress is slow, but you can
>>> try my current wip state at
>>>
>>> http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
>>>
>>> Please attach dmesg with drm.debug=0xe if you try this kernel.
>>> Backlight works now for me, but I still have issues with edp link
>>> training here.
>>
>> Thanks Daniel; I'm happy to collect local information/debug etc, sure.
>>
>> Alas, it looks like that repo is in an unexpected state:
[...]
> That thing is totally in the expected shape, it simply does not have a
> HEAD, but only branches
That worked, thanks. Booting, we see:
[drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
[drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
[drm:intel_dp_init], panel power up delay 21, power down delay 50,
power cycle delay 400
[drm:intel_dp_init], backlight on delay 5, off delay 5
[drm:intel_dp_init], panel power sequencer register settings: PP_ON
0x40d20032, PP_OFF 0x1f40032, PP_DIV 0x186904
[drm:intel_dp_i2c_init], i2c_init DPDDC-A
[drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
[drm:ironlake_edp_panel_vdd_on], eDP VDD already on
[drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
[drm:intel_dp_i2c_aux_ch], aux_ch failed -110
Notable, the nvidia DP init script executed fine; perhaps tracing the
I2C access may be useful?
Full boot log at http://quora.org/2012/mbp-i915-panel-2.txt .
Thanks,
Daniel
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-16 16:10 ` Daniel J Blueman
@ 2012-10-16 16:43 ` Daniel Vetter
2012-10-24 5:27 ` Daniel J Blueman
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2012-10-16 16:43 UTC (permalink / raw)
To: Daniel J Blueman, Dave Airlie; +Cc: intel-gfx
On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman <daniel@quora.org> wrote:
> [drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
> [drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
> [drm:intel_dp_init], panel power up delay 21, power down delay 50,
> power cycle delay 400
> [drm:intel_dp_init], backlight on delay 5, off delay 5
> [drm:intel_dp_init], panel power sequencer register settings: PP_ON
> 0x40d20032, PP_OFF 0x1f40032, PP_DIV 0x186904
> [drm:intel_dp_i2c_init], i2c_init DPDDC-A
> [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
> [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
> [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
>
> Notable, the nvidia DP init script executed fine; perhaps tracing the
> I2C access may be useful?
Hm, dp aux transfer don't work (this is the first one in the setup
sequence, so it's not an i2c over aux issue with the edid read). I
guess the mux is getting in the way. Dave, do you have an idea what's
still going wrong? panel power sequence is now operationl. For
reference, the wip patch series is at:
http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-16 16:43 ` Daniel Vetter
@ 2012-10-24 5:27 ` Daniel J Blueman
2012-10-24 8:03 ` Daniel Vetter
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2012-10-24 5:27 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Seth Forshee, intel-gfx
On 17 October 2012 00:43, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman <daniel@quora.org> wrote:
>> [drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
>> [drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
>> [drm:intel_dp_init], panel power up delay 21, power down delay 50,
>> power cycle delay 400
>> [drm:intel_dp_init], backlight on delay 5, off delay 5
>> [drm:intel_dp_init], panel power sequencer register settings: PP_ON
>> 0x40d20032, PP_OFF 0x1f40032, PP_DIV 0x186904
>> [drm:intel_dp_i2c_init], i2c_init DPDDC-A
>> [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
>> [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
>> [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
>> [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
>>
>> Notable, the nvidia DP init script executed fine; perhaps tracing the
>> I2C access may be useful?
>
> Hm, dp aux transfer don't work (this is the first one in the setup
> sequence, so it's not an i2c over aux issue with the edid read). I
> guess the mux is getting in the way. Dave, do you have an idea what's
> still going wrong? panel power sequence is now operationl. For
> reference, the wip patch series is at:
> http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
Booting for-pzanoni as of today, when switching to i915, the backlight
turns off [1]. Full boot log at
http://quora.org/2012/mbp-i915-panel-3.txt ; the same situation occurs
on 3.7-rc2 alas.
Is there a way to trigger re-enumeration of the panels after I
switcheroo to i915?
I'm checking with Seth if the mux could be the issue, though the code
shows there would be an error message if switching failed.
Thanks,
Daniel
--- [1]
[ 3.522057] [drm:intel_dp_i2c_init], i2c_init DPDDC-A
[ 3.522060] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
[ 3.522066] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
[ 3.524598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
[ 3.524601] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
[ 3.527121] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
[ 3.527123] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
[ 3.527144] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
[ 3.527147] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
[ 3.527150] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
[ 3.529677] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
[ 3.549595] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
[ 3.564443] input: Apple Inc. Apple Internal Keyboard / Trackpad as
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.2/2-1.8.2:1.0/input/input4
[ 3.564721] apple 0003:05AC:0262.0001: input,hidraw0: USB HID v1.11
Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on
usb-0000:00:1d.0-1.8.2/input0
[ 3.569584] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
[ 3.587024] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
[ 3.587035] [drm] failed to retrieve link info, disabling eDP
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-24 5:27 ` Daniel J Blueman
@ 2012-10-24 8:03 ` Daniel Vetter
2012-10-24 12:56 ` Seth Forshee
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2012-10-24 8:03 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Seth Forshee, intel-gfx
On Wed, Oct 24, 2012 at 01:27:23PM +0800, Daniel J Blueman wrote:
> On 17 October 2012 00:43, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman <daniel@quora.org> wrote:
> >> [drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
> >> [drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
> >> [drm:intel_dp_init], panel power up delay 21, power down delay 50,
> >> power cycle delay 400
> >> [drm:intel_dp_init], backlight on delay 5, off delay 5
> >> [drm:intel_dp_init], panel power sequencer register settings: PP_ON
> >> 0x40d20032, PP_OFF 0x1f40032, PP_DIV 0x186904
> >> [drm:intel_dp_i2c_init], i2c_init DPDDC-A
> >> [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
> >> [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
> >> [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> >> [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> >>
> >> Notable, the nvidia DP init script executed fine; perhaps tracing the
> >> I2C access may be useful?
> >
> > Hm, dp aux transfer don't work (this is the first one in the setup
> > sequence, so it's not an i2c over aux issue with the edid read). I
> > guess the mux is getting in the way. Dave, do you have an idea what's
> > still going wrong? panel power sequence is now operationl. For
> > reference, the wip patch series is at:
> > http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
>
> Booting for-pzanoni as of today, when switching to i915, the backlight
> turns off [1]. Full boot log at
> http://quora.org/2012/mbp-i915-panel-3.txt ; the same situation occurs
> on 3.7-rc2 alas.
Yeah, you have an issue with dp aux not working (since the mux is set
wrongly), not with the panel not being powered on (or at least that's a
secondary issue). So the panel power improvements don't help you.
> Is there a way to trigger re-enumeration of the panels after I
> switcheroo to i915?
>
> I'm checking with Seth if the mux could be the issue, though the code
> shows there would be an error message if switching failed.
Iirc Dave Airlie has patches to delay the driver init until the mux code
is all set up, so that the driver could request the mux to be switched
while init is ongoing.
-Daniel
>
> Thanks,
> Daniel
>
> --- [1]
>
> [ 3.522057] [drm:intel_dp_i2c_init], i2c_init DPDDC-A
> [ 3.522060] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
> [ 3.522066] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
> [ 3.524598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> [ 3.524601] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> [ 3.527121] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> [ 3.527123] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> [ 3.527144] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
> [ 3.527147] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
> [ 3.527150] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
> [ 3.529677] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> [ 3.549595] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> [ 3.564443] input: Apple Inc. Apple Internal Keyboard / Trackpad as
> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.2/2-1.8.2:1.0/input/input4
> [ 3.564721] apple 0003:05AC:0262.0001: input,hidraw0: USB HID v1.11
> Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on
> usb-0000:00:1d.0-1.8.2/input0
> [ 3.569584] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> [ 3.587024] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
> [ 3.587035] [drm] failed to retrieve link info, disabling eDP
> --
> Daniel J Blueman
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-24 8:03 ` Daniel Vetter
@ 2012-10-24 12:56 ` Seth Forshee
2012-10-24 13:51 ` Daniel J Blueman
0 siblings, 1 reply; 12+ messages in thread
From: Seth Forshee @ 2012-10-24 12:56 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Seth Forshee, intel-gfx, Daniel J Blueman
On Wed, Oct 24, 2012 at 10:03:12AM +0200, Daniel Vetter wrote:
> On Wed, Oct 24, 2012 at 01:27:23PM +0800, Daniel J Blueman wrote:
> > On 17 October 2012 00:43, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman <daniel@quora.org> wrote:
> > >> [drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
> > >> [drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
> > >> [drm:intel_dp_init], panel power up delay 21, power down delay 50,
> > >> power cycle delay 400
> > >> [drm:intel_dp_init], backlight on delay 5, off delay 5
> > >> [drm:intel_dp_init], panel power sequencer register settings: PP_ON
> > >> 0x40d20032, PP_OFF 0x1f40032, PP_DIV 0x186904
> > >> [drm:intel_dp_i2c_init], i2c_init DPDDC-A
> > >> [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
> > >> [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
> > >> [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
> > >> [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> > >>
> > >> Notable, the nvidia DP init script executed fine; perhaps tracing the
> > >> I2C access may be useful?
> > >
> > > Hm, dp aux transfer don't work (this is the first one in the setup
> > > sequence, so it's not an i2c over aux issue with the edid read). I
> > > guess the mux is getting in the way. Dave, do you have an idea what's
> > > still going wrong? panel power sequence is now operationl. For
> > > reference, the wip patch series is at:
> > > http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
> >
> > Booting for-pzanoni as of today, when switching to i915, the backlight
> > turns off [1]. Full boot log at
> > http://quora.org/2012/mbp-i915-panel-3.txt ; the same situation occurs
> > on 3.7-rc2 alas.
>
> Yeah, you have an issue with dp aux not working (since the mux is set
> wrongly), not with the panel not being powered on (or at least that's a
> secondary issue). So the panel power improvements don't help you.
My suspicion is that Daniel has been using the technique of setting the
mux to the integrated GPU in OS X and rebooting, which I've heard others
say works. Likely the new firmware now resets the mux to the DGPU when
the machine reboots.
> > Is there a way to trigger re-enumeration of the panels after I
> > switcheroo to i915?
> >
> > I'm checking with Seth if the mux could be the issue, though the code
> > shows there would be an error message if switching failed.
>
> Iirc Dave Airlie has patches to delay the driver init until the mux code
> is all set up, so that the driver could request the mux to be switched
> while init is ongoing.
Actually those were my patches, which Dave rejected. I haven't had the
time yet to try and find yet another way of getting switcheroo to work
on these machines.
Seth
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-24 12:56 ` Seth Forshee
@ 2012-10-24 13:51 ` Daniel J Blueman
2012-10-24 15:17 ` Seth Forshee
0 siblings, 1 reply; 12+ messages in thread
From: Daniel J Blueman @ 2012-10-24 13:51 UTC (permalink / raw)
To: Seth Forshee; +Cc: intel-gfx
On 24 October 2012 20:56, Seth Forshee <seth.forshee@canonical.com> wrote:
> On Wed, Oct 24, 2012 at 10:03:12AM +0200, Daniel Vetter wrote:
>> On Wed, Oct 24, 2012 at 01:27:23PM +0800, Daniel J Blueman wrote:
>> > On 17 October 2012 00:43, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman <daniel@quora.org> wrote:
>> > >> [drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
>> > >> [drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
>> > >> [drm:intel_dp_init], panel power up delay 21, power down delay 50,
>> > >> power cycle delay 400
>> > >> [drm:intel_dp_init], backlight on delay 5, off delay 5
>> > >> [drm:intel_dp_init], panel power sequencer register settings: PP_ON
>> > >> 0x40d20032, PP_OFF 0x1f40032, PP_DIV 0x186904
>> > >> [drm:intel_dp_i2c_init], i2c_init DPDDC-A
>> > >> [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on
>> > >> [drm:ironlake_edp_panel_vdd_on], eDP VDD already on
>> > >> [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8
>> > >> [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
>> > >>
>> > >> Notable, the nvidia DP init script executed fine; perhaps tracing the
>> > >> I2C access may be useful?
>> > >
>> > > Hm, dp aux transfer don't work (this is the first one in the setup
>> > > sequence, so it's not an i2c over aux issue with the edid read). I
>> > > guess the mux is getting in the way. Dave, do you have an idea what's
>> > > still going wrong? panel power sequence is now operationl. For
>> > > reference, the wip patch series is at:
>> > > http://cgit.freedesktop.org/~danvet/drm/log/?h=for-pzanoni
>> >
>> > Booting for-pzanoni as of today, when switching to i915, the backlight
>> > turns off [1]. Full boot log at
>> > http://quora.org/2012/mbp-i915-panel-3.txt ; the same situation occurs
>> > on 3.7-rc2 alas.
>>
>> Yeah, you have an issue with dp aux not working (since the mux is set
>> wrongly), not with the panel not being powered on (or at least that's a
>> secondary issue). So the panel power improvements don't help you.
>
> My suspicion is that Daniel has been using the technique of setting the
> mux to the integrated GPU in OS X and rebooting, which I've heard others
> say works. Likely the new firmware now resets the mux to the DGPU when
> the machine reboots.
Exactly; this worked until the firmware update. I'll mail you in a
separate thread after I try the debugging approach I mentioned.
>> > Is there a way to trigger re-enumeration of the panels after I
>> > switcheroo to i915?
>> >
>> > I'm checking with Seth if the mux could be the issue, though the code
>> > shows there would be an error message if switching failed.
>>
>> Iirc Dave Airlie has patches to delay the driver init until the mux code
>> is all set up, so that the driver could request the mux to be switched
>> while init is ongoing.
>
> Actually those were my patches, which Dave rejected. I haven't had the
> time yet to try and find yet another way of getting switcheroo to work
> on these machines.
Generally, this sounds like a needed approach so we can boot with eg
video=igd (or module options to the same effect) in case we need to
avoid certain userspace issues.
Thanks,
Daniel
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bad panel power sequencing delays, disabling panel
2012-10-24 13:51 ` Daniel J Blueman
@ 2012-10-24 15:17 ` Seth Forshee
0 siblings, 0 replies; 12+ messages in thread
From: Seth Forshee @ 2012-10-24 15:17 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Seth Forshee, intel-gfx
On Wed, Oct 24, 2012 at 09:51:15PM +0800, Daniel J Blueman wrote:
> >> > Is there a way to trigger re-enumeration of the panels after I
> >> > switcheroo to i915?
> >> >
> >> > I'm checking with Seth if the mux could be the issue, though the code
> >> > shows there would be an error message if switching failed.
> >>
> >> Iirc Dave Airlie has patches to delay the driver init until the mux code
> >> is all set up, so that the driver could request the mux to be switched
> >> while init is ongoing.
> >
> > Actually those were my patches, which Dave rejected. I haven't had the
> > time yet to try and find yet another way of getting switcheroo to work
> > on these machines.
>
> Generally, this sounds like a needed approach so we can boot with eg
> video=igd (or module options to the same effect) in case we need to
> avoid certain userspace issues.
Some approach is needed. The following are the challenges we're facing
as I understand them.
1. It looks like DRM seems to expect drivers to enumerate all possible
connectors during initialization. So i915 can't say there's no eDP
or LVDS connector during initialization and later add one.
2. Macs generally don't supply a VBT for the integrated GPU, and
sometimes when they do the informaton in the VBT is incorrect, so
i915 can't reliably determine whether or not the machine should have
LVDS or eDP if the mux is switched to the DGPU at boot.
3. In order to switch the mux while i915 is initializing we need to
ensure that the switcheroo handler is registered before this
happens. Since the mux in this case is in a completely separate
driver there's no obvious way of making this happen.
Also, I'm not really familiar at all with DisplayPort. The solution
of switching the mux during driver initialization assumes that we
really only need to switch the i2c lines. If eDP requires also
switching the display signals then that's obviously going to present
a problem.
One way that I know can be made to work for LVDS is to add quirks for
each specific machine to supply the mode information. This has the
downside of requiring that new machines be quirked before switcheroo
will work, and I'm again uncertain of the viability of this solution for
eDP.
If anyone has suggestions, I'm all ears.
Seth
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-10-24 15:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-13 5:28 bad panel power sequencing delays, disabling panel Daniel J Blueman
2012-10-16 13:26 ` Daniel J Blueman
2012-10-16 14:43 ` Daniel Vetter
2012-10-16 15:15 ` Daniel J Blueman
2012-10-16 15:16 ` Daniel Vetter
2012-10-16 16:10 ` Daniel J Blueman
2012-10-16 16:43 ` Daniel Vetter
2012-10-24 5:27 ` Daniel J Blueman
2012-10-24 8:03 ` Daniel Vetter
2012-10-24 12:56 ` Seth Forshee
2012-10-24 13:51 ` Daniel J Blueman
2012-10-24 15:17 ` Seth Forshee
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).