[Intel-gfx] bad panel power sequencing delays, disabling panel

[Daniel J Blueman]

On 24 October 2012 20:56, Seth Forshee <seth.forshee at 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 at ffwll.ch> wrote:
>> > > On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman <daniel at 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