drm/msm/dp: reset the link phy params before link training
Before re-starting link training reset the link phy params namely
the pre-emphasis and voltage swing levels otherwise the next
link training begins at the previously cached levels which can result
in link training failures.
drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()
For cases where the crtc's connectors_changed was set without enable/active
getting toggled , there is an atomic_enable() call followed by an
atomic_disable() but without an atomic_mode_set().
This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in
the atomic_enable() as the dpu_encoder's connector was cleared in the
atomic_disable() but not re-assigned as there was no atomic_mode_set() call.
Fix the NULL ptr access by moving the assignment for atomic_enable() and also
use drm_atomic_get_new_connector_for_encoder() to get the connector from
the atomic_state.
Abhinav Kumar [Mon, 5 Aug 2024 20:20:08 +0000 (13:20 -0700)]
drm/msm/dp: fix the max supported bpp logic
Fix the dp_panel_get_supported_bpp() API to return the minimum
supported bpp correctly for relevant cases and use this API
to correct the behavior of DP driver which hard-codes the max supported
bpp to 30.
This is incorrect because the number of lanes and max data rate
supported by the lanes need to be taken into account.
Replace the hardcoded limit with the appropriate math which accounts
for the accurate number of lanes and max data rate.
changes in v2:
- Fix the dp_panel_get_supported_bpp() and use it
- Drop the max_t usage as dp_panel_get_supported_bpp() already
returns the min_bpp correctly now
changes in v3:
- replace min_t with just min as all params are u32
DPU debugging macros need to be converted to a proper drm_debug_*
macros, however this is a going an intrusive patch, not suitable for a
fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER
to make sure that DPU debugging messages always end up in the drm debug
messages and are controlled via the usual drm.debug mask.
I don't think that it is a good idea for a generic DPU_DEBUG macro to be
tied to DRM_UT_KMS. It is used to report a debug message from driver, so by
default it should go to the DRM_UT_DRIVER channel. While refactoring
debug macros later on we might end up with particular messages going to
ATOMIC or KMS, but DRIVER should be the default.
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/601231/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Mon, 1 Jul 2024 21:32:14 +0000 (14:32 -0700)]
drm/msm/gem: Add missing rcu_dereference()
Fixes a sparse "different address spaces" error.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406280050.syeEwLTE-lkp@intel.com/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/601612/
Akhil P Oommen [Sat, 29 Jun 2024 01:49:36 +0000 (07:19 +0530)]
drm/msm/adreno: Introduce gmu_chipid for a740 & a750
To simplify, introduce the new gmu_chipid for a740 & a750 GPUs.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/601396/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Akhil P Oommen [Sat, 29 Jun 2024 01:49:35 +0000 (07:19 +0530)]
drm/msm/adreno: Add support for X185 GPU
Add support in drm/msm driver for the Adreno X185 gpu found in
Snapdragon X1 Elite chipset.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/601399/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Akhil P Oommen [Sat, 29 Jun 2024 01:49:34 +0000 (07:19 +0530)]
dt-bindings: display/msm/gmu: Add Adreno X185 GMU
Document Adreno X185 GMU in the dt-binding specification.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/601395/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Neil Armstrong [Wed, 26 Jun 2024 12:04:21 +0000 (14:04 +0200)]
drm/msm/adreno: fix a743 and a740 cx mem init
Disable the call to qcom_scm_gpu_init_regs() for a730 and a740
after init failures on the HDK8550 and HDK8450 platforms:
msm_dpu ae01000.display-controller: failed to load adreno gpu
msm_dpu ae01000.display-controller: failed to bind 3d00000.gpu (ops a3xx_ops [msm]): -5
msm_dpu ae01000.display-controller: adev bind failed: -5
While debugging, it happens the call to:
qcom_scm_gpu_init_regs(QCOM_SCM_GPU_ALWAYS_EN_REQ)
returns -5 and makes the gpu fail to initialize.
Remove the scm call since it's not done downstream either and
works fine without.
Fixes: 14b27d5df3ea ("drm/msm/a7xx: Initialize a750 "software fuse"") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/600972/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Tue, 25 Jun 2024 18:54:42 +0000 (20:54 +0200)]
Revert "drm/msm/a6xx: Poll for GBIF unhalt status in hw_init"
Commit f6ebff4fe810 ("drm/msm/adreno: De-spaghettify the use of memory
barriers") made some fixups relating to write arrival, ensuring that
the GPU's memory interface has *really really really* been told to come
out of reset. That in turn rendered the hacky commit being reverted no
longer necessary.
Get rid of it.
This reverts commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/600870/ Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Tue, 25 Jun 2024 18:54:41 +0000 (20:54 +0200)]
drm/msm/adreno: De-spaghettify the use of memory barriers
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.
Replace the barriers with a readback (or drop altogether where possible)
that ensures the previous writes have exited the write buffer (as the CPU
must flush the write to the register it's trying to read back).
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/600869/ Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
dt-bindings: display/msm/gpu: fix the schema being not applied
dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
given binding validation if the schema contains compatible list with
pattern and a const fallback. This leads to binding being a no-op - not
being applied at all. Issue should be fixed in the dtschema but for now
add a work-around do the binding can be used against DTS validation.
dt-bindings: display/msm/gpu: define reg-names in top-level
All devices should (and actually do) have same order of entries, if
possible. That's the case for reg/reg-names, so define the reg-names in
top-level to enforce that.
dt-bindings: display/msm/gpu: constrain clocks in top-level
We expect each schema with variable number of clocks, to have the widest
constrains in top-level "properties:". This is more readable and also
makes binding stricter, if there is no "if:then:" block for given
variant.
The frame event callback is always set to dpu_crtc_frame_event_cb() (or
to NULL) and the data is always either the CRTC itself or NULL
(correpondingly). Thus drop the event callback registration, call the
dpu_crtc_frame_event_cb() directly and gate on the dpu_enc->crtc
assigned using dpu_encoder_assign_crtc().
Daniil Titov [Sun, 23 Jun 2024 20:30:39 +0000 (22:30 +0200)]
drm/msm/dsi: Add phy configuration for MSM8937
Add phy configuration for 28nm dsi phy found on MSM8937 SoC. Only
difference from existing msm8916 configuration is number of phy
and io_start addresses.
CTLs on older qualcomm SOCs like msm8953 and msm8996 has not got interrupts,
so better to skip CTL irq callback register/unregister
make dpu_ctl_cfg be able to define without intr_start.
Rename dpu_hw_setup_vsync_source functions to make the names match the
implementation: on DPU 5.x the TOP only contains timer setup, while 3.x
and 4.x used MDP_VSYNC_SEL register to select TE source.
Dmitry Baryshkov [Thu, 13 Jun 2024 17:05:09 +0000 (20:05 +0300)]
drm/msm/dsi: parse vsync source from device tree
Allow board's device tree to specify the vsync source (aka TE source).
If the property is omitted, the display controller driver will use the
default setting.
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
[DB: fixed clearing of return value if there is no TE property] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Patchwork: https://patchwork.freedesktop.org/patch/598740/ Link: https://lore.kernel.org/r/20240613-dpu-handle-te-signal-v2-6-67a0116b5366@linaro.org
Dmitry Baryshkov [Thu, 13 Jun 2024 17:05:08 +0000 (20:05 +0300)]
drm/msm/dpu: rework vsync_source handling
The struct msm_display_info has is_te_using_watchdog_timer field which
is neither set anywhere nor is flexible enough to specify different
sources. Replace it with the field specifying the vsync source using
enum dpu_vsync_source.
Dmitry Baryshkov [Thu, 13 Jun 2024 17:05:07 +0000 (20:05 +0300)]
drm/msm/dpu: pull the is_cmd_mode out of _dpu_encoder_update_vsync_source()
Setting vsync source makes sense only for DSI CMD panels. Pull the
is_cmd_mode condition out of the function into the calling code, so that
it becomes more explicit.
Dmitry Baryshkov [Thu, 13 Jun 2024 17:05:04 +0000 (20:05 +0300)]
dt-bindings: display/msm/dsi: allow specifying TE source
Command mode panels provide TE signal back to the DSI host to signal
that the frame display has completed and update of the image will not
cause tearing. Usually it is connected to the first GPIO with the
mdp_vsync function, which is the default. In such case the property can
be skipped.
Abhinav Kumar [Thu, 20 Jun 2024 20:17:30 +0000 (13:17 -0700)]
drm/msm/dpu: drop validity checks for clear_pending_flush() ctl op
clear_pending_flush() ctl op is always assigned irrespective of the DPU
hardware revision. Hence there is no needed to check whether the op has
been assigned before calling it.
Drop the checks across the driver for clear_pending_flush() and also
update its documentation that it is always expected to be assigned.
changes in v2:
- instead of adding more validity checks just drop the one for clear_pending_flush
- update the documentation for clear_pending_flush() ctl op
- update the commit text reflecting these changes
changes in v3:
- simplify the documentation of clear_pending_flush
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/464fbd84-0d1c-43c3-a40b-31656ac06456@moroto.mountain/T/ Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/600241/ Link: https://lore.kernel.org/r/20240620201731.3694593-1-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Jonathan Marek [Thu, 30 May 2024 05:56:50 +0000 (13:56 +0800)]
drm/msm/dsi: add a comment to explain pkt_per_line encoding
Make it clear why the pkt_per_line value is being "divided by 2".
Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jun Nie <jun.nie@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/596236/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-6-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Jonathan Marek [Thu, 30 May 2024 05:56:49 +0000 (13:56 +0800)]
drm/msm/dsi: set VIDEO_COMPRESSION_MODE_CTRL_WC
Video mode DSC won't work if this field is not set correctly. Set it to fix
video mode DSC (for slice_per_pkt==1 cases at least).
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jun Nie <jun.nie@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/596234/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-5-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Jonathan Marek [Thu, 30 May 2024 05:56:48 +0000 (13:56 +0800)]
drm/msm/dsi: set video mode widebus enable bit when widebus is enabled
The value returned by msm_dsi_wide_bus_enabled() doesn't match what the
driver is doing in video mode. Fix that by actually enabling widebus for
video mode.
Fixes: efcbd6f9cdeb ("drm/msm/dsi: Enable widebus for DSI") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Jun Nie <jun.nie@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK
Patchwork: https://patchwork.freedesktop.org/patch/596232/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-4-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Jonathan Marek [Thu, 30 May 2024 05:56:45 +0000 (13:56 +0800)]
drm/msm/dpu: fix video mode DSC for DSI
Add width change in DPU timing for DSC compression case to work with
DSI video mode.
Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Jun Nie <jun.nie@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/596227/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-1-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/msm/a7xx: Add missing register writes from downstream
This isn't known to fix anything yet, but it's a good idea to add it.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/592043/ Signed-off-by: Rob Clark <robdclark@chromium.org>
On all Qualcomm platforms with a7xx GPUs, qcom_scm provides a method to
initialize cx_mem. Copy this from downstream (minus BCL which we
currently don't support). On a750, this includes a new "fuse" register
which can be used by qcom_scm to fuse off certain features like
raytracing in software. The fuse is default off, and is initialized by
calling the method. Afterwards we have to read it to find out which
features were enabled.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/592042/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Mon, 13 May 2024 15:51:47 +0000 (08:51 -0700)]
drm/msm: Add obj flags to gpu devcoredump
When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/593854/
Konrad Dybcio [Wed, 5 Jun 2024 20:10:15 +0000 (22:10 +0200)]
soc: qcom: smem: Add a feature code getter
Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely
identifying the specific SKU and the precise speed bin (in the general
meaning of this word, anyway): a pair of values called Product Code
and Feature Code.
Based on this information, we can deduce the available frequencies for
things such as Adreno. In the case of Adreno specifically, Pcode is
useless for non-prototype SoCs.
Introduce a getter for the feature code and export it.
Konrad Dybcio [Wed, 5 Jun 2024 20:10:14 +0000 (22:10 +0200)]
soc: qcom: Move some socinfo defines to the header
In preparation for parsing the chip "feature code" (FC) and "product
code" (PC) (essentially the parameters that let us conclusively
characterize the sillicon we're running on, including various speed
bins), move the socinfo version defines to the public header.
Abhinav Kumar [Wed, 5 Jun 2024 18:34:15 +0000 (11:34 -0700)]
drm/msm/a6xx: use __unused__ to fix compiler warnings for gen7_* includes
GCC diagnostic pragma method throws below warnings in some of the versions
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown
option after '#pragma GCC diagnostic' kind [-Wpragmas]
#pragma GCC diagnostic ignored "-Wunused-const-variable"
^
In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:18:0:
drivers/gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h:924:19: warning:
'gen7_0_0_external_core_regs' defined but not used [-Wunused-variable]
static const u32 *gen7_0_0_external_core_regs[] = {
^
In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:19:0:
drivers/gpu/drm/msm/adreno/adreno_gen7_2_0_snapshot.h:748:19: warning:
'gen7_2_0_external_core_regs' defined but not used [-Wunused-variable]
static const u32 *gen7_2_0_external_core_regs[] = {
^
In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:20:0:
drivers/gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h:1188:43: warning:
'gen7_9_0_sptp_clusters' defined but not used [-Wunused-variable]
static struct gen7_sptp_cluster_registers gen7_9_0_sptp_clusters[] = {
^
drivers/gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h:1438:19: warning:
'gen7_9_0_external_core_regs' defined but not used [-Wunused-variable]
static const u32 *gen7_9_0_external_core_regs[] = {
Remove GCC version dependency by using __unused__ for the unused gen7_* includes.
Changes in v2:
- Fix the warnings in the commit text
- Use __attribute((__unused__)) instead of local assignment
changes in v3:
- drop the Link from the auto add
changes in v4:
- replace __attribute((__unused__)) with __always_unused
Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx") Suggested-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/597265/
[Add gen7_9_0_cx_debugbus_blocks as well] Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Tue, 18 Jun 2024 16:42:51 +0000 (09:42 -0700)]
drm/msm/adreno: Move CP_PROTECT settings to hw catalog
Move the CP_PROTECT settings into the hw catalog.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/599731/
Rob Clark [Tue, 18 Jun 2024 16:42:50 +0000 (09:42 -0700)]
drm/msm/adreno: Move hwcg table into a6xx specific info
Introduce a6xx_info where we can stash gen specific stuff without
polluting the toplevel adreno_info struct.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/599728/
Rob Clark [Tue, 18 Jun 2024 16:42:49 +0000 (09:42 -0700)]
drm/msm/adreno: Move hwcg regs to a6xx hw catalog
Move the hwcg tables into the hw catalog.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/599727/
Rob Clark [Tue, 18 Jun 2024 16:42:48 +0000 (09:42 -0700)]
drm/msm/adreno: Split catalog into separate files
Split each gen's gpu table into it's own file. Only code-motion, no
functional change.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/599725/
Rob Clark [Tue, 18 Jun 2024 16:42:47 +0000 (09:42 -0700)]
drm/msm/adreno: Split up giant device table
Split into a separate table per generation, in preparation to move each
gen's device table to it's own file.
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/599723/
drm/bridge-connector: implement glue code for HDMI connector
In order to let bridge chains implement HDMI connector infrastructure,
add necessary glue code to the drm_bridge_connector. In case there is a
bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs
implementation.
Note, to simplify implementation, there can be only one bridge in a
chain that sets DRM_BRIDGE_OP_HDMI. Setting more than one is considered
an error. This limitation can be lifted later, if the need arises.
drm/bridge-connector: switch to using drmm allocations
Turn drm_bridge_connector to using drmm_kzalloc() and
drmm_connector_init() and drop the custom destroy function. The
drm_connector_unregister() and fwnode_handle_put() are already handled
by the drm_connector_cleanup() and so are safe to be dropped.
Add drm_atomic_helper_connector_hdmi_disable_audio_infoframe(), an API
to allow the driver disable sending the Audio Infoframe. This is to be
used by the drivers if setup of the infoframes is not tightly coupled
with the audio functionality and just disabling the audio playback
doesn't stop the HDMI hardware from sending the Infoframe.
drm/panel: raydium-rm67191: Don't call unprepare+disable at shutdown
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by IMX boards. The IMX driver appears to be
correctly calling drm_atomic_helper_shutdown() so we can remove the
calls.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
The conversion of the rm67191 panel driver follows many of the other
panel drivers but has a few differences that need to be called out.
Like in commit 1e0465eb16a4 ("drm/panel: otm8009a: Don't double check
prepared/enabled"), this panel also uses the "prepared" flag to
prevent the backlight functions from running when the panel is powered
off. This is probably not the safest thing to do but the old behavior
was preserved. See the discussion in the otm8009a patch. Because of
this, I've left the driver tracking "prepared" but removed its
tracking of "enabled".
NOTE: as part of this, transition the panel's direct calls to its
disable/unprepare functions in shutdown to call through DRM panel.
drm/panel: sharp-ls043t1le01: Don't call disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Qualcomm boards. The Qualcomm driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: sharp-lq101r1sx01: Don't call disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Tegra boards. The Tegra driver appears to
be correctly calling drm_atomic_helper_shutdown() so we can remove the
calls.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: seiko-43wvf1g: Don't call disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by IMX boards. As far as I can tell, all IMX
boards are now correctly calling drm_atomic_helper_shutdown() so we
can remove the calls.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: panasonic-vvx10f034n00: Don't call disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: jdi-lt070me05000: Don't call disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Qualcomm boards. The Qualcomm driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
NOTE: as part of this, transition the panel's direct calls to its
disable function in shutdown/remove to call through DRM panel.
drm/panel: tdo-tl070wsh30: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: osd-osd101t2587-53ts: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by TI OMAP boards. The OMAP driver appears
to be correctly calling drm_atomic_helper_shutdown() so we can remove
the calls.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: olimex-lcd-olinuxino: Don't call unprepare+disable at remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: khadas-ts050: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
drm/panel: boe-himax8279d: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
NOTE: as part of this, transition the panel's direct calls to its
disable/unprepare functions in shutdown/remove to call through DRM
panel.
The VFP, HBP, and HSA are divided between the available lanes if
there is more than one lane. For certain timings and lane
configurations, the HFP may not be evenly divisible. If the HFP
is rounded down, it ends up being too small which can cause some
monitors to not sync properly. In these instances, adjust htotal
and hsync to round the HFP up, and recalculate the htotal.
This allows 720P-60 to operation on an i.MX8MP with a four-lane
configuration.
Adam Ford [Sat, 1 Jun 2024 14:41:01 +0000 (09:41 -0500)]
drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
As noted by Frieder, there are descripencies between the reference
manuals of the Mini, Nano and Plus, so I reached out to my NXP
rep and got the following response regarding the varing notes
in the documentation.
"Yes it is definitely wrong, the one that is part of the NOTE in
MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
not correct. I will report this to Doc team, the one customer should
be take into account is the Table 13-40 DPHY PLL Parameters and the
Note above."
With this patch, the clock rates now match the values used in NXP's
downstream kernel.
Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Marek Vasut <marex@denx.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240601144103.198299-1-aford173@gmail.com
Marek Vasut [Fri, 31 May 2024 20:33:12 +0000 (22:33 +0200)]
drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ
Make sure the connector is fully initialized before signalling any
HPD events via drm_kms_helper_hotplug_event(), otherwise this may
lead to NULL pointer dereference.
Marek Vasut [Fri, 31 May 2024 20:32:01 +0000 (22:32 +0200)]
drm/bridge: tc358767: Fix comment in tc_edp_mode_valid
Fix comment copy-paste error in tc_edp_mode_valid(), this function
is validating DP/eDP clock, not DPI clock frequency. Update the
comment to match. No functional change.
projects / thirdparty / kernel / linux.git / log
