summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display (follow)
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Add missing HDMI audio pixel clocks for gen12Kai Vehmanen2020-03-111-0/+8
| | | | | | | | | | | | Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz and 593.4/594Mhz. Add the missing rates and add logic to ignore them if running on older hardware. Bspec: 49333 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310162338.9387-1-kai.vehmanen@linux.intel.com
* drm/i915/overlay: convert to drm_device based logging.Wambui Karuga2020-03-111-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_overlay.c. This transformation was achieved using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Note that this converts DRM_DEBUG to drm_dbg(). Checkpatch warnings were addressed manually. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ca3c14de13e308419caf33eb4bbf274f5387f1e0.1583766715.git.jani.nikula@intel.com
* drm/i915/lvds: convert to drm_device based logging macros.Wambui Karuga2020-03-111-18/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_lvds.c. This transformation was done by the following coccinelle script that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e622ebd2ce07291f2db56174a0a0b31cc2df67df.1583766715.git.jani.nikula@intel.com
* drm/i915/lpe_audio: convert to drm_device based logging macros.Wambui Karuga2020-03-111-9/+14
| | | | | | | | | | | | | Convert various uses of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_lpe_audio.c. Note that this converts DRM_DEBUG to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/98588d757a3729d7c8a4b1aaa0b5e7d160398b89.1583766715.git.jani.nikula@intel.com
* drm/i915/hotplug: convert to drm_device based logging.Wambui Karuga2020-03-111-16/+24
| | | | | | | | | | | Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_hotplug.c. In some cases, this involves extracting the drm_i915_private pointer from the drm_device struct to be used in the logging macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3dfda89ab4a234f299ada77abd14163cef3f8bd4.1583766715.git.jani.nikula@intel.com
* drm/i915/gmbus: convert to drm_device based logging,Wambui Karuga2020-03-111-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conversion instances of printk based drm logging macros to use the struct drm_device based logging macros in i915/display/intel_gmbus.c. This was done using the following coccinelle semantic patch that transforms based on the existence of an existing drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5964ce0a603e2ec0e6110c927a11234e66891258.1583766715.git.jani.nikula@intel.com
* drm/i915/fifo_underrun: convert to drm_device based logging.Wambui Karuga2020-03-111-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_fifo_underrun.c. This was done using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3e8e74494c8aa662ab3fb4de1dac63fedef35c47.1583766715.git.jani.nikula@intel.com
* drm/i915/dsb: convert to drm_device based logging macros.Wambui Karuga2020-03-111-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts uses of the printk based drm logging macros to the struct drm_device logging macros in i915/display/intel_dsb.c. This was done using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2e049c74146f5430ea95653a4f745224d36f960.1583766715.git.jani.nikula@intel.com
* drm/i915/display: Do not write in removed FBC fence registersRadhakrishna Sripada2020-03-101-1/+1
| | | | | | | | | | | | | | | | | Platforms without fences don't have FBC host tracking and those registers are marked as reserved in those platforms. v2: checking num_fences to write to FBC fence registers (Ville) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-2-jose.souza@intel.com
* drm/i915/display: Deactive FBC in fastsets when disabled by parameterJosé Roberto de Souza2020-03-101-22/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the kms_frontbuffer_tracking tests disables the feature being tested, draw, get the CRC then enable the feature, draw again, get the CRC and check if it matches. Some times it is able to do that with a fastset, so intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was not checking if FBC is now enabled in this CRTC leaving FBC active and causing the warning bellow in __intel_fbc_disable() [IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw Setting dangerous option enable_fbc - tainting kernel i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1 i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36 [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz [drm:intel_dp_compute_config [i915]] Force DSC en = 0 [drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24 [drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000 i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset] i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode: [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode: [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa [drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0 [drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid> i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] rotation: 0x1, scaler: -1 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0 i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1 i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS ------------[ cut here ]------------ i915 0000:00:02.0: drm_WARN_ON(fbc->active) WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G U 5.5.0-CI-Trybot_5651+ #1 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915] Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1 RSP: 0018:ffffc90000613b68 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006 RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1 RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000 R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40 R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000 FS: 00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0 PKRU: 55555554 Call Trace: intel_fbc_disable+0x4a/0x50 [i915] intel_update_crtc+0x12c/0x1d0 [i915] skl_commit_modeset_enables+0x14d/0x600 [i915] intel_atomic_commit_tail+0x30d/0x1480 [i915] ? queue_work_on+0x31/0x70 ? intel_atomic_commit_ready+0x3f/0x48 [i915] ? __i915_sw_fence_complete+0x1a0/0x250 [i915] intel_atomic_commit+0x312/0x390 [i915] intel_psr_fastset_force+0x119/0x150 [i915] i915_edp_psr_debug_set+0x53/0x70 [i915] simple_attr_write+0xb0/0xd0 full_proxy_write+0x51/0x80 vfs_write+0xb9/0x1d0 ksys_write+0x9f/0xe0 do_syscall_64+0x4f/0x220 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f8157240281 Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53 RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281 RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152 R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000 irq event stamp: 55208 hardirqs last enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330 hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c softirqs last enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0 ---[ end trace afa50c52e5a512bb ]--- [drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1] i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A] [drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0 i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0 v2: using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-1-jose.souza@intel.com
* drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacksLyude Paul2020-03-101-2/+31
| | | | | | | | | | | | | | | | | | | | | i915 can enable aux device nodes for DP MST by calling drm_dp_mst_connector_late_register()/ drm_dp_mst_connector_early_unregister(), so let's hook that up. Changes since v1: * Call intel_connector_register/unregister() from intel_dp_mst_connector_late_register/unregister() so we don't lose error injection - Ville Syrjälä Changes since v2: * Don't forget to clean up if intel_connector_register() fails - Ville Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310195122.1590925-1-lyude@redhat.com
* drm/i915: Lock gmbus/aux mutexes while changing cdclkVille Syrjälä2020-03-091-0/+22
| | | | | | | | | | | | | | | | gmbus/aux may be clocked by cdclk, thus we should make sure no transfers are ongoing while the cdclk frequency is being changed. We do that by simply grabbing all the gmbus/aux mutexes. No one else should be holding any more than one of those at a time so the lock ordering here shouldn't matter. v2: Use mutex_lock_nest_lock() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302174442.5803-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Pass the crtc to the low level read_lut() funcsVille Syrjälä2020-03-091-26/+25
| | | | | | | | | | | The low level read_lut() functions don't need the entire crtc state as they know exactly what they're reading. Just need to pass in the crtc to get at the pipe. This now neatly mirrors the load_lut() direction. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-10-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Fix readout of PIPEGCMAXVille Syrjälä2020-03-091-1/+2
| | | | | | | | | | | PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can represent a value of 1.0 when the maximum we can store in the software LUT is 0.ffff. Clamp the value so that it gets saturated to the max the uapi supports. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-9-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Refactor LUT read functionsVille Syrjälä2020-03-091-61/+63
| | | | | | | | | | Extract all the 'hw value -> LUT entry' stuff into small helpers to make the main 'read out the entire LUT' loop less bogged down by such mundane details. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-8-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Clean up integer types in color codeVille Syrjälä2020-03-091-24/+19
| | | | | | | | | | | | A variable called 'i' having an unsigned type is just looking for trouble, and using a sized type generally makes no sense either. Change all of them to just plain old int. And do the same for some 'lut_size' variables which generally provide the loop end codition for 'i'. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-7-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/Ville Syrjälä2020-03-091-2/+2
| | | | | | | | | | chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so let's rename it to reflect that fact. This also mirrors the other direction's chv_load_cgm_gamma(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-6-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: s/blob_data/lut/Ville Syrjälä2020-03-091-33/+33
| | | | | | | | | | We're talking about LUT contents here so let's call the thing 'lut' rather than 'blob_data'. This is the name the load_lut() code used before already. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-5-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Split i9xx_read_lut_8() to gmch vs. ilk variantsVille Syrjälä2020-03-091-6/+35
| | | | | | | | | | To mirror the load_luts path let's clone an ilk+ version from i9xx_read_lut_8(). I guess the extra branch isn't a huge issue but feels better to make a clean split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-4-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Clean up i9xx_load_luts_internal()Ville Syrjälä2020-03-091-44/+60
| | | | | | | | | | Split i9xx_load_luts_internal() into neat gmch vs. ilk+ chunks. Avoids at least one branch in the inner loop, and makes life a bit less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-3-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Polish CHV CGM CSC loadingVille Syrjälä2020-03-091-37/+38
| | | | | | | | | | | | | | | Only load the CGM CSC based on the cgm_mode bit like we do with the gamma/degamma LUTs. And make the function naming and arguments consistent as well. TODO: the code to convert the coefficients look totally bogus. IIRC CHV uses two's complement format but the code certainly doesn't generate that, so probably negative coefficients are totally busted. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-2-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915: Fix documentation for intel_dpll_get_freq()Imre Deak2020-03-092-0/+13
| | | | | | | | | | | | Fix the following kerneldoc warning and while at it also the doc for the corresponding vfunc hook. $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304150918.25473-1-imre.deak@intel.com
* drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v5)Vivek Kasireddy2020-03-061-22/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some platforms such as Elkhart Lake, although we may use DDI D to drive a connector, we have to use PHY A (Combo Phy PORT A) to detect the hotplug interrupts as per the spec because there is no one-to-one mapping between DDIs and PHYs. Therefore, use the function intel_port_to_phy() which contains the logic for such mapping(s) to find the correct hpd_pin. This change should not affect other platforms as there is always a one-to-one mapping between DDIs and PHYs. v2: - Convert the case statements to use PHYs instead of PORTs (Jani) v3: - Refactor the function to reduce the number of return statements by lumping all the case statements together except PHY_F which needs special handling (Jose) v4: - Add a comment describing how the HPD pin value associated with any port can be retrieved using port or phy enum value. (Jani) v5: - Use case ranges instead of individual labels and also normalize the return statement by adding -PHY_A to the expression (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304234240.12062-1-vivek.kasireddy@intel.com
* drm/i915: properly sanity check batch_start_offsetMatthew Auld2020-03-061-6/+6
| | | | | | | | | | | | | | | | | | | | Check the edge case where batch_start_offset sits exactly on the batch size. v2: add new range_overflows variant to capture the special case where the size is permitted to be zero, like with batch_len. v3: other way around. the common case is the exclusive one which should just be >=, with that we then just need to convert the three odd ball cases that don't apply to use the new inclusive _end version. Testcase: igt/gem_exec_params/invalid-batch-start-offset Fixes: 0b5372727be3 ("drm/i915/cmdparser: Use cached vmappings") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200306094735.258285-1-matthew.auld@intel.com
* drm/i915/display: Decrease log levelSwati Sharma2020-03-051-2/+3
| | | | | | | | | | | | | | Converting error to debug print if sink fails to configure scrambling or TMDS bit clock ratio. In this case, we are timing out while disabling the scrambling and setting the SCDC ratio, as there is no response to the I2C SCDC write from the sink device. Error isn't due to something wrong done from driver side. Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302213807.6488-1-swati2.sharma@intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
* drm/i915: Add invert-brightness quirk for Thundersoft TST178 tabletHans de Goede2020-03-041-0/+10
| | | | | | | | | | | | | | | | | | The Thundersoft TST178 tablet uses a DSI panel with an external PWM controller (as all DSI panels do). But unlike other DSI panels a duty-cycle of 100% turns the backlight off and 0% sets it to maximum brightness. I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but it does not set the active_low_pwm flag. This tablet re-uses the main PCI vendor and product ids for the subsystem ids, so I see no other option then to add a DMI based quirk to fix this. Note that the PWM backlight code in intel_panel.c currently does not honor the vbt.active_low_pwm flag, but that does not matter in this case. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-2-hdegoede@redhat.com
* drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight()Hans de Goede2020-03-041-7/+11
| | | | | | | | | | | Use intel_panel_compute_brightness() from pwm_setup_backlight() so that we correctly take i915_modparams.invert_brightness and/or QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial brightness value. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-1-hdegoede@redhat.com
* drm/i915/ehl: Check PHY type before reading DPLL frequencyMatt Roper2020-03-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | intel_ddi_clock_get() tests the DPLL ID against DPLL_ID_ICL_TBTPLL (2) to determine whether to try to descend into a TBT-specific handler. However this test will also be true when DPLL4 on EHL is used since that shares the same DPLL ID (2). Add an extra check to ensure the PHY is actually a Type-C PHY before descending into the TBT handling. This should ensure EHL still takes the correct code path and somewhat future-proof the code as well. v2: Drop the gen+ check since only gen11+ platforms can have Type-C outputs. (Imre) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Imre Deak <imre.deak@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1369 Fixes: 45e4728b87ad ("drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303195043.959913-1-matthew.d.roper@intel.com
* drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panelLyude Paul2020-03-041-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | The X1 Extreme is one of the systems that lies about which backlight interface that it uses in its VBIOS as PWM backlight controls don't work at all on this machine. It's possible that this panel could be one of the infamous ones that can switch between PWM mode and DPCD backlight control mode, but we haven't gotten any more details on this from Lenovo just yet. For the time being though, making sure the backlight 'just works' is a bit more important. So, add a quirk to force DPCD backlight controls on for these systems based on EDID (since this panel doesn't appear to fill in the device ID). Hopefully in the future we'll figure out a better way of probing this. Changes since v2: * The bugzilla URL is deprecated, bug reporting happens on gitlab now. Update the messages we print to reflect this * Also, take the opportunity to move FDO_BUG_URL out of i915_utils.c and into i915_utils.h so that other places which print things that aren't traditional errors but are worth filing bugs about, can actually use it. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303215320.93491-1-lyude@redhat.com
* drm/dp: Introduce EDID-based quirksLyude Paul2020-03-044-6/+10
| | | | | | | | | | | | | | | | | | | | The whole point of using OUIs is so that we can recognize certain devices and potentially apply quirks for them. Normally this should work quite well, but there appears to be quite a number of laptop panels out there that will fill the OUI but not the device ID. As such, for devices like this I can't imagine it's a very good idea to try relying on OUIs for applying quirks. As well, some laptop vendors have confirmed to us that their panels have this exact issue. So, let's introduce the ability to apply DP quirks based on EDID identification. We reuse the same quirk bits for OUI-based quirks, so that callers can simply check all possible quirks using drm_dp_has_quirk(). Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-2-lyude@redhat.com
* drm/i915/hdcp: Fix config_stream_type() ret valueAnshuman Gupta2020-03-041-1/+5
| | | | | | | | | | | | | | | | DP shim's config_stream_type considered to be succeeded when return value of intel_dp_hdcp2_write_msg() equals to size of message to be written, it makes config_stream_type to return a zero success value in order to succeed the HDCP auth. v2: - config_stream_type() returns 0 on success. [Ram] CC: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303073838.25871-1-anshuman.gupta@intel.com
* drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msgAnshuman Gupta2020-03-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | HDCP Repeater initializes seq_num_V to 0 at the beginning of hdcp Session i.e. after AKE_init received, refer HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20. HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT considers failure of authentication if the repeater provides a non-zero value in seq_num_V in the first, RepeaterAuth_Send_ReceiverID_List message. Make sure that HDCP repeater initializes seq_num_V to zero at beginning of session i.e. after AKE_Init, fail the Auth if there is non zero seq_num_V. v2: - Used existing hdcp2_encrypted flag instead of declaring new flag. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200220123217.23635-2-anshuman.gupta@intel.com
* drm/i915: Polish CHV .load_luts() a bitVille Syrjälä2020-03-031-7/+4
| | | | | | | | | | | | | | It irks me to use crtc_state_is_legacy_gamma() inside the guts of the CHV color management code. Let's get rid of it and instead just consult cgm_mode to figure out if we want to enable the pipe gamma or the CGM gamma. Also CHV display engine is based on i965/g4x so we should fall back to the i965 path when the CGM gamma is not used. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-3-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
* drm/i915/vgpu: improve vgpu abstractionsJani Nikula2020-03-032-0/+2
| | | | | | | | | | | | | | Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to intel_vgpu_detect() to match other function naming, un-inline intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and intel_vgpu_has_huge_gtt() to reduce header interdependencies. The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-1-jani.nikula@intel.com
* drm/i915: Fix kbuild test robot build errorAnshuman Gupta2020-03-031-9/+9
| | | | | | | | | | | | | | | | has_transcoder() was unused because function which was using it, intel_display_capture_error_state() defined under CONFIG_DRM_I915_CAPTURE_ERROR. Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR. No functional change. Fixes: d54c1a513c48 ("drm/i915: Fix broken transcoder err state") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227175147.11362-1-anshuman.gupta@intel.com
* drm/i915/hdcp: conversion to struct drm_device based logging macros.Ramalingam C2020-03-031-47/+62
| | | | | | | | | | | | | | | | | | | Converts remaining instances of the printk based logging macros in i915/display/intel_hdcp.c with the struct drm_device based macros manually. This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.") v2: i915_dev_priv is used instead of drm_device for reusability [JaniN] v3: Made it independent from the series. once instance of dev_priv naming is changed to i915 [Jani N] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212123007.6659-1-ramalingam.c@intel.com
* drm/i915: move watermark structs more towards usageJani Nikula2020-03-031-0/+16
| | | | | | | | | Shrink i915_drv.h a bit by moving watermark structs where they are needed. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227170047.31089-3-jani.nikula@intel.com
* drm/i915/dmc: Use firmware v2.06 for TGLJosé Roberto de Souza2020-03-031-2/+2
| | | | | | | | | New firmware contains minor fixes around context restore. Reviewed-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227235005.18706-1-jose.souza@intel.com
* drm/i915: Unify the DPLL ref clock frequency trackingImre Deak2020-03-022-56/+124
| | | | | | | | | | | | | | | | | | | | | | All platforms using the shared DPLL framework use 3 reference clocks for their DPLLs: SSC, non-SSC and DSI. For a more unified way across platforms store the frequency of these ref clocks as part of the DPLL global state. This also allows us to keep the HW access reading out the ref clock value separate from the DPLL frequency calculation that depends on the ref clock. For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code has its own logic for calculating DPLL parameters instead of the shared DPLL framework. v2: - Apply the ICL combo PHY PLL ref_clock/2 adjustment during the frequency->PLL param conversion direction as well. (CI shards) - s/kHZ/kHz/ (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228153328.17842-1-imre.deak@intel.com
* drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading out againImre Deak2020-03-021-5/+2
| | | | | | | | | Instead of reading out the WRPLL/SPLL control values from HW, we can use the DPLL state that was already read out, or swapped-to. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-13-imre.deak@intel.com
* drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculationImre Deak2020-03-024-145/+140
| | | | | | | | | Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-12-imre.deak@intel.com
* drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency calculationImre Deak2020-03-021-35/+56
| | | | | | | | | Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-11-imre.deak@intel.com
* drm/i915/hsw: Split out the SPLL parameter calculationImre Deak2020-03-021-14/+22
| | | | | | | | | For consistency with the WRPLL/LCPLL parameter calculation functions, split out the SPLL specific logic to its own function. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-10-imre.deak@intel.com
* drm/i915/hsw: Rename the get HDMI/DP DPLL funcs to get WRPLL/LCPLLImre Deak2020-03-021-5/+5
| | | | | | | | | | The types of PLLs used for HDMI/DP on HSW are WRPLL/LCPLL accordingly, so use these names to align better with the rest of WRPLL/LCPLL function names elsewhere. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-9-imre.deak@intel.com
* drm/i915/skl: Parametrize the DPLL ref clock instead of open-coding itImre Deak2020-03-021-9/+12
| | | | | | | | | | | For clarity keep the SKL DPLL ref clock in a variable instead of open-coding it. Store the value in kHZ units as done on other platforms. This allows us in a later patch to keep track of the DPLL ref clock in a more unified way across all platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-8-imre.deak@intel.com
* drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.cImre Deak2020-03-025-437/+431
| | | | | | | | | | | | | Move all the DPLL params->DPLL frequency conversion functions to intel_dpll_mgr.c where the corresponding inverse conversions are. The GEN11+ TBT PLL outputs multiple frequencies and for selecting the one in use we need to check the DDI CLK mux. As part of the DDI clock logic this selection is kept in intel_ddi.c. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-7-imre.deak@intel.com
* drm/i915/hsw: Use the DPLL ID when calculating DPLL clockImre Deak2020-03-021-9/+8
| | | | | | | | | Instead of converting DPLL ID to CLK_SEL to identify the DPLL use the DPLL ID directly for this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-6-imre.deak@intel.com
* drm/i915: Move the DPLL vfunc inits after the func definesImre Deak2020-03-021-60/+60
| | | | | | | | | Move the per-platform DPLL and DPLL-manager vfunc initializations right after the corresponding function definitions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-5-imre.deak@intel.com
* drm/i915: Keep the global DPLL state in a DPLL specific structImre Deak2020-03-025-47/+49
| | | | | | | | | | For clarity add a new DPLL specific struct to the i915 device struct and move all DPLL fields into it. Accordingly remove the dpll_ prefixes, as the new struct already provides the required namespacing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-4-imre.deak@intel.com
* drm/i915: Move DPLL HW readout/sanitize fns to intel_dpll_mgr.cImre Deak2020-03-023-42/+63
| | | | | | | | | Move the HW readout/sanitize functions to intel_dpll_mgr.c which contains the rest of shared DPLL functionality. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-3-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-08 07:58:27 +0100