Message ID | 1415985875-7485-5-git-send-email-damien.lespiau@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
-------------------------------------Summary-------------------------------------
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/291->290/291
PNV: pass/total=352/356->356/356
ILK: pass/total=371/372->364/372
IVB: pass/total=545/546->545/546
SNB: pass/total=424/425->424/425
HSW: pass/total=579/579->579/579
BDW: pass/total=434/435->434/435
-------------------------------------Detailed-------------------------------------
test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...->result_with_patch_applied(count, machine_id)...
PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) -> PASS(4, M7)
PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) -> PASS(1, M7)
PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) -> PASS(1, M7)
PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) -> PASS(1, M7)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26)
ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26)
ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26)
ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26)
Hi Shuang, You wanted suggestions, so how about: For both examples, to determine the size of the column, I'd take the length of the longest value of that column (including the title) and add 4 to account for spacing. Left alignment for text, right alignement for numbers (of course, all of that is debatable). On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang.he@intel.com wrote: > Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) > -------------------------------------Summary------------------------------------- > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate > BYT: pass/total=290/291->290/291 > PNV: pass/total=352/356->356/356 > ILK: pass/total=371/372->364/372 > IVB: pass/total=545/546->545/546 > SNB: pass/total=424/425->424/425 > HSW: pass/total=579/579->579/579 > BDW: pass/total=434/435->434/435 For this one: - a bit more spacing - some table-like alignment. That's assuming the mail client will use monospaced fonts for text emails, it really should. - add the delta so it's easier to parse the interesting information - sort by gens - baseline_drm_intel_nightly_pass_rate can really just be drm-intel-nightly - it's not just a single patch applied, so series applied? Platform Delta drm-intel-nightly Series Applied -------------------------------------------------------- PNV +4 352/356 356/356 ILK -7 371/372 364/372 SNB 0 424/425 424/425 IVB 0 545/546 545/546 BYT 0 290/291 290/291 HSW 0 579/579 579/579 BDW 0 434/435 434/435 > -------------------------------------Detailed------------------------------------- > test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...->result_with_patch_applied(count, machine_id)... > PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) -> PASS(4, M7) > PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) -> PASS(1, M7) > PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) -> PASS(1, M7) > PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) -> PASS(1, M7) > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26) > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26) > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26) > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26) > ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) And for this one: - it's not nessary to repeat the test suite name for every single row, if needed at all (I don't think it is when replying to kernel patches), it can be put beforehand. - sorted by gen - The machine id isn't useful in this report - It'd be nice to add a some explanations on how to decipher the result column (what is the count, what the various states mean). Maybe after the table as it only needs to be read a few times to get it. Platform Test drm-intel-nightly Series Applied ------------------------------------------------------------------------------------------------------------------- ILK igt_kms_flip_flip-vs-absolute-wf_vblank DMESG_WARN(1) PASS(3) DMESG_WARN(2) PASS(2) ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible DMESG_WARN(1) PASS(3) DMESG_WARN(1) PASS(3) .. HTH,
On Sat, Nov 15, 2014 at 10:54:47AM +0000, Damien Lespiau wrote: > Hi Shuang, > > You wanted suggestions, so how about: > > For both examples, to determine the size of the column, I'd take the > length of the longest value of that column (including the title) and add > 4 to account for spacing. Left alignment for text, right alignement for > numbers (of course, all of that is debatable). > > On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang.he@intel.com wrote: > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) > > -------------------------------------Summary------------------------------------- > > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate > > BYT: pass/total=290/291->290/291 > > PNV: pass/total=352/356->356/356 > > ILK: pass/total=371/372->364/372 > > IVB: pass/total=545/546->545/546 > > SNB: pass/total=424/425->424/425 > > HSW: pass/total=579/579->579/579 > > BDW: pass/total=434/435->434/435 > > For this one: > > - a bit more spacing > - some table-like alignment. That's assuming the mail client will use > monospaced fonts for text emails, it really should. > - add the delta so it's easier to parse the interesting information I think the delta should mention both + and - counts separately so that it's easy to see when a patch regressed the same amount of tests as it fixed. Iirc there's been a few cases before where this was important. Otherwise I agree with damien, the column aligment and headers make the results a lot easier to read. -Daniel > - sort by gens > - baseline_drm_intel_nightly_pass_rate can really just be > drm-intel-nightly > - it's not just a single patch applied, so series applied? > > Platform Delta drm-intel-nightly Series Applied > -------------------------------------------------------- > PNV +4 352/356 356/356 > ILK -7 371/372 364/372 > SNB 0 424/425 424/425 > IVB 0 545/546 545/546 > BYT 0 290/291 290/291 > HSW 0 579/579 579/579 > BDW 0 434/435 434/435 > > > > -------------------------------------Detailed------------------------------------- > > test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...->result_with_patch_applied(count, machine_id)... > > PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) -> PASS(4, M7) > > PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) -> PASS(1, M7) > > PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) -> PASS(1, M7) > > PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) -> PASS(1, M7) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) -> DMESG_WARN(2, M26)PASS(2, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > > And for this one: > > - it's not nessary to repeat the test suite name for every single row, > if needed at all (I don't think it is when replying to kernel > patches), it can be put beforehand. > - sorted by gen > - The machine id isn't useful in this report > - It'd be nice to add a some explanations on how to decipher the > result column (what is the count, what the various states mean). > Maybe after the table as it only needs to be read a few times to get > it. > > Platform Test drm-intel-nightly Series Applied > ------------------------------------------------------------------------------------------------------------------- > ILK igt_kms_flip_flip-vs-absolute-wf_vblank DMESG_WARN(1) PASS(3) DMESG_WARN(2) PASS(2) > ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible DMESG_WARN(1) PASS(3) DMESG_WARN(1) PASS(3) > .. > > HTH, > > -- > Damien > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Nov 14, 2014 at 05:24:35PM +0000, Damien Lespiau wrote: > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > --- > drivers/gpu/drm/i915/intel_ddi.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c > index b5a279a..924f1ec 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -767,12 +767,20 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder, > > pipe_config->port_clock = link_clock; > > + /* > + * On SKL the eDP DPLL (DPLL0 as we don't use SSC) is not part of the > + * shared DPLL framework and thus needs to be read out separately > + */ > + if (encoder->type == INTEL_OUTPUT_EDP) Hw state readout shouldn't depend upon our sw state, and given the multiple personality nature of DDI ports I think this is the case here: We might have a different opinion than the bios guys about what's edp (it happened) or how consistently to apply this clock selection algo (also happened). So might be better to stuff this into the ddi clock readout code (the one where you patched away the WARN for DPLL0 I guess). Merged patch 3 meanwhile, thanks. -Daniel > + pipe_config->dpll_hw_state.ctrl1 = (dpll_ctl1 >> (dpll * 6)) & 0x3f; > + > if (pipe_config->has_dp_encoder) > pipe_config->adjusted_mode.crtc_clock = > intel_dotclock_calculate(pipe_config->port_clock, > &pipe_config->dp_m_n); > else > pipe_config->adjusted_mode.crtc_clock = pipe_config->port_clock; > + > } > > static void hsw_ddi_clock_get(struct intel_encoder *encoder, > -- > 1.8.3.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> -----Original Message----- > From: Lespiau, Damien > Sent: Saturday, November 15, 2014 6:55 PM > To: He, Shuang > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0 > > Hi Shuang, > > You wanted suggestions, so how about: > > For both examples, to determine the size of the column, I'd take the > length of the longest value of that column (including the title) and add > 4 to account for spacing. Left alignment for text, right alignement for > numbers (of course, all of that is debatable). [He, Shuang] Hello, Damien, Thanks for your great input, we'll check how those suggestion could be integrated, I've created one jira task to track it: https://jira01.devtools.intel.com/browse/VIZ-4672 > > On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang.he@intel.com wrote: > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact: > shuang.he@intel.com) > > -------------------------------------Summary------------------------------------- > > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate > > BYT: pass/total=290/291->290/291 > > PNV: pass/total=352/356->356/356 > > ILK: pass/total=371/372->364/372 > > IVB: pass/total=545/546->545/546 > > SNB: pass/total=424/425->424/425 > > HSW: pass/total=579/579->579/579 > > BDW: pass/total=434/435->434/435 > > For this one: > > - a bit more spacing > - some table-like alignment. That's assuming the mail client will use > monospaced fonts for text emails, it really should. > - add the delta so it's easier to parse the interesting information > - sort by gens [He, Shuang] yes, this makes sense > - baseline_drm_intel_nightly_pass_rate can really just be > drm-intel-nightly [He, Shuang] yes, this makes sense > - it's not just a single patch applied, so series applied? [He, Shuang] yes, it's series applied > > Platform Delta drm-intel-nightly Series Applied > -------------------------------------------------------- > PNV +4 352/356 356/356 > ILK -7 371/372 364/372 > SNB 0 424/425 424/425 > IVB 0 545/546 545/546 > BYT 0 290/291 290/291 > HSW 0 579/579 579/579 > BDW 0 434/435 434/435 > > > > -------------------------------------Detailed------------------------------------- > > test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, > machine_id...)...->result_with_patch_applied(count, machine_id)... > > PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) -> > PASS(4, M7) > > PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) -> > PASS(1, M7) > > PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) -> PASS(1, > M7) > > PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) -> PASS(1, > M7) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, > DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2, > M26) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, > DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, > M26) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, > PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, > DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, > M26) > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) -> > DMESG_WARN(2, M26)PASS(2, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) -> > DMESG_WARN(2, M26)PASS(2, M26) > > ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, > M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > > And for this one: > > - it's not nessary to repeat the test suite name for every single row, > if needed at all (I don't think it is when replying to kernel > patches), it can be put beforehand. [He, Shuang] this makes sense > - sorted by gen > - The machine id isn't useful in this report [He, Shuang] Some time, test result diffs because of Machine have changed, machine id is put there to help understand the issue > - It'd be nice to add a some explanations on how to decipher the > result column (what is the count, what the various states mean). > Maybe after the table as it only needs to be read a few times to get > it. [He, Shuang] yes, it may help. I'm always be hesitating on how to put these things in the right position. I'll see if your way could help > > Platform Test > drm-intel-nightly Series Applied > ---------------------------------------------------------------------------------------------------------------- > --- > ILK igt_kms_flip_flip-vs-absolute-wf_vblank > DMESG_WARN(1) PASS(3) DMESG_WARN(2) PASS(2) > ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible > DMESG_WARN(1) PASS(3) DMESG_WARN(1) PASS(3) > .. > > HTH, [He, Shuang] By the way, What is HTH? "Hope to help"? :) > > -- > Damien
> -----Original Message----- > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Monday, November 17, 2014 11:03 PM > To: Lespiau, Damien > Cc: He, Shuang; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0 > > On Sat, Nov 15, 2014 at 10:54:47AM +0000, Damien Lespiau wrote: > > Hi Shuang, > > > > You wanted suggestions, so how about: > > > > For both examples, to determine the size of the column, I'd take the > > length of the longest value of that column (including the title) and add > > 4 to account for spacing. Left alignment for text, right alignement for > > numbers (of course, all of that is debatable). > > > > On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang.he@intel.com wrote: > > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact: > shuang.he@intel.com) > > > -------------------------------------Summary------------------------------------- > > > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate > > > BYT: pass/total=290/291->290/291 > > > PNV: pass/total=352/356->356/356 > > > ILK: pass/total=371/372->364/372 > > > IVB: pass/total=545/546->545/546 > > > SNB: pass/total=424/425->424/425 > > > HSW: pass/total=579/579->579/579 > > > BDW: pass/total=434/435->434/435 > > > > For this one: > > > > - a bit more spacing > > - some table-like alignment. That's assuming the mail client will use > > monospaced fonts for text emails, it really should. > > - add the delta so it's easier to parse the interesting information > > I think the delta should mention both + and - counts separately so that > it's easy to see when a patch regressed the same amount of tests as it > fixed. Iirc there's been a few cases before where this was important. [He, Shuang] Agree with that, it's kind of like patch Thanks --Shuang > > Otherwise I agree with damien, the column aligment and headers make the > results a lot easier to read. > -Daniel > > > - sort by gens > > - baseline_drm_intel_nightly_pass_rate can really just be > > drm-intel-nightly > > - it's not just a single patch applied, so series applied? > > > > Platform Delta drm-intel-nightly Series Applied > > -------------------------------------------------------- > > PNV +4 352/356 356/356 > > ILK -7 371/372 364/372 > > SNB 0 424/425 424/425 > > IVB 0 545/546 545/546 > > BYT 0 290/291 290/291 > > HSW 0 579/579 579/579 > > BDW 0 434/435 434/435 > > > > > > > -------------------------------------Detailed------------------------------------- > > > test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, > machine_id...)...->result_with_patch_applied(count, machine_id)... > > > PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) -> > PASS(4, M7) > > > PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) -> > PASS(1, M7) > > > PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) -> > PASS(1, M7) > > > PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) -> > PASS(1, M7) > > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, > DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2, > M26) > > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, > DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, > M26) > > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, > PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26) > > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, > DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3, > M26) > > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) -> > DMESG_WARN(2, M26)PASS(2, M26) > > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) > -> DMESG_WARN(2, M26)PASS(2, M26) > > > ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, > M37M26) -> DMESG_WARN(1, M26)PASS(3, M26) > > > > And for this one: > > > > - it's not nessary to repeat the test suite name for every single row, > > if needed at all (I don't think it is when replying to kernel > > patches), it can be put beforehand. > > - sorted by gen > > - The machine id isn't useful in this report > > - It'd be nice to add a some explanations on how to decipher the > > result column (what is the count, what the various states mean). > > Maybe after the table as it only needs to be read a few times to get > > it. > > > > Platform Test > drm-intel-nightly Series Applied > > > ---------------------------------------------------------------------------------------------------------------- > --- > > ILK igt_kms_flip_flip-vs-absolute-wf_vblank > DMESG_WARN(1) PASS(3) DMESG_WARN(2) PASS(2) > > ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible > DMESG_WARN(1) PASS(3) DMESG_WARN(1) PASS(3) > > .. > > > > HTH, > > > > -- > > Damien > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Nov 17, 2014 at 07:28:28PM +0100, Daniel Vetter wrote: > On Fri, Nov 14, 2014 at 05:24:35PM +0000, Damien Lespiau wrote: > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > --- > > drivers/gpu/drm/i915/intel_ddi.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c > > index b5a279a..924f1ec 100644 > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > @@ -767,12 +767,20 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder, > > > > pipe_config->port_clock = link_clock; > > > > + /* > > + * On SKL the eDP DPLL (DPLL0 as we don't use SSC) is not part of the > > + * shared DPLL framework and thus needs to be read out separately > > + */ > > + if (encoder->type == INTEL_OUTPUT_EDP) > > Hw state readout shouldn't depend upon our sw state, and given the > multiple personality nature of DDI ports I think this is the case here: We > might have a different opinion than the bios guys about what's edp (it > happened) or how consistently to apply this clock selection algo (also > happened). So might be better to stuff this into the ddi clock readout > code (the one where you patched away the WARN for DPLL0 I guess). And after a night of pondering I stand correct on our irc discussion about putting dpll0 into the shared dpll infrastructure - if the bios indeed does something we don't expect and we don't properly track the use count for dpll0 it'll blow up. So I guess we'll need indeed need that. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index b5a279a..924f1ec 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -767,12 +767,20 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder, pipe_config->port_clock = link_clock; + /* + * On SKL the eDP DPLL (DPLL0 as we don't use SSC) is not part of the + * shared DPLL framework and thus needs to be read out separately + */ + if (encoder->type == INTEL_OUTPUT_EDP) + pipe_config->dpll_hw_state.ctrl1 = (dpll_ctl1 >> (dpll * 6)) & 0x3f; + if (pipe_config->has_dp_encoder) pipe_config->adjusted_mode.crtc_clock = intel_dotclock_calculate(pipe_config->port_clock, &pipe_config->dp_m_n); else pipe_config->adjusted_mode.crtc_clock = pipe_config->port_clock; + } static void hsw_ddi_clock_get(struct intel_encoder *encoder,
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> --- drivers/gpu/drm/i915/intel_ddi.c | 8 ++++++++ 1 file changed, 8 insertions(+)