The msm_gem_get_vaddr() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 6a8bd08d0465 ("drm/msm: add sudo flag to submit ioctl")
Signed-off-by: Gaosheng Cui
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
1 file changed, 1 in
The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
1 file
v2:
- I'm sorry I missed some emails, these patches were submitted last year,
now let me resend it with the following changes:
1. remove the patch: "drm/msm: Fix IS_ERR_OR_NULL() vs NULL check in
msm_icc_get()"
2. remove the patch: "drm/vc4: kms: Fix IS_ERR() vs NULL check for vc4_kms"
3.
The mipi_dsi_device_register_full() returns an ERR_PTR() on failure,
we should use IS_ERR() to check the return value.
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 2 +-
1 fi
On 2023-07-12 09:53, Christian König wrote:
> Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
>> Hello Maxime,
>>
>> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
>>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> Background is that this makes merge conflict
On 11/10/2022 1:44 AM, Gaosheng Cui wrote:
The msm_gem_get_vaddr() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 6a8bd08d0465 ("drm/msm: add sudo flag to submit ioctl")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
From: Rob Clark
In an error path where the submit is free'd without the job being run,
the hw_fence pointer is simply a kzalloc'd block of memory. In this
case we should just kfree() it, rather than trying to decrement it's
reference count. Fortunately we can tell that this is the case by
check
On 12/07/2023 04:20, Abhinav Kumar wrote:
dpu_hw_intf has a few instances of structs which do not have
the dpu_hw prefix. Lets fix this by renaming those structs
and updating the usage of those accordingly.
Signed-off-by: Abhinav Kumar
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 18 +
On 12/07/2023 04:20, Abhinav Kumar wrote:
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
changes in v5:
This function does nothing, just clears one struct field. Drop it now.
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 10 --
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
The dev_pm_opp_set_rate() already contains a call for clk_round_rate for
the passed value. Stop calling it manually from
_dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it
this way, as we should round the final calculated clock rate rather than
rounding all the intermediate val
Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
are not used by the code.
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 --
dpu_core_perf.c contains several multi-line conditions which are hard to
comprehent because of the indentation. Rework the identation of these
conditions to make it easier to understand them.
Reviewed-by: Abhinav Kumar
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm
dpu_core_perf should not make decisions on the maximum possible core
clock rate. Pass the value from dpu_kms_hw_init().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 11 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 ++--
drivers/gpu/drm
Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
full-featured catalog data.
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 73 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 +-
drivers/
The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argument useless. Remove it completely.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 ++--
Skip bandwidth aggregation and return early if there are no interconnect
paths defined for the DPU device.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_c
The values in struct dpu_core_perf_tune are fixed per the core perf
mode. Drop the 'tune' values and substitute them with known values when
performing perf management.
Note: min_bus_vote was not used at all, so it is just silently dropped.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm
Drop the leftover of bus-client -> interconnect conversion, the enum
dpu_core_perf_data_bus_id.
Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus
scaling")
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp
In preparation to refactoring the dpu_core_perf debugfs interface,
extract the bandwidth aggregation function from
_dpu_core_perf_crtc_update_bus().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 39 +++
1 file changed, 22 insertions(+), 17 de
Apply several cleanups to the DPU's core_perf module.
Changes since v3:
- Dropped avg_bw type change (Abhinav)
- Removed core_perf from the commit cubject (Abhinav)
Changes since v2:
- Dropped perf tuning patches for now (Abhinav)
- Restored kms variable assignment in dpu_core_perf_crtc_release_b
On 13/07/2023 01:02, Abhinav Kumar wrote:
On 7/12/2023 5:11 AM, Dmitry Baryshkov wrote:
The SM8550 platform employs newer UBWC decoder, which requires slightly
different programming.
Fixes: a2f33995c19d ("drm/msm: mdss: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
Reviewed-by:
On 7/12/2023 5:11 AM, Dmitry Baryshkov wrote:
The SM8550 platform employs newer UBWC decoder, which requires slightly
different programming.
Fixes: a2f33995c19d ("drm/msm: mdss: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Do we also need another fi
On 6/27/2023 1:14 PM, Marijn Suijten wrote:
The regulator setup was likely copied from other SoCs by mistake. Just
like SM6125 the DSI PHY on this platform is not getting power from a
regulator but from the MX power domain.
Fixes: 572e9fd6d14a ("drm/msm/dsi: Add phy configuration for QCM2290
On 7/7/2023 12:39 PM, Dmitry Baryshkov wrote:
The dev_pm_opp_set_rate() already contains a call for clk_round_rate for
the passed value. Stop calling it manually from
_dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it
this way, as we should round the final calculated clock
On 7/7/2023 12:39 PM, Dmitry Baryshkov wrote:
Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
are not used by the code.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
drivers/gpu/drm/msm/disp/dp
On 7/10/2023 7:34 PM, Dmitry Baryshkov wrote:
On 11/07/2023 05:31, Abhinav Kumar wrote:
On 7/7/2023 12:39 PM, Dmitry Baryshkov wrote:
The values in struct dpu_core_perf_tune are fixed per the core perf
mode. Drop the 'tune' values and substitute them with known values when
performing perf
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with t
On 12/07/2023 20:31, Sean Paul wrote:
>>> 216 struct drm_device *ddev
>>> 234 struct drm_device *drm_dev
>>> 611 struct drm_device *drm
>>>4190 struct drm_device *dev
>>>
>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>> it's not only me and others like th
On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula wrote:
>
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually
On 12/07/2023 14:11, Dmitry Baryshkov wrote:
> From: Konrad Dybcio
>
> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are
> other connection paths:
> - a path that connects rotator block to the DDR.
> - a path that needs to be handled to ensure MDSS register access
> function
On 7/9/23 03:03, Abhinav Kumar wrote:
On 7/7/2023 1:47 AM, Neil Armstrong wrote:
On 07/07/2023 09:18, Neil Armstrong wrote:
Hi,
On 06/07/2023 11:20, Amit Pundir wrote:
On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:
[Adding freedreno@ to cc list]
On Wed, 5 Jul 2023 at 08:31, Jagan
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit
On 12/07/2023 15:02, Amit Pundir wrote:
> Add and document the reserved memory region property
> in the qcom,sdm845-mdss schema.
>
> Signed-off-by: Amit Pundir
Please keep consistent versioning, so this is new patch in v4.
> ---
> .../devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml|
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
Background is that this makes merge conflicts easier to handle and detect.
Really?
FWIW, I agree with
On Wed, Jul 12, 2023 at 03:38:03PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > > Background is that this makes merge conflicts easier to handle and
> >
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > Background is that this makes merge conflicts easier to handle and detect.
> >
> > Really?
>
> FWIW, I agree with Christian here.
>
> > Each fil
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > Background is that this makes merge conflicts easier to handle and detect.
>
> Really?
FWIW, I agree with Christian here.
> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> unless I'm missing something
On 12/07/2023 16:02, Amit Pundir wrote:
Add and document the reserved memory region property
in the qcom,sdm845-mdss schema.
Signed-off-by: Amit Pundir
---
.../devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml| 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/dev
Adding a reserved memory region for the framebuffer memory
(the splash memory region set up by the bootloader).
Signed-off-by: Amit Pundir
---
v4: Re-sending this along with a new dt-bindings patch to
document memory-region property in qcom,sdm845-mdss
schema and keep dtbs_check happy.
v
Add and document the reserved memory region property
in the qcom,sdm845-mdss schema.
Signed-off-by: Amit Pundir
---
.../devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml| 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mds
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when thes
On 12.07.2023 13:07, Julia Lawall wrote:
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about s
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong
Hi Uwe,
On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
Well personally I usu
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device po
Hello Thomas,
On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > beca
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that nam
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when
Add support for the MDSS cfg-cpu bus vote on the SM8450 platform.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
ind
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects, from none to otherwise
inexplicable DSI timeouts.
Pro
As we are going to use MDSS data for DPU programming, populate missing
MDSS data. The UBWC 1.0 and no UBWC cases do not require MDSS
programming, so skip them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 21 +++--
1 file changed, 19 insertions(+), 2 delet
From: Konrad Dybcio
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are
other connection paths:
- a path that connects rotator block to the DDR.
- a path that needs to be handled to ensure MDSS register access
functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG
From: Konrad Dybcio
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DISPLAY_CFG path, rename
There are just two places where we set the bandwidth: in the resume and
in the suspend paths. Drop the wrapping function
msm_mdss_icc_request_bw() and call icc_set_bw() directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 19 ---
1 file changed, 8 insert
Stop using hand-written reset function for ICC release, use
devm_of_icc_get() instead.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm
The SM8550 platform employs newer UBWC decoder, which requires slightly
different programming.
Fixes: a2f33995c19d ("drm/msm: mdss: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(
Per agreement with Konrad, picked up this patch series.
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effect
Uwe Kleine-König writes:
[dropping some recipients since my SMTP server was complaining about the size]
> Hello Thomas,
>
> On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
>> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
>> > Hello,
>> >
>> > while I debugged an issue in the
On Mon, 03 Jul 2023 20:15:53 +0200, Konrad Dybcio wrote:
> Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator
> responsible for providing a reference voltage to some on-SoC IPs (like DSI
> or PHYs). It can be turned off when unused to save power.
>
> This series introduces
Prepare dropping the alias "dev" for struct drm_crtc::drm_dev. "drm_dev"
is the better name as "dev" is usually a struct device pointer.
No semantic changes.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
On Tue, 11 Jul 2023 15:42:28 -0700
Abhinav Kumar wrote:
> On 7/11/2023 3:19 PM, Dmitry Baryshkov wrote:
> > On 12/07/2023 01:07, Jessica Zhang wrote:
> >>
> >>
> >> On 7/10/2023 1:11 PM, Dmitry Baryshkov wrote:
> >>> On 10/07/2023 22:51, Jessica Zhang wrote:
>
>
> On 6/30/202
62 matches
Mail list logo
