Age | Commit message (Collapse) | Author |
|
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements Y-Tiling support, to still be able to draw
the panic screen.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-10-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 4 laptops, Haswell (with 128MB of eDRAM),
Comet Lake, Raptor Lake, and Lunar Lake.
For hardware using DPT, it's not possible to disable tiling, as you
will need to reconfigure the way the GPU is accessing the
framebuffer, so this will be handled by the following patches.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-9-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Implement both functions for i915 and xe, they prepare the work for
drm_panic support.
They both use kmap_try_from_panic(), and map one page at a time, to
write the panic screen on the framebuffer.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-8-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Encapsulate the struct intel_framebuffer into an xe_framebuffer
or i915_framebuffer, and allow to add specific fields for each
variant for the panic use-case.
This is particularly needed to have a struct xe_res_cursor available
to support drm panic on discrete GPU.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-7-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
If the ttm bo is backed by pages, then it's possible to safely kmap
one page at a time, using kmap_try_from_panic().
Unfortunately there is no way to do the same with ioremap, so it
only supports the kmap case.
This is needed for proper drm_panic support with xe driver.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250624091501.257661-6-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
This assumes that the alignment restriction is always smaller in
linear than in tiled.
It also assumes that the linear framebuffer size is always smaller
than the tiled.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-5-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
This assumes that the alignment restriction is always smaller in
linear than in tiled.
It also assumes that the linear framebuffer size is always smaller
than the tiled.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-4-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
The vaddr of the fbdev framebuffer is private to the struct
intel_fbdev, so this function is needed to access it for drm_panic.
Also the struct i915_vma is different between i915 and xe, so it
requires a few functions to access fbdev->vma->iomap.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-3-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
This allows driver to set some private data in get_scanout_buffer(),
and re-use them in set_pixel() callback.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250624091501.257661-2-jfalempe@redhat.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Move this macro where other GEM_* definitions live.
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/all/ca83a9d8aa86bb92de84c31fd075e92a61f78895.1750251040.git.krzysztof.karas@intel.com
|
|
Move macros related to engines out of i915_drv.h header and
place them in intel_engine.h.
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/9b9ed5bbdb37470fa679c5baf961424c9cfbad11.1750251040.git.krzysztof.karas@intel.com
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for 6.17:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- ci: Add Device tree validation and kunit
- connector: Move HDR sink metadat to drm_display_info
Driver Changes:
- bochs: drm_panic Support
- panfrost: MT8370 Support
- bridge:
- tc358767: Convert to devm_drm_bridge_alloc()
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://lore.kernel.org/r/20250626-sincere-loon-of-effort-6dbdf9@houat
|
|
Add 1, 2, 3, and 4 component 32b float formats, so that buffers with
these formats can be imported/exported with fourcc+modifier, and/or
created by gbm.
These correspond to PIPE_FORMAT_{R32,R32G32,R32G32B32,R32G32B32A32}_FLOAT
in mesa.
v2: Fix comment describing float32 layout [Sima]
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Simona Vetter <simona@ffwll.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250625173712.116446-3-robin.clark@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Not something that is likely to be scanned out, but GPUs usually support
half-float formats with 1, 2, or possibly 3 components, and it is useful
to be able to import/export them with a valid fourcc, and/or use gbm to
create them.
These correspond to PIPE_FORMAT_{R16,R16G16,R16G16B16}_FLOAT in mesa.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Simona Vetter <simona@ffwll.ch>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250625173712.116446-2-robin.clark@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Add pw_ctl_idx_to_pg() helper function to deduplicate the open-coded
usage of the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/3aa74825db0b900f93b94aa89d0242a354929b85.1750855148.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Move the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros from intel_display_regs.h
to intel_display_power_well.c. The mapping from index to PG can be
hidden there.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/18e40b77eeb3517a056f1e567672163ec568ec55.1750855148.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
When the display registers were split off from i915_reg.h, enum
skl_power_gate was left behind. Move it to intel_display_regs.h.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/495054983b74163ca7dcbf5a1b6a24099047bc64.1750855148.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
iteration
To avoid duplicating the tricky bo locking implementation,
Implement ttm_lru_walk_for_evict() using the guarded bo LRU iteration.
To facilitate this, support ticketlocking from the guarded bo LRU
iteration.
v2:
- Clean up some static function interfaces (Christian König)
- Fix Handling -EALREADY from ticketlocking in the loop by
skipping to the next item. (Intel CI)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250623155313.4901-4-thomas.hellstrom@linux.intel.com
|
|
Instead of the struct ttm_operation_ctx, Pass a struct ttm_lru_walk_arg
to enable us to easily extend the walk functionality, and to
implement ttm_lru_walk_for_evict() using the guarded LRU iteration.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250623155313.4901-3-thomas.hellstrom@linux.intel.com
|
|
ttm_bo_lru_cursor
Let the locking functions take the new struct ttm_lru_walk_arg
as argument in order for them to be easily used from both
types of walk.
v2:
- Whitespace fix
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250623155313.4901-2-thomas.hellstrom@linux.intel.com
|
|
There was an error pointer vs NULL bug in __igt_breadcrumbs_smoketest().
The __mock_request_alloc() function implements the
smoketest->request_alloc() function pointer. It was supposed to return
error pointers, but it propogates the NULL return from mock_request()
so in the event of a failure, it would lead to a NULL pointer
dereference.
To fix this, change the mock_request() function to return error pointers
and update all the callers to expect that.
Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/685c1417.050a0220.696f5.5c05@mx.google.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Add support for the CMN N116BCJ-EAK, pleace the EDID here for
subsequent reference.
00 ff ff ff ff ff ff 00 0d ae 63 11 00 00 00 00
19 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27
1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20
a6 00 00 90 10 00 00 18 00 00 00 fe 00 4e 31 31
36 42 43 4a 2d 45 41 4b 0a 20 00 00 00 fe 00 43
4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 80
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250626122854.193239-1-yelangyan@huaqin.corp-partner.google.com
|
|
As of commit 92ac7de3175e3 ("gpiolib: don't allow setting values on input
lines"), the GPIO core makes sure values cannot be set on input lines.
Remove the unnecessary check.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250620074951.32758-1-brgl@bgdev.pl
|
|
To the best of my knowledge, all drivers in the mainline kernel adding a
DRM bridge are now converted to using devm_drm_bridge_alloc() for
allocation and initialization. Among others this ensures initialization of
the bridge refcount, allowing dynamic allocation lifetime.
devm_drm_bridge_alloc() is now mandatory for all new bridges. Code using
the old pattern ([devm_]kzalloc + filling the struct fields +
drm_bridge_add) is not allowed anymore.
Any drivers that might have been missed during the conversion, patches in
flight towards mainline and out-of-tre drivers still using the old pattern
will already be caught by a warning looking like:
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 2 PID: 83 at lib/refcount.c:25 refcount_warn_saturate+0x120/0x148
[...]
Call trace:
refcount_warn_saturate+0x120/0x148 (P)
drm_bridge_get.part.0+0x70/0x98 [drm]
drm_bridge_add+0x34/0x108 [drm]
sn65dsi83_probe+0x200/0x480 [ti_sn65dsi83]
[...]
This warning comes from the refcount code and happens because
drm_bridge_add() is increasing the refcount, which is uninitialized and
thus initially zero.
Having a warning and the corresponding stack trace is surely useful, but
the warning text does not clarify the root problem nor how to fix it.
Add a DRM_WARN() just before increasing the refcount, so the log will be
much more readable:
[drm] DRM bridge corrupted or not allocated by devm_drm_bridge_alloc()
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
[...etc...]
A DRM_WARN is used because drm_warn and drm_WARN require a struct
drm_device pointer which is not yet available when adding a bridge.
Do not print the dev_name() in the warning because struct drm_bridge has no
pointer to the struct device. The affected driver should be easy to catch
based on the following stack trace however.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-3-ca53372c9a84@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
drm_bridge_attach() adds the bridge to the encoder chain, so take a
reference for that. Vice versa in drm_bridge_detach().
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-2-ca53372c9a84@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
drm_bridge_add() adds the bridge to the global bridge_list, so take a
reference for that. Vice versa in drm_bridge_remove().
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-1-ca53372c9a84@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it
possible to connect them in dual-link or cloned single-link OLDI display
modes. The current OLDI support in tidss_dispc.c can only support for
a single OLDI TX, connected to a VP and doesn't really support
configuration of OLDIs in the other modes. The current OLDI support in
tidss_dispc.c also works on the principle that the OLDI output can only
be served by one, and only one, DSS video-port. This isn't the case in
the AM62Px SoC, where there are 2 DSS controllers present that share the
OLDI TXes.
Having their own devicetree and their own bridge entity will help
support the various display modes and sharing possiblilities of the OLDI
hardware.
For all these reasons, add support for the OLDI TXes as DRM bridges.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Tested-by: Michael Walle <mwalle@kernel.org> # on am67a
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://lore.kernel.org/r/20250528122544.817829-5-aradhya.bhatia@linux.dev
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The dss dt schema and the tidss driver have kept the single-link OLDI in
AM65x integrated with the parent video-port (VP) from DSS (as the OLDI
configuration happens from the source VP only).
To help configure the dual-lvds modes that the OLDI has to offer in
devices AM62x and later, a new OLDI bridge driver will be introduced.
Mark the existing OLDI code separately by renaming all the current OLDI
identifiers with the 'AM65X_' prefix in tidss driver, to help
distinguish from the upcoming OLDI bridge driver.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Link: https://lore.kernel.org/r/20250528122544.817829-4-aradhya.bhatia@linux.dev
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
The OLDI transmitters (TXes) do not have registers of their own, and are
dependent on the source video-ports (VPs) from the DSS to provide
configuration data. This hardware doesn't directly sit on the internal
bus of the SoC, but does so via the DSS. Hence, the OLDI TXes are
supposed to be child nodes under the DSS, and not independent devices.
Two of the OLDI TXes can function in tandem to output dual-link OLDI
output, or cloned single-link outputs. In these cases, one OLDI will be
the primary OLDI, and the other one, a companion. The following diagram
represents such a configuration.
+-----+-----+ +-------+
| | | | |
| | VP1 +----+--->+ OLDI0 | (Primary - may need companion)
| | | | | |
| DSS +-----+ | +-------+
| | | |
| | VP2 | | +-------+
| | | | | |
+-----+-----+ +--->+ OLDI1 | (Companion OLDI)
| |
+-------+
The DSS in AM625 SoC has a configuration like the one above. The AM625
DSS VP1 (port@0) can connect and control 2 OLDI TXes, to use them in
dual-link or cloned single-link OLDI modes. It is only the VP1 that can
connect to either OLDI TXes for the AM625 DSS, and not the VP2.
Alternatively, on some future TI SoCs, along with the above
configuration, the OLDI TX can _also_ connect to separate video sources,
making them work entirely independent of each other. In this case,
neither of the OLDIs are "companion" or "secondary" OLDIs, and nor do
they require one. They both are independent and primary OLDIs. The
following diagram represents such a configuration.
+-----+-----+ +-------+
| | | | |
| | VP1 +--+----------->+ OLDI0 | (Primary - may need companion)
| | | | | |
| +-----+ | +-------+
| | | |
| | VP2 | |
| | | |
| DSS +-----+ | +---+ +-------+
| | | +-->+ M | | |
| | VP3 +----->+ U +--->+ OLDI1 | (Companion or Primary)
| | | | X | | |
| +-----+ +---+ +-------+
| | |
| | VP4 |
| | |
+-----+-----+
Note that depending on the mux configuration, the OLDIs can either be
working together in tandem - sourced by VP1, OR, they could be working
independently sourced by VP1 and VP3 respectively.
The idea is to support all the configurations with this OLDI TX schema.
The OLDI functionality is further supported by a system-control module,
which contains a few registers to control OLDI IO power and other
electrical characteristics of the IO lanes.
Add devicetree binding schema for the OLDI TXes to support various
configurations, and extend their support to the AM625 DSS.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://lore.kernel.org/r/20250528122544.817829-3-aradhya.bhatia@linux.dev
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
Reduce tab size from 8 spaces to 4 spaces to make the bindings
consistent, and easy to expand.
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
Link: https://lore.kernel.org/r/20250528122544.817829-2-aradhya.bhatia@linux.dev
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
Create a new unordered workqueue to be used by the display code
instead of relying on the i915 one. Then move all the unordered works
used in the display code to use this new queue.
Since this is an unordered workqueue, by definition there can't be any
order dependency with non-display works, so no extra care is needed
in regard to that.
This is part of the effort to isolate the display code from i915.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250620091632.1256135-1-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
With all the code touching struct intel_cdclk_state moved inside
intel_cdclk.c, we move the struct definition there too, and make the
type opaque. This nicely reduces includes from intel_cdclk.h.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/2b58c52e8cbcb66a48ecd4a1453e49dc7bd66289.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_cdclk_actual_voltage_level()
Add intel_cdclk_actual() and intel_cdclk_actual_voltage_level() helpers
to avoid looking at struct intel_cdclk_state internals outside of
intel_cdclk.c.
v2: Better location (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/241a9b80a8262b82fded54707ca5622af215dd86.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_cdclk_read_hw() function to avoid looking at struct
intel_cdclk_state internals outside of intel_cdclk.c.
intel_cdclk_init_hw() would be a better name, but we already have that.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/ef720d37bfeee933d59b64e382dc976f3c9fade1.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_cdclk_force_min_cdclk() helper to avoid modifying struct
intel_cdclk_state internals outside of intel_cdclk.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/0bf8a94a1a7d3ac564406ba427d12c4c8eefb5bb.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_cdclk_pmdemand_needs_update() helper to avoid looking at
struct intel_cdclk_state internals outside of intel_cdclk.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/d0d4f073707a2badb432187f6e02d6d7f9fe431b.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_cdclk_bw_min_cdclk() helper to avoid looking at struct
intel_cdclk_state internals outside of intel_cdclk.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/d07499174ebe55fa8fb98d4cb5ff541b6f5ec95b.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_cdclk_min_cdclk() helper to avoid looking at struct
intel_cdclk_state internals outside of intel_cdclk.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/af768e7fc32d8fa8ddcbbe2683266c30ae3b925d.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_cdclk_logical() helper to avoid looking at struct
intel_cdclk_state internals outside of intel_cdclk.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/e965667550e82307341d6abbeedc67b93cae9fc6.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
With all the code touching struct intel_bw_state moved inside
intel_bw.c, we move the struct definition there too, and make the type
opaque. to_intel_bw_state() needs to be turned into a proper
function. All of this nicely reduces includes from intel_bw.h.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/743ba67e4e3c5dac4f5e58ab4d2357edea601d09.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_bw_qgv_point_peakbw() helper to avoid looking at struct
intel_bw_state internals outside of intel_bw.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/49a723e0f23e06a6045f8f9e0d06648a6bc899c7.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Prefer only looking at struct intel_bw_state internals inside
intel_bw.c. To that effect, move icl_sagv_{pre,post}_plane_update()
there.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/dedcbeb3389ecd50195aa37de75e9992fae5d197.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_bw_can_enable_sagv()
Prefer only looking at struct intel_bw_state internals inside
intel_bw.c. To that effect, move intel_can_enable_sagv() there, and
rename to intel_bw_can_enable_sagv() to have consistent naming.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/dd6e3857bd1343c07a36826e99c1c04f7dd5ddb5.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_bw_pmdemand_needs_update() helper to avoid looking at struct
intel_bw_state internals outside of intel_bw.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/163fda39da2e1cf0f0c4fcb9c71103c98863179e.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
With all the code touching struct intel_dbuf_state moved inside
skl_watermark.c, we move the struct definition there too, and make the
type opaque. This nicely reduces includes from skl_watermark.h.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/83ae5f022a1d6d83c031e5c079b04dc739102565.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_dbuf_num_enabled_slices() and intel_dbuf_num_active_pipes()
helpers to avoid looking at struct intel_dbuf_state internals outside of
skl_watermark.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/7d555e7b4e93632b732b8b5a3cd4076baf781bee.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_dbuf_pmdemand_needs_update() helper to avoid looking at struct
intel_dbuf_state internals outside of skl_watermark.c.
With this, we can also move to_intel_dbuf_state(),
intel_atomic_get_old_dbuf_state(), and intel_atomic_get_new_dbuf_state()
inside skl_watermark.c.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/b493f259d0d3db047151fee18d7e801ad469fa88.1750847509.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
DISPLAY_PLANE_FLIP_PENDING() has been unused since commit fd3a40242e87
("drm/i915: Rip out legacy page_flip completion/irq handling"). Remove.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250625132140.1564473-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
While doing voltage swing for type-c phy
for DP 1.62 and HDMI write the
LOADGEN_SHARING_PMD_DISABLE bit to 1.
-v2: Update commit.
Add bspec[Suraj]
-v3: Move w/a before DKL_TX_PMD_LANE_SUS.
Use DKL_TX_DPCNTL2[Ville]
-v4: Use intel_encoder_is_dp and
intel_encoder_is_hdmi. [Suraj]
Bspec: 55359
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250625074911.194085-1-nemesa.garg@intel.com
|
|
Allocate and register drm_panel to allow the panel_follower framework to
detect the eDP panel and pass drm_connector::kdev device to drm_panel
allocation for matching.
Call drm_panel_prepare/unprepare in ddi_enable for eDP to allow the
followers to get notified of the panel power state changes.
Note: This is for eDP with DDI platforms only.
v2: remove backlight setup from panel_register (Jani)
v3: Updated the commit message (Jani)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250624-edp_panel-v3-1-e8197b6d9fde@intel.com
|