[Intel-gfx] [PATCH v4 1/2] drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"
From: Ville Syrjälä Make the min_pixclk thing less confusing by changing it to track the minimum acceptable cdclk frequency instead. This means moving the application of the guardbands to a slightly higher level from the low level platform specific calc_cdclk() functions. The immediate benefit is elimination of the confusing 2x factors on GLK/CNL+ in the audio workarounds (which stems from the fact that the pipes produce two pixels per clock). v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling v3: Squash with the CNL cdclk limits patch (DK) v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) Cc: Paulo Zanoni Cc: Rodrigo Vivi Cc: Dhinakaran Pandiyan Cc: Maarten Lankhorst Reviewed-by: Dhinakaran Pandiyan Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 12 ++- drivers/gpu/drm/i915/intel_cdclk.c | 202 ++- drivers/gpu/drm/i915/intel_display.c | 21 ++-- drivers/gpu/drm/i915/intel_drv.h | 4 +- 4 files changed, 125 insertions(+), 114 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 0383e879a315..7a20f58e711a 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -569,6 +569,15 @@ struct i915_hotplug { (__i)++) \ for_each_if (plane_state) +#define for_each_new_intel_crtc_in_state(__state, crtc, new_crtc_state, __i) \ + for ((__i) = 0; \ +(__i) < (__state)->base.dev->mode_config.num_crtc && \ +((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \ + (new_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].new_state), 1); \ +(__i)++) \ + for_each_if (crtc) + + struct drm_i915_private; struct i915_mm_struct; struct i915_mmu_object; @@ -2335,7 +2344,8 @@ struct drm_i915_private { struct mutex dpll_lock; unsigned int active_crtcs; - unsigned int min_pixclk[I915_MAX_PIPES]; + /* minimum acceptable cdclk for each pipe */ + int min_cdclk[I915_MAX_PIPES]; int dpio_phy_iosf_port[I915_NUM_PHYS_VLV]; diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index 1241e5891b29..fafffb04b447 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -417,24 +417,21 @@ static void hsw_get_cdclk(struct drm_i915_private *dev_priv, cdclk_state->cdclk = 54; } -static int vlv_calc_cdclk(struct drm_i915_private *dev_priv, - int max_pixclk) +static int vlv_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk) { int freq_320 = (dev_priv->hpll_freq << 1) % 32 != 0 ? 33 : 32; - int limit = IS_CHERRYVIEW(dev_priv) ? 95 : 90; /* * We seem to get an unstable or solid color picture at 200MHz. * Not sure what's wrong. For now use 200MHz only when all pipes * are off. */ - if (!IS_CHERRYVIEW(dev_priv) && - max_pixclk > freq_320*limit/100) + if (IS_VALLEYVIEW(dev_priv) && min_cdclk > freq_320) return 40; - else if (max_pixclk > 27*limit/100) + else if (min_cdclk > 27) return freq_320; - else if (max_pixclk > 0) + else if (min_cdclk > 0) return 27; else return 20; @@ -612,13 +609,13 @@ static void chv_set_cdclk(struct drm_i915_private *dev_priv, intel_display_power_put(dev_priv, POWER_DOMAIN_PIPE_A); } -static int bdw_calc_cdclk(int max_pixclk) +static int bdw_calc_cdclk(int min_cdclk) { - if (max_pixclk > 54) + if (min_cdclk > 54) return 675000; - else if (max_pixclk > 45) + else if (min_cdclk > 45) return 54; - else if (max_pixclk > 337500) + else if (min_cdclk > 337500) return 45; else return 337500; @@ -724,23 +721,23 @@ static void bdw_set_cdclk(struct drm_i915_private *dev_priv, cdclk, dev_priv->cdclk.hw.cdclk); } -static int skl_calc_cdclk(int max_pixclk, int vco) +static int skl_calc_cdclk(int min_cdclk, int vco) { if (vco == 864) { - if (max_pixclk > 54) + if (min_cdclk > 54) return 617143; - else if (max_pixclk > 432000) + else if (min_cdclk > 432000) return 54; - else if (max_pixclk > 308571) + else if (min_cdclk > 308571) return 432000; else return 308571; } else { - if (max_pixclk > 54) + if (min_cdclk > 54) return 675000; - else if (max_pixclk > 45) + else if
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"
On Wed, Aug 30, 2017 at 09:57:03PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the min_pixclk thing less confusing by changing it to track > the minimum acceptable cdclk frequency instead. This means moving > the application of the guardbands to a slightly higher level from > the low level platform specific calc_cdclk() functions. > > The immediate benefit is elimination of the confusing 2x factors > on GLK/CNL+ in the audio workarounds (which stems from the fact > that the pipes produce two pixels per clock). > > v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling > v3: Squash with the CNL cdclk limits patch (DK) > v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) > > Cc: Paulo Zanoni > Cc: Rodrigo Vivi > Cc: Dhinakaran Pandiyan > Cc: Maarten Lankhorst > Reviewed-by: Dhinakaran Pandiyan > Signed-off-by: Ville Syrjälä I didn't get any objections from the CNL camp, so I went ahead and pushed the series. Thanks for the reviews. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"
Op 31-08-17 om 20:48 schreef Ville Syrjälä: > On Wed, Aug 30, 2017 at 09:57:03PM +0300, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> Make the min_pixclk thing less confusing by changing it to track >> the minimum acceptable cdclk frequency instead. This means moving >> the application of the guardbands to a slightly higher level from >> the low level platform specific calc_cdclk() functions. >> >> The immediate benefit is elimination of the confusing 2x factors >> on GLK/CNL+ in the audio workarounds (which stems from the fact >> that the pipes produce two pixels per clock). >> >> v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling >> v3: Squash with the CNL cdclk limits patch (DK) >> v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) >> >> Cc: Paulo Zanoni >> Cc: Rodrigo Vivi >> Cc: Dhinakaran Pandiyan >> Cc: Maarten Lankhorst >> Reviewed-by: Dhinakaran Pandiyan >> Signed-off-by: Ville Syrjälä > I didn't get any objections from the CNL camp, so I went ahead and > pushed the series. Thanks for the reviews. > I seem to have a WARN_ON during init now on my broadwell, likely related to this series? [ 13.105310] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 13.132264] systemd-journald[159]: Successfully sent stream file descriptor to service manager. [ 13.161016] WARN_ON(min_cdclk < 0) [ 13.161078] [ cut here ] [ 13.161336] WARNING: CPU: 1 PID: 209 at drivers/gpu/drm/i915/intel_display.c:15070 intel_modeset_setup_hw_state+0x15a4/0x3000 [i915] [ 13.161517] Modules linked in: snd_seq_device snd_timer drbg i915(+) cfg80211 ecdh_generic(+) prime_numbers drm_kms_helper snd syscopyarea sysfillrect sysimgblt fb_sys_fops drm soundcore fan thermal i2c_designware_platform i2c_designware_core acpi_pad parport_pc ppdev parport autofs4 [ 13.161822] CPU: 1 PID: 209 Comm: systemd-udevd Tainted: G U 4.13.0-rc7-patser+ #5236 [ 13.161884] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 [ 13.161963] task: 8800cd054500 task.stack: 8800c684 [ 13.162083] RIP: 0010:intel_modeset_setup_hw_state+0x15a4/0x3000 [i915] [ 13.162393] RSP: 0018:8800c68472a0 EFLAGS: 00010282 [ 13.162434] RAX: 0016 RBX: 8800c65d4c80 RCX: 8800cd054cd8 [ 13.162478] RDX: RSI: 8800cd054d78 RDI: 8800cd054cd4 [ 13.162521] RBP: 8800c68473e0 R08: R09: [ 13.162565] R10: 8800c65d4e57 R11: R12: dc00 [ 13.162611] R13: 8800c819 R14: 8800c65d6f88 R15: 8800c65d6e80 [ 13.162654] FS: 7fc3599c08c0() GS:8800d4e8() knlGS: [ 13.162710] CS: 0010 DS: ES: CR0: 80050033 [ 13.162750] CR2: 7ffd657bffb8 CR3: cb477000 CR4: 003406e0 [ 13.162794] Call Trace: [ 13.162911] ? intel_mode_from_pipe_config+0x560/0x560 [i915] [ 13.162975] ? drm_modeset_lock+0x162/0x270 [drm] [ 13.163036] ? drm_modeset_lock_all_ctx+0xf3/0x140 [drm] [ 13.163192] intel_modeset_init+0x327b/0x4720 [i915] [ 13.163316] ? intel_modeset_init_hw+0x160/0x160 [i915] [ 13.163431] i915_driver_load+0x2c50/0x3300 [i915] [ 13.163473] ? find_held_lock+0x36/0x1c0 [ 13.163579] ? __i915_printk+0x280/0x280 [i915] [ 13.163722] ? wait_for_completion_killable_timeout+0x430/0x430 [ 13.163775] ? mutex_unlock+0xd/0x10 [ 13.163809] ? acpi_dev_found+0xa7/0xb0 [ 13.163910] i915_pci_probe+0x108/0x180 [i915] [ 13.164011] ? i915_pci_remove+0x50/0x50 [i915] [ 13.164080] local_pci_probe+0xe8/0x160 [ 13.164120] pci_device_probe+0x3fe/0x580 [ 13.164190] ? pci_device_remove+0x1b0/0x1b0 [ 13.164230] ? _raw_spin_unlock+0x2c/0x40 [ 13.164271] driver_probe_device+0x2fb/0x670 [ 13.164313] ? driver_probe_device+0x670/0x670 [ 13.164352] __driver_attach+0xff/0x140 [ 13.164388] bus_for_each_dev+0x11b/0x1b0 [ 13.164675] ? store_drivers_autoprobe+0x120/0x120 [ 13.164719] ? _raw_spin_unlock+0x2c/0x40 [ 13.164759] driver_attach+0x45/0x50 [ 13.164791] bus_add_driver+0x2a2/0x520 [ 13.164832] driver_register+0x256/0x310 [ 13.164865] ? __raw_spin_lock_init+0x2d/0xf0 [ 13.164905] __pci_register_driver+0x192/0x1a0 [ 13.165013] i915_init+0xc8/0xd5 [i915] [ 13.165081] ? 0xc09e [ 13.165114] do_one_initcall+0x121/0x204 [ 13.165206] ? initcall_blacklisted+0x160/0x160 [ 13.165245] ? kasan_unpoison_shadow+0x35/0x50 [ 13.165282] ? kasan_kmalloc+0xb6/0xd0 [ 13.165317] ? kasan_unpoison_shadow+0x35/0x50 [ 13.165355] ? __asan_register_globals+0x7c/0xa0 [ 13.165399] do_init_module+0x1b6/0x500 [ 13.165440] load_module+0x6f4b/0x85e0 [ 13.165501] ? module_frob_arch_sections+0x20/0x20 [ 13.165554] ? open_exec+0x40/0x40 [ 13.165601] SYSC_finit_module+0x110/0x180 [ 13.165635] ? SYSC_finit_module+0x110/0x180 [ 13.
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"
On Mon, Sep 04, 2017 at 12:39:25PM +0200, Maarten Lankhorst wrote: > Op 31-08-17 om 20:48 schreef Ville Syrjälä: > > On Wed, Aug 30, 2017 at 09:57:03PM +0300, ville.syrj...@linux.intel.com > > wrote: > >> From: Ville Syrjälä > >> > >> Make the min_pixclk thing less confusing by changing it to track > >> the minimum acceptable cdclk frequency instead. This means moving > >> the application of the guardbands to a slightly higher level from > >> the low level platform specific calc_cdclk() functions. > >> > >> The immediate benefit is elimination of the confusing 2x factors > >> on GLK/CNL+ in the audio workarounds (which stems from the fact > >> that the pipes produce two pixels per clock). > >> > >> v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage > >> handling > >> v3: Squash with the CNL cdclk limits patch (DK) > >> v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) > >> > >> Cc: Paulo Zanoni > >> Cc: Rodrigo Vivi > >> Cc: Dhinakaran Pandiyan > >> Cc: Maarten Lankhorst > >> Reviewed-by: Dhinakaran Pandiyan > >> Signed-off-by: Ville Syrjälä > > I didn't get any objections from the CNL camp, so I went ahead and > > pushed the series. Thanks for the reviews. > > > I seem to have a WARN_ON during init now on my broadwell, likely related to > this series? > > [ 13.105310] i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > [ 13.132264] systemd-journald[159]: Successfully sent stream file > descriptor to service manager. > [ 13.161016] WARN_ON(min_cdclk < 0) Hmm. I think I need to see the full dmesg to figure this one out. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"
Op 04-09-17 om 17:58 schreef Ville Syrjälä: > On Mon, Sep 04, 2017 at 12:39:25PM +0200, Maarten Lankhorst wrote: >> Op 31-08-17 om 20:48 schreef Ville Syrjälä: >>> On Wed, Aug 30, 2017 at 09:57:03PM +0300, ville.syrj...@linux.intel.com >>> wrote: From: Ville Syrjälä Make the min_pixclk thing less confusing by changing it to track the minimum acceptable cdclk frequency instead. This means moving the application of the guardbands to a slightly higher level from the low level platform specific calc_cdclk() functions. The immediate benefit is elimination of the confusing 2x factors on GLK/CNL+ in the audio workarounds (which stems from the fact that the pipes produce two pixels per clock). v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling v3: Squash with the CNL cdclk limits patch (DK) v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) Cc: Paulo Zanoni Cc: Rodrigo Vivi Cc: Dhinakaran Pandiyan Cc: Maarten Lankhorst Reviewed-by: Dhinakaran Pandiyan Signed-off-by: Ville Syrjälä >>> I didn't get any objections from the CNL camp, so I went ahead and >>> pushed the series. Thanks for the reviews. >>> >> I seem to have a WARN_ON during init now on my broadwell, likely related to >> this series? >> >> [ 13.105310] i915 :00:02.0: vgaarb: changed VGA decodes: >> olddecodes=io+mem,decodes=io+mem:owns=io+mem >> [ 13.132264] systemd-journald[159]: Successfully sent stream file >> descriptor to service manager. >> [ 13.161016] WARN_ON(min_cdclk < 0) > Hmm. I think I need to see the full dmesg to figure this one out. > [ 188.354997] [drm:intel_modeset_init [i915]] 3 display pipes available. [ 188.356575] [drm:intel_update_cdclk [i915]] Current CD clock rate: 54 kHz, VCO: 0 kHz, ref: 0 kHz [ 188.357067] [drm:intel_update_max_cdclk [i915]] Max CD clock rate: 54 kHz [ 188.357220] [drm:intel_update_max_cdclk [i915]] Max dotclock rate: 54 kHz ... [ 188.363648] [drm:drm_atomic_set_mode_for_crtc [drm]] Set [MODE:640x480] for CRTC state 8800c79e2200 [ 188.363784] [drm:intel_crtc_compute_min_cdclk [i915]] required cdclk (607500 kHz) exceeds max (54 kHz) [ 188.363848] WARN_ON(min_cdclk < 0) ... [ 188.368005] [drm:intel_dump_pipe_config [i915]] [CRTC:36:pipe A][setup_hw_state] [ 188.368155] [drm:intel_dump_pipe_config [i915]] cpu_transcoder: A, pipe bpp: 24, dithering: 0 [ 188.368276] [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0 [ 188.368390] [drm:intel_dump_pipe_config [i915]] requested mode: [ 188.368692] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"640x480" 1286 54 640 656 752 800 480 490 492 525 0x40 0xa [ 188.368833] [drm:intel_dump_pipe_config [i915]] adjusted mode: [ 188.368897] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"640x480" 1286 54 640 656 752 800 480 490 492 525 0x40 0xa [ 188.369041] [drm:intel_dump_pipe_config [i915]] crtc timings: 54 640 656 752 800 480 490 492 525, type: 0x40 flags: 0xa [ 188.369235] [drm:intel_dump_pipe_config [i915]] port clock: 54, pipe src size: 720x400, pixel rate 607500 [ 188.369366] [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x, size: 0x028001e0, enabled [ 188.369490] [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0 [ 188.369600] [drm:hsw_dump_hw_state [i915]] dpll_hw_state: wrpll: 0x0 spll: 0x0 [ 188.369719] [drm:intel_dump_pipe_config [i915]] planes on this crtc Is this enough info? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Track minimum acceptable cdclk instead of "minimum dotclock"
On Mon, Sep 04, 2017 at 08:51:16PM +0200, Maarten Lankhorst wrote: > Op 04-09-17 om 17:58 schreef Ville Syrjälä: > > On Mon, Sep 04, 2017 at 12:39:25PM +0200, Maarten Lankhorst wrote: > >> Op 31-08-17 om 20:48 schreef Ville Syrjälä: > >>> On Wed, Aug 30, 2017 at 09:57:03PM +0300, ville.syrj...@linux.intel.com > >>> wrote: > From: Ville Syrjälä > > Make the min_pixclk thing less confusing by changing it to track > the minimum acceptable cdclk frequency instead. This means moving > the application of the guardbands to a slightly higher level from > the low level platform specific calc_cdclk() functions. > > The immediate benefit is elimination of the confusing 2x factors > on GLK/CNL+ in the audio workarounds (which stems from the fact > that the pipes produce two pixels per clock). > > v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage > handling > v3: Squash with the CNL cdclk limits patch (DK) > v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK) > > Cc: Paulo Zanoni > Cc: Rodrigo Vivi > Cc: Dhinakaran Pandiyan > Cc: Maarten Lankhorst > Reviewed-by: Dhinakaran Pandiyan > Signed-off-by: Ville Syrjälä > >>> I didn't get any objections from the CNL camp, so I went ahead and > >>> pushed the series. Thanks for the reviews. > >>> > >> I seem to have a WARN_ON during init now on my broadwell, likely related > >> to this series? > >> > >> [ 13.105310] i915 :00:02.0: vgaarb: changed VGA decodes: > >> olddecodes=io+mem,decodes=io+mem:owns=io+mem > >> [ 13.132264] systemd-journald[159]: Successfully sent stream file > >> descriptor to service manager. > >> [ 13.161016] WARN_ON(min_cdclk < 0) > > Hmm. I think I need to see the full dmesg to figure this one out. > > > [ 188.354997] [drm:intel_modeset_init [i915]] 3 display pipes available. > [ 188.356575] [drm:intel_update_cdclk [i915]] Current CD clock rate: 54 > kHz, VCO: 0 kHz, ref: 0 kHz > [ 188.357067] [drm:intel_update_max_cdclk [i915]] Max CD clock rate: 54 > kHz > [ 188.357220] [drm:intel_update_max_cdclk [i915]] Max dotclock rate: 54 > kHz > ... > [ 188.363648] [drm:drm_atomic_set_mode_for_crtc [drm]] Set [MODE:640x480] > for CRTC state 8800c79e2200 > [ 188.363784] [drm:intel_crtc_compute_min_cdclk [i915]] required cdclk > (607500 kHz) exceeds max (54 kHz) > [ 188.363848] WARN_ON(min_cdclk < 0) > ... > [ 188.368005] [drm:intel_dump_pipe_config [i915]] [CRTC:36:pipe > A][setup_hw_state] > [ 188.368155] [drm:intel_dump_pipe_config [i915]] cpu_transcoder: A, pipe > bpp: 24, dithering: 0 > [ 188.368276] [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0 > [ 188.368390] [drm:intel_dump_pipe_config [i915]] requested mode: > [ 188.368692] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"640x480" > 1286 54 640 656 752 800 480 490 492 525 0x40 0xa > [ 188.368833] [drm:intel_dump_pipe_config [i915]] adjusted mode: > [ 188.368897] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"640x480" > 1286 54 640 656 752 800 480 490 492 525 0x40 0xa > [ 188.369041] [drm:intel_dump_pipe_config [i915]] crtc timings: 54 640 > 656 752 800 480 490 492 525, type: 0x40 flags: 0xa Cool. 640x480 with a refresh rate of ~1286 Hz. I want one of those displays :P So now the question becomes if we made a mistake in the clock/timings readout or if the hardware is really programmed to use those values. > [ 188.369235] [drm:intel_dump_pipe_config [i915]] port clock: 54, pipe > src size: 720x400, pixel rate 607500 > [ 188.369366] [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x, > size: 0x028001e0, enabled > [ 188.369490] [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0 > [ 188.369600] [drm:hsw_dump_hw_state [i915]] dpll_hw_state: wrpll: 0x0 spll: > 0x0 > [ 188.369719] [drm:intel_dump_pipe_config [i915]] planes on this crtc > > > Is this enough info? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx