An error occurred fetching the project authors.
- 04 Oct, 2021 1 commit
-
-
Sean Paul authored
This reverts commit 746826bc. This patchset breaks on intel platforms and was previously NACK'd by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fernando Ramos <greenfoo@u92.eu> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-5-sean@poorly.run
-
- 01 Oct, 2021 1 commit
-
-
Fernando Ramos authored
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by:
Fernando Ramos <greenfoo@u92.eu> Signed-off-by:
-
- 28 Jul, 2021 1 commit
-
-
Badal Nilawar authored
In discrete cards, the graphics driver shouldn't proceed with the probe or resume unless PCODE indicated everything is done, including memory training and gt bring up. For this reason, the driver probe and resume paths needs to be blocked until PCODE indicates it is done. Also, it needs to aborted if the notification never arrives. In general, the few miliseconds would be enough and the regular PCODE recommendation for the timeout was 10 seconds. However there are some rare cases where this initialization can take up to 1 minute. So, PCODE has increased the recommendation to 3 minutes so we don't fully block the device utilization when something just got delayed for whatever reason. To be on the safest side, let's accept this recommendation, since on the regular case it won't delay or block the driver initialization and resume flows Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 15 Jul, 2021 2 commits
-
-
Matt Roper authored
Switch ICL to use a revid->stepping table as we're trying to do on all platforms going forward. While we're at it, let's include some additional steppings that have popped up, even if we don't yet have any workarounds tied to those steppings (we probably need to audit our workaround list soon to see if any of the bounds have moved or if new workarounds have appeared). Note that the current bspec table is missing information about how to map PCI revision ID to GT/display steppings; it only provides an SoC stepping. The mapping to GT/display steppings (which aren't always the same as the SoC stepping) used to be in the bspec, but was apparently dropped during an update in Nov 2019; I've made my changes here based on an older bspec snapshot that still had the necessary information. We've requested that the missing information be restored. I'm only including the production revids in the table here since we're past the point at which we usually stop trying to support pre-production hardware. An appropriate check is added to intel_detect_preproduction_hw() to print an error and taint the kernel just in case someone still tries to load the driver on old pre-production hardware. v2: - Drop pre-production steppings and add error/taint at startup when loading on pre-production hardware. Bspec: 21141 # pre-Nov 2019 snapshot Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-8-matthew.d.roper@intel.com
-
Matt Roper authored
Although we're converting our workarounds to use a revid->stepping lookup table, the function that detects pre-production hardware should continue to compare against PCI revision ID values directly. These are listed in the bspec as integers, so it's easier to confirm their correctness if we just use an integer literal rather than a symbolic name anyway. Bspec: 13620, 19131, 13626, 18329 Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-3-matthew.d.roper@intel.com
-
- 06 Jul, 2021 1 commit
-
-
Thomas Zimmermann authored
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt functions directly. v2: * also remove an outdated comment * move IRQ fix into separate patch * update Fixes tag (Daniel) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Fixes: b318b824 ("drm/i915: Nuke drm_driver irq vfuncs") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-3-tzimmermann@suse.de (cherry picked from commit 91b96f00) Signed-off-by:
-
- 02 Jul, 2021 1 commit
-
-
Thomas Zimmermann authored
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt functions directly. v2: * also remove an outdated comment * move IRQ fix into separate patch * update Fixes tag (Daniel) Signed-off-by:
-
- 01 Jul, 2021 1 commit
-
-
Thomas Zimmermann authored
Print the name of the DRM driver when taking over fbdev devices. Makes the output to dmesg more consistent. Note that the driver name is only used for printing a string to the kernel log. No UAPI is affected by this change. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by: Chen-Yu Tsai <wens@csie.org> # sun4i Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson Link: https://patchwork.freedesktop.org/patch/msgid/20210629135833.22679-1-tzimmermann@suse.de
-
- 07 Jun, 2021 1 commit
-
-
Lucas De Marchi authored
This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@ - !IS_GEN(dev_priv, E) + GRAPHICS_VER(dev_priv) != E @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + GRAPHICS_VER(dev_priv) == E @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_GRAPHICS_VER(dev_priv, from, until) @def@ expression E; identifier id =~ "^gen$"; @@ - id = GRAPHICS_VER(E) + ver = GRAPHICS_VER(E) @@ identifier def.id; @@ - id + ver It also takes care of renaming the variable we assign to GRAPHICS_VER() so to use "ver" rather than "gen". Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
- 02 Jun, 2021 1 commit
-
-
Thomas Hellström authored
Temporarily remove the buddy allocator and related selftests and hook up the TTM range manager for i915 regions. Also modify the mock region selftests somewhat to account for a fragmenting manager. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
- 01 Jun, 2021 1 commit
-
-
Thomas Hellström authored
We are currently sharing the VM reservation locks across a number of gem objects with page-table memory. Since TTM will individiualize the reservation locks when freeing objects, including accessing the shared locks, make sure that the shared locks are not freed until that is done. For PPGTT we add an additional refcount, for GGTT we take additional measures to make sure objects sharing the GGTT reservation lock are freed at GGTT takedown Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 20 May, 2021 2 commits
-
-
Anusha Srivatsa authored
Finally, rename the header and source file from csr to dmc. v2: Add file rename in Documentation. - Place headers in orders. (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Anusha Srivatsa authored
No functional change. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 04 May, 2021 1 commit
-
-
Matthew Auld authored
Same old gem_create but with now with extensions support. This is needed to support various upcoming usecases. v2:(Chris) - Use separate ioctl number for gem_create_ext, instead of hijacking the existing gem_create ioctl, otherwise we run into the issue with being unable to detect if the kernel supports the new extension behaviour. - We now have gem_create_ext.flags, which should be zeroed. - I915_GEM_CREATE_EXT_SETPARAM value is now zero, since this is the index into our array of extensions. - Setup a "vanilla" object which we can directly apply our extensions to. v3:(Daniel & Jason) - drop I915_GEM_CREATE_EXT_SETPARAM. Instead just have each extension do one thing only, instead of generic setparam which can cover various use cases. - add some kernel-doc. Signed-off-by:CQ Tang <cq.tang@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: mesa-dev@lists.freedesktop.org Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210429103056.407067-5-matthew.auld@intel.com
-
- 29 Apr, 2021 1 commit
-
-
Thomas Zimmermann authored
Using struct drm_device.pdev is deprecated. Don't assign it. Users should upcast from struct drm_device.dev. v6: * also fix the assignment in selftests in this patch (Chris) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210429105101.25667-5-tzimmermann@suse.de
-
- 14 Apr, 2021 3 commits
-
-
Lucas De Marchi authored
Replace gen with the new graphics_ver value and use GRAPHICS_VER() in those places. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-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:
-
Thomas Zimmermann authored
Mass-convert all drivers from FB helpers to aperture interfaces. No functional changes besides checking for returned errno codes. Signed-off-by:
-
- 09 Apr, 2021 1 commit
-
-
José Roberto de Souza authored
Display features should not be initialized or de-initialized when there is no display. Skip modeset initialization, output setup, plane, crtc, encoder, connector registration, display cdclk and rawclk initialization, display core initialization, etc. Skip the functionality at as high level as possible, and remove any redundant checks. If the functionality is conditional to *other* display checks, do not add more. If the un-initialization has checks for initialization, do not add more. We explicitly do not care about any GMCH/VLV/CHV code paths, as they've always had and will have display. Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 01 Apr, 2021 1 commit
-
-
Imre Deak authored
We need to wait for the DMC FW loader work to complete during shutdown, even if it's unlikely to be still pending by that time, fix this. This also fixes the wakeref tracking WARN during shutdown about the leaked reference we hold due to a missing DMC firmware. While at it add a TODO comment about unifying the shutdown and PM power-off sequences and later these sequences with the driver remove and system/runtime suspend sequences. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://lore.kernel.org/lkml/20210303055517.GB2708@xsang-OptiPlex-9020Reported-and-tested-by:
kernel test robot <oliver.sang@intel.com> Reported-and-tested-by:
Edward Baker <edward.baker@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 29 Mar, 2021 1 commit
-
-
Jani Nikula authored
Add new symbolic names for revision ids, and convert KBL revids to use them via the new stepping check macros. This also fixes theoretical out of bounds access to kbl_revids array. v3: upgrade dbg to warn on unknown revid (José) v2: Rename stepping->step Reviewed-by:
-
- 24 Mar, 2021 2 commits
-
-
Matthew Auld authored
In some future patches we will need to also support a stolen region carved from device local memory, on platforms like DG1. To handle this we can simply describe each in terms of its own memory class. Signed-off-by:
-
Matthew Auld authored
Device local memory is very much a GT thing, therefore it should be the responsibility of the GT to setup the device local memory region. Suggested-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
- 18 Mar, 2021 1 commit
-
-
Jason Ekstrand authored
libdrm has supported the newer execbuffer2 ioctl and using it by default when it exists since libdrm commit b50964027bef which landed Mar 2, 2010. The i915 and i965 drivers in Mesa at the time both used libdrm and so did the Intel X11 back-end. The SNA back-end for X11 has always used execbuffer2. v2 (Jason Ekstrand): - Add a comment saying what Linux version it's being removed in. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Acked-by:
Keith Packard <keithp@keithp.com> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
- 13 Feb, 2021 4 commits
-
-
Lucas De Marchi authored
intel_init_audio_hooks() sets up hooks in the display struct and only makes sense when we have display. Move it inside intel_init_display_hooks() so it isn't called when we don't have display. Signed-off-by:
-
Lucas De Marchi authored
Now that all display-related functions are grouped in i915_driver_register(), move them to display/ so we reduce the amount of display calls from the rest of the driver. Signed-off-by:
-
Lucas De Marchi authored
intel_gt_driver_register() may be called earlier than intel_opregion_register() and acpi_video_register(), so move it up. intel_display_debugfs_register() may be called later, together with the other display-related initializations. There is a slight change in behavior that sysfs files will show up before the display-related debugfs files, but that shouldn't be a problem - userspace shouldn't be relying in debugfs. This allows us to group all the display-related calls under a single check for "HAS_DISPLAY()" that can be later moved to a better place. Signed-off-by:
-
Lucas De Marchi authored
If drm_dev_register() fails there is no reason to continue registering the driver and initializing. Signed-off-by:
-
- 08 Feb, 2021 1 commit
-
-
Chris Wilson authored
Push the hibernate pm routines next to the suspend pm routines in gem/i915_gem_pm.c. This has the side-effect of putting the wbinvd() abusers next to each other. Reported-by:
Guenter Roeck <linux@roeck-us.net> Fixes: 30d2bfd0 ("drm/i915/gem: Almagamate clflushes on freeze") Signed-off-by:
-
- 04 Feb, 2021 1 commit
-
-
Imre Deak authored
At least on some TGL platforms PUNIT wants to access some display HW registers, but it doesn't handle display power management (disabling DC states as required) and so this register access will lead to a hang. To prevent this disable runtime power management for poweroff and reboot. v2: - Add code comment clarifying the requirement of display power states. (Ville) Reported-and-tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by:
-
- 02 Feb, 2021 1 commit
-
-
Thomas Zimmermann authored
Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by:
-
- 29 Jan, 2021 2 commits
-
-
José Roberto de Souza authored
Up to now we were reading some DRAM information from MCHBAR register and from pcode what is already not good but some GEN12(TGL-H and ADL-S) platforms have MCHBAR DRAM information in different offsets. This was notified to HW team that decided that the best alternative is always apply the 16gb_dimm watermark adjustment for GEN12+ platforms and read the remaning DRAM information needed to other display programming from pcode. So here moving the DRAM pcode function to intel_dram.c, removing the duplicated fields from intel_qgv_info, setting and using information from dram_info. v2: - bring back num_points to intel_qgv_info as num_qgv_point can be overwritten in icl_get_qgv_points() - add gen12_get_dram_info() and simplify gen11_get_dram_info() Reviewed-by:
-
José Roberto de Souza authored
Valid, ranks and bandwidth_kbps are set into dram_info but are not used anywhere else so nuking it. Reviewed-by:
-
- 21 Jan, 2021 1 commit
-
-
Jani Nikula authored
intel_display.c has some pps functions that belong to intel_pps.c. Move them over. While at it, refactor the duplicate intel_pps_init() in intel_display.c into an orthogonal intel_pps_setup() in intel_pps.c, and call it earlier in intel_modeset_init_nogem(). Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
- 11 Jan, 2021 1 commit
-
-
Chris Wilson authored
As with the regular suspend paths, also disable the wakeref assertions as we disable the driver during shutdown. Reported-by:
Hans de Goede <hdegoede@redhat.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2899 Fixes: fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by:
-
- 08 Jan, 2021 1 commit
-
-
Chris Wilson authored
As with the regular suspend paths, also disable the wakeref assertions as we disable the driver during shutdown. Reported-by:
-
- 05 Jan, 2021 2 commits
-
-
Chris Wilson authored
Older platforms use rawclk to derive the CS clock. rawclk is being determined during intel_device_info_init(), and so that needs to be pushed slightly earlier. Fixes: f170523a ("drm/i915/gt: Consolidate the CS timestamp clocks") Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210104115145.24460-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a single global pm_qos does not suffice. (One connector may disable the dma-latency boost prematurely while the second is still depending on it.) Instead of a single global pm_qos, track the pm_qos request for each intel_dp. v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini Fixes: 9ee32fea ("drm/i915: irq-drive the dp aux communication") Signed-off-by:
-
- 30 Dec, 2020 1 commit
-
-
Chris Wilson authored
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a single global pm_qos does not suffice. (One connector may disable the dma-latency boost prematurely while the second is still depending on it.) Instead of a single global pm_qos, track the pm_qos request for each intel_dp. v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini Fixes: 9ee32fea ("drm/i915: irq-drive the dp aux communication") Signed-off-by:
-
- 04 Dec, 2020 1 commit
-
-
Chris Wilson authored
Switch off the scanout during driver unregister, so we can shutdown the HW immediately for unbind. v2: Remove the old shutdown from remove, it should now be redundant. Signed-off-by:
-
