- 22 Apr, 2021 1 commit
-
-
CQ Tang authored
Add "REGION_STOLEN" device info to dg1, create stolen memory region from upper portion of local device memory, starting from DSMBASE. v2: - s/drm_info/drm_dbg; userspace likely doesn't care about stolen. - mem->type is only setup after the region probe, so setting the name as stolen-local or stolen-system based on this value won't work. Split system vs local stolen setup to fix this. - kill all the region->devmem/is_devmem stuff. We already differentiate the different types of stolen so such things shouldn't be needed anymore. v3: - split stolen lmem vs smem ops(Tvrtko) - add shortcut for stolen region in i915(Tvrtko) - sanity check dsm base vs bar size(Xinyun) v4(Tvrtko): - more cleanup - add some TODOs Signed-off-by:CQ Tang <cq.tang@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Xinyun Liu <xinyun.liu@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421104658.304142-1-matthew.auld@intel.com
-
- 21 Apr, 2021 3 commits
-
-
Matt Roper authored
Boot firmware performs memory training and health assessment during startup. If the memory training fails, the firmware will consider the GPU unusable and will instruct the punit to keep the GT powered down. If this happens, our driver will be unable to communicate with the GT (all GT registers will read back as 0, forcewake requests will timeout, etc.) so we should abort driver initialization if this happens. We can confirm that LMEM was initialized successfully via sgunit register GU_CNTL. Bspec: 53111 Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Caz Yokoyama <Caz.Yokoyama@intel.com> Reviewed-by:
-
Matthew Auld authored
Add section for drm/i915 uAPI and pull in i915_drm.h. Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210419105741.27844-2-matthew.auld@intel.com
-
Hsin-Yi Wang authored
pm_resume and pm_suspend might be conflict with the ones defined in include/linux/suspend.h. Rename all pm_* to igt_pm_* in selftests since they are only used here. v2 by Jani: - Use igt_ prefix instead of i915_ to avoid colliding with existing i915_pm_* functions - Rename all pm_ prefixed functions in the file Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210420130853.10573-1-jani.nikula@intel.com
-
- 20 Apr, 2021 6 commits
-
-
Chris Wilson authored
RAPL provides an on-package power measurements which does not encompass discrete graphics, so let's avoid using the igfx masurements when testing dgfx. Later we will abstract the simple librapl interface over hwmon so that we can verify basic power consumption scenarios. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
If there is no mappable aperture, we cannot remap it for access, and the selftest is void. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Joonas Lahtinen authored
Merge tag 'topic/intel-gen-to-ver-2021-04-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-gt-next Gen to ver conversions across the driver The main change is Lucas' series [1], with Ville's GLK fixes [2] and a cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid conflicts. [1] https://patchwork.freedesktop.org/series/88825/ [2] https://patchwork.freedesktop.org/series/88938/ [3] 70bfb307 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/878s5ebny0.fsf@intel.com
-
Matthew Auld authored
Add a note about the two-step process. v2(Tvrtko): - Also document the other method of just passing in a buffer which is large enough, which avoids two ioctl calls. Can make sense for smaller query items. v3: prefer kernel-doc references for structs and members Suggested-by:Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210419105741.27844-4-matthew.auld@intel.com
-
Matthew Auld authored
Add some example usage for the extension chaining also, which is quite nifty. v2: (Daniel) - clarify that the name is just some integer, also document that the name space is not global v3: prefer kernel-doc references for structs Suggested-by: -
Matthew Auld authored
Fix the cases where it is almost already valid kernel doc, for the others just nerf the warnings for now. Signed-off-by:
-
- 14 Apr, 2021 18 commits
-
-
Lucas De Marchi authored
Make them independent so we can use DGFX_FEATURES more generically. For future platforms that do not use the GEN nomenclature we will define graphics, media and display separately, so we avoid setting graphics_ver with the GEN() macro. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Since we are now converting from a single gen version to graphics_ver, media_ver and display_ver, add the last 2 when printing the device info. Reviewed-by:
-
Lucas De Marchi authored
Now that it's not being used anymore, finish its removal. Like for gen_mask, we replace INTEL_GEN() and IS_GEN() macros to use the new field. Reviewed-by:
-
Lucas De Marchi authored
Replace gen with the new graphics_ver value and use GRAPHICS_VER() in those places. Reviewed-by:
-
Lucas De Marchi authored
Now that it's not used anywhere, remove it from struct intel_device_info. To allow a period in which code will be converted to the new macro, keep IS_GEN_RANGE() around, just redefining it to use the new fields. The size advantage from IS_GEN_RANGE() using a mask is not that big as it has pretty limited use througout the driver: text data bss dec hex filename 2758497 95965 6496 2860958 2ba79e drivers/gpu/drm/i915/i915.ko.old 2758586 95953 6496 2861035 2ba7eb drivers/gpu/drm/i915/i915.ko.new Reviewed-by:
-
Lucas De Marchi authored
Remove the remaining uses of INTEL_GEN_MASK() and the correspondent gen_mask in struct intel_device_info. This will allow the removal of gen_mask later since it's incompatible with the new per-IP versioning scheme. Reviewed-by:
-
Lucas De Marchi authored
Since its introduction 2 years ago, we never used the mask to span more than one gen. Replace gen_mask a single number and start using the new GRAPHICS_VER(). Reviewed-by:
-
Lucas De Marchi authored
Start using the new fields graphics_version for the previous gen checks. Here we rename the "gen" field and replace the comparisons using it to start using the new GRAPHICS_VER(). Other uses of INTEL_GEN() were left as is for automatic conversion later. Reviewed-by:
-
Lucas De Marchi authored
Like it was done in commit 01eb15c9 ("drm/i915: Add DISPLAY_VER() and related macros") add the correspondent macros for graphics and media. Going forward we will prefer checking the versions for the specific IPs (graphics, media and display) rather than grouping everything under a "gen" version. For consistency and to make the maintenance easier, it'd be preferred not to mix the *GEN* macros with the new ones. For older platforms we can simply consider that the previous "gen" number will extend to all 3 IPs. Then we can start replacing its use in the driver. Right now this replacement is not done and only the infrastructure is put in place. We also leave gen and gen_mask inside struct intel_device_info while it's still being used throughout the code. v2: Repurpose IS_{GRAPHICS,MEDIA}_VER() macros to work with a range Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Lucas De Marchi authored
While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Lucas De Marchi authored
The macro we use to check is called DISPLAY_VER(). While using this macro and the new ones being added in following changes I made the mistake multiple times when mixing both "ver" and "version". Although it's usually better to prefer the complete name, the shorhand DISPLAY_VER() / GRAPHICS_VER / MEDIA_VER are clear and cause less visual polution. Another issue is when copying the variable to other places. "display.version" would be copied to a "display_version" variable which is long and would make people abbreviate as "version", or "display_ver". In the first case it's not always clear what version refers to, and in the second case it just hints it should be the name in the first place. So, in the same way use used "gen" rather than "generation", use "ver" instead of "version". Signed-off-by:
-
Lucas De Marchi authored
Commit 989634fb ("drm/i915/audio: set HDA link parameters in driver") added INTEL_GEN() in the display code, where it should actually be using DISPLAY_VER(). Switch to the new macro. Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Now that glk display version is 10 we can drop a few more glk checks. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Just let bxt/glk fall back to intel_hpd_pin_default() instead of using skl_hpd_pin() or cnl_hpd_pin(). Doesn't really matter since both functions will end up returning the correct hpd pin anyway, but I find it a bit less confusing when bxt/glk are fully separated from the logic for the other platforms. Reviewed-by:
-
Ville Syrjälä authored
The glk display version change is causing us to again attempt LTTPR detection on glk. We must not do tha since glk doesn't have a long enough AUX timeout. Restore the correct logic to skip the detection. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by:
-
Ville Syrjälä authored
We lost a CCS related w/a on glk when the display version became 10 instead of 9. Restore the correct check. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by:
-
Ville Syrjälä authored
We lost the FBC 16bpp 512byte stride requirement on glk when we switched from display version 9 to 10. Restore the w/a to avoid enabling FBC with a bad stride and thus display garbage. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by:
-
Matt Roper authored
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com (cherry picked from commit 70bfb307) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by:
-
- 09 Apr, 2021 6 commits
-
-
Tvrtko Ursulin authored
RC6 support cannot be simply established by looking at the static device HAS_RC6() flag. There are cases which disable RC6 at driver load time so use the status of those check when deciding whether to enumerate the rc6 counter. Signed-off-by:
Eero T Tamminen <eero.t.tamminen@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Reference needs to be taken before arming the timer. Luckily, given the default timer period of 20s, the potential to hit the race is extremely unlikely. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210326105759.2387104-1-tvrtko.ursulin@linux.intel.com
-
Swathi Dhanavanthri authored
This is a permanent workaround for TGL,RKL,DG1 and ADLS. Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by:
-
José Roberto de Souza authored
This WA is needed in all gen12 platforms, moving it to gen12_ctx_workarounds_init() allow us to remove the duplicated implementation. Also allow us to remove the tgl_ctx_workarounds_init() that after the WA move above was empty. Signed-off-by:
-
Caz Yokoyama authored
Wa_22010271021 does not apply only to EHL, but to all gen11 and other gen12 platforms. Gen12 is already covered in another code path, but we need to stop checking for EHL when handling gen11. Bspec: 33450, 52887 v2: Remove "gen11" suffix as it also applies to gen12 platforms Cc: Clinton Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by:
-
Caz Yokoyama authored
Follow Bspec 31870 to set recommended tuning values for certain GT register. These values aren't workarounds per-se, but it's best to handle them in the same general area of the driver, especially since there may be real workarounds that update other bits of the same registers. At the moment the only value we need to worry about is the TDS_TIMER setting in FF_MODE2. This setting was previously described as "Wa_1604555607" on some platforms, but the spec tells us that we should continue to program this on all current gen12 platforms, even those that do not have that WA. Bspec: 31870 v2: Rephrase some comments to make them clearer (Matt) Cc: Clinton Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
- 08 Apr, 2021 3 commits
-
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
Features: - Add support for FBs requiring a power-of-two stride padding (Imre) Refactoring: - Disassociate display version from gen (Matt) - Refactor legacy DP and HDMI code to separate files (Ville) - Refactor FB plane code to a separate file (Imre) - Refactor VBT child device info parsing and usage (Jani) - Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani) Fixes: - DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre) - HDCP fixes (Anshuman) - DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit) - Set HDA link parameters in driver (Kai) - Fix enabled_planes bitmask (Ville) - Fix transposed arguments to skl_plane_wm_level() (Ville) - Stop adding planes to the commit needlessly (Ville) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87v996ml17.fsf@intel.com
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2021-04-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Prepare for local/device memory support on DG1 by starting to use it for kernel internal allocations: context, ring and engine scratch (Matt A, CQ, Abdiel, Imre) - Sandybridge fix to avoid hard hang on ring resume (Chris) - Limit imported dma-buf size to int32 (Matt A) - Double check heartbeat timeout before resetting (Chris) - Use new tasklet API for execution list (Emil) - Fix SPDX checkpats warnings (Chris) - Fixes for various checkpatch warnings (Chris) - Selftest improvements (Chris) - Move the defer_request waiter active assertion to correct spot (Chris) - Make local-memory probing a GT operation (Matt, Tvrtko) - Protect against request freeing during cancellation on wedging (Chris) - Retire unexpected starting state error dumping (Chris) - Distinction of memory regions in debugging (Zbigniew) - Always flush the submission queue on checking for idle (Chris) - Consolidate 2big error check to helper (Matt) - Decrease number of subplatform bits (Tvrtko) - Remove unused internal request priority levels (Chris) - Document the unused internal header bits in buddy allocator (Matt) - Cleanup the region class/instance encoding (Matt) Signed-off-by:
-
Dave Airlie authored
Merge tag 'mediatek-drm-next-5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 5.13 1. Fine tune the line time for EOTp. 2. Add support mt8192 dpi. 3. Make crtc config-updating atomic. 4. Don't support hdmi connector creation. From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210405082248.3578-1-chunkuang.hu@kernel.orgSigned-off-by:
-
- 07 Apr, 2021 1 commit
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - mst: Improve topology logging - edid: Rework and improvements for displayid Driver Changes: - anx7625: Regulators support - bridge: Support for the Chipone ICN6211, Lontium LT8912B - lt9611: Fix 4k panels handling Signed-off-by:
-
- 01 Apr, 2021 2 commits
-
-
Dafna Hirschfeld authored
commit f0119514 ("drm/mediatek: mtk_dpi: Create connector for bridges") broke the display support for elm device since mtk_dpi calls drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR while mtk_hdmi does not yet support this flag. Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment. Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() to report HPD. This provides the necessary API to support disabling connector creation. In addition, the field 'conn' is removed from the mtk_hdmi struct since mtk_hdmi don't create a connector. It is replaced with a pointer 'curr_conn' that points to the current connector which can be access through the global state. This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c: commit ec971aaa ("drm: bridge: dw-hdmi: Make connector creation optional") But with the difference that in mtk-hdmi only the option of not creating a connector is supported. Fixes: f0119514 ("drm/mediatek: mtk_dpi: Create connector for bridges") Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org>
-
Dafna Hirschfeld authored
The bridge operation '.enable' and the audio cb '.get_eld' access hdmi->conn. In the future we will want to support the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will not have direct access to the connector. The atomic version '.atomic_enable' allows accessing the current connector from the state. This patch switches the bridge to the atomic version to prepare access to the connector in later patches. Signed-off-by:
-
