On 14.06.2023 21:41, Akhil P Oommen wrote:
> On Mon, May 29, 2023 at 03:52:32PM +0200, Konrad Dybcio wrote:
>>
>> 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 f
On 14.06.2023 22:18, Akhil P Oommen wrote:
> On Mon, May 29, 2023 at 03:52:37PM +0200, Konrad Dybcio wrote:
>>
>> 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 ye
On 13/06/2023 01:02, Bjorn Andersson wrote:
The DP component's unbind operation walks through the submodules to
unregister and clean things up. But if the unbind happens because the DP
controller itself is being removed, all the memory for those submodules
has just been freed.
Change the order o
On 6.06.2023 19:18, Akhil P Oommen wrote:
> On Mon, May 29, 2023 at 03:52:26PM +0200, Konrad Dybcio wrote:
>>
>> Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper
>> GPUs and reuse it in a6xx_gmu_force_off().
>>
>> This helper, contrary to the original usage in GMU code paths, add
On Mon, 12 Jun 2023 21:25:33 +0300, Dmitry Baryshkov wrote:
> We can not support color management without DSPP blocks being provided
> in the HW catalog. Do not enable color management for CRTCs if num_dspps
> is 0.
>
>
Applied, thanks!
[1/2] drm/msm/dpu: do not enable color-management if DSP
On Mon, 12 Jun 2023 21:25:27 +0300, Dmitry Baryshkov wrote:
> Change adreno_is_a690() prototype to accept the const struct adreno_gpu
> pointer instead of a non-const one. This fixes the following warning:
>
> In file included from drivers/gpu/drm/msm/msm_drv.c:33:
> drivers/gpu/drm/msm/adreno/a
On Tue, 13 Jun 2023 03:09:39 +0300, Dmitry Baryshkov wrote:
> Having a macro with 10 arguments doesn't seem like a good idea. It makes
> it inherently harder to compare the actual structure values. Also this
> leads to adding macros covering varieties of the block.
>
> As it was previously discu
On Mon, 12 Jun 2023 06:16:15 +0300, Dmitry Baryshkov wrote:
> Since commit 93e81e38e197 ("drm/fb_helper: Minimize damage-helper
> overhead") the drm_fb_helper_funcs::fb_dirty helper is required for
> proper dirty/damage processing. The drm/msm driver requires that to
> function to let CMD panels
On Thu, 15 Jun 2023 01:44:01 +0300, Dmitry Baryshkov wrote:
> Several source clocks are not used anymore, so stop handling them.
>
>
Applied, thanks!
[1/2] drm/msm/dsi: dsi_host: drop unused clocks
https://gitlab.freedesktop.org/lumag/msm/-/commit/2d1ae9a5ae51
[2/2] drm/msm/dsi: split d
On Fri, 09 Jun 2023 15:57:12 -0700, Jessica Zhang wrote:
> This is a series of changes for DSI to enable command mode support
> for DSC v1.2.
>
> This includes:
>
> 1) Rounding up `hdisplay / 3` in dsc_timing_setup()
> 2) Adjusting pclk_rate to account for compression
> 3) Fixing incorrect uses
On Mon, 12 Jun 2023 15:01:06 -0700, Bjorn Andersson wrote:
> Using devres to depopulate the aux bus made sure that upon a probe
> deferral the EDP panel device would be destroyed and recreated upon next
> attempt.
>
> But the struct device which the devres is tied to is the DPUs
> (drm_dev->dev)
On Mon, 12 Jun 2023 15:02:59 -0700, Bjorn Andersson wrote:
> The DP component's unbind operation walks through the submodules to
> unregister and clean things up. But if the unbind happens because the DP
> controller itself is being removed, all the memory for those submodules
> has just been fre
On Wed, 24 May 2023 10:45:13 -0700, Jessica Zhang wrote:
> There are some overlap in calculations for MSM-specific DSC variables
> between DP and DSI. In addition, the calculations for initial_scale_value
> and det_thresh_flatness that are defined within the DSC 1.2 specifications,
> but aren't y
On Thu, 25 May 2023 10:40:48 -0700, Kuogee Hsieh wrote:
> This series adds the DPU side changes to support DSC 1.2 encoder. This
> was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
> The DSI and DP parts will be pushed later on top of this change.
> This seriel is rebase on [1], [
On 2023-06-15 14:31:26, Dmitry Baryshkov wrote:
>
> On Fri, 09 Jun 2023 15:57:12 -0700, Jessica Zhang wrote:
> > This is a series of changes for DSI to enable command mode support
> > for DSC v1.2.
> >
> > This includes:
> >
> > 1) Rounding up `hdisplay / 3` in dsc_timing_setup()
> > 2) Adjustin
On Thu, Jun 15, 2023 at 12:34:06PM +0200, Konrad Dybcio wrote:
>
> On 6.06.2023 19:18, Akhil P Oommen wrote:
> > On Mon, May 29, 2023 at 03:52:26PM +0200, Konrad Dybcio wrote:
> >>
> >> Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper
> >> GPUs and reuse it in a6xx_gmu_force_off
On 15.06.2023 22:11, Akhil P Oommen wrote:
> On Thu, Jun 15, 2023 at 12:34:06PM +0200, Konrad Dybcio wrote:
>>
>> On 6.06.2023 19:18, Akhil P Oommen wrote:
>>> On Mon, May 29, 2023 at 03:52:26PM +0200, Konrad Dybcio wrote:
Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrappe
On Thu, Jun 15, 2023 at 10:59:23PM +0200, Konrad Dybcio wrote:
>
> On 15.06.2023 22:11, Akhil P Oommen wrote:
> > On Thu, Jun 15, 2023 at 12:34:06PM +0200, Konrad Dybcio wrote:
> >>
> >> On 6.06.2023 19:18, Akhil P Oommen wrote:
> >>> On Mon, May 29, 2023 at 03:52:26PM +0200, Konrad Dybcio wrote:
On 10.06.2023 00:06, Akhil P Oommen wrote:
> On Mon, May 29, 2023 at 03:52:29PM +0200, Konrad Dybcio wrote:
>>
>> 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, t
On 2023-06-13 03:09:56, Dmitry Baryshkov wrote:
> To simplify making changes to the hardware block definitions, expand
> corresponding macros. This way making all the changes are more obvious
> and visible in the source files.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog
On 16/06/2023 01:05, Marijn Suijten wrote:
On 2023-06-13 03:09:56, Dmitry Baryshkov wrote:
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
On 2023-06-13 03:09:39, Dmitry Baryshkov wrote:
> Having a macro with 10 arguments doesn't seem like a good idea. It makes
> it inherently harder to compare the actual structure values. Also this
> leads to adding macros covering varieties of the block.
>
> As it was previously discussed, inline a
On 2023-06-13 03:09:40, Dmitry Baryshkov wrote:
> During IRQ conversion we have lost the PP_DONE interrupts for sc7280
> platform. This was left unnoticed, because this interrupt is only used
> for CMD outputs and probably no sc7[12]80 systems use DSI CMD panels.
>
> Fixes: 667e9985ee24 ("drm/msm/
On 2023-06-13 03:09:41, Dmitry Baryshkov wrote:
> Each MERGE_3D block has just two registers. Correct the block length
> accordingly.
>
> Fixes: 4369c93cf36b ("drm/msm/dpu: initial support for merge3D hardware
> block")
> Signed-off-by: Dmitry Baryshkov
Indeed, and that patch wasn't even introd
On 2023-06-13 03:09:42, Dmitry Baryshkov wrote:
> sm6115 and qcm2290 do not have INTF_0. Drop corresponding interface
> definitions.
As Abhinav said, add sm6375.
If it wasn't for sc8280xp using INTF_NONE for fake MST, we could have
dropped INTF_NONE and the special-cases in dpu_hw_interrupts.c an
On 2023-06-13 03:09:43, Dmitry Baryshkov wrote:
> Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration.
>
> Signed-off-by: Dmitry Baryshkov
Nice, that'll be cleaner.
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/msm_drv.h | 8 +++-
> 1 file changed, 7 insertions(+)
On 2023-06-13 03:09:44, Dmitry Baryshkov wrote:
> In several catalog entries we did not use existing MSM_DP_CONTROLLER_n
> constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n
> for DSI interfaces.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalo
On 2023-06-15 14:31:22, Dmitry Baryshkov wrote:
>
> On Tue, 13 Jun 2023 03:09:39 +0300, Dmitry Baryshkov wrote:
> > Having a macro with 10 arguments doesn't seem like a good idea. It makes
> > it inherently harder to compare the actual structure values. Also this
> > leads to adding macros coverin
On 2023-06-13 03:09:45, Dmitry Baryshkov wrote:
> For each LM there is at max 1 peer LM which can be driven by the same
> CTL, so there no need to have a mask instead of just an ID of the peer
> LM.
>
> Signed-off-by: Dmitry Baryshkov
Nit: I think you can describe the the patch contents in the t
v8 -> v9:
- Re-pick-up Krzysztof's lost r-b tag (I messed up, sorry)
- Rebase on constifying-adreno_is_aXYZ and A690 changes
- Fix A610 inactive period
- Move the stray A619 register write from A610 patch to the A619 patch
- Add one more commit, cleaning up A690 addition for git context (for adding
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
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 adreno_is_revn rework came at the same time as A690 introduction
and that resulted in it not covering all cases. Fix it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adr
As pointed out by Akhil during the review process of GMU wrapper
introduction [1], it makes sense to move this write into the function
that's responsible for forcibly shutting the GMU off.
It is also very convenient to move this to GMU-specific code, so that
it does not have to be guarded by an if
Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper
GPUs and reuse it in a6xx_gmu_force_off().
This helper, contrary to the original usage in GMU code paths, adds
a readback+delay sequence to ensure that the reset is never deasserted
too quickly due to e.g. OoO execution going craz
Unify the indentation and explain the cryptic 0xF value.
Reviewed-by: Akhil P Oommen
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/a
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0.
This is typically done automatically on successful GX collapse, but in
case that fails, we should take care of it.
Also, add a memory barrier to ensure it's gone through before jumping
to
This function is responsible for telling the GPU to halt transactions
on all of its relevant buses, drain them and leave them in a predictable
state, so that the GPU can be e.g. reset cleanly.
Move the function to a6xx_gpu.c, remove the static keyword and add a
prototype in a6xx_gpu.h to accomodat
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.
Reviewed-by: Rob Clark
Reviewed-by: Akhil P Oommen
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adren
Since the introduction of A6xx support, we've been enabling the CX GMU
power counter 0 in a bit of a weird spot. Move it to hw_init so that
GMU wrapper GPUs can reuse the same code paths. As a bonus, this order
makes it easier to compare mainline and downstream register access traces.
Signed-off-b
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
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
Reviewed-by: Akhil P Oommen
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
dif
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
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
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 | 27 +
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.
Reviewed-b
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
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
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
Reviewed-by: Akhil P Oommen
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insert
50 matches
Mail list logo
