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
This hasn't been used in a while.
Moves io accessors from nvkm/core/os.h to nvif/os.h at the same time to
fix a compile issue that results from <nvkm/core/object.h> no longer
being included.
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-17-bskeggs@nvidia.com
These were a cludge used to prevent userspace's nvif ioctl from
accessing objects created by the kernel for the same client.
That interface was removed in a previous patch, so these are no
longer useful for anything.
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-16-bskeggs@nvidia.com
This has never really been used for anything, in part due to never
having reclocking stable enough in general to attempt to implement
dynamic clock changes based on load, etc.
To avoid having to rework its interfaces, remove it 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-13-bskeggs@nvidia.com
The previous commit removes the last remnants of userspace's own nvif
instance, so this isn't needed anymore to hide the abi16 objects from
userspace and we can use nouveau_cli.device instead.
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-10-bskeggs@nvidia.com
nouveau_usif.c was already stripped right back a couple of years ago,
limiting what userspace could do with it.
A follow-on series removes the nvkm side of these interfaces entirely,
in order to make it less of a nightmare to add/change internal APIs in
the future.
Unfortunately. Userspace uses some of this.
Fortunately, userspace only ever ended up using a fraction of the APIs,
so those are reimplemened here in a more direct manner, and return
-EINVAL to userspace for everything else.
v2:
- simplified struct nouveau_abi16_obj
- added a couple of comments
v3:
- comment harder
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-9-bskeggs@nvidia.com
drm->master isn't really a nouveau_cli, and is mostly just used to get
at an nvif_mmu object to implement a hack around issues with the ioctl
interface to nvkm.
Later patches in this series allocate nvif_device/mmu objects in
nouveau_drm directly, removing the need for master.
A pending series to remove the "ioctl" layer between DRM and NVKM
removes the need for the above-mentioned hack entirely.
The only other member of drm->master that's needed is the nvif_client,
and is a dependency of device/mmu. So the first step is to move its
allocation out of code handling nouveau_cli init.
v2:
- modified slightly due to the addition of tegra/pci cleanup patches
v3:
- move nvif init below drm_dev_alloc() to avoid changing nouveau_name()
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-7-bskeggs@nvidia.com
There's various different places in the drm code that get at the
nvkm_device via various creative (and not very type-safe) means.
One of those being via nvif_device.object.priv.
Another patch series is going to entirely remove the ioctl-like
interfaces beween the drm code and nvkm, and that field will no
longer exist.
This provides a safer replacement for accessing the nvkm_device,
and will used more in upcoming patches to cleanup other cases.
v2:
- fixup printk macros to not oops if used before client ctor
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-6-bskeggs@nvidia.com
HW isn't touched anymore (aside from detection) until the first
nvif_device has been allocated, so we no longer need a separate
probe-only step before kicking efifb (etc) off the HW.
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-5-bskeggs@nvidia.com
