On Fri, 25 Sep 2015, "Vivi, Rodrigo" <rodrigo.vivi@xxxxxxxxx> wrote: > On Fri, 2015-09-25 at 13:52 +0300, Jani Nikula wrote: >> On Wed, 23 Sep 2015, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote: >> > In case something goes wrong with power well initialization we were >> > calling >> > intel_prepare_ddi during boot while encoder list isnt't initilized. >> >> Broken record, is this a regression, what is the regressing commit, >> or >> if this was always broken, which commit introduced the broken >> feature? > > I believe it is broken since this call was introduced, but when > everything goes as expected it isn't executed. > Only in rare cases where power well initialization didn't go well and > post call is called during init it will trigger this case. > I don't believe this is something that a regular user of stables > platforms should worrie though... but it is always good to protect to > be on the safe side. Rodrigo, both Daniel and I asked which commit broke things. We have to keep asking this again and again, like a broken record. It doesn't scale that we have to dig the logs for every patch that looks like a fix, just to decide where to queueu the patch. This was the one: commit 1d2b9526a790d55b7ae870934a74937081f62de2 Author: Damien Lespiau <damien.lespiau@xxxxxxxxx> Date: Fri Mar 6 18:50:53 2015 +0000 drm/i915/skl: Restore the DDI translation tables when enabling PW1 And the patch, amended with the reference, is now pushed to drm-intel-fixes. Thanks for the patch and review. BR, Jani. > >> >> BR, >> Jani. >> >> >> > >> > [ 9.618747] i915 0000:00:02.0: Invalid ROM contents >> > [ 9.631446] [drm] failed to find VBIOS tables >> > [ 9.720036] BUG: unable to handle kernel NULL pointer >> > dereference at 00000000 >> > 00000058 >> > [ 9.721986] IP: [<ffffffffa014eb72>] >> > ddi_get_encoder_port+0x82/0x190 [i915] >> > [ 9.723736] PGD 0 >> > [ 9.724286] Oops: 0000 [#1] PREEMPT SMP >> > [ 9.725386] Modules linked in: intel_powerclamp snd_hda_intel(+) >> > coretemp crc >> > 32c_intel snd_hda_codec snd_hda_core serio_raw snd_pcm snd_timer >> > i915(+) parport >> > _pc parport pinctrl_sunrisepoint pinctrl_intel nfsd nfs_acl >> > [ 9.730635] CPU: 0 PID: 497 Comm: systemd-udevd Not tainted >> > 4.3.0-rc2-eywa-10 >> > 967-g72de2cfd-dirty #2 >> > [ 9.732785] Hardware name: Intel Corporation Cannonlake Client >> > platform/Skyla >> > ke DT DDR4 RVP8, BIOS CNLSE2R1.R00.X021.B00.1508040310 08/04/2015 >> > [ 9.735785] task: ffff88008a704700 ti: ffff88016a1ac000 task.ti: >> > ffff88016a1a >> > c000 >> > [ 9.737584] RIP: 0010:[<ffffffffa014eb72>] [<ffffffffa014eb72>] >> > ddi_get_enco >> > der_port+0x82/0x190 [i915] >> > [ 9.739934] RSP: 0000:ffff88016a1af710 EFLAGS: 00010296 >> > [ 9.741184] RAX: 000000000000004e RBX: ffff88008a9edc98 RCX: >> > 0000000000000001 >> > [ 9.742934] RDX: 000000000000004e RSI: ffffffff81fc1e82 RDI: >> > 00000000ffffffff >> > [ 9.744634] RBP: ffff88016a1af730 R08: 0000000000000000 R09: >> > 0000000000000578 >> > [ 9.746333] R10: 0000000000001065 R11: 0000000000000578 R12: >> > fffffffffffffff8 >> > [ 9.748033] R13: ffff88016a1af7a8 R14: ffff88016a1af794 R15: >> > 0000000000000000 >> > [ 9.749733] FS: 00007eff2e1e07c0(0000) >> > GS:ffff88016fc00000(0000) knlGS:00000 >> > 00000000000 >> > [ 9.751683] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> > [ 9.753083] CR2: 0000000000000058 CR3: 000000016922b000 CR4: >> > 00000000003406f0 >> > [ 9.754782] Stack: >> > [ 9.755332] ffff88008a9edc98 ffff88008a9ed800 ffffffffa01d07b0 >> > 00000000fffb9 >> > 09e >> > [ 9.757232] ffff88016a1af7d8 ffffffffa0154ea7 0000000000000246 >> > ffff88016a370 >> > 080 >> > [ 9.759182] ffff88016a370080 ffff88008a9ed800 0000000000000246 >> > ffff88008a9ed >> > c98 >> > [ 9.761132] Call Trace: >> > [ 9.761782] [<ffffffffa0154ea7>] intel_prepare_ddi+0x67/0x860 >> > [i915] >> > [ 9.763332] [<ffffffff81a56996>] ? >> > _raw_spin_unlock_irqrestore+0x26/0x40 >> > [ 9.765031] [<ffffffffa00fad01>] ? gen9_read32+0x141/0x360 >> > [i915] >> > [ 9.766531] [<ffffffffa00b43e1>] skl_set_power_well+0x431/0xa80 >> > [i915] >> > [ 9.768181] [<ffffffffa00b4a63>] >> > skl_power_well_enable+0x13/0x20 [i915] >> > [ 9.769781] [<ffffffffa00b2188>] >> > intel_power_well_enable+0x28/0x50 [i915] >> > [ 9.771481] [<ffffffffa00b4d52>] >> > intel_display_power_get+0x92/0xc0 [i915] >> > [ 9.773180] [<ffffffffa00b4fcb>] >> > intel_display_set_init_power+0x3b/0x40 [i91 >> > 5] >> > [ 9.774980] [<ffffffffa00b5170>] >> > intel_power_domains_init_hw+0x120/0x520 [i9 >> > 15] >> > [ 9.776780] [<ffffffffa0194c61>] i915_driver_load+0xb21/0xf40 >> > [i915] >> > >> > So let's protect this case. >> > >> > My first attempt was to remove the intel_prepare_ddi, but Daniel >> > had pointed out >> > this is really needed to restore those registers values. And Imre >> > pointed out >> > that this case was without the flag protection and this was >> > actually where things >> > were going bad. So I've just checked and this indeed solves my >> > issue. >> > >> > Cc: Imre Deak <imre.deak@xxxxxxxxx> >> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> >> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> >> > --- >> > drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c >> > b/drivers/gpu/drm/i915/intel_runtime_pm.c >> > index 85c35fd..d194492 100644 >> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c >> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c >> > @@ -246,7 +246,8 @@ static void skl_power_well_post_enable(struct >> > drm_i915_private *dev_priv, >> > } >> > >> > if (power_well->data == SKL_DISP_PW_1) { >> > - intel_prepare_ddi(dev); >> > + if (!dev_priv->power_domains.initializing) >> > + intel_prepare_ddi(dev); >> > gen8_irq_power_well_post_enable(dev_priv, 1 << >> > PIPE_A); >> > } >> > } >> > -- >> > 2.4.3 >> > >> > _______________________________________________ >> > Intel-gfx mailing list >> > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx