Downstream driver appears to not support preemption on A510 target,
trying to use one make device slow and fill log with rings related errors.
Set num_rings to 1 to disable preemption.
Suggested-by: Dmitry Baryshkov
Fixes: e20c9284c8f2 ("drm/msm/adreno: Add support for Adreno 510 GPU")
Signed-off
On 9.03.2023 10:19, Neil Armstrong wrote:
> Add the Display Port controller subnode to the MDSS node.
>
> Signed-off-by: Neil Armstrong
> ---
[...]
> +
> + dp_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> +
On 9.03.2023 10:19, Neil Armstrong wrote:
> The QMP PHY is a USB3/DP combo phy, switch to the newly
> documented bindings and register the clocks to the GCC
> and DISPCC controllers.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
>
On 9.03.2023 10:19, Neil Armstrong wrote:
> Add the Display Port controller subnode to the MDSS node.
>
> Tested-by: Dmitry Baryshkov #SM8350-HDK
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Neil Armstrong
> ---
[...]
> + dp_opp_table: opp-table {
> +
On 9.03.2023 10:19, Neil Armstrong wrote:
> The first QMP PHY is an USB3/DP combo phy, switch to the newly
> documented bindings and register the clocks to the GCC
> and DISPCC controllers.
>
> Reviewed-by: Dmitry Baryshkov
> Tested-by: Dmitry Baryshkov #SM8350-HDK
> Signed-off-by: Neil Armst
On 3/14/2023 8:41 AM, Dmitry Baryshkov wrote:
On Tue, 14 Mar 2023 at 17:36, Dmitry Baryshkov
wrote:
It is possible to use multirect feature and split source to use the SSPP
to output two consecutive rectangles. This commit brings in this
capability to support wider screen resolutions.
Sign
Dne petek, 10. marec 2023 ob 15:47:05 CET je Rob Herring napisal(a):
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties. As
> part of this, convert of_get_property/of
On Tue, 14 Mar 2023 at 18:48, Abhinav Kumar wrote:
>
>
>
> On 3/14/2023 9:43 AM, Dmitry Baryshkov wrote:
> > On 14/03/2023 18:35, Abhinav Kumar wrote:
> >>
> >>
> >> On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote:
> >>> On 14/03/2023 07:08, Abhinav Kumar wrote:
>
>
> On 3/9/2023 4:57
Thanks Dmitry and Adam.
On 3/11/2023 3:09 PM, Dmitry Baryshkov wrote:
On 12/03/2023 00:52, Adam Ford wrote:
On Sat, Mar 11, 2023 at 4:42 PM Dmitry Baryshkov
wrote:
On 12/03/2023 00:40, Adam Ford wrote:
On Sat, Mar 11, 2023 at 4:02 PM Dmitry Baryshkov
wrote:
On 11/03/2023 23:53, Adam Ford
On 3/14/2023 9:43 AM, Dmitry Baryshkov wrote:
On 14/03/2023 18:35, Abhinav Kumar wrote:
On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote:
On 14/03/2023 07:08, Abhinav Kumar wrote:
On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote:
Enable SmartDMA features for the rest of the platforms where it i
On 14/03/2023 18:35, Abhinav Kumar wrote:
On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote:
On 14/03/2023 07:08, Abhinav Kumar wrote:
On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote:
Enable SmartDMA features for the rest of the platforms where it is
supposed to work.
Signed-off-by: Dmitry Baryshk
On 3/14/2023 1:20 AM, Colin Ian King wrote:
There is a spelling mistake in a drm_dbg_dp message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/m
On 3/14/2023 3:58 AM, Dmitry Baryshkov wrote:
On 14/03/2023 07:08, Abhinav Kumar wrote:
On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote:
Enable SmartDMA features for the rest of the platforms where it is
supposed to work.
Signed-off-by: Dmitry Baryshkov
I am so glad we split this. Without
On Tue, 14 Mar 2023 at 17:36, Dmitry Baryshkov
wrote:
>
> It is possible to use multirect feature and split source to use the SSPP
> to output two consecutive rectangles. This commit brings in this
> capability to support wider screen resolutions.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> driv
The code doesn't use dpu_caps::smart_dma_rev field. It checks if the
corresponding feature is enabled in the SSPP features. Drop the
smart_dma_rev field completely.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 13 -
Enable SmartDMA features for the rest of the platforms where it is
supposed to work.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 51 ---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ca
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these featur
From: Abhinav Kumar
After cleaning up the older multirect support the function
dpu_plane_validate_multirect_v2() is unused. Lets remove it.
Signed-off-by: Abhinav Kumar
[DB: also drop struct dpu_multirect_plane_states]
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plan
From: Abhinav Kumar
Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe()
as it will give the complete information of the sw_pipe as well.
Signed-off-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 in
Remove dpu_hw_fmt_layout instance from struct dpu_hw_sspp_cfg, leaving
only src_rect and dst_rect. This way all the pipes used by the plane
will have a common layout instance (as the framebuffer is shared between
them), while still keeping a separate src/dst rectangle configuration
for each pipe.
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enabling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw cat
It is possible to use multirect feature and split source to use the SSPP
to output two consecutive rectangles. This commit brings in this
capability to support wider screen resolutions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 19 +++-
drivers/gpu/drm/msm/
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
Rework _dpu_crtc_blend_setup_mixer() to split away pipe handling to a
separate functon. This is a preparation for the r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 79 +++-
1 file changed, 50 inserti
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
drivers/gpu/drm/msm/di
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 47 +--
1 file changed, 27 insertions(+), 2
Rework static color fill code to separate the pipe / pipe_cfg handling.
This is a preparation for the r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 69 +--
1 file changed, 40 insertions(+), 29 delet
The plane's clipped coordinates has already been validated against FB
size in the drm_atomic_plane_check(). There is no need to check them
again. Remove corresponding checks and inline dpu_plane_validate_src().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/d
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/driv
As struct dpu_hw_sspp_cfg describes only the source and destination
rectangles, it is a software pipe configuration now. Rename it
accordingly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_h
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 91 +
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 +++
Now as all accesses to pipe_cfg and pstate have been cleaned, add
struct dpu_hw_sspp_cfg to struct dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped rectangles,
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 9 ++
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshko
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22 deletions
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshk
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be statically allocated during boot).
The sspp point
Wrap SSPP and multirect index/mode into a single structure that
represents software view on the pipe used.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++-
drivers/gpu/drm/
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file changed,
Where feasible, use dpu_sw_pipe rather than a combo of dpu_hw_sspp and
multirect_index/_mode arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 59 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 46 +--
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms. We are going to break
the 1:1 correspondence between planes and SSPPs, so it makes no sense
anymore to create SSPP debugfs entries in dpu_plane.c
Reviewed-by: Abhinav Kumar
Signed
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().
Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.
Rev
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/
Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
drive
This patchset brings in multirect usage to support using two SSPP
rectangles for a single plane. Full virtual planes support is omitted
from this pull request, it will come later.
Abhinav, note, I removed your Tested-by tag for now, pending additional
verification from your side.
Changes since v5
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125
(trinket) and SM6225 (khaje). Trinket does not support speed binning
(only a single SKU exists) and we don't yet support khaje upstream.
Hence, add a fuse mapping table for bengal to allow for per-chip
frequency limiting.
Reviewed
Before transitioning to using per-SoC and not per-Adreno speedbin
fuse values (need another patchset to land elsewhere), a good
improvement/stopgap solution is to use adreno_is_aXYZ macros in
place of explicit revision matching. Do so to allow differentiating
between A619 and A619_holi.
Signed-off
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these SoCs
Adreno 619 expects some tunables to be set differently. Make up for it.
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
A619_holi is a GMU-less variant of the already-supported A619 GPU.
It's present on at least SM4350 (holi) and SM6375 (blair). No mesa
changes are required. Add the required kernel-side support for it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 42 +
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset lin
The GPU can only be one at a time. Turn a series of ifs into if +
elseifs to save some CPU cycles.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm
A610 and A619_holi don't support the feature. Disable it to make the GPU stop
crashing after almost each and every submission - the received data on
the GPU end was simply incomplete in garbled, resulting in almost nothing
being executed properly. Extend the disablement to adreno_has_gmu_wrapper,
a
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the associated GMUs. This is due to the fact that
the GMU directly pokes at RPMh. Sadly, this means we have to take care
of enabling & scaling power rails, clocks and bandwidth ourselves.
Reuse existing Adreno
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0. For GMU-equipped GPUs this is
done in a6xx_bus_clear_pending_transactions(), but for the GMU-less
ones we have to do it *somewhere*. Unhalting both side by side sounds
like a good plan and
Rename lower_bit to hbb_lo and explain what it signifies.
Add explanations (wherever possible to other tunables).
Port setting min_access_length, ubwc_mode and hbb_hi from downstream.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 39 +++
These two will be reused by at least A619_holi in the non-gmu
paths. Turn them non-static them to make it possible.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
2 files changed, 4 ins
The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
we'd normally assign to the GMU as if they were a part of the GMU, even
though they are not". It's a (good) software representation of the GMU_CX
and GMU_GX register spaces within the GPUSS that helps us programatically
treat thes
The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
we'd normally assign to the GMU as if they were a part of the GMU, even
though they are not". It's a (good) software representation of the GMU_CX
and GMU_GX register spaces within the GPUSS that helps us programatically
treat thes
lter any UBWC config values in [4/14]
- Do so for a619_holi in [8/14]
- Rebase on next-20230314 (shouldn't matter at all)
v3:
https://lore.kernel.org/r/20230223-topic-gmuwrapper-v3-0-5be55a336...@linaro.org
v2 -> v3:
New dependencies:
-
https://lore.kernel.org/linux-arm-msm/2023022
On Tue, 14 Mar 2023 13:13:39 +0100, Konrad Dybcio wrote:
> The qcom, prefix was missed previously. Fix it.
>
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
> strings for every current SoC")
> Acked-by: Rob Herring
> Reviewed-by: Marijn Suijten
> Signed-off-by: K
On 2023-03-14 14:04:41, Marijn Suijten wrote:
> On 2023-03-14 13:13:44, Konrad Dybcio wrote:
> > Now that the logic can handle multiple sets of registers, move
> > the QCM2290 to the common logic and mark it deprecated. This allows us
> > to remove a couple of structs, saving some memory.
> >
> >
On 2023-03-14 14:44:06, Konrad Dybcio wrote:
>
>
> On 14.03.2023 14:05, Marijn Suijten wrote:
> > On 2023-03-14 13:13:45, Konrad Dybcio wrote:
> >> Now that the only user is handled by common code, remove the option to
> >> specify custom handlers through match data.
> >>
> >> This is effectively
On 14.03.2023 14:05, Marijn Suijten wrote:
> On 2023-03-14 13:13:45, Konrad Dybcio wrote:
>> Now that the only user is handled by common code, remove the option to
>> specify custom handlers through match data.
>>
>> This is effectively a revert of commit:
>> 5ae15e76271 ("drm/msm/dsi: Allow to
On 2023-03-14 13:13:47, Konrad Dybcio wrote:
> Add a compatible for the DSI on SM6115.
>
> Acked-by: Rob Herring
> Signed-off-by: Konrad Dybcio
Example is nice and tidy now, thanks!
Reviewed-by: Marijn Suijten
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
>
On 2023-03-14 13:13:45, Konrad Dybcio wrote:
> Now that the only user is handled by common code, remove the option to
> specify custom handlers through match data.
>
> This is effectively a revert of commit:
> 5ae15e76271 ("drm/msm/dsi: Allow to specify dsi config as pdata")
>
> Reviewed-by: Dmit
On 2023-03-14 13:13:44, Konrad Dybcio wrote:
> Now that the logic can handle multiple sets of registers, move
> the QCM2290 to the common logic and mark it deprecated. This allows us
> to remove a couple of structs, saving some memory.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Konrad Dyb
On 2023-03-14 12:59:40, Konrad Dybcio wrote:
>
>
> On 14.03.2023 00:51, Marijn Suijten wrote:
> > On 2023-03-07 14:01:41, Konrad Dybcio wrote:
> >> Currently, we allow for MAX_DSI entries in io_start to facilitate for
> >> MAX_DSI number of DSI hosts at different addresses. The configuration
> >>
Use the non-deprecated, SoC-specific DSI compatible.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
b/arch/
Now that the logic can handle multiple sets of registers, move
the QCM2290 to the common logic and mark it deprecated. This allows us
to remove a couple of structs, saving some memory.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi.c | 5 +++--
d
Add a compatible for the DSI on SM6115.
Acked-by: Rob Herring
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
.../devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml | 10 --
2 files changed, 10 insertions(+), 2 deletions(-
Now that the only user is handled by common code, remove the option to
specify custom handlers through match data.
This is effectively a revert of commit:
5ae15e76271 ("drm/msm/dsi: Allow to specify dsi config as pdata")
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: K
The configs are identical, other than the number of *maximum* DSI
hosts allowed. This isn't an issue, unless somebody deliberately
tries to access the inexistent host by adding a dt node for it.
Remove the SC7180 struct and point the hw revision match to the
SDM845's one. On a note, this could hav
The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl"
alone. This however didn't quite work out and the property became
undocumented instead of deprecated. Fix that.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Review
Currently, we allow for MAX_DSI entries in io_start to facilitate for
MAX_DSI number of DSI hosts at different addresses. The configuration
is matched against the DSI CTRL hardware revision read back from the
component. We need a way to resolve situations where multiple SoCs
with different register
Some structs were defined multiple times for no apparent reason.
Deduplicate them.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 93 +--
1 file changed, 30 insertions(+), 63 del
In preparation for supporting multiple sets of possible base registers,
remove the num_dsi variable. We're comparing the io_start array contents
with the reg value from the DTS, so it will either match one of the
expected values or don't match against a zero (which we get from partial
array initial
The qcom, prefix was missed previously. Fix it.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Acked-by: Rob Herring
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/display/msm/dsi-cont
v3 -> v4:
- Use the shiny new compatible in the 6115 bindings example [9/10]
- Remove the leftover include and header definition [6, 7/10]
- Deduplicate the qcm2290 clks/regs in the common deduplication commit
instead of doing it separately
- Pick up tags
- Rebase on next-20230314 (nothing se
On 14.03.2023 01:03, Marijn Suijten wrote:
> On 2023-03-07 14:01:44, Konrad Dybcio wrote:
>> Now that the logic can handle multiple sets of registers, move
>> the QCM2290 to the common logic and mark it deprecated. This allows us
>> to remove a couple of structs, saving some memory.
>>
>> Review
On 14.03.2023 00:55, Marijn Suijten wrote:
> On 2023-03-07 14:01:42, Konrad Dybcio wrote:
>> Some structs were defined multiple times for no apparent reason.
>> Deduplicate them.
>>
>> Reviewed-by: Dmitry Baryshkov
>> Signed-off-by: Konrad Dybcio
>
> Seems a bit inconsistent to name some of t
On 14.03.2023 00:51, Marijn Suijten wrote:
> On 2023-03-07 14:01:41, Konrad Dybcio wrote:
>> Currently, we allow for MAX_DSI entries in io_start to facilitate for
>> MAX_DSI number of DSI hosts at different addresses. The configuration
>> is matched against the DSI CTRL hardware revision read ba
On Tue, 14 Mar 2023 at 12:23, Sankeerth Billakanti (QUIC)
wrote:
>
> Hi Dmitry,
>
>
> The eDP panel is identified and enumerated during probe of the
> panel-edp driver. The current DP driver triggers this panel-edp
> driver probe while getting the panel-bridge associated with t
On 14/03/2023 07:08, Abhinav Kumar wrote:
On 3/9/2023 4:57 PM, Dmitry Baryshkov wrote:
Enable SmartDMA features for the rest of the platforms where it is
supposed to work.
Signed-off-by: Dmitry Baryshkov
I am so glad we split this. Without visual validation check we wouldnt
have caught th
On 14.03.2023 01:18, Marijn Suijten wrote:
> On 2023-03-08 12:51:03, Rob Herring wrote:
>>
>> On Tue, 07 Mar 2023 14:01:47 +0100, Konrad Dybcio wrote:
>>> Add a compatible for the DSI on SM6115.
>>>
>>> Signed-off-by: Konrad Dybcio
>>> ---
>>> .../devicetree/bindings/display/msm/dsi-controller
On 14.03.2023 01:15, Marijn Suijten wrote:
> On 2023-03-07 14:01:46, Konrad Dybcio wrote:
>> The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl"
>> alone. This however didn't quite work out and the property became
>> undocumented instead of deprecated. Fix that.
>>
>> Fixes: 0
On 14.03.2023 01:07, Marijn Suijten wrote:
> On 2023-03-07 14:01:45, Konrad Dybcio wrote:
>> Now that the only user is handled by common code, remove the option to
>> specify custom handlers through match data.
>>
>> This is effectively a revert of commit:
>> 5ae15e76271 ("drm/msm/dsi: Allow to
> -Original Message-
> From: Vinod Polimera (QUIC)
> Sent: Thursday, March 2, 2023 10:03 PM
> To: dri-de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> freedreno@lists.freedesktop.org; devicet...@vger.kernel.org
> Cc: Vinod Polimera (QUIC) ; linux-
> ker...@vger.kernel.org;
Hi Dmitry,
The eDP panel is identified and enumerated during probe of the
panel-edp driver. The current DP driver triggers this panel-edp
driver probe while getting the panel-bridge associated with the eDP
panel from the platform driver bind. If the panel-edp probe is
There is a spelling mistake in a drm_dbg_dp message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/dp/dp_link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index 5a4817ac086f..42427129acea
92 matches
Mail list logo
