Mario Limonciello [Wed, 3 Jul 2024 05:17:22 +0000 (00:17 -0500)]
drm/amd: Add power_saving_policy drm property to eDP connectors
When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.
When the `power_saving_policy` property is set to bit mask
"Require low latency" PSR should be disabled.
When the property is restored to an empty bit mask ABM and PSR
can be enabled again.
Mario Limonciello [Wed, 3 Jul 2024 05:17:21 +0000 (00:17 -0500)]
drm: Introduce 'power saving policy' drm property
The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.
This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the compositor.
Uprev IGT to the latest version, which includes a fix for the
writeback tests issue on MSM devices. Enable debugging for
igt-runner to log output such as 'Begin test' and 'End test'.
This will help identify which test causes system freeze or hangs.
Update xfails and add metadata header for each flake test.
drm/panel: boe-th101mb31ig002: Support for starry-er88577 MIPI-DSI panel
The init_code of the starry-er88577 panel is very similar to the
panel-boe-th101mb31ig002-28a.c driver, so we make it compatible with
the panel-boe-th101mb31ig002-28a.c driver
dt-bindings: display: panel: Add compatible for starry-er88577
The starry-er88577 is a 10.1" WXGA TFT-LCD panel, and the init_code
of the starry-er88577 panel is very similar to the boe-th101mb31ig002
panel, so We will add a new configuration based on
"boe,th101mb31ig002-28a.yaml".
Because the panel used reset gpio before but did not add the definition
of "reset gpio" in binding, reset gpio was added in binding, but since
the starry-er88577 panel did not use "reset gpio", a judgment was added
here.
Cong Yang [Thu, 4 Jul 2024 04:50:16 +0000 (12:50 +0800)]
drm/panel: jd9365da: Support for Melfas lmfbx101117480 MIPI-DSI panel
The Melfas lmfbx101117480 is a 10.1" WXGA TFT-LCD panel, use jd9365da
controller, which fits in nicely with the existing panel-jadard-jd9365da-h3
driver. Hence, we add a new compatible with panel specific config.
drm/panel: himax-hx8394: Add Support for Microchip AC40T08A MIPI Display Panel
Add support for the Microchip AC40T08A MIPI Display panel. This panel uses
a Himax HX8394 display controller and requires a vendor provided init
sequence. The display resolution is 720x1280@60Hz with width and height
of 76mm and 132mm respectively.
Add compatible string for the Microchip's AC40T08A MIPI Display
panel.This panel uses a Himax HX8394 display controller.
The reset line is not populated and leads to driver probe issues,
thus add conditional block to narrow reset-gpio property per variant.
Thomas Hellström [Fri, 5 Jul 2024 15:32:05 +0000 (17:32 +0200)]
drm/ttm: Use the LRU walker for eviction
Use the LRU walker for eviction. This helps
removing a lot of code with weird locking
semantics.
The functionality is slightly changed so that
when trylocked buffer objects are exhausted, we
continue to interleave walks with ticket-locks while
there is still progress made. The list walks are
not restarted in-between evictions.
Also provide a separate ttm_bo_evict_first()
function for its single user. The context of that
user allows sleeping dma_resv locks.
v6:
- Various cleanups suggested by Matthew Brost.
- Fix error return code of ttm_bo_evict_first(). (Matthew Brost)
- Fix an error check that was inverted. (Matthew Brost)
v7:
- Use s64 rather than long (Christian König)
- Early ttm_resource_cursor_fini() in ttm_bo_evict_first().
- Simplify check for bo_moved in ttm_bo_evict_first().
(Christian König)
- Don't evict pinned bos.
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-8-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Hellström [Fri, 5 Jul 2024 15:32:04 +0000 (17:32 +0200)]
drm/ttm: Use the LRU walker helper for swapping
Rework the TTM swapping to use the LRU walker helper.
This helps fixing up the ttm_bo_swapout() interface
to be consistent about not requiring any locking.
For now mimic the current behaviour of using trylock
only. We could be using ticket-locks here but defer
that until it's deemed necessary. The TTM swapout
functionality is a bit weird anyway since it
alternates between memory types without exhausting
TTM_PL_SYSTEM first.
Intentionally keep pages as the unit of progress since
changing that to bytes is an unrelated change that can
be done later.
v6:
- Improve on error code translation in the swapout callback
(Matthew Brost).
v7:
- Use s64 rather than long.
- Remove ttm_resource_cursor_fini() since it's no longer used.
- Rename ttm_resource_cursor_fini_locked() to
ttm_resource_cursor_fini().
- Don't swap out pinned bos.
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-7-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Hellström [Fri, 5 Jul 2024 15:32:03 +0000 (17:32 +0200)]
drm/ttm: Provide a generic LRU walker helper
Provide a generic LRU walker in TTM, in the spirit of drm_gem_lru_scan()
but building on the restartable TTM LRU functionality.
The LRU walker optionally supports locking objects as part of
a ww mutex locking transaction, to mimic to some extent the
current functionality in ttm. However any -EDEADLK return
is converted to -ENOSPC and then to -ENOMEM before reaching
the driver, so that the driver will need to backoff and possibly retry
without being able to keep the ticket.
v3:
- Move the helper to core ttm.
- Remove the drm_exec usage from it for now, it will be
reintroduced later in the series.
v4:
- Handle the -EALREADY case if ticketlocking.
v6:
- Some cleanup and added code comments (Matthew Brost)
- Clarified the ticketlock in the commit message (Matthew Brost)
v7:
- Use s64 rather than long for the target and progress
(Christian König)
- Update documentation to not encourage using pages as a
progress measure. (Christian König)
- Remove cond_resched(). (Christian König)
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-6-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Hellström [Fri, 5 Jul 2024 15:32:02 +0000 (17:32 +0200)]
drm/ttm, drm/amdgpu, drm/xe: Consider hitch moves within bulk sublist moves
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
ttm_lru_bulk_move_init() and ttm_lru_bulk_move_fini() when
initializing and finalizing the bulk move structure, so add
those calls to the amdgpu- and xe driver.
Compared to v1 this is slightly more code but less fragile
and hopefully easier to understand.
Changes in previous series:
- Completely rework the functionality
- Avoid a NULL pointer dereference assigning manager->mem_type
- Remove some leftover code causing build problems
v2:
- For hitch bulk tail moves, store the mem_type in the cursor
instead of with the manager.
v3:
- Remove leftover mem_type member from change in v2.
v6:
- Add some lockdep asserts (Matthew Brost)
- Avoid NULL pointer dereference (Matthew Brost)
- No need to check bo->resource before dereferencing
bo->bulk_move (Matthew Brost)
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-5-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Hellström [Fri, 5 Jul 2024 15:32:01 +0000 (17:32 +0200)]
drm/ttm: Use LRU hitches
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly added items will not be
missed, and bumped items will be iterated over a second time before
reaching the end of the list.
The exception is list with bulk move sublists. When bumping a
sublist, a hitch that is part of that sublist will also be moved
and we might miss items if restarting from it. This will be
addressed in a later patch.
Changes in previous series:
- Updated ttm_resource_cursor_fini() documentation.
v2:
- Don't reorder ttm_resource_manager_first() and _next().
(Christian König).
- Use list_add instead of list_move
(Christian König)
v3:
- Split into two patches, one cleanup, one new functionality
(Christian König)
- use ttm_resource_cursor_fini_locked() instead of open-coding
(Matthew Brost)
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-4-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Hellström [Fri, 5 Jul 2024 15:32:00 +0000 (17:32 +0200)]
drm/ttm: Slightly clean up LRU list iteration
To make the transition to using lru hitches easier,
simplify the ttm_resource_manager_next() interface to only take
the cursor and reuse ttm_resource_manager_next() functionality
from ttm_resource_manager_first().
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-3-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
Thomas Hellström [Fri, 5 Jul 2024 15:31:59 +0000 (17:31 +0200)]
drm/ttm: Allow TTM LRU list nodes of different types
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the iterator is pointing to it.
These list nodes need to be easily distinguishable from other
list nodes so that others traversing the list can skip
over them.
So declare a struct ttm_lru_item, with a struct list_head member
and a type enum. This will slightly increase the size of a
struct ttm_resource.
Changes in previous series:
- Update enum ttm_lru_item_type documentation.
v3:
- Introduce ttm_lru_first_res_or_null()
(Christian König, Thomas Hellström)
v5:
- Update also the TTM test code (Xe CI).
Cc: Christian König <christian.koenig@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240705153206.68526-2-thomas.hellstrom@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
The initial idea of the Colorspace prop was that this maps 1:1 to
InfoFrames/SDP but KMS does not give user space enough information nor
control over the output format to figure out which variants can be used
for a given KMS commit. At the same time, properties like Broadcast RGB
expect full range quantization range being produced by user space from
the CRTC and drivers to convert to the range expected by the sink for
the chosen output format, mode, InfoFrames, etc.
This change documents the reality of the Colorspace property. The
Default variant unfortunately is very much driver specific and not
reflected by the EDID. The BT2020 variants are in active use by generic
compositors which have expectations from the driver about the
conversions it has to do when selecting certain output formats.
Everything else is also marked as undefined. Coming up with valid
behavior that makes it usable from user space and consistent with other
KMS properties for those variants is left as an exercise for whoever
wants to use them.
v2:
* Talk about "pixel operation properties" that user space configures
* Mention that user space is responsible for checking the EDID for sink
support
* Make it clear that drivers can choose between RGB and YCbCr on their
own
Douglas Anderson [Wed, 12 Jun 2024 22:23:43 +0000 (15:23 -0700)]
drm/tegra: 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.
Lyude Paul [Wed, 3 Jul 2024 16:04:58 +0000 (12:04 -0400)]
drm/vkms: Remove event from vkms_output
While working on rvkms, I noticed that there's no code that actually uses
the drm_pending_vblank_event that's embedded in vkms_output. So, just drop
the member from the struct.
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:57:22 +0000 (21:57 +0100)]
drm/sti: hqvdp: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:57:21 +0000 (21:57 +0100)]
drm/sti: hdmi: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:38:31 +0000 (21:38 +0100)]
drm/sti: vtg: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:38:30 +0000 (21:38 +0100)]
drm/sti: tvout: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:38:29 +0000 (21:38 +0100)]
drm/sti: hda: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:38:28 +0000 (21:38 +0100)]
drm/sti: dvo: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Steven Price [Wed, 3 Jul 2024 15:56:46 +0000 (16:56 +0100)]
drm/panthor: Record devfreq busy as soon as a job is started
If a queue is already assigned to the hardware, then a newly submitted
job can start straight away without waiting for the tick. However in
this case the devfreq infrastructure isn't notified that the GPU is
busy. By the time the tick happens the job might well have finished and
no time will be accounted for the GPU being busy.
Fix this by recording the GPU as busy directly in queue_run_job() in the
case where there is a CSG assigned and therefore we just ring the
doorbell.
Imre Deak [Fri, 28 Jun 2024 16:44:42 +0000 (19:44 +0300)]
drm: Add helpers for q4 fixed point values
Add helpers to convert between q4 fixed point and integer/fraction
values. Also add the format/argument macros required to printk q4 fixed
point variables. The q4 notation is based on the short variant described
by
https://en.wikipedia.org/wiki/Q_(number_format)
where only the number of fraction bits in the fixed point value are
defined, while the full size is deducted from the container type, that
is the size of int for these helpers. Using the fxp_ prefix, which makes
moving these helpers outside of drm to a more generic place easier, if
they prove to be useful.
These are needed by later patches dumping the Display Stream Compression
configuration in DRM core and in the i915 driver to replace the
corresponding bpp_x16 helpers defined locally in the driver.
v2: Use the more generic/descriptive fxp_q4 prefix instead of drm_x16.
(Jani)
Wayne Lin [Wed, 26 Jun 2024 08:48:24 +0000 (16:48 +0800)]
drm/dp_mst: Skip CSN if topology probing is not done yet
[Why]
During resume, observe that we receive CSN event before we start topology
probing. Handling CSN at this moment based on uncertain topology is
unnecessary.
[How]
Add checking condition in drm_dp_mst_handle_up_req() to skip handling CSN
if the topology is yet to be probed.
Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-3-Wayne.Lin@amd.com
Wayne Lin [Wed, 26 Jun 2024 08:48:23 +0000 (16:48 +0800)]
drm/dp_mst: Fix all mstb marked as not probed after suspend/resume
[Why]
After supend/resume, with topology unchanged, observe that
link_address_sent of all mstb are marked as false even the topology probing
is done without any error.
It is caused by wrongly also include "ret == 0" case as a probing failure
case.
[How]
Remove inappropriate checking conditions.
Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Fixes: 37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit") Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-2-Wayne.Lin@amd.com
Dragan Simic [Mon, 17 Jun 2024 20:17:48 +0000 (22:17 +0200)]
drm/panfrost: Mark simple_ondemand governor as softdep
Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand
devfreq governor by default. This causes driver initialization to fail on
boot when simple_ondemand governor isn't built into the kernel statically,
as a result of the missing module dependency and, consequently, the required
governor module not being included in the initial ramdisk. Thus, let's mark
simple_ondemand governor as a softdep for Panfrost, to have its kernel module
included in the initial ramdisk.
This is a rather longstanding issue that has forced distributions to build
devfreq governors statically into their kernels, [1][2] or has forced users
to introduce some unnecessary workarounds. [3]
For future reference, not having support for the simple_ondemand governor in
the initial ramdisk produces errors in the kernel log similar to these below,
which were taken from a Pine64 RockPro64:
panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq
panfrost ff9a0000.gpu: Fatal error during GPU init
panfrost: probe of ff9a0000.gpu failed with error -22
Having simple_ondemand marked as a softdep for Panfrost may not resolve this
issue for all Linux distributions. In particular, it will remain unresolved
for the distributions whose utilities for the initial ramdisk generation do
not handle the available softdep information [4] properly yet. However, some
Linux distributions already handle softdeps properly while generating their
initial ramdisks, [5] and this is a prerequisite step in the right direction
for the distributions that don't handle them properly yet.
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:53 +0000 (17:27 +0200)]
drm/ast: Use drm_atomic_helper_commit_tail() helper
Ast has no special requirements for runtime power management. So
replace drm_atomic_helper_commit_tail_rpm() with the regular helper
drm_atomic_helper_commit_tail().
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:52 +0000 (17:27 +0200)]
drm/ast: Inline ast_crtc_dpms() into callers
The function ast_crtc_dpms() is left over from when the ast driver
did not implement atomic modesetting. But DPMS is not supported by
atomic modesetting and the helper is only called to enable or
disable the CRTC sync pulses. Inline the function into its callers.
To disable the CRTC, ast sets (AST_DPMS_VSYNC_OFF | AST_DPMS_HSYNC_OFF)
in VGACRB6. Replace the constants with the correct register constants
for VGACRB6.
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:51 +0000 (17:27 +0200)]
drm/ast: Only set VGA SCREEN_DISABLE bit in CRTC code
The SCREEN_DISABLE bit controls scanout from display memory. The bit
affects all planes, so set it only in the CRTC's atomic enable and
disable functions.
A number of bugs affect this fix. First of all, ast_set_std_regs()
tries to set VGASR1 except for the SD bit. But the read bitmask is
invert, so it preserves anything except the SD bit. Fix this by
re-inverting the read mask.
The second issue is that primary-plane and CRTC helpers modify the
SD bit. The bit controls scanout for all planes, primary and HW
cursor, so set it only in the CRTC code.
Further add a constant to represent the SD bit in VGASR1. Keep the
plane's atomic_disable around to make the DRM framework happy.
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:49 +0000 (17:27 +0200)]
drm/ast: Handle primary-plane format setup in atomic_update
Several color registers are programmed in the DPMS code of the CRTC's
atomic_enable helper and the primary plane's atomic_update. It requires
the color format and the display mode.
Both code paths handle different cases: the DPMS's code will not be
executed if the color format changes without a full mode switch. The
plane's code only runs if the color format changes, but ignores
display-mode changes.
The color format is a property of the primary plane, so consolidate all
color-format code in the plane's atomic_update. Remove it from the DPMS
helper.
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:48 +0000 (17:27 +0200)]
drm/ast: Move mode-setting code into mode_set_nofb CRTC helper
Do all mode setting in ast_crtc_helper_mode_set_nofb(), which
always runs after disabling the CRTC and before programming the
planes. Removes implicit synchronization between the CRTC's
atomic disable, enable and the vertical retrace.
Display-mode updates require HW cursors to be disabled. The HW
cursor only picks up changes at vertical retrace periods. So the
CRTC's atomic_disable helper waited for the retrace to delay any
following mode-setting operations, which then happened in
atomic_enable. See [1] for a description of the problem.
With the CRTC helper callback mode_set_nofb, we can now synchronize
and reprogram in the same place. As it always runs before the plane
update, the plane code can be reordered with the CRTC's later
atomic_enable et al.
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:47 +0000 (17:27 +0200)]
drm/ast: Program mode for AST DP in atomic_mode_set
The CRTC's atomic_flush function contains code to program the
display mode to the AST DP chip. Move the code to the encoder's
atomic_mode_set callback. The DRM atomic-modesetting code invoke
this callback as part of the atomic commit.
Thomas Zimmermann [Thu, 27 Jun 2024 15:27:46 +0000 (17:27 +0200)]
drm/ast: Implement atomic enable/disable for encoders
The CRTC helpers contain code to enable and disable DisplayPort
connectors. Implement this functionality in the respective connector's
atomic_enable/atomic_disable callbacks. DRM's atomic-modesetting
helpers will call the functions as part of the atomic commit.
Dragan Simic [Mon, 17 Jun 2024 20:22:02 +0000 (22:22 +0200)]
drm/lima: Mark simple_ondemand governor as softdep
Lima DRM driver uses devfreq to perform DVFS, while using simple_ondemand
devfreq governor by default. This causes driver initialization to fail on
boot when simple_ondemand governor isn't built into the kernel statically,
as a result of the missing module dependency and, consequently, the
required governor module not being included in the initial ramdisk. Thus,
let's mark simple_ondemand governor as a softdep for Lima, to have its
kernel module included in the initial ramdisk.
This is a rather longstanding issue that has forced distributions to build
devfreq governors statically into their kernels, [1][2] or may have forced
some users to introduce unnecessary workarounds.
Having simple_ondemand marked as a softdep for Lima may not resolve this
issue for all Linux distributions. In particular, it will remain
unresolved for the distributions whose utilities for the initial ramdisk
generation do not handle the available softdep information [3] properly
yet. However, some Linux distributions already handle softdeps properly
while generating their initial ramdisks, [4] and this is a prerequisite
step in the right direction for the distributions that don't handle them
properly yet.
A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not implemented. Since the
DSI kernel clock is based on the internal DSI pll. The common clock
driver can not directly expose this 'ck_dsi_phy' clock because it does
not contain any common registers with the DSI. Thus it needs to be done
directly within the DSI phy driver.
Raphael Gallais-Pou [Mon, 26 Feb 2024 10:48:06 +0000 (11:48 +0100)]
drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
The Low-Voltage Differential Signaling (LVDS) Display Interface
Transmitter handles the LVDS protocol: it maps the pixels received from
the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS
PHY.
It is composed of three sub blocks:
* LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps
its input pixels onto the data lanes of the PHY
* LVDS PHY: parallelize the data and drives the LVDS data lanes
* LVDS wrapper: handles top-level settings
The LVDS controller driver supports the following high-level features:
* FDP-Link-I and OpenLDI (v0.95) protocols
* Single-Link or Dual-Link operation
* Single-Display or Double-Display (with the same content
duplicated on both)
* Flexible Bit-Mapping, including JEIDA and VESA
* RGB888 or RGB666 output
* Synchronous design, with one input pixel per clock cycle
Zhaoxiong Lv [Mon, 24 Jun 2024 14:19:25 +0000 (22:19 +0800)]
drm/panel: jd9365da: Support for kd101ne3-40ti MIPI-DSI panel
The K&d kd101ne3-40ti is a 10.1" WXGA TFT-LCD panel, use
jd9365da controller,which fits in nicely with the existing
panel-jadard-jd9365da-h3 driver.Hence,we add a new compatible
with panel specific config.
Although they have the same control IC, the two panels are different,
and the timing will be slightly different, so we added some variables
in struct jadard_panel_desc to control the timing.
Zhaoxiong Lv [Mon, 24 Jun 2024 14:19:22 +0000 (22:19 +0800)]
drm/panel: jd9365da: Modify the method of sending commands
Currently, the init_code of the jd9365da driver is placed
in the enable() function and sent, but this seems to take
a long time. It takes 17ms to send each instruction (an init
code consists of about 200 instructions), so it takes
about 3.5s to send the init_code. So we moved the sending
of the inti_code to the prepare() function, and each
instruction seemed to take only 25μs.
We checked the DSI host and found that the difference in
command sending time is caused by the different modes of
the DSI host in prepare() and enable() functions.
Our DSI Host only supports sending cmd in LP mode, The
prepare() function can directly send init_code (LP->cmd)
in LP mode, but the enable() function is in HS mode and
needs to switch to LP mode before sending init code
(HS->LP->cmd->HS). Therefore, it takes longer to send
the command.
Lucas Stach [Wed, 19 Jun 2024 18:22:00 +0000 (20:22 +0200)]
drm/bridge: analogix_dp: handle AUX transfer timeouts
Timeouts on the AUX bus are to be expected in certain normal operating
conditions. There is no need to raise an error log or re-initialize the
whole AUX state machine. Simply acknowledge the AUX_ERR interrupt and
let upper layers know about the timeout.
Lucas Stach [Wed, 19 Jun 2024 18:21:59 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: only read AUX status when an error occured
All AUX error responses raise the AUX_ERR interrupt, so there is no
need to read the AUX status register in normal operation. Only read
the status when an error occurred and we can expect a different
status than OK.
Lucas Stach [Wed, 19 Jun 2024 18:21:58 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: simplify and correct PLL lock checks
Move the wait loop into its own function, so it doesn't need to be
replicated in multiple locations. Also move the PLL lock checks between
setting the link bandwidth, which may cause the PLL to unlock, and the
MACRO_RST which needs the PLL to be locked.
Lucas Stach [Wed, 19 Jun 2024 18:21:57 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: don't wait for PLL lock too early
The PLL will be reconfigured later, which may cause it to go out of lock
anyway, so there is no point in waiting for the PLL to lock here. Instead
we can continue execution of the link setup, which will properly set the
PLL parameters and will wait for the PLL to lock at the appropriate times.
Lucas Stach [Wed, 19 Jun 2024 18:21:56 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: move macro reset after link bandwidth setting
Setting the link bandwidth may change the PLL parameters, which will cause
the PLL to go out of lock, so make sure to apply the MACRO_RST, which
according to the comment is required to be pulsed after the PLL is locked.
Lucas Stach [Wed, 19 Jun 2024 18:21:55 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: remove PLL lock check from analogix_dp_config_video
This check is way too late in the DP enable flow. The PLL must be
locked much earlier, before any link training can happen. If the
PLL is unlocked at that point in time there is something seriously
wrong in the enable flow.
Lucas Stach [Wed, 19 Jun 2024 18:21:54 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: move basic controller init into runtime PM
Make sure the controller is in a basic working state after runtime
resume. Keep the analog function enable in the mode set path as this
enables parts of the PHY that are only required to be powered when
there is a data stream being sent out.
Lucas Stach [Wed, 19 Jun 2024 18:21:53 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: move platform and PHY power handling into runtime PM
Platform and PHY power isn't only required when the actual display data
stream is active, but may be required earlier to support AUX channel
transactions. Move them into the runtime PM calls, so they are properly
managed whenever various other parts of the driver need them to be active.
Lucas Stach [Wed, 19 Jun 2024 18:21:52 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: remove clk handling from analogix_dp_set_bridge
The clock is already managed by runtime PM, which is properly invoked
from the analogix_dp_set_bridge function, so there is no need for an
additional reference.
Now that the clock is handled dynamically through
analogix_dp_resume/suspend and it isn't statically enabled in the
driver probe routine, there is no need for the remove function anymore.
Lucas Stach [Wed, 19 Jun 2024 18:21:50 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: handle clock via runtime PM
There is no reason to enable the controller clock in driver probe, as
there is no HW initialization done in this function. Instead rely on
either runtime PM to handle the controller clock or statically enable
it in the driver bind routine, after which real hardware access is
required to work.
Lucas Stach [Wed, 19 Jun 2024 18:21:49 +0000 (20:21 +0200)]
drm/bridge: analogix_dp: register AUX bus after enabling runtime PM
AUX transactions require the controller to be in working state and
take a runtime PM reference. To avoid potential races beween the
first transactions on the bus and runtime PM being set up, move the
AUX registration behind the runtime PM setup.
Hook up the runtime PM suspend/resume paths to make the rockchip
glue behave more like the exynos one. The same suspend/resume
functions are used for system sleep via the runtime PM force
suspend/resume.
This isn't used, but gives the impression of the power on and power off
platform calls being non-symmetrical. Remove the unused callback and
rename the power_on_start to simply power_on.
Geert Uytterhoeven [Wed, 26 Jun 2024 08:41:45 +0000 (10:41 +0200)]
drm/panic: Restrict graphical logo handling to built-in
When CONFIG_DRM_PANIC=y, but CONFIG_DRM=m:
ld: drivers/gpu/drm/drm_panic.o: in function `drm_panic_setup_logo':
drivers/gpu/drm/drm_panic.c:99: multiple definition of `init_module'; drivers/gpu/drm/drm_drv.o:drivers/gpu/drm/drm_drv.c:1079: first defined here
Fix this by restricting the graphical logo handling and its
device_initcall() to the built-in case. Logos are freed during late
kernel initialization, so they are no longer available at module load
time anyway.
Fixes: 294bbd1f2697 ("drm/panic: Add support for drawing a monochrome graphical logo") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406261341.GYsbLpN1-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/4009fca99a7c05f617cc9899c6d0a5748415595d.1719391132.git.geert+renesas@glider.be
Geert Uytterhoeven [Wed, 26 Jun 2024 08:41:44 +0000 (10:41 +0200)]
drm/panic: Do not select DRM_KMS_HELPER
DRM core code cannot call into DRM helper code, as this would lead to
circular references in the modular case. Hence drop the selection of
DRM_KMS_HELPER. It was unused anyway, as v10 switched from using
the DRM format helpers to its own color format conversion, cfr. commit 9544309775c3 ("drm/panic: Add support for color format conversion").
Remove the unneeded include of <drm/drm_format_helper.h>.
Marek Vasut [Tue, 25 Jun 2024 12:02:33 +0000 (14:02 +0200)]
drm/bridge: tc358767: Set LSCLK divider for SYSCLK to 1
The only information in the datasheet regarding this divider is a note
in SYS_PLLPARAM register documentation which states that when LSCLK is
270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when
LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test
confirms using LSCLK_DIV 1 has no adverse effects either. In the worst
case, the internal TC358767 clock would run faster.
Marek Vasut [Tue, 25 Jun 2024 12:02:32 +0000 (14:02 +0200)]
drm/bridge: tc358767: Drop line_pixel_subtract
This line_pixel_subtract is no longer needed now that the bridge can
request and obtain specific pixel clock on input to the bridge, with
clock frequency that matches the Pixel PLL frequency.
The line_pixel_subtract is now always 0, so drop it entirely.
The line_pixel_subtract was not reliable as it never worked when the
Pixel PLL and input clock were off just so that the required amount
of pixels to subtract would not be whole integer.
Marek Vasut [Tue, 25 Jun 2024 12:02:31 +0000 (14:02 +0200)]
drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the
Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and
pass it down the display pipeline to obtain exactly this frequency on input
into this bridge.
The precise input frequency that matches the Pixel PLL frequency is
important for this bridge, as if the frequencies do not match, the
bridge does suffer VFIFO overruns or underruns.
Marek Vasut [Tue, 25 Jun 2024 12:02:30 +0000 (14:02 +0200)]
drm/bridge: tc358767: Split tc_pxl_pll_en() into parameter calculation and enablement
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL
parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc()
and then configures the Pixel PLL register.
This is a preparatory patch for further rework, where tc_pxl_pll_calc()
will also be used to find out the exact clock frequency generated by the
Pixel PLL. This frequency will be used as adjusted_mode clock frequency
and passed down the display pipeline to obtain exactly this frequency
on input into this bridge.
The precise input frequency that matches the Pixel PLL frequency is
important for this bridge, as if the frequencies do not match, the
bridge does suffer VFIFO overruns or underruns.
Thomas Zimmermann [Tue, 25 Jun 2024 13:18:09 +0000 (15:18 +0200)]
drm/ast: Inline drm_simple_encoder_init()
The function drm_simple_encoder_init() is a trivial helper and
deprecated. Replace it with the regular call to drm_encoder_init().
Resolves the dependency on drm_simple_kms_helper.h. No functional
changes.
Tejas Vipin [Wed, 26 Jun 2024 04:52:41 +0000 (10:22 +0530)]
drm/panel: sitronix-st7703: transition to mipi_dsi wrapped functions
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for
sitronix-st7703 based panels.
Lucas Stach [Fri, 17 May 2024 10:45:49 +0000 (12:45 +0200)]
gpu: ipu-v3: pre: don't use fixed timeout when waiting for safe window
The timeout when waiting for the PRE safe window is rather short, as
normally we would only need to wait a few dozen usecs for the problematic
scanline region to pass and we don't want to spin too long in case
something goes wrong. This however mixes badly with preemption, as we
can easily get scheduled away from the CPU for a longer time than our
timeout, in which case we would hit a spurious timeout and wrongly skip
the PRE update.
Instead of disabling preemption across the wait loop, potentially
impacting the overall system latency, use a wait loop with a fixed
max number of iterations, so time spent away from the CPU is not
accounted against the timeout budget.
imx-drm doesn't mandate a modeset when the framebuffer modifier changes,
but currently the tile prefetch and resolve (TPR) configuration of the
PRE is only set up on the initial modeset.
As the TPR configuration is double buffered, same as all the other PRE
states, we can support dynamic reconfiguration of the buffer layout from
one frame to another. As switching between (super-)tiled and linear
prefetch needs to touch the CTRL register make sure to do the
reconfiguration inside the safe window.
projects / users / jedix / linux-maple.git / log