[Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

[He, Shuang]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, March 26, 2015 9:13 PM
> To: He, Shuang
> Cc: Daniel Vetter; Gao, Ethan; intel-gfx at lists.freedesktop.org;
> daniel.vetter at ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for
> initial fb config
> 
> On Thu, Mar 26, 2015 at 11:08:00AM +0000, He, Shuang wrote:
> > > -----Original Message-----
> > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> > > Vetter
> > > Sent: Thursday, March 26, 2015 6:24 PM
> > > To: He, Shuang
> > > Cc: Gao, Ethan; intel-gfx at lists.freedesktop.org; daniel.vetter at ffwll.ch
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for
> > > initial fb config
> > >
> > > On Thu, Mar 26, 2015 at 02:53:10AM -0700, shuang.he at intel.com wrote:
> > > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> > > shuang.he at intel.com)
> > > > Task id: 6053
> > > > -------------------------------------Summary-------------------------------------
> > > > Platform          Delta          drm-intel-nightly          Series Applied
> > > > PNV                 -1              276/276              275/276
> > > > ILK                                  303/303              303/303
> > > > SNB                                  304/304              304/304
> > > > IVB                                  339/339              339/339
> > > > BYT                                  287/287              287/287
> > > > HSW                                  362/362              362/362
> > > > BDW                                  310/310              310/310
> > > > -------------------------------------Detailed-------------------------------------
> > > > Platform  Test                                drm-intel-nightly          Series Applied
> > > >  PNV  igt at gem_userptr_blits@minor-normal-sync
> > > DMESG_WARN(1)PASS(1)      DMESG_WARN(1)PASS(1)
> > > >
> > >
> WARNING:at_drivers/gpu/drm/i915/i915_gem_evict.c:#i915_gem_evict_vm
> > > [i915]()@WARNING:.* at .* i915_gem_evict_vm+0x
> > > >
> > >
> Modules_linked_in:dm_mod_b43_mac80211_iTCO_wdt_cfg80211_rfkill_iTC
> > >
> O_vendor_support_snd_hda_codec_conexant_snd_hda_codec_generic_pc
> > >
> spkr_serio_raw_i2c_i801_snd_hda_intel_snd_hda_controller_lpc_ich_mfd_
> > >
> core_snd_hda_codec_snd_hda_core_snd_hwdep_bcma_snd_pcm_snd_ti
> > >
> mer_snd_soundcore_wmi_joydev_battery_ac_acpi_cpufreq_i915_button_
> > > video_drm_kms_helper_drm_broadcom at Modules linked in:
> dm_mod .*
> > > iTCO_wdt .* rfkill iTCO_vendor_support snd_hda_codec_conexant
> > > snd_hda_codec_generic pcspkr serio_raw .* snd_hda_intel
> > > snd_hda_controller lpc_ich mfd_core snd_hda_codec snd_hda_core
> > > snd_hwdep bcma snd_pcm snd_timer snd soundcore wmi joydev
> battery ac
> > > acpi_cpufreq .* button video drm_kms_helper drm broadcom
> > > > #>]?i915_gem_evict_vm[i915]@i915_gem_evict_vm+0x
> > > > #>]i915_gem_evict_vm[i915]@i915_gem_evict_vm+0x
> > > >
> > >
> #>]i915_gem_execbuffer_reserve[i915]@i915_gem_execbuffer_reserve+0x
> > > > #>]i915_gem_do_execbuffer[i915]@i915_gem_do_execbuffer
> > > > #>]i915_gem_execbuffer2[i915]@i915_gem_execbuffer2+0x
> > > > #>]drm_ioctl[drm]@drm_ioctl+0x
> > > > #>]?i915_gem_execbuffer[i915]@i915_gem_execbuffer+0x
> > > > Note: You need to pay more attention to line start with '*'
> > >
> > > I can't parse this really ... is this the old or the new dmesg? Also I
> > > guess we need to change the dmesg filtering in piglit a bit so that it
> > > still preserves the entire dmesg and only filters it to decide what the
> > > result should be.
> > [He, Shuang] First of all, this one have bug in our parsing script,
> > there should be only one line for each kind of dmesg. Current implement
> > in PRTS takes dmesg recorded by piglit and parsing it. Secondly, you're
> > asking for automatic judgment (old or the new dmesg) that is very hard
> > implement. For example, reference kernel result not having one dmesg
> > doesn't mean it really doesn't have it, right? It really depend how much
> > effort you spent on testing it and how often the dmesg could be
> > triggered. From my point of view, in the near future, the best we can
> > have, is giving you the dmesg that may interest you instead of do that
> > very advanced judgment for you.
> 
> I don't mean automatic judgement, I just want to know whether the dmesg
> splat in the mail is with the patch or without. In this case both nightly
> and with the series applied there was a DMESG_WARN, so I can't tell
> whether the dmesg noise is the old one (no problem) or the same one (no
> problem) or a new kind of dmesg new (needs action).
[He, Shuang] Oh, I see, it is for new result (With patch applied). I will add some indicator for that. 

Thanks
	--Shuang
> 
> I don't expect the script to do that decision for me.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch