- Add checks for Cursor update and dirty rects (sending updates to dmub)
- Add checks for dc_notify_vsync, and fbc and subvp
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_STATUS
from "2" (i.e. 'PXP is supported but not yet ready')
to "-ENODEV". This typically should not happen and if it
does, we have a platform configuration issue.
- If a PXP arbitration session creation event failed
due to incorrect firmware version or blocking SOC fusing
or blocking BIOS configuration (platform reasons that won't
change if we retry), then reflect that blockage by also
returning -ENODEV in the GET_PARAM:PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
supported but non-i915 dependencies (component-driver /
firmware) we are still pending to complete the init flows.
In this case, just return "2" immediately (i.e. 'PXP is
supported but not yet ready').
Difference from prio revs:
v3: - Rebase with latest tip that has pulled in setting the
gsc fw load to fail if proxy init fails.
v2: - Use a #define for the default readiness timeout (Vivaik).
- Improve comments around the failing of proxy-init.
v1: - Change the commit msg style to be imperative. (Jani)
- Rename timeout to timeout_ms. (Jani)
- Fix is_fw_err_platform_config to use higher order
param (pxp) first. (Jani)
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Balasubrawmanian, Vivaik <vivaik.balasubrawmanian@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230802182550.1592926-1-alan.previn.teres.alexis@intel.com
amdgpu:
- SDMA 6.1.0 support
- SMU 13.x fixes
- PSP 13.x fixes
- HDP 6.1 support
- SMUIO 14.0 support
- IH 6.1 support
- Coding style cleanups
- Misc display fixes
- Initial Freesync panel replay support
- RAS fixes
- SDMA 5.2 MGCG updates
- SR-IOV fixes
- DCN3+ gamma fix
- Revert zpos properly until IGT regression is fixed
- NBIO 7.9 fixes
- Use TTM to manage the doorbell BAR
- Async flip fix
- DPIA tracing support
- DCN 3.x TMDS HDMI fixes
- FRU fixes
amdkfd:
- Coding style cleanups
- SVM fixes
- Trap handler fixes
- Convert older APUs to use dGPU path like newer APUs
- Drop IOMMUv2 path as it is no longer used
radeon:
- Coding style cleanups
drm buddy:
- Fix debugging output
UAPI:
- A new memory pool was added to amdgpu_drm.h since we converted doorbell BAR management to use TTM,
but userspace is blocked from allocating from it at this point, so kind of not really anything new
here per se
Signed-off-by: Dave Airlie <airlied@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQgO5Idg2tXNTSZAr293/aFa7yZ2AUCZNahZwAKCRC93/aFa7yZ
# 2KNjAP0UV2vJZjrze7OQI/YoI+40UlGjS81nKGlMIN3eR8nzvAD/c9McLJViL82R
# idEAK7tsr/MaCKoPAlED7CkUZiHNlQw=
# =4w7I
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 12 Aug 2023 07:00:23 AEST
# gpg: using EDDSA key 203B921D836B5735349902BDBDDFF6856BBC99D8
# gpg: Can't check signature: No public key
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230811211554.7804-1-alexander.deucher@amd.com
Mediatek DRM Next for Linux 6.6
1. Small mtk-dpi cleanups
2. DisplayPort: support eDP and aux-bus
3. Fix uninitialized symbol
4. Do not check for 0 return after calling platform_get_irq()
5. Convert to platform remove callback returning void
6. Fix coverity issues
7. Fix potential memory leak if vmap() fail
8. Fix void-pointer-to-enum-cast warning
9. Rid W=1 warnings from GPU
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230813152726.14802-1-chunkuang.hu@kernel.org
There isn't actually a a690_gmu.bin. But it appears that the normal
a660_gmu.bin works fine. Normally all the devices within a sub-
generation (or "family") will use the same fw, and a690 is in the a660
family.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fixes: 5e7665b5e4 ("drm/msm/adreno: Add Adreno A690 support")
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/552406/
This should be done before the soft min/max frequencies are restored.
When we disable the "Ignore efficient frequency" flag, GuC does not
actually bring the requested freq down to RPn.
Specifically, this scenario-
- ignore efficient freq set to true
- reduce min to RPn (from efficient)
- suspend
- resume (includes GuC load, restore soft min/max, restore efficient freq)
- validate min freq has been resored to RPn
This will fail if we didn't first restore(disable, in this case) efficient
freq flag before setting the soft min frequency.
v2: Bring the min freq down to RPn when we disable efficient freq (Rodrigo)
Also made the change to set the min softlimit to RPn at init. Otherwise, we
were storing RPe there.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
Fixes: 55f9720dbf ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
Fixes: 95ccf312a1 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230726010044.3280402-1-vinay.belgaumkar@intel.com
(cherry picked from commit 28e671114f)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Commit 03e909acd9 ("drm/panel: simple: Add support for AUO G121EAN01.4
panel") added support for this panel model, but the timings it implements
are very different from what the datasheet describes. I checked both the
G121EAN01.0 datasheet from [0] and the G121EAN01.4 one from [1] and they
all have the same timings: for example the LVDS clock typical value is 74.4
MHz, not 66.7 MHz as implemented.
Replace the timings with the ones from the documentation. These timings
have been tested and the clock frequencies verified with an oscilloscope to
ensure they are correct.
Also use struct display_timing instead of struct drm_display_mode in order
to also specify the minimum and maximum values.
[0] https://embedded.avnet.com/product/g121ean01-0/
[1] https://embedded.avnet.com/product/g121ean01-4/
Fixes: 03e909acd9 ("drm/panel: simple: Add support for AUO G121EAN01.4 panel")
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230804151239.835216-1-luca.ceresoli@bootlin.com
Add additional pixel formats for which blending is disabled when
DRM_MODE_BLEND_PIXEL_NONE is set.
Refactor the fourcc selection into a separate function to handle the
increased number of formats.
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The (large) rcar_du_modeset_init() function can fail for many reasons,
two of two involving probe deferral. Use dev_err_probe() in those code
paths to record the cause of the probe deferral, in order to help
debugging probe issues.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
1. Fix build warning message in mtk_disp_ovl_adaptor.c
>> drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c:415:10:
warning: cast to smaller integer type 'enum mtk_ovl_adaptor_comp_type'
from 'const void *' [-Wvoid-pointer-to-enum-cast]
type = (enum mtk_ovl_adaptor_comp_type)of_id->data;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
2. Also fix the same warning message in mtk_drm_drv.c
>> drivers/gpu/drm/mediatek/mtk_drm_drv.c:832:15:
warning: cast to smaller integer type 'enum mtk_ddp_comp_type'
from 'const void *' [-Wvoid-pointer-to-enum-cast]
comp_type = (enum mtk_ddp_comp_type)of_id->data;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Fixes: 453c336463 ("drm/mediatek: Add ovl_adaptor support for MT8195")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202305042054.ZtWME9OU-lkp@intel.com/
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/dri-devel/patch/20230621075421.1982-1-jason-jh.lin@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
We need the domains in amdgpu_drm.h for the kernel driver to manage
the pool, but we don't want userspace using it until the code
is ready. So reject for now.
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the dGPU path instead. There were a lot of platform
issues with IOMMU in general on these chips due to windows
not enabling IOMMU at the time. The dGPU path has been
used for a long time with newer APUs and works fine. This
also paves the way to simplify the driver significantly.
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the dGPU path instead. There were a lot of platform
issues with IOMMU in general on these chips due to windows
not enabling IOMMU at the time. The dGPU path has been
used for a long time with newer APUs and works fine. This
also paves the way to simplify the driver significantly.
v2: use the dGPU queue manager functions
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
atomic_get_input_bus_fmts is only implemented for LVDS decoders, resulting
that LVDS encoders only support bus format MEDIA_BUS_FMT_FIXED. This
results in warnings like:
mxsfb 21c8000.lcdif: Bridge does not provide bus format, assuming
MEDIA_BUS_FMT_RGB888_1X24.
Please fix bridge driver by handling atomic_get_input_bus_fmts.
Fix this by reusing lvds_codec_atomic_get_input_bus_fmts currently used
for LVDS decoders. Use RGB888_1X24 for LVDS encoders. This also allows
removing the dedicated struct drm_bridge_funcs for decoders.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230810063229.597533-1-alexander.stein@ew.tq-group.com
As described in the previous patch a connector shouldn't change its
status while it's forced to a connected/disconnected state. This can
still happen while running the connector detect function to account for
lost HPD events in a low-power state.
Fix this by reusing the connector detect function which handles a
hotplug event and prevents updating the status for forced connectors as
expected.
Testcase: igt@kms_force_connector_basic@force-connector-state
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/20230809104307.1218058-3-imre.deak@intel.com
DRM display connectors forced to a connected/disconnected state via the
drm_connector::force member shouldn't change their status. Atm, this can
still happen in the connector's detect function when called to handle a
hotplug event. This in turn may lead to the GETCONNECTOR ioctl to report
the incorrect state if it's called to return the connector properties
without doing an actual detection (by calling the ioctl with a non-zero
drm_mode_get_connector::count_modes).
Fix the above by updating the connector state during hotplug detect only
if the connector state is not forced.
Testcase: igt@kms_force_connector_basic@force-connector-state
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/20230809104307.1218058-2-imre.deak@intel.com
The issue fixed in
commit a8ddac7c9f ("drm/i915: Avoid HPD poll detect triggering a new detect cycle")
on VLV, CHV is still present on platforms where the display hotplug
detection functionality is available whenever the device is in D0 state
(hence these platforms switch to HPD polling only when the device is
runtime suspended).
The above commit avoids an endless i915_hpd_poll_init_work() ->
connector detect loop by making sure that by the end of
i915_hpd_poll_init_work() all display power references acquired by the
connector detect functions which can trigger a new cycle (display core
power domain) are dropped. However on platforms where HPD polling is
enabled/disabled only from the runtime suspend/resume handlers, this is
not ensured: for instance eDP VDD, TypeC port PHYs and the runtime
autosuspend delay may still keep the device runtime resumed (via a power
reference acquired during connector detection and hence result in an
endless loop like the above).
Solve the problem described in the above commit on all platforms, by
making sure that a i915_hpd_poll_init_work() -> connector detect
sequence can't take any power reference in the first place which would
trigger a new cycle, instead of relying on these power references to be
dropped by the end of the sequence.
With the default runtime autosuspend delay (10 sec) this issue didn't
happen in practice, since the device remained runtime resumed for the
whole duration of the above sequence. CI/IGT tests however set the
autosuspend delay to 0, which makes the problem visible, see References:
below.
Tested on GLK, CHV.
v2: Don't warn about a requeued work, to account for disabling
polling directly during driver loading, reset and system resume.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403
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/20230809104307.1218058-1-imre.deak@intel.com
