[Intel-gfx] bad panel power sequencing delays, disabling panel
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 :01:00.0: enabling device (0006 -> 0007) [drm] nouveau :01:00.0: Detected an NVe0 generation card (0x0e7150a2) [drm] nouveau :01:00.0: acceleration disabled by default, pass noaccel=0 to force enable checking generic (9002 1c2) vs hw (9000 1000) 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 :01:00.0: Checking PRAMIN for VBIOS [drm] nouveau :01:00.0: ... appears to be valid [drm] nouveau :01:00.0: Using VBIOS from PRAMIN [drm] nouveau :01:00.0: BIT BIOS found [drm] nouveau :01:00.0: Bios version 80.07.26.04 [drm] nouveau :01:00.0: TMDS table version 2.0 [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do [drm] nouveau :01:00.0: DCB version 4.0 [drm] nouveau :01:00.0: DCB outp 00: 048101b6 0f230010 [drm] nouveau :01:00.0: DCB outp 01: 018212d6 0f220020 [drm] nouveau :01:00.0: DCB outp 02: 01021212 00020020 [drm] nouveau :01:00.0: DCB outp 03: 088324c6 0f220010 [drm] nouveau :01:00.0: DCB outp 04: 08032402 00020010 [drm] nouveau :01:00.0: DCB outp 05: 02843862 00020010 [drm] nouveau :01:00.0: DCB conn 00: 00020047 [drm] nouveau :01:00.0: DCB conn 01: 02208146 [drm] nouveau :01:00.0: DCB conn 02: 01104246 [drm] nouveau :01:00.0: DCB conn 03: 00410361 [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0x86B5 [drm] nouveau :01:00.0: 0x853A: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0x8EFC [drm] nouveau :01:00.0: 0x8F0A: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: 0x8F9B: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0x66E1 [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xAAA0 [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xAAA1 [drm] nouveau :01:00.0: 0x85E7: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xAB59 [drm] nouveau :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 :01:00.0: Detected 1024MiB VRAM (GDDR5) [drm] nouveau :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 :01:00.0: ACPI backlight interface available, not registering our own [drm] nouveau :01:00.0: voltage table 0x50 unknown [drm] nouveau :01:00.0: 4 available performance level(s) [drm] nouveau :01:00.0: 1: core 209MHz shader 419MHz memory 405MHz voltage 520mV [drm] nouveau :01:00.0: 2: core 390MHz shader 780MHz memory 1080MHz voltage 610mV [drm] nouveau :01:00.0: 3: core 1000MHz shader 2000MHz memory 1080MHz voltage 630mV [drm] nouveau :01:00.0: 4: core 1254MHz shader 2508MHz memory 1080MHz voltage 630mV [drm] nouveau :01:00.0: c: [drm] nouveau :01:00.0: allocated 2880x1800 fb: 0xe, bo 88026311b800 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 :01:00.0 on minor 0 pci :00:00.0: Intel Ivybridge Chipset pci :00:00.0: detected gtt size: 2097152K total, 262144K mappable pci :00:00.0: detected 65536K stolen memory i915 :00:02.0: setting latency timer to 64 i915 :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 :00:02.0: Invalid ROM contents [drm] failed to find VBIOS tables vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none vgaarb: device changed decodes: PCI::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
[Intel-gfx] bad panel power sequencing delays, disabling panel
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 :01:00.0: enabling device (0006 -> 0007) [drm] nouveau :01:00.0: Detected an NVe0 generation card (0x0e7150a2) [drm] nouveau :01:00.0: acceleration disabled by default, pass noaccel=0 to force enable checking generic (9002 1c2) vs hw (9000 1000) 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 :01:00.0: Checking PRAMIN for VBIOS [drm] nouveau :01:00.0: ... appears to be valid [drm] nouveau :01:00.0: Using VBIOS from PRAMIN [drm] nouveau :01:00.0: BIT BIOS found [drm] nouveau :01:00.0: Bios version 80.07.26.04 [drm] nouveau :01:00.0: TMDS table version 2.0 [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do [drm] nouveau :01:00.0: DCB version 4.0 [drm] nouveau :01:00.0: DCB outp 00: 048101b6 0f230010 [drm] nouveau :01:00.0: DCB outp 01: 018212d6 0f220020 [drm] nouveau :01:00.0: DCB outp 02: 01021212 00020020 [drm] nouveau :01:00.0: DCB outp 03: 088324c6 0f220010 [drm] nouveau :01:00.0: DCB outp 04: 08032402 00020010 [drm] nouveau :01:00.0: DCB outp 05: 02843862 00020010 [drm] nouveau :01:00.0: DCB conn 00: 00020047 [drm] nouveau :01:00.0: DCB conn 01: 02208146 [drm] nouveau :01:00.0: DCB conn 02: 01104246 [drm] nouveau :01:00.0: DCB conn 03: 00410361 [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0x86B5 [drm] nouveau :01:00.0: 0x853A: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0x8EFC [drm] nouveau :01:00.0: 0x8F0A: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: 0x8F9B: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0x66E1 [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xAAA0 [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xAAA1 [drm] nouveau :01:00.0: 0x85E7: Condition still not met after 20ms, skipping following opcodes [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xAB59 [drm] nouveau :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 :01:00.0: Detected 1024MiB VRAM (GDDR5) [drm] nouveau :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 :01:00.0: ACPI backlight interface available, not registering our own [drm] nouveau :01:00.0: voltage table 0x50 unknown [drm] nouveau :01:00.0: 4 available performance level(s) [drm] nouveau :01:00.0: 1: core 209MHz shader 419MHz memory 405MHz voltage 520mV [drm] nouveau :01:00.0: 2: core 390MHz shader 780MHz memory 1080MHz voltage 610mV [drm] nouveau :01:00.0: 3: core 1000MHz shader 2000MHz memory 1080MHz voltage 630mV [drm] nouveau :01:00.0: 4: core 1254MHz shader 2508MHz memory 1080MHz voltage 630mV [drm] nouveau :01:00.0: c: [drm] nouveau :01:00.0: allocated 2880x1800 fb: 0xe, bo 88026311b800 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 :01:00.0 on minor 0 pci :00:00.0: Intel Ivybridge Chipset pci :00:00.0: detected gtt size: 2097152K total, 262144K mappable pci :00:00.0: detected 65536K stolen memory i915 :00:02.0: setting latency timer to 64 i915 :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 :00:02.0: Invalid ROM contents [drm] failed to find VBIOS tables vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none vgaarb: device changed decodes: PCI::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 _DO
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On 16 October 2012 22:43, Daniel Vetter wrote: > On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On Tue, Oct 16, 2012 at 5:15 PM, Daniel J Blueman wrote: > On 16 October 2012 22:43, Daniel Vetter wrote: >> On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On 16 October 2012 23:16, Daniel Vetter wrote: > On Tue, Oct 16, 2012 at 5:15 PM, Daniel J Blueman wrote: >> On 16 October 2012 22:43, Daniel Vetter wrote: >>> On Tue, Oct 16, 2012 at 3:26 PM, Daniel J Blueman 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On 17 October 2012 00:43, Daniel Vetter wrote: > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman 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/pci:00/: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-: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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On Wed, Oct 24, 2012 at 01:27:23PM +0800, Daniel J Blueman wrote: > On 17 October 2012 00:43, Daniel Vetter wrote: > > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman 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/pci:00/: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-: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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
On 24 October 2012 20:56, Seth Forshee 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 wrote: >> > > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman >> > > 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
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 wrote: > > > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman > > > 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] bad panel power sequencing delays, disabling panel
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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
