Douglas Anderson [Fri, 1 Sep 2023 23:39:55 +0000 (16:39 -0700)]
drm/ssd130x: Call drm_atomic_helper_shutdown() at remove time
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at remove time. Let's
add it.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS driver remove comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.
Douglas Anderson [Fri, 1 Sep 2023 23:39:54 +0000 (16:39 -0700)]
drm/vc4: Call drm_atomic_helper_shutdown() at shutdown time
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.
Douglas Anderson [Fri, 1 Sep 2023 23:39:53 +0000 (16:39 -0700)]
drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.
All of the drivers in this patch were fairly straightforward to fix
since they already had a call to drm_atomic_helper_shutdown() at
remove/unbind time but were just lacking one at system shutdown. The
only hitch is that some of these drivers use the component model to
register/unregister their DRM devices. The shutdown callback is part
of the original device. The typical solution here, based on how other
DRM drivers do this, is to keep track of whether the device is bound
based on drvdata. In most cases the drvdata is the drm_device, so we
can just make sure it is NULL when the device is not bound. In some
drivers, this required minor code changes. To make things simpler,
drm_atomic_helper_shutdown() has been modified to consider a NULL
drm_device as a noop in the patch ("drm/atomic-helper:
drm_atomic_helper_shutdown(NULL) should be a noop").
Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.2.I9115e5d094a43e687978b0699cc1fe9f2a3452ea@changeid
Douglas Anderson [Fri, 1 Sep 2023 23:41:12 +0000 (16:41 -0700)]
drm/armada: Call drm_atomic_helper_shutdown() at shutdown time
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.
This driver was fairly easy to update. The drm_device is stored in the
drvdata so we just have to make sure the drvdata is NULL whenever the
device is not bound. To make things simpler,
drm_atomic_helper_shutdown() has been modified to consider a NULL
drm_device as a noop in the patch ("drm/atomic-helper:
drm_atomic_helper_shutdown(NULL) should be a noop").
AngeloGioacchino Del Regno [Wed, 20 Sep 2023 08:27:27 +0000 (10:27 +0200)]
drm/bridge: panel: Fix device link for DRM_BRIDGE_ATTACH_NO_CONNECTOR
When external bridges are attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR,
the panel bridge may also get the same flag, but in the .attach()
callback for the panel bridge a device link is added only when this
flag is not present; To make things worse, the .detach() callback
tries to delete the device link unconditionally and without checking
if it was created in the first place, crashing the kernel with a NULL
pointer kernel panic upon calling panel_bridge_detach().
Fix that by moving the device_link_add() call before checking if the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is present.
Tvrtko Ursulin [Wed, 21 Jun 2023 09:48:24 +0000 (10:48 +0100)]
drm: Update file owner during use
With the typical model where the display server opens the file descriptor
and then hands it over to the client(*), we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected to allow for lockless readers. Update
side is protected with dev->filelist_mutex.
Before:
$ cat /sys/kernel/debug/dri/0/clients
command pid dev master a uid magic
Xorg 2344 0 y y 0 0
Xorg 2344 0 n y 0 2
Xorg 2344 0 n y 0 3
Xorg 2344 0 n y 0 4
After:
$ cat /sys/kernel/debug/dri/0/clients
command tgid dev master a uid magic
Xorg 830 0 y y 0 0
xfce4-session 880 0 n y 0 1
xfwm4 943 0 n y 0 2
neverball 1095 0 n y 0 3
*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:
"""
The traditional model, the server was the orchestrator managing the
primary device node. From the fd, to the master status and
authentication. But looking at the fd alone, this has varied across
the years.
IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
fd(s) and reuse those whenever needed, DRI2 the client was responsible
for open() themselves and with DRI3 the fd was passed to the client.
Around the inception of DRI3 and systemd-logind, the latter became
another possible orchestrator. Whereby Xorg and Wayland compositors
could ask it for the fd. For various reasons (hysterical and genuine
ones) Xorg has a fallback path going the open(), whereas Wayland
compositors are moving to solely relying on logind... some never had
fallback even.
Over the past few years, more projects have emerged which provide
functionality similar (be that on API level, Dbus, or otherwise) to
systemd-logind.
"""
v2:
* Fixed typo in commit text and added a fine historical explanation
from Emil.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Tested-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230621094824.2348732-1-tvrtko.ursulin@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:59 +0000 (09:50 +0300)]
drm/bridge: tc358768: Attempt to fix DSI horizontal timings
The DSI horizontal timing calculations done by the driver seem to often
lead to underflows or overflows, depending on the videomode.
There are two main things the current driver doesn't seem to get right:
DSI HSW and HFP, and VSDly. However, even following Toshiba's
documentation it seems we don't always get a working display.
This patch attempts to fix the horizontal timings for DSI event mode, and
on a system with a DSI->HDMI encoder, a lot of standard HDMI modes now
seem to work. The work relies on Toshiba's documentation, but also quite
a bit on empirical testing.
This also adds timing related debug prints to make it easier to improve
on this later.
The DSI pulse mode has only been tested with a fixed-resolution panel,
which limits the testing of different modes on DSI pulse mode. However,
as the VSDly calculation also affects pulse mode, so this might cause a
regression.
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:57 +0000 (09:50 +0300)]
drm/bridge: tc358768: Clean up clock period code
The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer
to clock periods. The original author does not remember where all this
came from. Effectively the driver is using picoseconds as the unit for
clock periods, yet referring to them by "nsk".
Clean this up by just saying the periods are in picoseconds.
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:56 +0000 (09:50 +0300)]
drm/bridge: tc358768: Rename dsibclk to hsbyteclk
The Toshiba documentation talks about HSByteClk when referring to the
DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a
few places the driver calculates the byte clock from the DSI clock, even
if the byte clock is already available in a variable.
To align the driver with the documentation, change the 'dsibclk'
variable to 'hsbyteclk'. This also make it easier to visually separate
'dsibclk' and 'dsiclk' variables.
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:54 +0000 (09:50 +0300)]
drm/bridge: tc358768: Print logical values, not raw register values
The driver debug prints DSI related timings as raw register values in
hex. It is much more useful to see the "logical" value of the timing,
not the register value.
Change the prints to print the values separately, in case a single
register contains multiple values, and use %u to have it in a more human
consumable form.
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:53 +0000 (09:50 +0300)]
drm/bridge: tc358768: Use struct videomode
The TC358768 documentation uses HFP, HBP, etc. values to deal with the
video mode, while the driver currently uses the DRM display mode
(htotal, hsync_start, etc).
Change the driver to convert the DRM display mode to struct videomode,
which then allows us to use the same units the documentation uses. This
makes it much easier to work on the code when using the TC358768
documentation as a reference.
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:52 +0000 (09:50 +0300)]
drm/bridge: tc358768: Cleanup PLL calculations
As is quite common, some of TC358768's PLL register fields are to be
programmed with (value - 1). Specifically, the FBD and PRD, multiplier
and divider, are such fields.
However, what the driver currently does is that it considers that the
formula used for PLL rate calculation is:
RefClk * [(FBD + 1)/ (PRD + 1)] * [1 / (2^FRS)]
where FBD and PRD are values directly from the registers, while a more
sensible way to look at it is:
RefClk * FBD / PRD * (1 / (2^FRS))
and when the FBD and PRD values are written to the registers, they will
be subtracted by one.
Change the driver accordingly, as it simplifies the PLL code.
Tomi Valkeinen [Wed, 6 Sep 2023 06:50:50 +0000 (09:50 +0300)]
drm/bridge: tc358768: Default to positive h/v syncs
As the TC358768 is a DPI to DSI bridge, the DSI side does not need to
define h/v sync polarities. This means that sometimes we have a mode
without defined sync polarities, which does not work on the DPI side.
Add a mode_fixup hook to default to positive sync polarities.
drm/tegra: rgb: Parameterize V- and H-sync polarities
The polarities of the V- and H-sync signals are encoded as flags in the
display mode, so use the existing information to setup the signals for
the RGB interface.
Signed-off-by: Thierry Reding <treding@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com>
[tomi.valkeinen@ideasonboard.com: default to positive sync] Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-1-31725f008a50@ideasonboard.com
Ben Skeggs [Tue, 19 Sep 2023 21:56:24 +0000 (17:56 -0400)]
drm/nouveau/kms/nv50-: split DP disable+enable into two modesets
Link training can finally be moved out of the supervisor sequence,
but first we need to split DP modesets into separate disable and
enable sequences to be able to perform link training between them
instead.
- adds tracking for post-UPDATE modeset operations, similar to mst[mo]'s
- audio won't work on RM without this
- we should probably have been doing this anyway
Ben Skeggs [Tue, 19 Sep 2023 21:56:08 +0000 (17:56 -0400)]
drm/nouveau/disp: add acquire_sor/pior()
- preparing to move protocol-specific args out of acquire() again
- avoid re-acquiring acquired output, will matter when enforced later
- sor/pior done at same time due to shared tmds/dp handling
Ben Skeggs [Tue, 19 Sep 2023 21:56:07 +0000 (17:56 -0400)]
drm/nouveau/disp: add acquire_dac()
- preparing to move protocol-specific args out of acquire() again
- avoid re-acquiring acquired output, will matter when enforced later
- this one is basically just a rename
Lyude Paul [Tue, 19 Sep 2023 21:56:05 +0000 (17:56 -0400)]
drm/nouveau/kms: Add INHERIT ioctl to nvkm/nvif for reading IOR state
Now that we're supporting things like Ada and the GSP, there's situations
where we really need to actually know the display state that we're starting
with when loading the driver in order to prevent breaking GSP expectations.
The first step in doing this is making it so that we can read the current
state of IORs from nvkm in DRM, so that we can fill in said into into the
atomic state.
We do this by introducing an INHERIT ioctl to nvkm/nvif. This is basically
another form of ACQUIRE, except that it will only acquire the given output
path for userspace if it's already set up in hardware. This way, we can go
through and probe each outp object we have in DRM in order to figure out
the current hardware state of each one. If the outp isn't in use, it simply
returns -ENODEV.
This is also part of the work that will be required for implementing GSP
support for display. While the GSP should mostly work without this commit,
this commit should fix some edge case bugs that can occur on initial driver
load. This also paves the way for some of the initial groundwork for
fastboot support.
Imre Deak [Wed, 13 Sep 2023 22:32:17 +0000 (01:32 +0300)]
drm/dp_mst: Tune down error message during payload addition
If a sink is removed in the middle of payload addition the corresponding
AUX transfer will fail as expected, so tune the error message down to a
debug messge.
Imre Deak [Wed, 13 Sep 2023 22:32:16 +0000 (01:32 +0300)]
drm/dp_mst: Sanitize error return during payload addition
Return an error during payload addition if the payload port isn't
found. This shouldn't change the behavior since only the i915 driver
checks the return value, printing an error message in case of a failure.
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-1-imre.deak@intel.com
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
We should prefer more robust and less ambiguous string interfaces.
A suitable replacement is `strscpy` [2] due to the fact that it guarantees
NUL-termination on the destination buffer without unnecessarily NUL-padding.
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
We should prefer more robust and less ambiguous string interfaces.
A suitable replacement is `strscpy` [2] due to the fact that it guarantees
NUL-termination on the destination buffer without unnecessarily NUL-padding.
There is likely no bug in the current implementation due to the safeguard:
| cname[sizeof(cname) - 1] = '\0';
... however we can provide simpler and easier to understand code using
the newer (and recommended) `strscpy` api.
`strncpy` is deprecated and as such we should prefer more robust and
less ambiguous string interfaces.
A suitable replacement is `strscpy_pad` due to the fact that it
guarantees NUL-termination on the destination buffer whilst also
maintaining the NUL-padding behavior that `strncpy` provides. I am not
sure whether NUL-padding is strictly needed but I see in
`nvif_object_ctor()` args is memcpy'd elsewhere so I figured we'd keep
the same functionality.
Jani Nikula [Thu, 14 Sep 2023 13:19:51 +0000 (16:19 +0300)]
MAINTAINERS: add drm_bridge_connector.[ch] files under bridge chips
Clearly this should be under bridge chips.
Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131951.2473844-1-jani.nikula@intel.com
Jani Nikula [Thu, 14 Sep 2023 13:11:59 +0000 (16:11 +0300)]
drm: bridge: it66121: ->get_edid callback must not return err pointers
The drm stack does not expect error valued pointers for EDID anywhere.
Fixes: e66856508746 ("drm: bridge: it66121: Set DDC preamble only once before reading EDID") Cc: Paul Cercueil <paul@crapouillou.net> Cc: Robert Foss <robert.foss@linaro.org> Cc: Phong LE <ple@baylibre.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: <stable@vger.kernel.org> # v6.3+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131159.2472513-1-jani.nikula@intel.com
drm/ssd130x: Store the HW buffer in the driver-private CRTC state
The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's
.atomic_check() callback") moved the allocation of the intermediate and
HW buffers from the encoder's .atomic_enable callback, to the plane's
.atomic_check callback.
This was suggested by Maxime Ripard, because drivers aren't allowed to
fail after the drm_atomic_helper_swap_state() function has been called.
And the encoder's .atomic_enable happens after the new atomic state has
been swapped, so allocations (that can fail) shouldn't be done there.
But the HW buffer isn't really tied to the plane's state. It has a fixed
size that only depends on the (also fixed) display resolution defined in
the Device Tree Blob.
That buffer can be considered part of the CRTC state, and for this reason
makes more sense to do its allocation in the CRTC .atomic_check callback.
The other allocated buffer (used to store a conversion from the emulated
XR24 format to the native R1 format) is part of the plane's state, since
it will be optional once the driver supports R1 and allows user-space to
set that pixel format.
So let's keep the allocation for it in the plane's .atomic_check callback,
this can't be moved to the CRTC's .atomic_check because changing a format
does not trigger a CRTC mode set.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/dri-devel/CAMuHMdWv_QSatDgihr8=2SXHhvp=icNxumZcZOPwT9Q_QiogNQ@mail.gmail.com/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230913052938.1114651-1-javierm@redhat.com
drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21: error: variable 'old_payload' is uninitialized when used here [-Werror,-Wuninitialized]
368 | new_payload, old_payload);
| ^~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61: note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
| ^
| = NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Douglas Anderson [Fri, 1 Sep 2023 23:41:14 +0000 (16:41 -0700)]
drm/ingenic: Call drm_atomic_helper_shutdown() at shutdown time
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart comes straight out of the kernel doc "driver
instance overview" in drm_drv.c.
Since this driver uses the component model and shutdown happens at the
base driver, we communicate whether we have to call
drm_atomic_helper_shutdown() by seeing if drvdata is non-NULL.
Douglas Anderson [Fri, 1 Sep 2023 23:41:24 +0000 (16:41 -0700)]
drm/imx/ipuv3: Call drm_atomic_helper_shutdown() at shutdown/unbind time
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time
and at driver unbind time. Among other things, this means that if a
panel is in use that it won't be cleanly powered off at system
shutdown time.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS shutdown/restart and at driver remove (or unbind) time comes
straight out of the kernel doc "driver instance overview" in
drm_drv.c.
A few notes about this fix:
- When adding drm_atomic_helper_shutdown() to the unbind path, I added
it after drm_kms_helper_poll_fini() since that's when other drivers
seemed to have it.
- Technically with a previous patch, ("drm/atomic-helper:
drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
actually need to check to see if our "drm" pointer is NULL before
calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
though, so that this patch can land without any dependencies. It
could potentially be removed later.
- This patch also makes sure to set the drvdata to NULL in the case of
bind errors to make sure that shutdown can't access freed data.
Douglas Anderson [Fri, 1 Sep 2023 23:39:52 +0000 (16:39 -0700)]
drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop
As with other places in the Linux kernel--kfree(NULL) being the most
famous example--it's convenient to treat being passed a NULL argument
as a noop in cleanup functions. Let's make
drm_atomic_helper_shutdown() work like this.
This is convenient for DRM devices that use the "component" model. On
these devices we want shutdown to be a noop if the bind() call of the
component hasn't been called yet. As long as drivers are careful to
make sure the drvdata is NULL whenever the driver is not bound then we
can just do a simple call to drm_atomic_helper_shutdown() with the
drvdata at shutdown time.
Douglas Anderson [Wed, 6 Sep 2023 14:28:03 +0000 (07:28 -0700)]
MAINTAINERS: Update DRM DRIVERS FOR FREESCALE IMX entry
As per the discussion on the lists [1], changes to this driver
generally flow through drm-misc. If they need to be coordinated with
v4l2 they sometimes go through Philipp Zabel's tree instead. List both
trees in MAINTAINERS. Also update the title of this driver to specify
that it's just for IMX 5/6 since, as per Philipp "There are a lot more
i.MX that do not use IPUv3 than those that do."
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
For the "otm8009a" driver we fully remove the storing of the "enabled"
state and we remove the double-checking, but we still keep the storing
of the "prepared" state since the backlight code in the driver checks
it. This backlight code may not be perfectly safe since there doesn't
appear to be sufficient synchronization between the backlight driver
(which userspace can call into directly) and the code that's
unpreparing the panel. However, this lack of safety is not new and can
be addressed in a future patch.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
For the s6e63m0 panel driver, this actually fixes a subtle/minor error
handling bug in s6e63m0_prepare(). In one error case s6e63m0_prepare()
called s6e63m0_unprepare() directly if there was an error. This call
to s6e63m0_unprepare() would have been a no-op since ctx->prepared
wasn't set yet.
Douglas Anderson [Fri, 4 Aug 2023 21:06:04 +0000 (14:06 -0700)]
drm/panel: Don't store+check prepared/enabled for simple cases
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
This pile of panel drivers appears to be simple to handle. Based on
code inspection they seemed to be using the prepared/enabled state
simply for double-checking that nothing else in the kernel called them
inconsistently. Now that the core drm_panel is doing the double
checking (and warning) it should be very clear that these devices
don't need their own double-check.
Problem statement: The current method roundup_power_of_two()
to allocate contiguous address triggers -ENOSPC in some cases
even though we have enough free spaces and so to help with
that we introduce a try harder mechanism.
In case of -ENOSPC, the new try harder mechanism rounddown the
original size to power of 2 and iterating over the round down
sized freelist blocks to allocate the required size traversing
RHS and LHS.
As part of the above new method implementation we moved
contiguous/alignment size computation part and trim function
to the drm buddy file.
v2: Modify the alloc_range() function to return total allocated size
on -ENOSPC err and traverse RHS/LHS to allocate the required
size (Matthew).
Thomas Zimmermann [Thu, 7 Sep 2023 08:52:05 +0000 (10:52 +0200)]
fbdev/core: Remove empty internal helpers from fb_logo.c
Remove the two empty helpers for the case the CONFIG_FB_LOGO_EXTRA
has not been set. They are internal functions and only called once.
Providing empty replacements seems like overkill. Instead protect
the call sites with a test for CONFIG_FB_LOGO_EXTRA.
Thomas Zimmermann [Thu, 7 Sep 2023 08:52:04 +0000 (10:52 +0200)]
fbdev/core: Move logo functions into separate source file
Move the fbdev function for displaying boot-up logos into their
own file fb_logo.c. Only build fb_logo.c if CONFIG_LOGO has been
selected. No functional changes.
v2:
* include fb_internal.h (kernel test robot)
* simplify option-parsing ifdefs
* build fb_logo.o iff CONFIG_LOGO has been set
Thomas Zimmermann [Thu, 7 Sep 2023 08:52:03 +0000 (10:52 +0200)]
fbdev/core: Unexport logo helpers
The interfaces for the fbdev logo are not used outside of the fbdev
module. Hence declare the fbdev logo functions in the internal header
file and remove their symbol exports. Only build the functions if
CONFIG_LOGO has been selected.
Thomas Zimmermann [Thu, 7 Sep 2023 08:52:02 +0000 (10:52 +0200)]
fbdev/core: Fix style of code for boot-up logo
Fix a number of warnings from checkpatch.pl in this code before
moving it into a separate file. This includes
* Prefer 'unsigned int' to bare use of 'unsigned'
* space required after that ',' (ctx:VxV)
* space prohibited after that open parenthesis '('
* suspect code indent for conditional statements (16, 32)
* braces {} are not necessary for single statement blocks
Thomas Zimmermann [Thu, 7 Sep 2023 08:52:01 +0000 (10:52 +0200)]
fbdev/mmp/mmpfb: Do not display boot-up logo
The fbcon module takes care of displaying the logo, if any. Remove
the code form mmpfb. It is probably no tworking as expected, as it
interferes with the framebuffer console. If we want to display the
logo without fbcon, we should implement this in the fbdev core code.
Thomas Zimmermann [Thu, 7 Sep 2023 08:52:00 +0000 (10:52 +0200)]
fbdev/au1200fb: Do not display boot-up logo
The fbcon module takes care of displaying the logo, if any. Remove
the code form au1200fb. If we want to display the logo without fbcon,
we should implement this in the fbdev core code.
Geert Uytterhoeven [Thu, 24 Aug 2023 15:08:41 +0000 (17:08 +0200)]
drm/ssd130x: Use bool for ssd130x_deviceinfo flags
The .need_pwm and .need_chargepump fields in struct ssd130x_deviceinfo
are flags that can have only two possible values: 0 and 1.
Reduce kernel size by changing their types from int to bool.
Geert Uytterhoeven [Thu, 24 Aug 2023 15:08:40 +0000 (17:08 +0200)]
drm/ssd130x: Fix screen clearing
Due to the reuse of buffers, ssd130x_clear_screen() no longers clears
the screen, but merely redraws the last image that is residing in the
intermediate buffer.
As there is no point in clearing the intermediate buffer and transposing
an all-black image, fix this by just clearing the HW format buffer, and
writing it to the panel.
drm/ssd130x: Print the PWM's label instead of its number
struct pwm_device::pwm is a write-only variable in the pwm core and used
nowhere apart from this and another dev_dbg. So it isn't useful to
identify the used PWM. Emit the PWM's label instead in the debug
message.
projects / users / jedix / linux-maple.git / log