On 2/23/2023 2:08 PM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Thu, 23 Feb 2023 at 21:17, Abhinav Kumar wrote:
Hi Dmitry
On 2/23/2023 1:57 AM, Dmitry Baryshkov wrote:
The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
when setting the SSPP_NONE pipe. However it was unn
Hi Abhinav,
On Thu, 23 Feb 2023 at 21:17, Abhinav Kumar wrote:
>
> Hi Dmitry
>
> On 2/23/2023 1:57 AM, Dmitry Baryshkov wrote:
> > The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
> > when setting the SSPP_NONE pipe. However it was unnoticed until the
> > kernel was tested
Hi Dmitry
On 2/23/2023 1:57 AM, Dmitry Baryshkov wrote:
The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
when setting the SSPP_NONE pipe. However it was unnoticed until the
kernel was tested under AOSP (with some kind of stack protection/check).
This fixes the following b
On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen wrote:
>
> On Wed, 22 Feb 2023 07:37:26 -0800
> Rob Clark wrote:
>
> > On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 21 Feb 2023 09:53:56 -0800
> > > Rob Clark wrote:
> > >
> > > > On Tue, Feb 21, 2023 at 8:48 AM Luben T
On Thu, 23 Feb 2023 at 15:27, Dmitry Baryshkov
wrote:
>
> The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
> when setting the SSPP_NONE pipe. However it was unnoticed until the
> kernel was tested under AOSP (with some kind of stack protection/check).
>
> This fixes the foll
On 23/02/2023 12:51, Konrad Dybcio wrote:
This is a partial merge of [1], subject to be dropped if a header
update is executed.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21484
Suggested-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a2xx
On 23/02/2023 12:51, Konrad Dybcio wrote:
This is a partial merge of [1], subject to be dropped if a header
update is executed.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21480/
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a2xx.xml.h | 6 ++
1 file chan
On Thu, 23 Feb 2023 at 15:57, Sankeerth Billakanti
wrote:
>
> The DP driver resources are currently enabled and disabled directly based on
> code flow.
> As mentioned in bug 230631602, we want to do the following:
private bug tracker
>
> 1) Refactor the dp/edp parsing code to move it to probe (
On Thu, 23 Feb 2023 at 15:57, Sankeerth Billakanti
wrote:
>
> 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
On 23.02.2023 15:48, Dmitry Baryshkov wrote:
> On Thu, 23 Feb 2023 at 15:49, Konrad Dybcio wrote:
>>
>>
>>
>> On 23.02.2023 14:06, Dmitry Baryshkov wrote:
>>> On Thu, 23 Feb 2023 at 14:07, Konrad Dybcio
>>> wrote:
According to the vendor sources, it's equal to 16, which makes hbb_lo
On Thu, 23 Feb 2023 at 15:49, Konrad Dybcio wrote:
>
>
>
> On 23.02.2023 14:06, Dmitry Baryshkov wrote:
> > On Thu, 23 Feb 2023 at 14:07, Konrad Dybcio
> > wrote:
> >>
> >> According to the vendor sources, it's equal to 16, which makes hbb_lo
> >> equal to 3.
> >
> > I think we might be stricken
On 23.02.2023 15:43, Dmitry Baryshkov wrote:
> On Thu, 23 Feb 2023 at 14:06, 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, this me
On Thu, 23 Feb 2023 at 14:06, 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, this means we have to take care
> of enabling & scaling power
The current DP driver directly enables or disables the necessary control
resources based on code flow. This could disable a required resource that
is needed in a different usecase. It can also lead to excessive voting of
a resource and may increase power consumption.
The pm_runtime framework can s
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 deferred, then the whole bunch of
MDSS pa
The DP driver resources are currently enabled and disabled directly based on
code flow.
As mentioned in bug 230631602, we want to do the following:
1) Refactor the dp/edp parsing code to move it to probe (it is currently done
in bind).
2) Then bind all the power resources needed for AUX in pm_r
On 23.02.2023 14:06, Dmitry Baryshkov wrote:
> On Thu, 23 Feb 2023 at 14:07, Konrad Dybcio wrote:
>>
>> According to the vendor sources, it's equal to 16, which makes hbb_lo
>> equal to 3.
>
> I think we might be stricken with the ddr kind difference here, but I
> would not bet on it.
It total
On Thu, 23 Feb 2023 at 14:07, Konrad Dybcio wrote:
>
> According to the vendor sources, it's equal to 16, which makes hbb_lo
> equal to 3.
I think we might be stricken with the ddr kind difference here, but I
would not bet on it.
>
> Fixes: 840d10b64dad ("drm: msm: Add 680 gpu to the adreno gpu
On 23.02.2023 13:06, Konrad Dybcio wrote:
> GMU wrapper-equipped A6xx GPUs require clocks and clock-names to be
> specified under the GPU node, just like their older cousins.
> Account for that.
>
> Signed-off-by: Konrad Dybcio
> ---
[...]
> -then: # Since Adreno 6xx series clocks should b
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
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
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
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
According to the vendor sources, it's equal to 16, which makes hbb_lo
equal to 3.
Fixes: 840d10b64dad ("drm: msm: Add 680 gpu to the adreno gpu list")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a
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
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 | 43 +
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
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).
Sort the variable definition and assignment alphabetically.
Port setting min_access_length, ubwc_mode and hbb_hi from downstream.
Set default values for all of the tunables to zero, 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
GMU wrapper is essentially a register space within the GPU, which
Linux sees as a dumbed-down regular GMU: there's no clocks,
interrupts, multiple regs, iommus and OPP. Document it.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/gmu.yaml | 49 --
1
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
GMU wrapper-equipped A6xx GPUs require clocks and clock-names to be
specified under the GPU node, just like their older cousins.
Account for that.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/gpu.yaml | 63 ++
1 file changed, 53 insertions(+), 10
v2 -> v3:
New dependencies:
-
https://lore.kernel.org/linux-arm-msm/20230223-topic-opp-v3-0-5f22163cd...@linaro.org/T/#t
-
https://lore.kernel.org/linux-arm-msm/20230120172233.1905761-1-konrad.dyb...@linaro.org/
Sidenote: A speedbin rework is in progress, the of_machine_is_compatible
calls
On 23.02.2023 12:53, Dmitry Baryshkov wrote:
> On Thu, 23 Feb 2023 at 12:57, Konrad Dybcio wrote:
>>
>>
>>
>> On 23.02.2023 10:57, Dmitry Baryshkov wrote:
>>> The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
>>> when setting the SSPP_NONE pipe. However it was unnoticed un
On Thu, 23 Feb 2023 at 12:57, Konrad Dybcio wrote:
>
>
>
> On 23.02.2023 10:57, Dmitry Baryshkov wrote:
> > The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
> > when setting the SSPP_NONE pipe. However it was unnoticed until the
> > kernel was tested under AOSP (with some ki
On 23.02.2023 10:57, Dmitry Baryshkov wrote:
> The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
> when setting the SSPP_NONE pipe. However it was unnoticed until the
> kernel was tested under AOSP (with some kind of stack protection/check).
>
> This fixes the following ba
Implement gpu_busy based on the downstream msm-3.4 code [1]. This
allows us to use devfreq on this old old old hardware!
[1]
https://github.com/LineageOS/android_kernel_sony_apq8064/blob/lineage-16.0/drivers/gpu/msm/adreno_a2xx.c#L1975
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
Add support for gpu_busy on a4xx, which is required for devfreq
support.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm
Add support for gpu_busy on a3xx, which is required for devfreq
support.
Tested-by: Dmitry Baryshkov #ifc6410
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ms
Add the dev_pm_opp_of_find_icc_paths() call to let the OPP framework
handle bus voting as part of power level setting.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/dr
Some older GPUs (namely a2xx with no opp tables at all and a320 with
downstream-remnants gpu pwrlevels) used not to have OPP tables. They
both however had just one frequency defined, making it extremely easy
to construct such an OPP table from within the driver if need be.
Do so and switch all clk
v2 -> v3:
- Add [2/7], x-ref with
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21484
- De-magic-ify the remaining BIT(6) in a2xx_busy (thanks Dmitry)
- Drop unnecessary else{} level in [3/7]
- Pick up tags
v2:
https://lore.kernel.org/linux-arm-msm/20230223-topic-opp-v2-0-24ed24
This is a partial merge of [1], subject to be dropped if a header
update is executed.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21484
Suggested-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a2xx.xml.h | 12
1 file changed, 12
This is a partial merge of [1], subject to be dropped if a header
update is executed.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21480/
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a2xx.xml.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu
On 23.02.2023 03:09, Dmitry Baryshkov wrote:
> On Thu, 23 Feb 2023 at 03:47, Konrad Dybcio wrote:
>>
>> Implement gpu_busy based on the downstream msm-3.4 code [1]. This
>> allows us to use devfreq on this old old old hardware!
>>
>> [1]
>> https://github.com/LineageOS/android_kernel_sony_apq8
The rewritten dpu_hw_ctl_setup_blendstage() can lightly smash the stack
when setting the SSPP_NONE pipe. However it was unnoticed until the
kernel was tested under AOSP (with some kind of stack protection/check).
This fixes the following backtrace:
Unexpected kernel BRK exception at EL1
Internal
On Wed, 22 Feb 2023 07:37:26 -0800
Rob Clark wrote:
> On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen wrote:
> >
> > On Tue, 21 Feb 2023 09:53:56 -0800
> > Rob Clark wrote:
> >
> > > On Tue, Feb 21, 2023 at 8:48 AM Luben Tuikov
> > > wrote:
> > > >
> > > > On 2023-02-20 11:14, Rob Clark wr
Am 20.02.23 um 17:09 schrieb Rob Clark:
On Mon, Feb 20, 2023 at 12:27 AM Christian König
wrote:
Am 18.02.23 um 22:15 schrieb Rob Clark:
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisio
50 matches
Mail list logo
