On VC4, the TV margins on the HDMI connector are implemented by scaling
the planes.
However, if only the TV margins or the connector are changed by a new
state, the planes ending up on that connector won't be. Thus, they won't
be updated properly and we'll effectively ignore that change until the
next commit affecting these planes.
Let's make sure to add all the planes attached to the connector so that
we can update them properly.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-2-bdd54f66884e@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display. The DRM core
calls both, the old callbacks and the new client helpers, from
the same places. The new functions perform the same operation as
before, so there's no change in functionality.
Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to armada_fbdev_setup() after armada has registered its
DRM device. As in most drivers, aramda's fbdev emulation now acts
like a regular DRM client.
The fbdev client setup consists of the initial preparation and the
hot-plugging of the display. The latter creates the fbdev device
and sets up the fbdev framebuffer. The setup performs display
hot-plugging once. If no display can be detected, DRM probe helpers
re-run the detection on each hotplug event.
A call to drm_dev_unregister() releases the client automatically.
No further action is required within armada. If the fbdev framebuffer
has been fully set up, struct fb_ops.fb_destroy implements the
release. For partially initialized emulation, the fbdev client
reverts the initial setup.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230330073046.7150-5-tzimmermann@suse.de
This bridge doesn't actually implement HPD due to it being way too slow
but instead expects the panel driver to wait enough to assume HPD is
asserted. However some panels (such as the generic 'edp-panel') expect
the bridge to deal with the delay and pass maximum delay to the aux
instead.
In order to support such panels, add a dummy implementation of wait
that would just sleep the maximum delay and assume no failure has
happened.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230408082014.235425-1-nikita@trvn.ru
STI core files have been located in console and fbdev code. Move
the source code and header to the directories for video helpers.
Also update the config and build rules such that the code depends
on the config symbol CONFIG_STI_CORE, which STI console and STI
framebuffer select automatically.
Cleans up the console makefile and prepares PARISC to implement
fb_is_primary_device() within the arch/ directory. No functional
changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-12-tzimmermann@suse.de
Generic implementations of fb_pgprotect() and fb_is_primary_device()
have been in the source code for a long time. Prepare the header file
to make use of them.
Improve the code by using an inline function for fb_pgprotect()
and by removing include statements. The default mode set by
fb_pgprotect() is now writecombine, which is what most platforms
want.
Symbols are protected by preprocessor guards. Architectures that
provide a symbol need to define a preprocessor token of the same
name and value. Otherwise the header file will provide a generic
implementation. This pattern has been taken from <asm/io.h>.
v3:
* include the correct header files
v2:
* use writecombine mappings by default (Arnd)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-2-tzimmermann@suse.de
Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().
Note that this check is only valid for atomic drivers, because, for
non-atomic drivers, checking drm_any_plane_has_format() is not
possible since the format list for the primary plane is fake, and we'd
therefore reject valid formats.
Adding this check to drm_gem_fb_create() will guarantee that the
igt@kms_addfb_basic@addfb25-bad-modifier IGT test passes for drivers
using this callback.
This commit is a recapture of a series sent a while ago. Initially,
I sent a patch [1] similar to this one in which I introduced the
format check to drm_gem_fb_create().
Based on the feedback on the patch, I placed the check inside
framebuffer_check() [2] so that it wouldn't be needed to hit any
driver-specific code path when the check fails. Therefore, we could
remove the check from the specific drivers (i915, amdgpu, and vmwgfx).
But, with some new feedback, it was shown that introducing this check
inside framebuffer_check() is problematic for the i915 driver [3].
For the i915 driver, in the legacy case, in which we don't get the
modifier from the userspace, i915's fb_create hook computes the right
modifier, which isn't necessarily linear. Therefore, if we check the
modifier before that point, we might get wrong answers.
So, I kept the check inside the i915 driver and removed the check from
amdgpu and vmwgfx [4]. But, this yet hasn't solved the i915 problem [5].
As we cannot add the check inside framebuffer_check() without
affecting the i915 behavior, this commit went back to the original
patch. This way we can guarantee a more uniform behavior from the
drivers that use the drm_gem_fb_create() callback.
[1] https://lore.kernel.org/dri-devel/20230103125322.855089-1-mcanal@igalia.com/T/
[2] https://lore.kernel.org/dri-devel/20230109105807.18172-1-mcanal@igalia.com/T/
[3] https://lore.kernel.org/dri-devel/Y8AAdW2y7zN7DCUZ@intel.com/
[4] https://lore.kernel.org/dri-devel/20230113112743.188486-1-mcanal@igalia.com/T/
[5] https://lore.kernel.org/dri-devel/Y8FXWvEhO7GCRKVJ@intel.com/
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230412142923.136707-1-mcanal@igalia.com
It already happend a few times that patches slipped through which
implemented access to an entity through a job that was already removed
from the entities queue. Since jobs and entities might have different
lifecycles, this can potentially cause UAF bugs.
In order to make it obvious that a jobs entity pointer shouldn't be
accessed after drm_sched_entity_pop_job() was called successfully, set
the jobs entity pointer to NULL once the job is removed from the entity
queue.
Moreover, debugging a potential NULL pointer dereference is way easier
than potentially corrupted memory through a UAF.
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Link: https://lore.kernel.org/r/20230418100453.4433-1-dakr@redhat.com
Reviewed-by: Luben Tuikov <luben.tuikov@amd.com>
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “nvkm_fanpwm_create” and “nvkm_fantog_create”.
Thus avoid the risk for undefined behaviour by moving the assignment
for the data structure member “fan” behind two null pointer checks.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3d0215dc-74d4-2c42-2eee-7a5fcf62b9f1@web.de
