| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SINK_COUNT_ESI read
Due to a problem in the iTBT DP-in adapter's firmware the sink on a TBT
link may get disconnected inadvertently if the SINK_COUNT_ESI and the
DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers are read in a single AUX
transaction. Work around the issue by reading these registers in
separate transactions.
The issue affects MTL+ platforms and will be fixed in the DP-in adapter
firmware, however releasing that firmware fix may take some time and is
not guaranteed to be available for all systems. Based on this apply the
workaround on affected platforms.
See HSD #13013007775.
v2: Cc'ing Mika Westerberg.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13760
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14147
Cc: Mika Westerberg <[email protected]>
Cc: [email protected]
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
(cherry picked from commit c3a48363cf1f76147088b1adb518136ac5df86a0)
Signed-off-by: Joonas Lahtinen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PTL XELPDP_PORT_CLOCK_CTL register XELPDP_DDI_CLOCK_SELECT field's
size is 5 bits vs. the earlier platforms where its size is 4 bits. Make
sure the field is read-out/programmed everywhere correctly, according to
the above.
Cc: Mika Kahola <[email protected]>
Cc: [email protected] # v6.13+
Tested-by: Mika Kahola <[email protected]>
Reviewed-by: Mika Kahola <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
(cherry picked from commit d0bf684bd42db22e7d131a038f8f78927fa6a72a)
Signed-off-by: Joonas Lahtinen <[email protected]>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://gitlab.freedesktop.org/drm/nova into drm-next
Nova changes for v6.16
auxiliary:
- bus abstractions
- implementation for driver registration
- add sample driver
drm:
- implement __drm_dev_alloc()
- DRM core infrastructure Rust abstractions
- device, driver and registration
- DRM IOCTL
- DRM File
- GEM object
- IntoGEMObject rework
- generically implement AlwaysRefCounted through IntoGEMObject
- refactor unsound from_gem_obj() into as_ref()
- refactor into_gem_obj() into as_raw()
driver-core:
- merge topic/device-context-2025-04-17 from driver-core tree
- implement Devres::access()
- fix: doctest build under `!CONFIG_PCI`
- accessor for Device::parent()
- fix: conditionally expect `dead_code` for `parent()`
- impl TryFrom<&Device> bus devices (PCI, platform)
nova-core:
- remove completed Vec extentions from task list
- register auxiliary device for nova-drm
- derive useful traits for Chipset
- add missing GA100 chipset
- take &Device<Bound> in Gpu::new()
- infrastructure to generate register definitions
- fix register layout of NV_PMC_BOOT_0
- move Firmware into own (Rust) module
- fix: select AUXILIARY_BUS
nova-drm:
- initial driver skeleton (depends on drm and auxiliary bus
abstractions)
- fix: select AUXILIARY_BUS
Rust (dependencies):
- implement Opaque::zeroed()
- implement Revocable::try_access_with()
- implement Revocable::access()
From: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/aCxAf3RqQAXLDhAj@cassiopeiae
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_DRM) unless
another driver happens to do it for us.
Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_CORE) unless
another driver happens to do it for us.
Fixes: e041d81a0377 ("gpu: nova-core: register auxiliary device for nova-drm")
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We will extend the firmware methods, so move it to its own module
instead to keep gpu.rs focused.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Don't require a bound device, remove pub visibility from Firmware
fields, use FIRMWARE_VERSION consistently. - Danilo ]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The layout of NV_PMC_BOOT_0 has two small issues:
- The "chipset" field, while useful to identify a chip, is actually an
aggregate of two distinct fields named "architecture" and
"implementation".
- The "architecture" field is split, with its MSB being at a different
location than the rest of its bits.
Redefine the register layout to match its actual definition as provided
by OpenRM and expose the fully-constructed "architecture" field through
our own "Architecture" type. The "chipset" pseudo-field is also useful
to have, so keep providing it.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Use Result from kernel::prelude. - Danilo ]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the register!() macro, which defines a given register's layout and
provide bit-field accessors with a way to convert them to a given type.
This macro will allow us to make clear definitions of the registers and
manipulate their fields safely.
The long-term goal is to eventually move it to the kernel crate so it
can be used by other drivers as well, but it was agreed to first land it
into nova-core and make it mature there.
To illustrate its usage, use it to define the layout for the Boot0
(renamed to NV_PMC_BOOT_0 to match OpenRM's naming scheme) and take
advantage of its accessors.
Suggested-by: Danilo Krummrich <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Fix typo in commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We will need to perform things like allocating DMA memory during device
creation, so make sure to take the device context that will allow us to
perform these actions. This also allows us to use Devres::access to
obtain the BAR without holding a RCU lock.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
linux-firmware contains a directory for GA100, and it is a defined
chipset in Nouveau.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We will commonly need to compare chipset versions, so derive the
ordering traits to make that possible. Also derive Copy and Clone since
passing Chipset by value will be more efficient than by reference.
Signed-off-by: Alexandre Courbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the initial nova-drm driver skeleton.
nova-drm is connected to nova-core through the auxiliary bus and
implements the DRM parts of the nova driver stack.
For now, it implements the fundamental DRM abstractions, i.e. creates a
DRM device and registers it, exposing a three sample IOCTLs.
DRM_IOCTL_NOVA_GETPARAM
- provides the PCI bar size from the bar that maps the GPUs VRAM
from nova-core
DRM_IOCTL_NOVA_GEM_CREATE
- creates a new dummy DRM GEM object and returns a handle
DRM_IOCTL_NOVA_GEM_INFO
- provides metadata for the DRM GEM object behind a given handle
I implemented a small userspace test suite [1] that utilizes this
interface.
Link: https://gitlab.freedesktop.org/dakr/drm-test [1]
Reviewed-by: Maxime Ripard <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Kconfig: depend on DRM=y rather than just DRM. - Danilo ]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Register an auxiliary device for nova-drm.
For now always use zero for the auxiliary device's ID; we don't use it
yet anyways. However, once it lands, we should switch to XArray.
Acked-by: Dave Airlie <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the Rust DRM device abstraction we need to allocate a struct
drm_device.
Currently, there are two options, the deprecated drm_dev_alloc() (which
does not support subclassing) and devm_drm_dev_alloc(). The latter
supports subclassing, but also manages the initial reference through
devres for the parent device.
In Rust we want to conform with the subclassing pattern, but do not want
to get the initial reference managed for us, since Rust has its own,
idiomatic ways to properly deal with it.
There are two options to achieve this.
1) Allocate the memory ourselves with a KBox.
2) Implement __drm_dev_alloc(), which supports subclassing, but is
unmanged.
While (1) would be possible, it would be cumbersome, since it would
require exporting drm_dev_init() and drmm_add_final_kfree().
Hence, go with option (2) and implement __drm_dev_alloc().
Reviewed-by: Maxime Ripard <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
https://gitlab.freedesktop.org/drm/msm into drm-next
Updates for v6.16
CI:
- uprev mesa
GPU:
- ACD (Adaptive Clock Distribution) support for X1-85. This is required
enable the higher frequencies.
- Drop fictional `address_space_size`. For some older devices, the address
space size is limited to 4GB to avoid potential 64b rollover math problems
in the fw. For these, an `ADRENO_QUIRK_4GB_VA` quirk is added. For
everyone else we get the address space size from the SMMU `ias` (input
address sizes), which is usually 48b.
- Improve robustness when GMU HFI responses time out
- Fix crash when throttling GPU immediately during boot
- Fix for rgb565_predicator on Adreno 7c3
- Remove `MODULE_FIRMWARE()`s for GPU, the GPU can load the firmware after
probe and having partial set of fw (ie. sqe+gmu but not zap) causes problems
MDSS:
- Added SAR2130P support to MDSS driver
DPU:
- Changed to use single CTL path for flushing on DPU 5.x+
- Improved SSPP allocation code to allow sharing of SSPP between planes
- Enabled SmartDMA on SM8150, SC8180X, SC8280XP, SM8550
- Added SAR2130P support
- Disabled DSC support on MSM8937, MSM8917, MSM8953, SDM660
- Misc fixes
DP:
- Switch to use new helpers for DP Audio / HDMI codec handling
- Fixed LTTPR handling
DSI:
- Added support for SA8775P
- Added SAR2130P support
MDP4:
- Fixed LCDC / LVDS controller on
HDMI:
- Switched to use new helpers for ACR data
- Fixed old standing issue of HPD not working in some cases
Signed-off-by: Dave Airlie <[email protected]>
From: Rob Clark <[email protected]>
Link: https://lore.kernel.org/r/CAF6AEGv2Go+nseaEwRgeZbecet-h+Pf2oBKw1CobCF01xu2XVg@mail.gmail.com
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
DisplayPort requires per-segment link training when LTTPR are switched
to non-transparent mode, starting with LTTPR closest to the source.
Only when each segment is trained individually, source can link train
to sink.
Implement per-segment link traning when LTTPR(s) are detected, to
support external docking stations. On higher level, changes are:
* Pass phy being trained down to all required helpers
* Run CR, EQ link training per phy
* Set voltage swing, pre-emphasis levels per phy
Since at least some LTTPRs (eg. Parade PS8830) do not correctly report
voltage-swing, pre-emphasis level 3 support, always assume level 3 is
supported. This is permitted under DP 2.1(a) section 3.6.7.2 stating
that LTTPR shall set its transmitter levels as close as possible to
those requested by the DPTX, if the DPTX sets the voltage swing or
pre-emphasis to a level that the LTTPR does not support. It shall be
noted that LTTPR’s level choosing is implementation-specific.
This ensures successful link training both when connected directly to
the monitor (single LTTPR onboard most X1E laptops) and via the docking
station (at least two LTTPRs).
Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Tested-by: Jessica Zhang <[email protected]> # SA8775P
Tested-by: Johan Hovold <[email protected]>
Tested-by: Rob Clark <[email protected]>
Tested-by: Stefan Schmidt <[email protected]>
Signed-off-by: Aleksandrs Vinarskis <[email protected]>
Reviewed-by: Abel Vesa <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/652305/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per-segment link training requires knowing the number of LTTPRs
(if any) present. Store the count during LTTPRs' initialization.
Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Aleksandrs Vinarskis <[email protected]>
Tested-by: Jessica Zhang <[email protected]> # SA8775P
Tested-by: Johan Hovold <[email protected]>
Tested-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/652306/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Take into account LTTPR capabilities when selecting maximum allowed
link rate, number of data lines.
Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Aleksandrs Vinarskis <[email protected]>
Tested-by: Jessica Zhang <[email protected]> # SA8775P
Tested-by: Johan Hovold <[email protected]>
Tested-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/652302/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Initialize LTTPR before msm_dp_panel_read_sink_caps, as DPTX shall
(re)read DPRX caps after LTTPR detection, as required by DP 2.1a,
Section 3.6.7.6.1.
Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abhinav Kumar <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Aleksandrs Vinarskis <[email protected]>
Tested-by: Jessica Zhang <[email protected]> # SA8775P
Tested-by: Johan Hovold <[email protected]>
Tested-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/652301/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Follow the changes in the commit a2649952f66e ("drm/msm/dpu: remove
DPU_CTL_SPLIT_DISPLAY from CTL blocks on DPU >= 5.0") and remove
DPU_CTL_SPLIT_DISPLAY from the CTL blocks on the SAR2130P platform.
Single CTL is used for all interfaces used by a single path
Fixes: 178575173472 ("drm/msm/dpu: add catalog entry for SAR2130P")
Reviewed-by: Marijn Suijten <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651883/
Link: https://lore.kernel.org/r/20250506-dpu-sar2130p-no-split-display-v1-1-b619c0fddea5@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MDSS/MDP v12 comes with new bits in flush registers (e.g.
MDP_CTL_0_FLUSH) for Layer Mixer 6 and 7.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651260/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add IDs for new blocks present in MDSS/MDP v12 for LM, DSC, PINGPONG and
MERGE_3D blocks.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651262/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Drop comments about SoC before each 'struct dpu_lm_sub_blks' for given
SoC because it's duplicating the actual name of structure.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651251/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before blend setup, all existing blend stages are cleared, so shall be
active fetch pipes.
Fixes: b3652e87c03c ("drm/msm/disp/dpu1: add support to program fetch active in ctl path")
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651263/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Resetting entire CTL path should also include resetting active fetch
pipes.
Fixes: e1a950eec256 ("drm/msm/dpu: add reset_intf_cfg operation for dpu_hw_ctl")
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651252/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Resetting mixers should also include resetting active fetch pipes.
Fixes: ae4d721ce100 ("drm/msm/dpu: add an API to reset the encoder related hw blocks")
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651246/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The set_active_pipes() callback configures CTL_FETCH_PIPE_ACTIVE and
newer DPU v12.0 comes with CTL_PIPE_ACTIVE, thus rename it to
set_active_fetch_pipes() to better match the purpose.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651261/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The HDMI driver already has msm_hdmi_hpd_enable() and
msm_hdmi_hpd_disable() functions. Wire them into the
msm_hdmi_bridge_funcs, so that HPD can be enabled and disabled
dynamically rather than always having HPD events generation enabled.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The HDMI block needs to be enabled to properly generate HPD events. Make
sure it is not turned off in the disable paths if HPD delivery is enabled.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651722/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Expand the HDMI_CFG() macro in HDMI config description. It has no added
value other than hiding some boilerplate declarations.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651724/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As these clocks are now used in the runtime PM callbacks, they have no
connection to 'HPD'. Rename corresponding fields to follow clocks
purpose, to power up the HDMI controller.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651720/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is completely not obvious, but the so-called 'hpd' clocks and
regulators are required for the HDMI host to function properly. Merge
pwr and hpd regulators. Use regulators, clocks and pinctrl to implement
proper runtime PM callbacks.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651715/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We must be sure that the HDMI controller is powered on, while performing
the DDC transfer. Add corresponding runtime PM calls to
msm_hdmi_i2c_xfer().
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651727/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The pm_runtime_get_sync() function is a bad choise for runtime power
management. Switch HDMI driver to pm_runtime_resume_and_get() and add
proper error handling, while we are at it.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651713/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The last platform using legacy clock names for HDMI block (APQ8064)
switched to new clock names in 5.16. It's time to stop caring about old
DT, drop hand-coded helpers and switch to clk_bulk_* API.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651716/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The only clock which has frequency being set through hpd_freqs is the
"core" aka MDSS_HDMI_CLK clock. It always has the specified frequency,
so we can drop corresponding clk_set_rate() call together with the
hpd_freq infrastructure.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651717/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the extp being the only "power" clock left, remove the surrounding
loops and handle the extp clock directly.
Reviewed-by: Jessica Zhang <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651710/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
According to the vendor kernel [1] , the alt_iface clock should be
enabled together with the rest of HPD clocks, to make HPD to work
properly.
[1] https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/commit/e07a5487e521e57f76083c0a6e2f995414ac6d03
Reviewed-by: Jessica Zhang <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651709/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As a preparation to the next patches convert 'static const char *'
arrays to 'static const char * const', as required by the checkpatch.pl
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Jessica Zhang <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651705/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The driver handles the case where gpu fw is not in the initrd. OTOH it
doesn't always handle the case where _some_ fw is in the initrd, but
others are not. In particular the zap fw tends to be signed with an OEM
specific key, so the paths/names differ across devices with the same
SoC/GPU, so we cannot sanely list them with MODULE_FIRMWARE().
So MODULE_FIRMWARE() just ends up causing problems without actually
solving anything. Remove them!
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/652195/
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This feature is supposed to be enabled with UBWC v4 or later.
Implementations of this SKU feature an effective UBWC version of 3, so
disable it, in line with the BSP kernel.
Reported-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Akhil P Oommen <[email protected]>
Fixes: 192f4ee3e408 ("drm/msm/a6xx: Add support for Adreno 7c Gen 3 gpu")
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651759/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a module param to disable ACD which will help to quickly rule it
out for any GPU issues.
Signed-off-by: Akhil P Oommen <[email protected]>
Tested-by: Maya Matuszczyk <[email protected]>
Tested-by: Anthony Ruhier <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/649349/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix the following for qmp_get() errors:
1. Correctly handle probe defer for A6x GPUs
2. Ignore other errors because those are okay when GPU ACD is
not required. They are checked again during gpu acd probe.
Signed-off-by: Akhil P Oommen <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Tested-by: Maya Matuszczyk <[email protected]>
Tested-by: Anthony Ruhier <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/649346/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When ACD feature is enabled, it triggers some internal calibrations
which result in a pretty long delay during the first HFI perf vote.
So, increase the HFI response timeout to match the downstream driver.
Signed-off-by: Akhil P Oommen <[email protected]>
Tested-by: Maya Matuszczyk <[email protected]>
Tested-by: Anthony Ruhier <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/649344/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ACD a.k.a Adaptive Clock Distribution is a feature which helps to reduce
the power consumption. In some chipsets, it is also a requirement to
support higher GPU frequencies. This patch adds support for GPU ACD by
sending necessary data to GMU and AOSS. The feature support for the
chipset is detected based on devicetree data.
Signed-off-by: Akhil P Oommen <[email protected]>
Tested-by: Maya Matuszczyk <[email protected]>
Tested-by: Anthony Ruhier <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/649342/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Really the only purpose of this was to limit the address space size to
4GB to avoid 32b rollover problems in 64b pointer math in older sqe fw.
So replace the address_space_size with a quirk limiting the address
space to 4GB. In all other cases, use the SMMU input address size (IAS)
to determine the address space size.
v2: Properly account for vm_start
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/649467/
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the GMU takes too long to respond to an HFI message, we may return
early. If the GMU does eventually respond, and then we send a second
message, we will see the response for the first, throw another error,
and keep going. But we don't currently wait for the interrupt from the
GMU again, so if the second response isn't there immediately we may
prematurely return. This can cause a continuous cycle of missed HFI
messages, and for reasons I don't quite understand the GMU does not shut
down properly when this happens.
Fix this by waiting for the GMU interrupt when we see an empty queue. If
the GMU never responds then the queue really is empty and we quit. We
can't wait for the interrupt when we see a wrong response seqnum because
the GMU might have already queued both responses by the time we clear
the interrupt the first time so we do need to check the queue before
waiting on the interrupt again.
Signed-off-by: Connor Abbott <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/650013/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:
Unable to handle kernel paging request at virtual address 0000000000014110
pc : a6xx_gpu_busy+0x1c/0x58 [msm]
lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
Call trace:
a6xx_gpu_busy+0x1c/0x58 [msm] (P)
devfreq_simple_ondemand_func+0x3c/0x150
devfreq_update_target+0x44/0xd8
qos_max_notifier_call+0x30/0x84
blocking_notifier_call_chain+0x6c/0xa0
pm_qos_update_target+0xd0/0x110
freq_qos_apply+0x3c/0x74
apply_constraint+0x88/0x148
__dev_pm_qos_update_request+0x7c/0xcc
dev_pm_qos_update_request+0x38/0x5c
devfreq_cooling_set_cur_state+0x98/0xf0
__thermal_cdev_update+0x64/0xb4
thermal_cdev_update+0x4c/0x58
step_wise_manage+0x1f0/0x318
__thermal_zone_device_update+0x278/0x424
__thermal_cooling_device_register+0x2bc/0x308
thermal_of_cooling_device_register+0x10/0x1c
of_devfreq_cooling_register_power+0x240/0x2bc
of_devfreq_cooling_register+0x14/0x20
msm_devfreq_init+0xc4/0x1a0 [msm]
msm_gpu_init+0x304/0x574 [msm]
adreno_gpu_init+0x1c4/0x2e0 [msm]
a6xx_gpu_init+0x5c8/0x9c8 [msm]
adreno_bind+0x2a8/0x33c [msm]
...
At this point we haven't initialized the GMU at all yet, so we cannot read
the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag
accordingly. This means the df->suspended flag does not match the actual
devfreq state after initialization and msm_devfreq_get_dev_status() will
end up accessing GMU registers, causing the crash.
Fix this by setting df->suspended correctly during initialization.
Cc: [email protected]
Fixes: 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy")
Signed-off-by: Stephan Gerhold <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/650772/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current s3cp implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use curl. Uprev mesa [1][2] to adapt these
changes. Also replace broken s3cp command with a curl wrapper call in
drm-ci.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244
Signed-off-by: Vignesh Raman <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/645597/
Signed-off-by: Rob Clark <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add DSI Controller v2.5.1 support for SA8775P SoC.
Signed-off-by: Ayushi Makhija <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/651433/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
|
