- 28 Feb, 2022 9 commits
-
-
Imre Deak authored
Move intel_display_power_well_is_enabled() to intel_power_well.c, as a step towards making the low-level power well internals (i915_power_well_ops/desc structs) hidden. Eventually the call to this function and in general accessing power wells directly from elsewhere in the driver should be replaced by the use of power domains. No functional change. Suggested-by:
Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-9-imre.deak@intel.com
-
Imre Deak authored
Add functions to get a power well's actual- and cached-enabled state, name, domain mask and refcount, as a step towards making the low-level power well internals (i915_power_well_ops/desc structs) hidden. No functional change. Suggested-by:
-
Imre Deak authored
Add a function to call a power well's sync_hw() hook, instead of open-coding the same, as a step towards making the low-level power well internals (i915_power_well_ops/desc structs) hidden. The cached-enable state should be always up-to-date, so update it whenever sync_hw() is called. No functional change. Suggested-by:
-
Imre Deak authored
Move the power well get/put/enable/disable hooks to the new intel_display_power_well.c file. The motivation is to reduce the clutter in intel_display_power.c, keeping the functionality related to power domains in that file and moving the low-level power well functionality to intel_display_power_well.c. No functional change. Suggested-by:
-
Imre Deak authored
Move the i915_power_well_regs struct into i915_power_well_ops. Most of the power wells use the same ops/regs combination, so this saves some space and also simplifies the platform power domain->power well definitions. Signed-off-by:
-
Imre Deak authored
Commit d5ce34da ("drm/i915: Add state verification for the TypeC port mode") added a verification to the TypeC AUX power well enable()/disable() hooks to check if the TypeC port related to this power well is properly locked. If the disabling happens asynchronously the verification is skipped, since in this case the port is unlocked. The detection of asnychronous disabling doesn't work as intended though, since the power well's reference count is always 0 when its disable() hook is called (and since there won't be any domain reference held for this power well either, the verification is always skipped); remove the verification from the disable() hook for now. In the power well's enable() hook the power well's reference will be always >0 and there won't be any asynchronous disabling pending for it, so we can drop the async refcount check from there. No functional change. Signed-off-by:
-
Imre Deak authored
Instead of open-coding the call of the power wells' enable()/disable() hooks use the corresponding helper functions. This will also ensure that the power well's cached-enable state is always up-to-date. Luckily the lack of this updating hasn't been a problem, since the state either didn't change (in intel_display_power_set_target_dc_state()), or got updated subsequently (for vlv_cmnlane_wa(), in the following intel_power_domains_sync_hw()). Signed-off-by:
-
Imre Deak authored
The POWER_DOMAIN_TRANSCODER() macro depends on the POWER_DOMAIN_TRANSCODER_A/B .. DSI_A/C enum values to be consecutive, move POWER_DOMAIN_TRANSCODER_VDSC_PW2 after these to ensure this. The wrong order didn't cause a problem, since the DSI_A/C domains are in always-on power wells on all relevant platforms. The same power well ends up being enabled/disabled when the VDSC_PW2 domain is selected incorrectly. While at it add a code comment about enum values that need to stay consecutive. Signed-off-by:
-
Jani Nikula authored
Use REG_FIELD_{PREP,GET} for completeness, and to avoid bitwise operations with different sizes. v2: Also use REG_FIELD_GET in skl_wm_level_from_reg_val() (Ville) Cc: 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/20220223103517.634229-1-jani.nikula@intel.com
-
- 25 Feb, 2022 12 commits
-
-
Ville Syrjälä authored
When calculating pipe_mode and when doing readout we need to order our steps correctly. 1. We start with adjusted_mode crtc timings being populated with the transcoder timings (either via readout or compute_config(). These will be per-segment for MSO. 2. For all other uses we want the full crtc timings so we ask intel_splitter_adjust_timings() to expand the per-segment numbers to their full glory 3. If bigjoiner is used we the divide the full numbers down to per-pipe numbers using intel_bigjoiner_adjust_timings() During readout we also have to reconstruct the adjusted_mode normal timings (ie. not the crtc_ stuff). These are supposed to reflect the full timings of the display. So we grab these between steps 2 and 3. The "user" mode readout (mainly done for fastboot purposes) should be whatever mode the user would have used had they asked us to do a modeset. We want the full timings for this as the per-segment timings are not suppoesed to be user visible. Also the user mode normal timings hdisplay/vdisplay need to match PIPESRC (that is where we get our PIPESRC size we doing a modeset with a user supplied mode). And we end up with - adjusted_mode normal timigns == full timings - adjusted_mode crtc timings == transcoder timings (per-segment timings for MSO, full timings otherwise) - pipe_mode normal/crtc timings == pipe timings (full timings divided by the number of bigjoiner pipes, if any) - user mode normal timings == full timings with hdisplay/vdisplay replaced with PIPESRC size - user mode crtc timings == full timings Yes, that is a lot of timings. One day we'll try to remove some of the ones we don't actually need to keep around... Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Pull intel_crtc_compute_pipe_mode() out from intel_crtc_compute_config(). Since it's semi related we'll suck in the max dotclock/double wide checks in as well. And we'll pimp the debugs while at it. Reviewed-by:
-
Ville Syrjälä authored
intel_crtc_compute_config() doesn't really tell a unified story. Let's chunk it up into pieces. We'll start with intel_crtc_compute_pipe_src(). Reviewed-by:
-
Ville Syrjälä authored
Deduplicate the code to convert the full timings to per-pipe timings for bigjoiner usage. Reviewed-by:
-
Ville Syrjälä authored
Let's not replicate the same piece of code to expand the MSO segment timings to full width in many places. Pull it into a helper Reviewed-by:
-
Ville Syrjälä authored
Do the s/dev_priv/i915/ and s/pipe_config/crtc_state/ renames to intel_crtc_compute_config(). I want to start splitting this up a bit and doing the renames now avoids spreading these old nameing conventions elsewhere. No functional changes. Reviewed-by:
-
Ville Syrjälä authored
We just copied over the whole master crtc state, including cpu_transcoder+has_audio. No need to copy those again. Also get rid of the unhelpful comment. Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Adjust the cursor dst coordinates appripriately when it's on the bigjoiner slave pipe. intel_atomic_plane_check_clipping() already did this but with the cursor we discard those results (apart from uapi.visible and error checks) since the hardware will be doing the clipping for us. v2: Rebase due to bigjoiner bitmask usage Reviewed-by:
-
Ville Syrjälä authored
bigjoiner_pipes==0 leads bigjoiner_master_pipe() to do BIT(ffs(0)-1) which is undefined behaviour. The code should actually still work fine since the only place we provoke that is intel_crtc_bigjoiner_slave_pipes() and it'll bitwise AND the result with 0, so doesn't really matter what we get out of bigjoiner_master_pipe(). But best not provoke undefined behaviour anyway. Reported-by:
kernel test robot <oliver.sang@intel.com> Fixes: a6e7a006 ("drm/i915: Change bigjoiner state tracking to use the pipe bitmask") Signed-off-by:
-
Ville Syrjälä authored
This JSP2 PCH actually seems to be some special Apple specific ICP variant rather than a JSP. Make it so. Or at least all the references to it seem to be some Apple ICL machines. Didn't manage to find these PCI IDs in any public chipset docs unfortunately. The only thing we're losing here with this JSP->ICP change is Wa_14011294188, but based on the HSD that isn't actually needed on any ICP based design (including JSP), only TGP based stuff (including MCC) really need it. The documented w/a just never made that distinction because Windows didn't want to differentiate between JSP and MCC (not sure how they handle hpd/ddc/etc. then though...). Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4226 Fixes: 943682e3 ("drm/i915: Introduce Jasper Lake PCH") Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Tested-by:
Tomas Bzatek <bugs@bzatek.net>
-
Lucas De Marchi authored
Checking by >= DISPLAY_VER(12) made sense when the support for Tiger Lake was added. However now it only leads to wrong behavior when adding more platforms since it's expected they either don't have DMC to load or they have their own blob. Logs from DG2 loading on a CFL host, without having a DMC firmware defined: <6>[ 0.000000] DMI: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021 ... <6>[ 2.706607] pci 0000:03:00.0: [8086:56a0] type 00 class 0x030000 ... <7>[ 6.340397] i915 0000:03:00.0: [drm:intel_dmc_ucode_init [i915]] Loading i915/tgl_dmc_ver2_12.bin <7>[ 6.341841] i915 0000:03:00.0: [drm:intel_fbc_init [i915]] Sanitized enable_fbc value: 1 <3>[ 6.342432] genirq: Flags mismatch irq 0. 00000080 (i915) vs. 00015a00 (timer) <6>[ 6.346283] i915 0000:03:00.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12) <3>[ 6.385756] i915 0000:03:00.0: Device initialization failed (-16) <5>[ 6.385778] i915 0000:03:00.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details. <4>[ 6.385782] i915: probe of 0000:03:00.0 failed with error -16 TGL is the only platform left with DISPLAY_VER() == 12 that is not handled already in the if/else ladder, so handle it specifically. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223210933.3049143-1-lucas.demarchi@intel.com
-
Matt Roper authored
If one of our PHYs fails to complete calibration, we should skip the general initialization of the corresponding output. Most likely this is going to happen on outputs that don't actually exist on the board; in theory we should have already decided to skip this output based on the VBT, but we can't always rely on the VBT being accurate. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 24 Feb, 2022 7 commits
-
-
Ville Syrjälä authored
Drop the locks around sprite plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Drop the locks around most primary plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The one exception we have to make is DSPADDR/DSPSURF which is (ab)used to also trigger FBC nukes on pre-snb (since the hardware doesn't seem to have any dedicated mechanism to trigger nukes). So we need to keep the lock around it to protect against the rmw performed by the fbc code. Signed-off-by:
-
Ville Syrjälä authored
Drop the locks around cursor plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The locking did have a secondary effect of disabling interrupts around the cursor registers writes though. If we drop that then we open outselves up for sceduling delays and whatnot while on the middle of the register writes. That increases the chance of not all the register writes land during the same frame. For normal atomic commits this is not a concern as the vblank evade mechanism anyway disables interrupts around the update, but the legacy cursor codepath does not. Technically we should do a vblank evade there as well, but so far no one has bothered to hook that up. So in the meantime let's put an explicit local irq disable/enable around the legacy cursor update to keep the race window minimal. v2: local_irq_{disable,enable}() for legacy cursor ioctl Signed-off-by: -
Ville Syrjälä authored
Drop the locks around most universal plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. Signed-off-by:
-
Ville Syrjälä authored
On icl+ all plane registers are armed by PLANE_SURF, so we can move almost everything over into the update_noarm() hook. The PLANE_CTL write has to stay in the icl_update_arm() hook though as it still exhibits the somewhat annoying self-arming behaviour when the plane transitioning from disabled to enabled. We could either do a full split for skl+ vs. icl+, or we could try some other kind of split where we'd eg. keep most things in the skl+ functions and call them from the icl+ functions. I think a full split is probably the cleaner approach since we've anyway accumulated quite a bit of icl+ specific things, so that is what I opted to do. Some i915_update_info stats for tgl: before: after: Updates: 5043 Updates: 5043 | | 1us | 1us | |** |*** 4us |****** 4us |******** |********** |*********** 16us |*********** 16us |********** |**** |* 66us | 66us | | | 262us | 262us | | | 1ms | 1ms | | | 4ms | 4ms | | | 17ms | 17ms | | | Min update: 3494ns Min update: 2983ns Max update: 49491ns Max update: 39986ns Average update: 18031ns Average update: 13423ns Overruns > 100us: 0 Overruns > 100us: 0 Signed-off-by: -
Stanislav Lisovskiy authored
Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Moved Tile4 associating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier checks(Imre Deak) - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12 (Imre Deak) v3: - Rebased patch on top of new changes related to plane_caps. - Added static assert to check that PLANE_CTL_TILING_YF matches PLANE_CTL_TILING_4(Nanley Chery) - Fixed naming and layout description for Tile 4 in drm uapi header(Nanley Chery) v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery) Reviewed-by:Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com
-
Stanislav Lisovskiy authored
This tiling layout uses 4KB tiles in a row-major layout. It has the same shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It only differs from Tile Y at the 256B granularity in between. At this granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape of 64B x 8 rows. Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Signed-off-by:
-
- 23 Feb, 2022 9 commits
-
-
Rodrigo Vivi authored
Merge tag 'drm-intel-gt-next-2022-02-17' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next UAPI Changes: - Weak parallel submission support for execlists Minimal implementation of the parallel submission support for execlists backend that was previously only implemented for GuC. Support one sibling non-virtual engine. Core Changes: - Two backmerges of drm/drm-next for header file renames/changes and i915_regs reorganization Driver Changes: - Add new DG2 subplatform: DG2-G12 (Matt R) - Add new DG2 workarounds (Matt R, Ram, Bruce) - Handle pre-programmed WOPCM registers for DG2+ (Daniele) - Update guc shim control programming on XeHP SDV+ (Daniele) - Add RPL-S C0/D0 stepping information (Anusha) - Improve GuC ADS initialization to work on ARM64 on dGFX (Lucas) - Fix KMD and GuC race on accessing PMU busyness (Umesh) - Use PM timestamp instead of RING TIMESTAMP for reference in PMU with GuC (Umesh) - Report error on invalid reset notification from GuC (John) - Avoid WARN splat by holding RPM wakelock during PXP unbind (Juston) - Fixes to parallel submission implementation (Matt B.) - Improve GuC loading status check/error reports (John) - Tweak TTM LRU priority hint selection (Matt A.) - Align the plane_vma to min_page_size of stolen mem (Ram) - Introduce vma resources and implement async unbinding (Thomas) - Use struct vma_resource instead of struct vma_snapshot (Thomas) - Return some TTM accel move errors instead of trying memcpy move (Thomas) - Fix a race between vma / object destruction and unbinding (Thomas) - Remove short-term pins from execbuf (Maarten) - Update to GuC version 69.0.3 (John, Michal Wa.) - Improvements to GT reset paths in GuC backend (Matt B.) - Use shrinker_release_pages instead of writeback in shmem object hooks (Matt A., Tvrtko) - Use trylock instead of blocking lock when freeing GEM objects (Maarten) - Allocate intel_engine_coredump_alloc with ALLOW_FAIL (Matt B.) - Fixes to object unmapping and purging (Matt A) - Check for wedged device in GuC backend (John) - Avoid lockdep splat by locking dpt_obj around set_cache_level (Maarten) - Allow dead vm to unbind vma's without lock (Maarten) - s/engine->i915/i915/ for DG2 engine workarounds (Matt R) - Use to_gt() helper for GGTT accesses (Michal Wi.) - Selftest improvements (Matt B., Thomas, Ram) - Coding style and compiler warning fixes (Matt B., Jasmine, Andi, Colin, Gustavo, Dan) From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Yg4i2aCZvvee5Eai@jlahtine-mobl.ger.corp.intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> [Fixed conflicts while applying, using the fixups/drm-intel-gt-next.patch from drm-rerere's 1f2b1742abdd ("2022y-02m-23d-16h-07m-57s UTC: drm-tip rerere cache update")]
-
Ville Syrjälä authored
Extract the data rate calculation loop out from intel_bw_atomic_check() to make it a bit less confusing. v2: Deal with 'bool changed' Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Declutter intel_bw_atomic_check() a bit by pulling the max QGV mask calculation out. Signed-off-by:
-
Ville Syrjälä authored
Currently we just leave the old gunk lying around in the crtc state when userspace asks us to fully disable the crtc. That doesn't match what the state would be had we never even enabled the crtc in the first place. So let's make this consistent and call intel_crtc_prepare_cleared_state() for disabled crtcs as well (excluding bigjoiner slaves of course which have had their state copied from the master). I actually already did this once in commit fff13e63 ("drm/i915: Clear most of crtc state when disabling the crtc") but then commit 19f65a3d ("drm/i915: Try to make bigjoiner work in atomic check") undid it all :( Signed-off-by:
-
Ville Syrjälä authored
For some reason we're flagging that we need to run through the full modeset calculations (any_ms==true -> do cdclk/etc. checks) if any crtc got initially flagged for a modeset and is not enabled via the uapi. No idea why this is here since later on (after all fastset handling) we do full run through the crtcs and flag any_ms if anything still needs a full modeset. So let's just throw out this early weirdo. Signed-off-by:
-
Ville Syrjälä authored
Include hw.enable and pipe_mode in the crtc debugfs state dump. These are fairly fundemental to the operation of the driver so not seeing them leaves us in the dark. Signed-off-by:
-
Ville Syrjälä authored
Let's just dump the "full" hw crtc state in debugs so that we can see if some stale junk was left behind when the crtc is supposed to be entirely off. Signed-off-by:
-
Ville Syrjälä authored
This reverts commit 9bc34b4d. Just oopses on most machines. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Tejas Upadhyay authored
Add the PCH ID for ADL-N. Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
- 22 Feb, 2022 1 commit
-
-
Manasi Navare authored
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings. When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit in the DPCD. Currently the driver parses that onevery HPD but fails to reset the corresponding VRR Capable Connector property. Hence the userspace still sees this as VRR Capable panel which is incorrect. Fix this by explicitly resetting the connector property. v2: Reset vrr capable if status == connector_disconnected v3: Use i915 and use bool vrr_capable (Jani Nikula) v4: Move vrr_capable to after update modes call (Jani N) Remove the redundant comment (Jan N) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 21 Feb, 2022 2 commits
-
-
Imre Deak authored
Add display workaround # 1309179469 , which fixes a PHY hang when switching from TBT mode to DP-alt/legacy mode. The workaround also requires an IFWI/PHY firmware change, before that this change has no effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared). HSDES: 18018237866 HSDES: 16014473319 Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218122611.767974-1-imre.deak@intel.com
-
Jani Nikula authored
Always use forward declarations instead of includes in headers if possible. Signed-off-by:
-
