summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display
Commit message (Collapse)AuthorAgeFilesLines
...
| * drm/i915: ELiminate intel_pipe_to_cpu_transcoder() from assert_fdi_tx()Ville Syrjälä2019-12-111-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's start to eliminate intel_pipe_to_cpu_transcoder() so that we can get rid of one more crtc->config usage (which we will want to nuke as well). In the case of assert_fdi_tx() we know that we're never dealing with the EDP transcoder so we can simply replace this with a cast. v2: Fix poor English in comment Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112163812.22075-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/dsi: add support for DSCJani Nikula2019-12-111-3/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable DSC for DSI, if specified in VBT. This still lacks DSC aware get config implementation, and therefore state checker will fail. Also mode valid is not there yet. v5: - add dsc get config call v4: - convert_rgb = true (Vandita) - ignore max cdclock check (Vandita) - rename pipe_config to crtc_state v3: - take compressed bpp into account v2: - Nuke conn_state->max_requested_bpc, it's not used on DSI Bspec: 49263 Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e0136299e03c582238523189f6951eeb08daed98.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: Fix state mismatch warns for horizontal timings with DSCVandita Kulkarni2019-12-111-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When DSC is enabled consider the compression ratio that was used during horizontal timing calculations. This may still lead to warns due to rounding errors in the round-trip. v2 by Jani: - rebase on top of the more generic dsc state readout Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2481aaf67ea396aa4698cd2d8e23d19ec4f4ecf.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: account for DSC in horizontal timingsJani Nikula2019-12-111-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When DSC is enabled, we need to adjust the horizontal timings to account for the compressed (and therefore reduced) link speed. The compressed frequency ratio simplifies down to the ratio between compressed and non-compressed bpp. Bspec: 49263 Suggested-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fecebdc2719dd0c78eaf8f4d3225bb185956d7db.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: use compressed pixel format with DSCJani Nikula2019-12-111-16/+20
| | | | | | | | | | | | | | | | | | | | | | | | When compression is enabled, configure the DSI transcoder to use compressed format. Suggested-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0e58022ce5425560b3b31062c41de385a736c8b1.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: take compression into account in afe_clk()Jani Nikula2019-12-111-16/+24
| | | | | | | | | | | | | | | | | | | | | | Pass crtc_state to afe_clk() to be able to take compression into account in the computation. Once we enable compression, that is. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a698780362b8d6955d115ef8bb6cf1f7aabbee00.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: use afe_clk() instead of intel_dsi_bitrate()Jani Nikula2019-12-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We'll be expanding afe_clk() to take DSC into account. Switch to using it where DSC matters. Which is really everywhere that intel_dsi_bitrate() is currently used in ICL DSI code. The functional difference is that we round the result closest instead of down. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b6c52b320daa8aaa0d79618ce714170f8f04ff67.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: abstract afe_clk calculationJani Nikula2019-12-111-5/+13
| | | | | | | | | | | | | | | | | | | | We'll make more use of it in the future. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0341fdc13260625150315b0b57a4227eb766c50f.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsi: set pipe_bpp on ICL configure configJani Nikula2019-12-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | The ICL DSI pipe_bpp currently comes from compute_baseline_pipe_bpp(). Fix it. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/191f5c4fa5f4af29d4bf7e30bb35f45ce05b33f0.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsc: add basic hardware state readout supportJani Nikula2019-12-114-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic hardware state readout for DSC, and check the most relevant details in the state checker. v2: - check for DSC power before reading its state - check if source supports DSC at all As a side effect, this should also get the power domains for the enabled DSC on takeover, and subsequently disable DSC if it's not needed. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3fb018cf9bd9a4c275aab389b6ec0f2a4e938bb9.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsc: make DSC source support helper genericJani Nikula2019-12-113-22/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Move intel_dp_source_supports_dsc() from intel_dp.c as intel_dsc_source_support() in intel_vdsc.c. The DSC source support is more about DSC than about DP, and will be needed for DP independent code. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6c9f646090913290fb00efd46a4332421bf95930.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsc: add support for computing and writing PPS for DSI encodersJani Nikula2019-12-111-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Add DSI specific computation and transmission to display of PPS. With hopes that this approach will work for both DP and DSI encoders. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/461db10b1f4d76625625a9f2b1e3d932fff42799.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsc: move slice height calculation to encoderJani Nikula2019-12-112-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | Turns out this isn't compatible with DSI, where we use the value from VBT. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3dd689688a51daff26088eaf6feac27f8b9f5ebc.1575974743.git.jani.nikula@intel.com
| * drm/i915/dsc: move DP specific compute params to intel_dp.cJani Nikula2019-12-112-48/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out future DSI specific parameters aren't workable with the approach of having the encoder specific functions in intel_vdsc.c. Make intel_dsc_compute_params() a helper that does the encoder independent parts, and have encoder code call it. Move intel_dsc_dp_compute_params() to intel_dp.c as intel_dp_dsc_compute_params(). No functional changes. v2: Rename pipe_config to crtc_state while at it. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/620688ec302f7f49cc539c6c1653bfaf6092fce0.1575974743.git.jani.nikula@intel.com
| * drm/i915/bios: add support for querying DSC details for encoderJani Nikula2019-12-112-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add function for retrieving the DSC data for an encoder. Initially, this is DSI specific, as DP does not use VBT settings for DSC at all. It's also not very pretty. In the future we might have a pointer from encoder to the child device, which would make the child device list query here so much more sensible. v3: - use crtc_state instead of pipe_config - return true by default from intel_bios_get_dsc_params() - expand the comment about rc_buffer_block_size and rc_buffer_size v2: - make more robust, debug log errors better Bspec: 29885 Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b895c349d964d70e4cad26f12a629ea1898bfcc2.1575974743.git.jani.nikula@intel.com
| * drm/i915/bios: parse compression parameters blockJani Nikula2019-12-112-3/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check for child devices that specify compression, and store the device specific compression parameters in the display device data struct for later use. Warn if compression is requested but not available. Use fairly rigid checks for compression data for starters. These can be made more dynamic later. Log about DSC presence in DDI port parse, though this is not universal across platforms or port types (DSI). v2: amended debug logging Bspec: 29885 Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/357d685ba047faf2285138c2f7014a8dee9a12b7.1575974743.git.jani.nikula@intel.com
| * drm/i915/bios: pass devdata to parse_ddi_portJani Nikula2019-12-111-3/+4
| | | | | | | | | | | | | | | | | | | | | | Allow accessing the parent structure later on. Drop const for allowing future modification as well. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3318b09aaccbbe141e233ca510d581b421259a2a.1575974743.git.jani.nikula@intel.com
| * drm/i915/tgl: Program BW_BUDDY registers during display initMatt Roper2019-12-101-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gen12 can improve bandwidth efficiency by pairing up memory requests with similar addresses. We need to program the BW_BUDDY1 and BW_BUDDY2 registers according to the memory configuration during display initialization to take advantage of this capability. The magic numbers we program here feel like something that could definitely change on future platforms, so let's use a table-based programming scheme to make this easy to extend in the future. v2: - Add separate table for Wa_1409767108. (Stan) - Reorder structure reduce size by a word. Page mask can still be up to 28 bits (even though current values are small) so we should keep it as a u32, but just using a u8 for DRAM type instead of the actual enum type saves space. (Lucas, Ville) - Rename function to tgl_bw_buddy_init() to be more precise about what it does. (Lucas) Bspec: 49189 Bspec: 49218 Bspec: 52890 Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205224848.76712-1-matthew.d.roper@intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
| * drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()Ville Syrjälä2019-12-095-28/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intel_hdcp_transcoder_config() is clobbering some globally visible state in .compute_config(). That is a big no no as .compute_config() is supposed to have no visible side effects when either the commit fails or it's just a TEST_ONLY commit. Inline this stuff into intel_hdcp_enable() so that the state only gets modified when we actually commit the state to the hardware. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Fixes: 39e2df090c3c ("drm/i915/hdcp: update current transcoder into intel_hdcp") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
| * drm/i915/fbc: Reallocate cfb if we need more of itVille Syrjälä2019-12-091-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code assumes we can omit the cfb allocation once fbc has been enabled once. That's nonsense. Let's try to reallocate it if we need to. The code is still a mess, but maybe this is enough to get fbc going in some cases where it initially underallocates the cfb and there's no full modeset to fix it up. Cc: Daniel Drake <drake@endlessm.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jian-Hong Pan <jian-hong@endlessm.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-15-ville.syrjala@linux.intel.com Tested-by: Daniel Drake <drake@endlessm.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Enable fbc by default on glk+ once againVille Syrjälä2019-12-091-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have the glk+ w/a for back to back fbc disable + plane update in place we can once more enable fbc on glk+ by default. Cc: Daniel Drake <drake@endlessm.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jian-Hong Pan <jian-hong@endlessm.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-14-ville.syrjala@linux.intel.com Tested-by: Daniel Drake <drake@endlessm.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Wait for vblank after FBC disable on glk+Ville Syrjälä2019-12-093-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On glk+ the hardware gets confused if we disable FBC while it's recompressing and we perform a plane update during the same frame. The result is that top of the screen gets corrupted. We can avoid that by giving the hardware enough time to finish the FBC disable before we touch the plane registers. Ie. we need an extra vblank wait after FBC disable. v2: Don't do the vblank wait if we never activated FBC in hw Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191128150338.12490-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Start using flip nukeVille Syrjälä2019-12-091-11/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware automagically nukes the cfb on flip. We can use that whenever the plane/crtc configuration doesn't change too much. Let's hook that up. We'll need this for glk+ since we need to introduce an extra vblank wait after FBC disable. As we're currently disabling FBC around all plane updates we'd slow them down by an extra frame. Not a great user experience when your fps is always capped at vrefres/2. With flip nuke we don't need the extra vblank wait. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-12-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Nuke fbc.enabledVille Syrjälä2019-12-091-14/+9
| | | | | | | | | | | | | | | | fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-11-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/Ville Syrjälä2019-12-091-2/+2
| | | | | | | | | | | | | | | | | | Replace the 'gen9 && !glk' with the slightly more obvious 'gen9_bc || bxt'. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-10-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Make fence_id optional for i965gmVille Syrjälä2019-12-091-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i965gm no longer needs the fence for scanout so we should be do what we do for ctg+ and only configure a fence for FBC when we have one. In theory this should do nothing atm on account of intel_fbc_can_activate() requiring the fence, but since we do this for g4x+ let's do it for i965gm as well. We may want to relax the requirements at some point and allow FBC without a fence. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-9-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Store fence_id directly in fbc cache/paramsVille Syrjälä2019-12-091-15/+18
| | | | | | | | | | | | | | | | | | | | Rather than playing around with vma+flags let's just grab the fence id from within and stash that directly in the fbc cache/params. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-8-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Track plane visibilityVille Syrjälä2019-12-091-11/+10
| | | | | | | | | | | | | | | | | | | | Currently the code (ab)uses cache->vma to indicate the plane visibility. I want to nuke that so let's add a dedicated boolean for this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-7-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Precompute gen9 cfb stride w/aVille Syrjälä2019-12-091-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Precompute the override cfb stride value so that we can check it when determining if flip nuke can be used or not. The hardware has 13 bits for this, so we can shrink the storage to u16 while at it. v2: Don't explode when crtc_state->enable_fbc lies to us Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-6-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNBVille Syrjälä2019-12-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't want to use the FBC hardware render tracking so let's not enable it. To use the hw tracking properly we'd anyway need to integrate this into the command submissing path as the register is context saved, and if rendering happens via the ppgtt we'd have to configure it with the ppgtt address instead of the ggtt address. Easier to use software tracking instead. Note that on pre-ilk we can't actually disable render tracking. However we can't rely on it because it requires that DSPSURF to match the render target address, and since we play tricks with DSPSURF that may not be the case. Hence we shall rely on software render tracking on all platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-5-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915: Relocate intel_crtc_active()Ville Syrjälä2019-12-092-20/+0
| | | | | | | | | | | | | | | | | | | | Move intel_crtc_active() next to its only remaining user (pre-g4x wm code). Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-4-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Nuke bogus single pipe fbc1 restrictionVille Syrjälä2019-12-093-55/+0
| | | | | | | | | | | | | | | | | | | | | | Not sure where the single pipe only restriction came for fbc1. Nothing I can see that would prevent this. v2: Nuke no_fbc_on_multiple_pipes() too Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-3-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915/fbc: Disable fbc by default on all glk+Ville Syrjälä2019-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're missing a workaround in the fbc code for all glk+ platforms which can cause corruption around the top of the screen. So enabling fbc by default is a bad idea. I'm not keen to backport the w/a so let's start by disabling fbc by default on all glk+. We'll lift the restriction once the w/a is in place. Cc: stable@vger.kernel.org Cc: Daniel Drake <drake@endlessm.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jian-Hong Pan <jian-hong@endlessm.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * drm/i915: Avoid calling i915_gem_object_unbind holding object lockChris Wilson2019-12-072-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the extreme case, we may wish to wait on an rcu-barrier to reap stale vm to purge the last of the object bindings. However, we are not allowed to use rcu_barrier() beneath the dma_resv (i.e. object) lock and do not take lightly the prospect of unlocking a mutex deep in the bowels of the routine. i915_gem_object_unbind() itself does not need the object lock, and it turns out the callers do not need to the unbind as part of a locked sequence around set-cache-level, so rearrange the code to avoid taking the object lock in the callers. <4> [186.816311] ====================================================== <4> [186.816313] WARNING: possible circular locking dependency detected <4> [186.816316] 5.4.0-rc8-CI-CI_DRM_7486+ #1 Tainted: G U <4> [186.816318] ------------------------------------------------------ <4> [186.816320] perf_pmu/1321 is trying to acquire lock: <4> [186.816322] ffff88849487c4d8 (&mm->mmap_sem#2){++++}, at: __might_fault+0x39/0x90 <4> [186.816331] but task is already holding lock: <4> [186.816333] ffffe8ffffa05008 (&cpuctx_mutex){+.+.}, at: perf_event_ctx_lock_nested+0xa9/0x1b0 <4> [186.816339] which lock already depends on the new lock. <4> [186.816341] the existing dependency chain (in reverse order) is: <4> [186.816343] -> #6 (&cpuctx_mutex){+.+.}: <4> [186.816349] __mutex_lock+0x9a/0x9d0 <4> [186.816352] perf_event_init_cpu+0xa4/0x140 <4> [186.816357] perf_event_init+0x19d/0x1cd <4> [186.816362] start_kernel+0x372/0x4f4 <4> [186.816365] secondary_startup_64+0xa4/0xb0 <4> [186.816381] -> #5 (pmus_lock){+.+.}: <4> [186.816385] __mutex_lock+0x9a/0x9d0 <4> [186.816387] perf_event_init_cpu+0x6b/0x140 <4> [186.816404] cpuhp_invoke_callback+0x9b/0x9d0 <4> [186.816406] _cpu_up+0xa2/0x140 <4> [186.816409] do_cpu_up+0x61/0xa0 <4> [186.816411] smp_init+0x57/0x96 <4> [186.816413] kernel_init_freeable+0xac/0x1c7 <4> [186.816416] kernel_init+0x5/0x100 <4> [186.816419] ret_from_fork+0x24/0x50 <4> [186.816421] -> #4 (cpu_hotplug_lock.rw_sem){++++}: <4> [186.816424] cpus_read_lock+0x34/0xd0 <4> [186.816427] rcu_barrier+0xaa/0x190 <4> [186.816429] kernel_init+0x21/0x100 <4> [186.816431] ret_from_fork+0x24/0x50 <4> [186.816433] -> #3 (rcu_state.barrier_mutex){+.+.}: <4> [186.816436] __mutex_lock+0x9a/0x9d0 <4> [186.816438] rcu_barrier+0x23/0x190 <4> [186.816502] i915_gem_object_unbind+0x3a6/0x400 [i915] <4> [186.816537] i915_gem_object_set_cache_level+0x32/0x90 [i915] <4> [186.816571] i915_gem_object_pin_to_display_plane+0x5d/0x160 [i915] <4> [186.816612] intel_pin_and_fence_fb_obj+0x9e/0x200 [i915] <4> [186.816679] intel_plane_pin_fb+0x3f/0xd0 [i915] <4> [186.816717] intel_prepare_plane_fb+0x130/0x520 [i915] <4> [186.816722] drm_atomic_helper_prepare_planes+0x85/0x110 <4> [186.816761] intel_atomic_commit+0xc6/0x350 [i915] <4> [186.816764] drm_atomic_helper_update_plane+0xed/0x110 <4> [186.816768] setplane_internal+0x97/0x190 <4> [186.816770] drm_mode_setplane+0xcd/0x190 <4> [186.816773] drm_ioctl_kernel+0xa7/0xf0 <4> [186.816775] drm_ioctl+0x2e1/0x390 <4> [186.816778] do_vfs_ioctl+0xa0/0x6f0 <4> [186.816780] ksys_ioctl+0x35/0x60 <4> [186.816782] __x64_sys_ioctl+0x11/0x20 <4> [186.816785] do_syscall_64+0x4f/0x210 <4> [186.816787] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [186.816789] -> #2 (reservation_ww_class_mutex){+.+.}: <4> [186.816793] __ww_mutex_lock.constprop.15+0xc3/0x1090 <4> [186.816795] ww_mutex_lock+0x39/0x70 <4> [186.816798] dma_resv_lockdep+0x10e/0x1f7 <4> [186.816800] do_one_initcall+0x58/0x2ff <4> [186.816802] kernel_init_freeable+0x137/0x1c7 <4> [186.816804] kernel_init+0x5/0x100 <4> [186.816806] ret_from_fork+0x24/0x50 <4> [186.816808] -> #1 (reservation_ww_class_acquire){+.+.}: <4> [186.816811] dma_resv_lockdep+0xec/0x1f7 <4> [186.816813] do_one_initcall+0x58/0x2ff <4> [186.816815] kernel_init_freeable+0x137/0x1c7 <4> [186.816817] kernel_init+0x5/0x100 <4> [186.816819] ret_from_fork+0x24/0x50 <4> [186.816820] -> #0 (&mm->mmap_sem#2){++++}: <4> [186.816824] __lock_acquire+0x1328/0x15d0 <4> [186.816826] lock_acquire+0xa7/0x1c0 <4> [186.816828] __might_fault+0x63/0x90 <4> [186.816831] _copy_to_user+0x1e/0x80 <4> [186.816834] perf_read+0x200/0x2b0 <4> [186.816836] vfs_read+0x96/0x160 <4> [186.816838] ksys_read+0x9f/0xe0 <4> [186.816839] do_syscall_64+0x4f/0x210 <4> [186.816841] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [186.816843] other info that might help us debug this: <4> [186.816846] Chain exists of: &mm->mmap_sem#2 --> pmus_lock --> &cpuctx_mutex <4> [186.816849] Possible unsafe locking scenario: <4> [186.816851] CPU0 CPU1 <4> [186.816853] ---- ---- <4> [186.816854] lock(&cpuctx_mutex); <4> [186.816856] lock(pmus_lock); <4> [186.816858] lock(&cpuctx_mutex); <4> [186.816860] lock(&mm->mmap_sem#2); <4> [186.816861] *** DEADLOCK *** Closes: https://gitlab.freedesktop.org/drm/intel/issues/728 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-5-chris@chris-wilson.co.uk
| * drm/i915/display: Refactor intel_commit_modeset_disables()José Roberto de Souza2019-12-061-56/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order") reverted the order that pipes gets disabled because of TGL master/slave relationship between transcoders in MST mode. But as stated in a comment in skl_commit_modeset_enables() the enabling order is not always crescent, possibly causing previously selected slave transcoder being enabled before master so another approach will be needed to select a transcoder to master in MST mode. It will be similar to the approach taken in port sync. But instead of implement something like intel_trans_port_sync_modeset_disables() to MST lets simply it and iterate over all pipes 2 times, the first one disabling any slave and then disabling everything else. The MST bits will be added in another patch. v2: Not using crtc->active as it is deprecated v3: Removing is_trans_port_sync_mode() check, just check for is_trans_port_sync_master() is enough v4: Adding and using is_trans_port_sync_slave(), otherwise non-port sync pipes will be disabled in the first loop, what is not wrong but is not what patch description promises Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205210350.96795-3-jose.souza@intel.com
| * drm/i915/display/tgl: Fix the order of the step to turn transcoder clock offJosé Roberto de Souza2019-12-062-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For TGL the step to turn off the transcoder clock was moved to after the complete shutdown of DDI. Only the MST slave transcoders should disable the clock before that. v2: - Adding last_mst_stream to intel_mst_post_disable_dp, make code more easy to read and is similar to first_mst_stream in intel_mst_pre_enable_dp()(Ville's idea) - Calling intel_ddi_disable_pipe_clock() for GEN12+ right intel_disable_ddi_buf() as stated in BSpec(Ville) BSpec: 49190 Cc: Lucas De Marchi <lucas.demarchi@intel.com> 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/20191205210350.96795-2-jose.souza@intel.com
| * drm/i915/display: Do not check for the ddb allocations of turned off pipesJosé Roberto de Souza2019-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | It should not care about DDB allocations of pipes going through a fullmodeset, as at this point those pipes are disabled. The comment in the code also points to that but that was not what was being executed. 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/20191205210350.96795-1-jose.souza@intel.com
| * drm/i915: Make intel_crtc_arm_fifo_underrun() functional on gen2Ville Syrjälä2019-12-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Assuming intel_crtc_arm_fifo_underrun() only gets called when there's no pending plane updates we can utilize it on gen2 by checking the active_planes bitmask so that we only re-enable underrun reporting if some planes are active. i915_fifo_underrun_reset_write() seems to have the necessary hw_done/flip_done waits in place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-8-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915: Nuke intel_pre_disable_primary_noatomic()Ville Syrjälä2019-12-041-35/+22
| | | | | | | | | | | | | | | | | | | | | | | | Let's just inline intel_pre_disable_primary_noatomic() into intel_plane_disable_noatomic(). The CxSR disable we can do regardless of which plane we're disabling, and while at it we can make the gen2 underrun w/a accurate by consulting the active_planes bitmask. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-7-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915: Clean up the gen2 "no planes -> underrun" workaroundVille Syrjälä2019-12-041-85/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have the active_planes bitmask now so use it to properly determine when some planes are visible for the gen2 underrun workaround. This let's us almost eliminate intel_post_enable_primary(). The manual underrun checks we can simply move into intel_atomic_commit_tail() since they loop over all the pipes already. No point in repeating the checks multiple times when there are multiple pipes in the commit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915: Clean up intel_{pre,post}_plane_update()Ville Syrjälä2019-12-043-59/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | Change the calling convention to just pass the state+crtc and switch to intel_ types throughout. We'll also do a quick s/if (old_primary_state)/if (new_primary_state)/ so that we'll be able to eliminate old_primary_state later. This is fine since we always have either both old and new state or neither. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-5-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915: s/pipe_config/new_crtc_state/ intel_{pre,post}_plane_update()Ville Syrjälä2019-12-041-20/+20
| | | | | | | | | | | | | | | | Replace the old world 'pipe_config' variable name with the new thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915: Pass dev_priv to ilk_disable_lp_wm()Ville Syrjälä2019-12-041-1/+1
| | | | | | | | | | | | | | | | Get rid of another 'dev' usage by passing dev_priv instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915: Clean up arguments to nv12/scaler w/a funcsVille Syrjälä2019-12-041-12/+14
| | | | | | | | | | | | | | | | | | Don't pass the redundant dev_priv to needs_nv12_wa() and needs_scalerclk_wa(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/display/mst: Move DPMS_OFF call to post_disableJosé Roberto de Souza2019-12-032-8/+7
| | | | | | | | | | | | | | | | | | Moving just to simplify handling as there is no change in behavior. Cc: Lucas De Marchi <lucas.demarchi@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/20191202222513.337777-3-jose.souza@intel.com
| * drm/i915/dp: Power down sink before disable pipe/transcoder clockJosé Roberto de Souza2019-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | Disabling pipe/transcoder clock before power down sink could cause sink lost signal, causing it to trigger a hotplug to notify source that link signal was lost. Cc: Lucas De Marchi <lucas.demarchi@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/20191202222513.337777-2-jose.souza@intel.com
| * drm/i915/display: Check the old state to find port sync slaveJosé Roberto de Souza2019-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the CRTC is going from enabled to disabled and it is a port sync slave, it needs to check to the old state to be disabled before the port sync master. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> 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/20191202222513.337777-1-jose.souza@intel.com
| * drm/i915/bios: assume vbt is 4-byte aligned into opromLucas De Marchi2019-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unaligned ioread32() will make us read byte by byte looking for the vbt. We could just as well have done a ioread8() + a shift and avoid the extra confusion on how we are looking for "$VBT". However when using ACPI it's guaranteed the VBT is 4-byte aligned per spec, so we can probably assume it here as well. v2: do not try to simplify the loop by eliminating the auxiliary counter (Jani and Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-4-lucas.demarchi@intel.com
| * drm/i915/bios: fold pci rom map/unmap into copy functionLucas De Marchi2019-12-021-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't need to keep the pci rom mapped during the entire intel_bios_init() anymore. Move it to the previous copy_vbt() function and rename it to oprom_get_vbt() since now it's responsible to to all operations related to get the vbt from the oprom. v2: fix double __iomem attribute detected by sparse v3: fix missing unmap on success (Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-3-lucas.demarchi@intel.com
| * drm/i915/bios: do not discard address spaceLucas De Marchi2019-12-021-12/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we map the VBT through pci_map_rom() we may not be allowed to simply discard the address space and go on reading the memory. That doesn't work on my test system, but by dumping the rom via sysfs I can can get the correct vbt. So change our find_vbt() to do the same as done by pci_read_rom(), i.e. use memcpy_fromio(). v2: the just the minimal changes by not bothering with the unaligned io reads: this can be done on top (from Ville and Jani) v3: drop const in function return since now we are copying the vbt, rather than just finding it Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-2-lucas.demarchi@intel.com
OpenPOWER on IntegriCloud