Control the VIDRST pin from the VGA-BMC encoder's atomic_check and
remove the respective code from CRTC. Makes the VIDRST functionality
fully composable.
The VIDRST pin allows an external clock source to control the SYNC
signals of the Matrox chip. The functionality is part of the CRTC,
but depends on the presence of the clock source. This is the case for
some BMCs, so control the pin from the VGA-BMC output.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240805130622.63458-4-tzimmermann@suse.de
The VGA-BMC connector selects the VGA output if a display has been
attached to the physical connector. Otherwise it selects the BMC
output. In any case, the connector status is set to 'detected', so
that the userspace compositor displays to it.
Depending on the setting, the connector's display modes either come
from the VGA monitor's EDID or from an internal list of BMC-compatible
modes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240805130622.63458-3-tzimmermann@suse.de
Duplicate VGA output to VGA-BMC output and update all code for Matrox
server chips. The new output represents a VGA output that has a BMC
attached to it. No functional changes so far.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240805130622.63458-2-tzimmermann@suse.de
Building with Sparse enabled prints this warning for cpu_to_le16()
calls:
warning: incorrect type in assignment (different base types)
expected unsigned short [usertype]
got restricted __le16 [usertype]
And this warning for le16_to_cpu() calls:
warning: cast to restricted __le16
Declare the target buffer as __le16 to fix both warnings.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
Acked-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240716161725.41408-2-jose.exposito89@gmail.com
For rockchip rk3288 and rk3399, the display driver is rockchip
and gpu driver is panfrost. Currently, in drm-ci for rockchip
rk3288 and rk3399, only the gpu driver is tested. Refactor
the existing rockchip jobs to test both display and gpu driver
and update xfails.
Since the correct driver name is passed from the job to test gpu
and display driver, remove the check to set IGT_FORCE_DRIVER
based on driver name for rockchip jobs.
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240730021545.912271-7-vignesh.raman@collabora.com
For Amlogic Meson G12B (A311D) SOC the display driver is meson and
gpu driver is panfrost. Currently, in drm-ci for Meson G12B (A311D),
only the gpu driver is tested. Refactor the existing meson jobs
and add support in drm-ci to test both display and gpu driver for
Amlogic Meson G12B (A311D) and update xfails.
Since the correct driver name is passed from the job to test gpu
and display driver, remove the check to set IGT_FORCE_DRIVER
based on driver name for meson jobs.
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240730021545.912271-6-vignesh.raman@collabora.com
For mediatek mt8173, the display driver is mediatek, while the
gpu driver is powervr. Currently, in drm-ci for mt8173, only the
display driver is tested. Add support in drm-ci to test powervr
driver for mt8173. Powervr driver was merged in linux kernel,
but there's no mediatek support yet. So disable the powervr:mt8173
job which uses powervr driver.
Also update the MAINTAINERS file to include xfails for powervr driver.
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240730021545.912271-5-vignesh.raman@collabora.com
For mediatek mt8183, the display driver is mediatek, while the
gpu driver is panfrost. Currently, in drm-ci for mt8183, only
the gpu driver is tested. Refactor the existing mediatek jobs
and add support in drm-ci to test both display and gpu driver
for mt8183 and update xfails.
Since the correct driver name is passed from the job to test gpu
and display driver, remove the check to set IGT_FORCE_DRIVER
based on driver name for mediatek jobs.
Update the MAINTAINERS file to include xfails for panfrost driver.
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240730021545.912271-4-vignesh.raman@collabora.com
tools_test is a wrapper for running tools/intel_reg
and tools/intel_l3_parity. So skip these tests on
non-intel platforms and update expectaion files.
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240730021545.912271-3-vignesh.raman@collabora.com
Enable CONFIG_DRM_ANALOGIX_ANX7625 in the arm64 defconfig to get
display driver probed on the mt8183-kukui-jacuzzi-juniper machine.
arch/arm64/configs/defconfig has CONFIG_DRM_ANALOGIX_ANX7625=m,
but drm-ci don't have initrd with modules, so add
CONFIG_DRM_ANALOGIX_ANX7625=y in CI arm64 config.
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240730021545.912271-2-vignesh.raman@collabora.com
Having no in-kernel devices that use !DRM_BRIDGE_ATTACH_NO_CONNECTOR
mode for the Lontium LT9611UXC bridge, drop the in-bridge implementation
of the drm_connector.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240701-lt9611uxc-next-bridge-v1-2-665bce5fdaaa@linaro.org
Enable the transmission of an EoTp (end of transmission packet) by
default. EoTp should be enabled anyway because it is a Linux necessity
that can be disabled by a dsi mod_flag if needed.
EoTp signals the end of an HS transmission, this adds overall robustness
at protocol level at the expense of an increased overhead.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/6a7293bd06942131161c5a7b7878c51cfbbb807e.camel@googlemail.com
Fix support for VBLANK interrupts on G200ER, G200EV and G200SE, which
use a slightly different implementation than the others. The original
commits forgot to update the custom helpers when adding interrupt
handling for VBLANK events.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 89c6ea2006 ("drm/mgag200: Add vblank support")
Fixes: d5070c9b29 ("drm/mgag200: Implement struct drm_crtc_funcs.get_vblank_timestamp")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240731071004.519566-1-tzimmermann@suse.de
The place for link training is in the encoder's atomic_enable
helper. Remove all related tests from other helper ASTDP functions;
especially ast_astdp_is_connected(), which tests HPD status.
DP link training is controlled by the firmware. A status flag reports
success or failure. The process can be fragile on Aspeed hardware. Moving
the test from connector detection to the atomic_enable allows for several
retries and a longer timeout.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240717143319.104012-5-tzimmermann@suse.de
The overall control flow of the driver ensures that it never reads
EDID or sets display state on unconnected outputs. Therefore remove
all tests for Hot Plug Detection from these helpers. Also rename
the register constants.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240717143319.104012-4-tzimmermann@suse.de
Test for running ASTDP firmware during probe. Do not bother testing
this later. We cannot do much anyway if the firmware fails. Do not
initialize the ASTDP conenctor if the test fails during device probing.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Shixiong Ou <oushixiong@kylinos.cn>
Tested-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240717143319.104012-3-tzimmermann@suse.de
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240711052734.1273652-3-eahariha@linux.microsoft.com
The only remaining nouveau_drm.master struct member that's being used is
the mutex that protects its object tree. Move that into nouveau_drm and
remove nouveau_drm.master entirely.
A pending series to remove the "ioctl" layer between DRM and NVKM also
removes the need for object handle lookups, and hence this mutex, but
it's still required for the moment.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-35-bskeggs@nvidia.com
This allocates a new nvif_mmu in nouveau_drm, and uses it for TTM
backend memory allocations instead of nouveau_drm.master.mmu,
which is removed by a later commit that removes nouveau_drm.master
entirely.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-29-bskeggs@nvidia.com
These are some dodgy "convenience" macros for the DRM driver to peek
into NVKM state. They're still used in a few places, but don't belong
in nvif/device.h in any case.
Move them to nouveau_drv.h, and modify callers to pass a nouveau_drm
instead of an nvif_device.
v2:
- use drm->nvkm pointer for nvxx_*() macros, removing some void*
v3:
- add some explanation of the nvxx_*() macros
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-28-bskeggs@nvidia.com
There's no good reason the ioremap() that results from nvif_object_map()
should fail, so add a check that the map succeeded, and remove the rd/wr
methods from display channel objects.
As this was the last user of rd/wr methods, the nvif plumbing is removed
at the same time.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-27-bskeggs@nvidia.com
The next commit removes the nvif rd/wr methods from nvif_device, which
were probably a bad idea, and mostly intended as a fallback if ioremap()
failed (or wasn't available, as was the case in some tools I once used).
The nv04 KMS driver already mapped the device, because it's mostly been
kept alive on life-support for many years and still directly bashes PRI
a lot for modesetting.
Post-nv50, I tried pretty hard to keep PRI accesses out of the DRM code,
but there's still a few random places where we do, and those were using
the rd/wr paths prior to this commit.
This allocates and maps a new nvif_device (which will replace the usage
of nouveau_drm.master.device later on), and replicates this pointer to
all other possible users.
This will be cleaned up by the end of another patch series, after it's
been made safe to do so.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-25-bskeggs@nvidia.com
These were once used by used by userspace tools (with nvkm built as a
library), to access multiple GPUs from a single nvif_client.
The DRM code just uses the driver's default device, so remove the
arguments.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-24-bskeggs@nvidia.com
This was once used by userspace tools (with nvkm built as a library), as
a way to select a "default device".
The DRM code doesn't need this at all as clients only have access to a
single device already, so inherit the value from its parent.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240726043828.58966-20-bskeggs@nvidia.com
