On 11.02.2023 14:17, Dmitry Baryshkov wrote:
> On 11/02/2023 13:51, 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 bac
On 11.02.2023 14:19, Dmitry Baryshkov wrote:
> On 11/02/2023 13:51, Konrad Dybcio wrote:
>> In preparation for supporting multiple sets of possible base registers,
>> Zero-terminate the array that contains them to remove the need of
>> specifying num_dsi for each set.
>>
>> Signed-off-by: Konrad
On 11.02.2023 14:26, Dmitry Baryshkov wrote:
> On 11/02/2023 13:51, Konrad Dybcio wrote:
>> Now that msm_dsi_config is ready to accept multiple sets of registers
>> (where array[n][idx] holds the base registers of DSI(idx) for the nth
>> entry), loop through all available configs to resolve hw v
On 11.02.2023 16:52, Dmitry Baryshkov wrote:
> On 11/02/2023 13:51, Konrad Dybcio wrote:
>> Some structs were defined multiple times for no apparent reason.
>> Deduplicate them.
>>
>> Fixes: 3f3c8aff1f8f ("drm/msm/dsi: Add configuration for 8x76")
>> Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 i
On 11.02.2023 16:52, Dmitry Baryshkov wrote:
> On 11/02/2023 13:51, Konrad Dybcio wrote:
>> 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.
>>
On 11.02.2023 18:00, Dmitry Baryshkov wrote:
> On 11/02/2023 14:26, Konrad Dybcio wrote:
>> These blocks are of variable length on different SoCs. Set the
>> correct values where I was able to retrieve it from downstream
>> DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
>> intf) ot
On 12/02/2023 00:12, Dmitry Baryshkov wrote:
QSEED4 is a newer variant of QSEED3LITE, which should be used on
sm8550. Fix the DPU caps structure and used feature masks.
I found nowhere SM8550 uses Qseed4, on downstream DT, it's written:
qcom,sde-qseed-sw-lib-rev = "qseedv3lite";
On 12.02.2023 00:12, Dmitry Baryshkov wrote:
> From: Konrad Dybcio
>
> These blocks are of variable length on different SoCs. Set the
> correct values where I was able to retrieve it from downstream
> DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
> intf) otherwise.
>
> Signed-o
This series will enable color features on sc7280 target which has
primary panel as eDP
The series removes DSPP allocation based on encoder type and allows
the DSPP reservation based on user request via CTM.
The series will release/reserve the dpu resources whenever there is
a CTM enable/disabl
Return immediately on failure, this will make dpu reservations
part look cleaner.
Signed-off-by: Kalyan Thota
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/d
Clear DSPP reservations from the global state during
rm release
Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
dpu driver")
Signed-off-by: Kalyan Thota
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 ++
1
Add DSPP blocks into the topology for reservation, if there
is a CTM request for that composition.
Signed-off-by: Kalyan Thota
Reviewed-by: Dmitry Baryshkov
---
Changes in v1:
- Minor nits (Dmitry)
Changes in v2:
- Populate DSPPs into the reservation only if CTM is requested (Dmitry)
---
drive
Allow modeset to be triggered during CTM enable/disable.
In the modeset callbacks, DPU resources required for the
CTM feature are managed appropriately.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/msm_atomic.c | 18 ++
drivers/gpu/drm/msm/msm_drv.c| 2 +-
drivers/gpu
On 2023-02-11 13:26:51, Konrad Dybcio wrote:
> These blocks are of variable length on different SoCs. Set the
> correct values where I was able to retrieve it from downstream
> DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
> intf) otherwise.
>
> Signed-off-by: Konrad Dybcio
> ---
>
On 11.02.2023 17:32, Dmitry Baryshkov wrote:
> On 11/02/2023 14:26, Konrad Dybcio wrote:
>> Add SM6350 support to the DPU1 driver to enable display output.
>>
>> Signed-off-by: Konrad Dybcio
>> Signed-off-by: Konrad Dybcio
>> ---
>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 187 +++
On 13/02/2023 12:41, Neil Armstrong wrote:
On 12/02/2023 00:12, Dmitry Baryshkov wrote:
QSEED4 is a newer variant of QSEED3LITE, which should be used on
sm8550. Fix the DPU caps structure and used feature masks.
I found nowhere SM8550 uses Qseed4, on downstream DT, it's written:
qcom,
On 11.02.2023 17:47, Dmitry Baryshkov wrote:
> On 11/02/2023 14:26, Konrad Dybcio wrote:
>> Add basic SM6375 support to the DPU1 driver to enable display output.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
In short, ack to all, thanks for prompt review.
Konrad
>> .../gpu/drm/msm/disp/dpu1/dpu_
On 13/02/2023 13:01, Konrad Dybcio wrote:
On 12.02.2023 00:12, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8 for sspp and 0x280 fo
On 2023-02-13 12:15:19, Konrad Dybcio wrote:
[...]
> >> @@ -1674,6 +1765,15 @@ static struct dpu_pingpong_cfg sc8280xp_pp[] = {
> >> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
> >> };
> >> +static struct dpu_pingpong_cfg sm6350_pp[] = {
> >> + PP_BLK("pingpong_0", PINGPONG_0, 0x7
On 13/02/2023 13:30, Marijn Suijten wrote:
On 2023-02-13 12:15:19, Konrad Dybcio wrote:
[...]
@@ -1674,6 +1765,15 @@ static struct dpu_pingpong_cfg sc8280xp_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
};
+static struct dpu_pingpong_cfg sm6350_pp[] = {
+ PP_BLK("ping
On 13/02/2023 13:12, Marijn Suijten wrote:
On 2023-02-11 13:26:51, Konrad Dybcio wrote:
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
intf) otherwise.
Sig
On 13/02/2023 11:18, Konrad Dybcio wrote:
On 11.02.2023 14:19, Dmitry Baryshkov wrote:
On 11/02/2023 13:51, Konrad Dybcio wrote:
In preparation for supporting multiple sets of possible base registers,
Zero-terminate the array that contains them to remove the need of
specifying num_dsi for eac
The qcom, prefix was missed previously. Fix it.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 +-
1 file changed, 1 insertion(+), 1
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
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
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 77 +++
1 file changed, 26 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/d
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
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.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi.c | 4 +++-
drivers/gpu/drm/msm/dsi/dsi_cfg.c
Add a compatible for the DSI on SM6115.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindi
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
Signed-off-by: Konrad Dybcio
---
drivers/gp
Use the non-deprecated, SoC-specific DSI compatible.
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/arm64/boot/dts/qcom/sm6115.dtsi
index bff067ed2e94..15811be8
v1 -> v2:
- squash the 2d-array-ification and fixing up the logic into one patch
- drop num_variants, loop over VARIANTS_MAX*DSI_MAX unconditionally
- drop inadequate Fixes: tags
- pick up rbs
v1:
https://lore.kernel.org/linux-arm-msm/2023025110.1462920-1-konrad.dyb...@linaro.org/
Some DSI
On 10/02/2023 16:54, Dmitry Baryshkov wrote:
On 10/02/2023 17:28, Neil Armstrong wrote:
On 10/02/2023 16:24, Dmitry Baryshkov wrote:
On 10/02/2023 16:44, Neil Armstrong wrote:
Add the Display Port controller subnode to the MDSS node.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qc
On 13/02/2023 14:10, Konrad Dybcio wrote:
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 z
On 13/02/2023 14:10, 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 back from the
component. We need a way to resolve situations
On 13/02/2023 14:10, 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.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi.c
On 13/02/2023 13:32, neil.armstr...@linaro.org wrote:
On 10/02/2023 16:54, Dmitry Baryshkov wrote:
On 10/02/2023 17:28, Neil Armstrong wrote:
On 10/02/2023 16:24, Dmitry Baryshkov wrote:
On 10/02/2023 16:44, Neil Armstrong wrote:
Add the Display Port controller subnode to the MDSS node.
Sign
On 2023-02-13 13:35:01, Dmitry Baryshkov wrote:
> On 13/02/2023 13:30, Marijn Suijten wrote:
> > On 2023-02-13 12:15:19, Konrad Dybcio wrote:
> > [...]
> @@ -1674,6 +1765,15 @@ static struct dpu_pingpong_cfg sc8280xp_pp[] = {
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
> >>>
On 2023-02-13 13:38:33, Dmitry Baryshkov wrote:
> On 13/02/2023 13:12, Marijn Suijten wrote:
> > On 2023-02-11 13:26:51, Konrad Dybcio wrote:
> >> These blocks are of variable length on different SoCs. Set the
> >> correct values where I was able to retrieve it from downstream
> >> DTs and leave th
On 13/02/2023 16:31, Marijn Suijten wrote:
On 2023-02-13 13:38:33, Dmitry Baryshkov wrote:
On 13/02/2023 13:12, Marijn Suijten wrote:
On 2023-02-11 13:26:51, Konrad Dybcio wrote:
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from
On 13/02/2023 16:28, Marijn Suijten wrote:
On 2023-02-13 13:35:01, Dmitry Baryshkov wrote:
On 13/02/2023 13:30, Marijn Suijten wrote:
On 2023-02-13 12:15:19, Konrad Dybcio wrote:
[...]
@@ -1674,6 +1765,15 @@ static struct dpu_pingpong_cfg sc8280xp_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TO
On 2023-02-13 16:40:56, Dmitry Baryshkov wrote:
> On 13/02/2023 16:31, Marijn Suijten wrote:
> > On 2023-02-13 13:38:33, Dmitry Baryshkov wrote:
> >> On 13/02/2023 13:12, Marijn Suijten wrote:
> >>> On 2023-02-11 13:26:51, Konrad Dybcio wrote:
> These blocks are of variable length on different
On 13/02/2023 17:02, Marijn Suijten wrote:
On 2023-02-13 16:40:56, Dmitry Baryshkov wrote:
On 13/02/2023 16:31, Marijn Suijten wrote:
On 2023-02-13 13:38:33, Dmitry Baryshkov wrote:
On 13/02/2023 13:12, Marijn Suijten wrote:
On 2023-02-11 13:26:51, Konrad Dybcio wrote:
These blocks are of va
On Sat, 11 Feb 2023 13:26:49 +0100, Konrad Dybcio wrote:
> Document 6350 DPU and MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> .../display/msm/qcom,sm6350-mdss.yaml | 213 ++
> 2 files changed, 307 inserti
On Sat, 11 Feb 2023 13:26:50 +0100, Konrad Dybcio wrote:
> Document SM6375 DPU and MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6375-dpu.yaml | 106 +
> .../display/msm/qcom,sm6375-mdss.yaml | 216 ++
> 2 files changed, 322 inse
On 13/02/2023 16:58, Dmitry Baryshkov wrote:
On 13/02/2023 16:28, Marijn Suijten wrote:
Feel free to propose a merge order listing all the aforementioned SoCs,
your rework, my INTF TE patches and whatever else is in the pipeline.
As I've been away for a while, and only have limited hobby time (_
On 2023-02-13 16:58:00, Dmitry Baryshkov wrote:
> On 13/02/2023 16:28, Marijn Suijten wrote:
> > On 2023-02-13 13:35:01, Dmitry Baryshkov wrote:
> >> On 13/02/2023 13:30, Marijn Suijten wrote:
> >>> On 2023-02-13 12:15:19, Konrad Dybcio wrote:
> >>> [...]
> >> @@ -1674,6 +1765,15 @@ static stru
On 13/02/2023 17:14, Marijn Suijten wrote:
On 2023-02-13 16:58:00, Dmitry Baryshkov wrote:
So, *possible* the merge order is the following:
- fixes from https://patchwork.freedesktop.org/series/113910/ go to
msm-fixes
- fixes from your intf-te go to msm-fixes
- https://patchwork.freedesktop.org/
On 13/02/2023 12:16, Dmitry Baryshkov wrote:
On 13/02/2023 12:41, Neil Armstrong wrote:
On 12/02/2023 00:12, Dmitry Baryshkov wrote:
QSEED4 is a newer variant of QSEED3LITE, which should be used on
sm8550. Fix the DPU caps structure and used feature masks.
I found nowhere SM8550 uses Qseed4,
On 12/02/2023 00:12, Dmitry Baryshkov wrote:
Fix typo if the name of the sblk structure for the sm8550's dma_sblk_5.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
1 file changed, 2 inse
Hi,
On Fri, Jan 27, 2023 at 2:15 AM Kalyan Thota wrote:
>
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
>
> Representation: master_flush && (PCC_flush | IGC_flush .. etc )
>
> This chang
Hi,
On Mon, Feb 13, 2023 at 3:11 AM Kalyan Thota wrote:
>
> This series will enable color features on sc7280 target which has
> primary panel as eDP
>
> The series removes DSPP allocation based on encoder type and allows
> the DSPP reservation based on user request via CTM.
>
> The series will re
On 2/13/2023 8:25 AM, Dmitry Baryshkov wrote:
On 13/02/2023 17:14, Marijn Suijten wrote:
On 2023-02-13 16:58:00, Dmitry Baryshkov wrote:
So, *possible* the merge order is the following:
- fixes from https://patchwork.freedesktop.org/series/113910/ go to
msm-fixes
- fixes from your intf-te go
On 12/31/2022 1:50 PM, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0,
but excluding 7.x.x) have the tear interrupt and control registers moved
out of the PINGPONG block and into the INTF block. Wire up the
necessary interrupts and IRQ masks on all
Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
functions in both MDP4 and DPU drivers.
Changes in V2:
- Added changes to remove empty prepare_commit() functions
Changes in V3:
- Reordered "drm/msm/dpu: Move TE setup to prepare_for_kickoff()" for
clarity
- Fixed spelli
Currently, DPU will enable TE during prepare_commit(). However, this
will cause issues when trying to read/write to register in
get_autorefresh_config(), because the core clock rates aren't set at
that time.
This used to work because phys_enc->hw_pp is only initialized in mode
set [1], so the firs
Add a NULL check before calling prepare_commit() in
msm_atomic_commit_tail()
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_atomic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/m
Now that the TE setup has been moved to prepare_for_kickoff(), and
dpu_encoder_prepare_commit() is not empty, remove prepare_commit()
from DPU driver.
Changes in V3:
- Reworded commit message to be more clear
- Corrected spelling mistake in commit message
Signed-off-by: Jessica Zhang
---
driver
On Mon, 13 Feb 2023 at 21:14, Abhinav Kumar wrote:
> On 2/13/2023 8:25 AM, Dmitry Baryshkov wrote:
> > On 13/02/2023 17:14, Marijn Suijten wrote:
> >> On 2023-02-13 16:58:00, Dmitry Baryshkov wrote:
> >>> So, *possible* the merge order is the following:
> >>> - fixes from https://patchwork.freedes
On Mon, 13 Feb 2023 at 20:12, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Feb 13, 2023 at 3:11 AM Kalyan Thota wrote:
> >
> > This series will enable color features on sc7280 target which has
> > primary panel as eDP
> >
> > The series removes DSPP allocation based on encoder type and allows
> > the
On 13/02/2023 21:37, Jessica Zhang wrote:
On 12/31/2022 1:50 PM, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0,
but excluding 7.x.x) have the tear interrupt and control registers moved
out of the PINGPONG block and into the INTF block. Wire up the
On 13/02/2023 21:48, Jessica Zhang wrote:
Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
functions in both MDP4 and DPU drivers.
Changes in V2:
- Added changes to remove empty prepare_commit() functions
Changes in V3:
- Reordered "drm/msm/dpu: Move TE setup to prepare_
On 13/02/2023 21:48, Jessica Zhang wrote:
Currently, DPU will enable TE during prepare_commit(). However, this
will cause issues when trying to read/write to register in
Nit: what issues? SError? reboot to the sahara? board reset?
get_autorefresh_config(), because the core clock rates aren't
On 13/02/2023 21:48, Jessica Zhang wrote:
Now that the TE setup has been moved to prepare_for_kickoff(), and
dpu_encoder_prepare_commit() is not empty, remove prepare_commit()
from DPU driver.
Well. dpu_encoder_prepare_commit() is not empty. I'd say instead:
"... to prepare_for_kickoff(), we h
On Thu, 9 Feb 2023 15:38:33 +0200, Dmitry Baryshkov wrote:
> Add A660 device to the Qualcomm SM8350 platform and enable it for the
> sm8350-hdk board. Unfortunately while adding the GPU & related devices I
> noticed that DT nodes on SM8350 are greatly out of the adress sorting
> order, so patches 2
Remove empty prepare_commit() function from MDP4 driver.
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4
On 2/13/2023 1:51 PM, Dmitry Baryshkov wrote:
On 13/02/2023 21:48, Jessica Zhang wrote:
Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
functions in both MDP4 and DPU drivers.
Changes in V2:
- Added changes to remove empty prepare_commit() functions
Changes in V3:
-
On 14/02/2023 02:01, Abhinav Kumar wrote:
On 2/13/2023 1:51 PM, Dmitry Baryshkov wrote:
On 13/02/2023 21:48, Jessica Zhang wrote:
Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
functions in both MDP4 and DPU drivers.
Changes in V2:
- Added changes to remove empty pr
Hi Doug
Sorry for the delayed response.
On 2/2/2023 2:46 PM, Doug Anderson wrote:
Hi,
On Thu, Feb 2, 2023 at 2:37 PM Abhinav Kumar wrote:
Hi Doug
On 1/31/2023 2:18 PM, Douglas Anderson wrote:
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time") the error handling
Mesa 22.3.x changed the priorities used for the GPU contexts, making
kernel switch between different ring buffers. This uncovered several
issues in the A5xx preemption code, which are now being resolved by this
patchset.
Dmitry Baryshkov (4):
drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LO
Rather than writing CP_PREEMPT_ENABLE_GLOBAL twice, follow the vendor
kernel and set CP_PREEMPT_ENABLE_LOCAL register instead. a5xx_submit()
will override it during submission, but let's get the sequence correct.
Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
Signed-off-by:
A530 has highest bank bit equal to 15 (like A540). Fix values written to
REG_A5XX_RB_MODE_CNTL and REG_A5XX_TPL1_MODE_CNTL registers.
Fixes: 1d832ab30ce6 ("drm/msm/a5xx: Add support for Adreno 508, 509, 512 GPUs")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
Quoting Yassine: ring->memptrs->rptr is never updated and stays 0, so
the comparison always evaluates to false and get_next_ring always
returns ring 0 thinking it isn't empty.
Fix this by calling get_rptr() instead of reading rptr directly.
Reported-by: Yassine Oudjana
Fixes: b1fc2839d2f9 ("drm/
The rptr_addr is set in the preempt_init_ring(), which is called from
a5xx_gpu_init(). It uses shadowptr() to set the address, however the
shadow_iova is not yet initialized at that time. Move the rptr_addr
setting to the a5xx_preempt_hw_init() which is called after setting the
shadow_iova, getting
On 2/13/2023 1:46 PM, Dmitry Baryshkov wrote:
On 13/02/2023 21:37, Jessica Zhang wrote:
On 12/31/2022 1:50 PM, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0,
but excluding 7.x.x) have the tear interrupt and control registers moved
out of the PIN
On Tuesday, February 14th, 2023 at 6:09 AM, Dmitry Baryshkov
wrote:
> Mesa 22.3.x changed the priorities used for the GPU contexts, making
> kernel switch between different ring buffers. This uncovered several
> issues in the A5xx preemption code, which are now being resolved by this
> patchset.
76 matches
Mail list logo
