Check if the requested stable pstate matches the current one before
changing it. This avoids changing the stable pstate on context
destroy if the user never changed it in the first place via the
IOCTL.
v2: compare the current and requested rather than setting a flag (Lijo)
Fixes: 8cda7a4f96 ("drm/amdgpu/UAPI: add new CTX OP to get/set stable pstates")
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
support reading smartshift apu and dgpu power for smu11 based asic
v2: add new version of SmuMetrics and make calculation more readable (Lijo)
v3: avoid calculations that result in -ve values and skip related checks
v4: use the current power limit on dGPU and exclude smu 11_0_7 (Lijo)
v5: remove redundant code (Lijo)
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add support for atomic update of gamma lut.
With this patch the "Night light" feature of gnome3
is working properly on mgag200.
v2:
- Add a default linear gamma function
- renamed functions with mgag200 prefix
- use format's 4cc code instead of bit depth
- use better interpolation for 16bits gamma
- remove legacy function mga_crtc_load_lut()
- can't remove the call to drm_mode_crtc_set_gamma_size()
because it doesn't work with userspace.
- other small refactors
v3:
- change mgag200_crtc_set_gamma*() argument
to struct drm_format_info *format
- fix printk format to %p4cc for 4cc and %zu for size_t
- rebased to drm-misc-next.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220513084900.1832381-1-jfalempe@redhat.com
Currently we have some corner cases where area calculation fails. For
these sel fetch area calculation ends up having update area as y1 = 0,
y2 = 4. Instead of these values safer option is full update.
One of such for example is big fb with offset. We don't have usable
offset in psr2_sel_fetch_update. Currently it's open what is the
proper way to fix this corner case. Use full update for now.
v2: Commit message modified
v3: Print out debug info once when area calculation fails
v4: Use drm_info_once
v5: pipeA -> "pipe %c", pipe_name(crtc-pipe)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220513142811.779331-2-jouni.hogander@intel.com
Don't add a mode for the kernel's command-line parameters from
within the DRM client code. Doing so can result in an unusable
display. If there's no compatible command-line mode, the client
will use one of the connector's preferred modes.
All mode creation and validation has to be performed by the
connector. When clients run, the connector's fill_modes callback
has already processed the kernel parameters and validated each
mode before adding it. The connector's mode list does not contain
invalid modes.
v2:
* grammar in commit message (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511183125.14294-4-tzimmermann@suse.de
There are 2 ways an engine can get reset in i915 and the method of reset
affects how KMD labels a context as guilty/innocent.
(1) GuC initiated engine-reset: GuC resets a hung engine and notifies
KMD. The context that hung on the engine is marked guilty and all other
contexts are innocent. The innocent contexts are resubmitted.
(2) GT based reset: When an engine heartbeat fails to tick, KMD
initiates a gt/chip reset. All active contexts are marked as guilty and
discarded.
In order to correctly mark the contexts as guilty/innocent, pass a mask
of engines that were reset to __guc_reset_context.
Fixes: eb5e7da736 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220426003045.3929439-1-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 303760aa91)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Introduce new opaque type struct drm_edid to encapsulate the EDID data
and the size allocated for it. The contents will be private to
drm_edid.c.
There are a number of reasons for adding a container around struct edid:
* struct edid is a raw blob pointer to data that usually originates
outside of the kernel. Its size is contained within the structure.
* There's no way to attach meta information (such as allocated memory
size) to struct edid.
* Validation of the EDID blob and its size become crucial, and it's
spread all over the subsystem, with varying levels of accuracy.
* HDMI Forum has introduced an HF-EEODB extension that defines an
override EDID size within an EDID extension. The size allocated for an
EDID depends on whether the allocator understands the HF-EEODB
extension. Given a struct edid *, it's impossible to know how much
memory was actually allocated for it.
There are also some reasons for making the container type struct
drm_edid opaque and private to drm_edid.c:
* Have only one place for creating and parsing the EDID, to avoid
duplicating bugs.
* Prepare for reading a pure DisplayID 2.0 from its own DDC address, and
adding it within the same struct drm_edid container, transparently,
and for all drivers.
* With the idea that the drm_edid objects are immutable during their
lifetimes, it will be possible to refcount them and reduce EDID
copying everywhere (this is left for future work).
Initially, just add the type. In follow-up, we'll start converting the
guts of drm_edid.c to use it, and finally add interfaces around it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f3ecabd8a219aea678ad00f7bcdecf77b27b3c78.1652097712.git.jani.nikula@intel.com
With very limited vram on svga3 it's difficult to handle all the surface
migrations. Without gbobjects, i.e. the ability to store surfaces in
guest mobs, there's no reason to support intermediate svga2 features,
especially because we can fall back to fb traces and svga3 will never
support those in-between features.
On svga3 we wither want to use fb traces or screen targets
(i.e. gbobjects), nothing in between. This fixes presentation on a lot
of fusion/esxi tech previews where the exposed svga3 caps haven't been
finalized yet.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: 2cd80dbd35 ("drm/vmwgfx: Add basic support for SVGA3")
Cc: <stable@vger.kernel.org> # v5.14+
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-5-zack@kde.org
Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with command buffers and extra registers.
The initial version of SVGAv3 lacked support for most advanced features
(e.g. 3D) which made fences unnecessary. That is no longer the case,
especially as 3D support is being turned on.
Switch from FIFO commands and capabilities to command buffers and extra
registers to enable fences on SVGAv3.
Fixes: 2cd80dbd35 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-5-zack@kde.org
