Add support for the Monolithic Power Systems MPM3695 family.
It contains four devices with suffixes: -10, -20, -25 and -100.
The device is PMBus compliant and shares characteristics with the
MPM82504.
MPM3695-25 has different VOLTAGE_SCALE_LOOP register size [11:0]
and therefore needs to have a separate compatible entry.
Tested with device tree based matching (MPM3695-10).
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Link: https://lore.kernel.org/r/20250511035701.2607947-6-paweldembicki@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the Monolithic Power Systems MPM82504 digital voltage
regulator. MPM82504 uses PMBus direct format for voltage output.
Tested with device tree based matching.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Link: https://lore.kernel.org/r/20250511035701.2607947-5-paweldembicki@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Implement support for setting the VOUT_SCALE_LOOP PMBus register
based on an optional device tree property
"mps,vout-fb-divider-ratio-permille".
This allows the driver to provide the correct VOUT value depending
on the feedback voltage divider configuration for chips where the
bootloader does not configure the VOUT_SCALE_LOOP register.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Link: https://lore.kernel.org/r/20250511035701.2607947-4-paweldembicki@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Refactor the driver to support multiple Monolithic Power Systems devices.
Introduce chip ID handling based on device tree matching.
No functional changes intended.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Link: https://lore.kernel.org/r/20250511035701.2607947-3-paweldembicki@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add device tree bindings for Monolithic Power Systems MPQ8785, MPM82504
and MPM3695 PMBus-compliant voltage regulators.
These bindings also documents the optional
"mps,vout-fb-divider-ratio-permille" property.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250511035701.2607947-2-paweldembicki@gmail.com
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Modify the calculation formula to adapt to different chips.
Signed-off-by: Wenliang Yan <wenliang202407@163.com>
Link: https://lore.kernel.org/r/20250506053741.4837-4-wenliang202407@163.com
[groeck: Fixed checkpatch issue (space before and after arithmetic operators)]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add structure ina238_config to store proprietary properties for different
chips to meet different chip adaptations
Signed-off-by: Wenliang Yan <wenliang202407@163.com>
Link: https://lore.kernel.org/r/20250506053741.4837-2-wenliang202407@163.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The MSM HDMI port nodes are missing any restrictions on additional
properties. The $ref should be to "/properties/port" rather than
"/$defs/port-base" as there are not additional properties in the nodes
to define.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/652299/
Link: https://lore.kernel.org/r/20250507215912.2748964-1-robh@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.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: 72d0af4acc ("drm/msm/dp: Add support for LTTPR handling")
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/652305/
Link: https://lore.kernel.org/r/20250507230113.14270-5-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Per-segment link training requires knowing the number of LTTPRs
(if any) present. Store the count during LTTPRs' initialization.
Fixes: 72d0af4acc ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/652306/
Link: https://lore.kernel.org/r/20250507230113.14270-4-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Take into account LTTPR capabilities when selecting maximum allowed
link rate, number of data lines.
Fixes: 72d0af4acc ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/652302/
Link: https://lore.kernel.org/r/20250507230113.14270-3-alex.vinarskis@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Follow the changes in the commit a2649952f6 ("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: 1785751734 ("drm/msm/dpu: add catalog entry for SAR2130P")
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
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 <dmitry.baryshkov@oss.qualcomm.com>
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 <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651251/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-11-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651261/
Link: https://lore.kernel.org/r/20250430-b4-sm8750-display-v5-7-8cab30c3e4df@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-13-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651715/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-9-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651713/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-7-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651716/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-6-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 <quic_jesszhan@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/651717/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-5-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The DE33 is a newer version of the Allwinner Display Engine IP block,
found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
supported by the mainline driver.
The DE33 in the H616 has mixer0 and writeback units. The clocks
and resets required are identical to the H3 and H5 respectively, so use
those existing structs for the H616 description.
There are two additional 32-bit registers (at offsets 0x24 and 0x28)
which require clearing and setting respectively to bring up the
hardware. The function of these registers is currently unknown, and the
values are taken from the out-of-tree driver.
Add the required clock description struct and compatible string to the
DE2 driver.
Signed-off-by: Ryan Walklin <ryan@testtoast.com>
Link: https://patch.msgid.link/20250511104042.24249-9-ryan@testtoast.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Allwinner H616 and variants have a new display engine revision
(DE33).
Add a clock binding for the DE33.
Signed-off-by: Ryan Walklin <ryan@testtoast.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://patch.msgid.link/20250511104042.24249-7-ryan@testtoast.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
When the binding was originally written, it was assumed that all
ax45mp-caches had the same properties etc. This has turned out to be
incorrect, as the QiLai SoC has a different number of cache-sets.
Add a specific compatible for the RZ/Five for property enforcement and
in case there turns out to be additional differences between these
implementations of the cache controller.
Acked-by: Ben Zong-You Xie <ben717@andestech.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Powering off RPU using force_pwrdwn call results in system failure
if there are multiple users of that RPU node. Better mechanism is to use
request_node and release_node EEMI calls. With use of these EEMI calls,
platform management controller will take-care of powering off RPU
when there is no user.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20250506165944.1109534-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
We don't need the configs that won't end up being used, such as
the "br" config for discrete devices, remove them. Also remove
the module firmware for test chips, that's never needed.
For now keep the iwl_dr_mac_cfg even if it's unused, we'll add
platforms with it once we have their PCI IDs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.15e2056ec40f.I75a6ce4ad0b14d2b4413615f05523a8f62f08954@changeid
Add iwl_trans_get_device_id() to extract the device ID
from the hw_id member in the iwl_trans structure.
hw_id member contains both sub-device ID and device ID,
with the device ID occupying bits 16 to 31.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.4411402701f2.I81cde20de05e3bb993977f8d4bbf90707819347f@changeid
Looks like these were never marked discrete, since they always
used the iwl_so_mac_cfg (earlier iwl_so_trans_cfg). Mark them
as discrete since they are.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
PerCI-Ready: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.f3a75ae80f28.I79964f4426389f04798b70841a9e847be48bf9c3@changeid
Now that it's all split into MAC and RF configs, remove
the matching on MAC type and step. If we ever need to do
something based on the MAC step, we'll have to find some
new mechanism (since the MAC type is known already from
the PCI IDs table, but not the step), or just handle the
(likely small) differences in code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.fca99a5ab315.Iae27b781221fd29845493adf2c29d9e4f7a9c33b@changeid
