As discusssed in the the review of [1], rework these two functions to
separate single point parser and provide clean error path.
Depenencies: [1]
[1] https://lore.kernel.org/all/20230215235048.1166484-1-robdcl...@gmail.com
Dmitry Baryshkov (2):
drm/msm: drop unused ring variable in msm_ioctl_g
Simplify two functions msm_parse_deps() and msm_parse_post_deps():
extract single item parsing function and clean up error path.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gem_submit.c | 196 +++
1 file changed, 106 insertions(+), 90 deletions(-)
diff --
The variable ring is not used by msm_parse_deps() and
msm_ioctl_gem_submit() and thus can be dropped.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +++---
drivers/gpu/drm/msm/msm_gpu_trace.h | 10 --
2 files changed, 7 insertions(+), 13 deletions(-)
On 13/02/2023 13:11, Kalyan Thota wrote:
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
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_atomic.c
On 12/02/2023 18:28, Vinod Polimera wrote:
Populate the enocder software structure to reflect the updated
crtc appropriately during crtc enable/disable for a new commit
while taking care of the self refresh transitions when crtc
disable is triggered from the drm self refresh library.
Signed-off-
On 17.02.2023 22:44, Dmitry Baryshkov wrote:
> On 17/02/2023 23:41, Konrad Dybcio wrote:
>>
>>
>> On 17.02.2023 22:37, Dmitry Baryshkov wrote:
>>> On 14/02/2023 19:31, Konrad Dybcio wrote:
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the asso
On 17/02/2023 23:41, Konrad Dybcio wrote:
On 17.02.2023 22:37, Dmitry Baryshkov wrote:
On 14/02/2023 19:31, 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
On 14/02/2023 19:31, Konrad Dybcio wrote:
Adreno 619 expects some tunables to be set differently. Make up for it.
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 del
On 14/02/2023 19:31, 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 feature a VDDGX line
either, being powered solely by VDDCX and has an unfortu
On 17.02.2023 22:37, Dmitry Baryshkov wrote:
> On 14/02/2023 19:31, 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 t
On 14/02/2023 19:31, 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 rails, clocks and
On 14/02/2023 19:31, 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 yet support khaje upstream.
Hence, add a fuse mapping table for bengal to allo
On 14/02/2023 19:31, Konrad Dybcio wrote:
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 tha
On 17/02/2023 21:23, Konrad Dybcio wrote:
On 17.02.2023 22:20, Bryan O'Donoghue wrote:
On 17/02/2023 21:16, Konrad Dybcio wrote:
Correct, but QCM2290 is not supported upstream yet.
SM6115 (a different SoC) however is, but it used the qcm2290 compatible
as it was a convenient hack to get the
On 17.02.2023 22:20, Bryan O'Donoghue wrote:
> On 17/02/2023 21:16, Konrad Dybcio wrote:
>> Correct, but QCM2290 is not supported upstream yet.
>>
>> SM6115 (a different SoC) however is, but it used the qcm2290 compatible
>> as it was a convenient hack to get the DSI host ID recognized based on
On 14/02/2023 19:31, Konrad Dybcio wrote:
The GPU can only be one at a time. Turn a series of ifs into if +
elseifs to save some CPU cycles.
Signed-off-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
1 file changed, 4 insertions(+)
On 17.02.2023 22:19, Dmitry Baryshkov wrote:
> On 14/02/2023 19:31, Konrad Dybcio wrote:
>> 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 i
On 17/02/2023 21:16, Konrad Dybcio wrote:
Correct, but QCM2290 is not supported upstream yet.
SM6115 (a different SoC) however is, but it used the qcm2290 compatible
as it was a convenient hack to get the DSI host ID recognized based on
the (identical-to-qcm2290) base register without additional
On 14/02/2023 19:31, Konrad Dybcio wrote:
On GMU-equipped GPUs, the GMU requests appropriate bandwidth votes
for us. This is however not the case for the other GPUs. Add the
dev_pm_opp_of_find_icc_paths() call to let the OPP framework handle
bus voting as part of power level setting.
Signed-off-
On 14/02/2023 19:31, Konrad Dybcio wrote:
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/m
On 17.02.2023 22:13, Bryan O'Donoghue wrote:
> On 17/02/2023 12:24, Krzysztof Kozlowski wrote:
>> First, it would be nice to know what was the intention of Bryan's commit?
>
> Sorry I've been grazing this thread but, not responding.
>
> - qcom,dsi-ctrl-6g-qcm2290
>
> is non-compliant with qco
On 17/02/2023 12:24, Krzysztof Kozlowski wrote:
First, it would be nice to know what was the intention of Bryan's commit?
Sorry I've been grazing this thread but, not responding.
- qcom,dsi-ctrl-6g-qcm2290
is non-compliant with qcom,socid-dsi-ctrl which is our desired naming
convention, so t
On 14/02/2023 19:31, Konrad Dybcio wrote:
Currently we only utilize the OPP table connected to the GPU for
getting (available) frequencies. We do however need to scale the
voltage rail(s) accordingly to ensure that we aren't trying to
run the GPU at 1GHz with a VDD_LOW vote, as that would result
On 14/02/2023 19:31, Konrad Dybcio wrote:
These SKUs 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.
Signed-off-by:
On 17.02.2023 21:46, Dmitry Baryshkov wrote:
> On 14/02/2023 19:31, Konrad Dybcio wrote:
>> Port setting min_access_length, ubwc_mode and upper_bit from downstream.
>> Values were validated using downstream device trees for SM8[123]50 and
>> left default (as per downstream) elsewhere.
>>
>> Sign
On 14/02/2023 19:31, Konrad Dybcio wrote:
Port setting min_access_length, ubwc_mode and upper_bit from downstream.
Values were validated using downstream device trees for SM8[123]50 and
left default (as per downstream) elsewhere.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6x
On 14/02/2023 19:31, Konrad Dybcio wrote:
These two will be reused by at least A619_holi in the non-gmu
paths. De-staticize them to make it possible.
Nit: 'remove static annotation' or something like that.
Other than that:
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
On Fri, Feb 17, 2023 at 09:18:54AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 16.02.23 um 21:11 schrieb Daniel Vetter:
> > On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> > > Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> > > calling fbdev implementation.
On Thu, 16 Feb 2023 at 23:46, Marijn Suijten
wrote:
>
> On 2023-02-16 18:34:43, Dmitry Baryshkov wrote:
> > On 16/02/2023 10:31, Marijn Suijten wrote:
> > > On 2023-02-16 04:22:13, Dmitry Baryshkov wrote:
> > >> On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
> > >> wrote:
> > >>>
> > >>> DPU's cata
On 17.02.2023 13:24, Krzysztof Kozlowski wrote:
> On 17/02/2023 12:36, Konrad Dybcio wrote:
>>>>
>>>> compatible = "qcom,dsi-ctrl-6g-qcm2290";
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/
On 17/02/2023 12:36, Konrad Dybcio wrote:
>>>
>>> compatible = "qcom,dsi-ctrl-6g-qcm2290";
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221
>>
>> I meant, that o
enum:
>>>>- qcom,dsi-ctrl-6g-qcm2290
>>>> - - const: qcom,mdss-dsi-ctrl
>>>
>>> Wasn't then intention to deprecate both - qcm2290 and mdss - when used
>>> alone?
>> "qcom,dsi-ctrl-6g-qcm2290", "qco
drop the items as it is just an enum.
>>
>>>- enum:
>>>- qcom,dsi-ctrl-6g-qcm2290
>>> - - const: qcom,mdss-dsi-ctrl
>>
>> Wasn't then intention to deprecate both - qcm2290 and mdss - when used
>> alone?
rl
>
> Wasn't then intention to deprecate both - qcm2290 and mdss - when used
> alone?
"qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl"
was never used. The only upstream usage of the 2290 compat
is in sm6115.dtsi:
compatible = "qcom,dsi-ctrl-6g-qcm2290";
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221
Konrad
>
>
> Best regards,
> Krzysztof
>
On 17/02/2023 12:13, Konrad Dybcio wrote:
> Since the DSI autodetection is bound to work correctly on 6115 now,
> switch to using the correct per-SoC + generic fallback compatible
> combo.
>
> Signed-off-by: Konrad Dybcio
> ---
> Depends on (and should have been a part of):
>
> https://lore.kern
On 17/02/2023 12:13, Konrad Dybcio wrote:
> SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290",
> without the generic fallback. Fix the deprecated binding to reflect
> that.
>
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
> strings for every curren
Since the DSI autodetection is bound to work correctly on 6115 now,
switch to using the correct per-SoC + generic fallback compatible
combo.
Signed-off-by: Konrad Dybcio
---
Depends on (and should have been a part of):
https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dyb...@
SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290",
without the generic fallback. Fix the deprecated binding to reflect
that.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Signed-off-by: Konrad Dybcio
---
Depends on (
On 16/02/2023 14:14, Konrad Dybcio wrote:
> Since the DSI autodetection is bound to work correctly on 6115 now,
> switch to using the correct per-SoC + generic fallback compatible
> combo.
>
> Signed-off-by: Konrad Dybcio
> ---
> Depends on (and should have been a part of):
>
> https://lore.kern
Hi
Am 16.02.23 um 21:11 schrieb Daniel Vetter:
On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
calling fbdev implementation. Avoids a possible stale mutex with
generic fbdev code.
As indicated by its name, drm
40 matches
Mail list logo
