On Sat, May 20, 2023 at 09:20:50PM +0300, Dmitry Baryshkov wrote:
> Remove most of remains of downstream usbpd code. Mainline kernel uses
> different approach for managing Type-C / USB-PD, so this remains unused.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
On Sat, May 20, 2023 at 04:26:59AM +0300, Dmitry Baryshkov wrote:
> On 15/05/2023 06:02, Bjorn Andersson wrote:
> > The dp_power module keeps track of both the DP controller's struct
> > platform_device and struct device - with the prior pulled out of the
> > dp_parser module.
> >
> > Clean up the
On 20/05/2023 00:17, Jessica Zhang wrote:
Currently, slice_count is being used to calculate word count and
pkt_per_line. In downstream, these values are calculated using slice per
packet, which is not the same as slice_count.
I'd say the reference to downstream is not correct. We have seen case
On 19/05/2023 02:33, Kuogee Hsieh wrote:
There are two tiers of pending flush control, main controller and
individual hardware block. Currently only the main controller of
flush mask is reset to 0 but leave out some individual pending flush
mask of particular hardware block keep previous value at
On 15/05/2023 17:30, Rob Clark wrote:
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.
On 15/05/2023 17:30, Rob Clark wrote:
From: Rob Clark
Also store the override strings in drm_file so that fdinfo can display
them. We still need to keep our original copy as we could need these
override strings after the device file has been closed and drm_file
freed.
Signed-off-by: Rob Clark
On 07/05/2023 19:25, Uwe Kleine-König wrote:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resou
On 20/04/2023 20:47, Jeykumar Sankaran wrote:
On 4/19/2023 3:23 PM, Dmitry Baryshkov wrote:
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using two LMs instead of one when the display width is lower
than the maximum supported value. For example on MSM8996/MSM8998, the
actual maxwidth is
Simplify calculations around pixel_clk_rate division. Replace common
pattern of doing 64-bit multiplication and then a do_div() call with
simpler mult_frac() invocation.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 11 ---
1 file c
In dsi_calc_clk_rate_v2() there is no need to call dsi_get_pclk_rate().
This function has just been called (from dsi_calc_pclk()) and its
result is stored at msm_host->pixel_clk_rate. Use this variable
directly.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
Remove most of remains of downstream usbpd code. Mainline kernel uses
different approach for managing Type-C / USB-PD, so this remains unused.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Also drop USBPD callbacks as per [1].
[1] https://patchwork.freedesktop.org/patch/536942/?series
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 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
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
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
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
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 | 27 +
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
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 write memory barrier which together with the necessary delay should
ensure that the reset is never deasserted too qui
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
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
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 39 +++
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
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
Unify the indentation and explain the cryptic 0xF value.
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/adreno/a6xx_gpu.c
index 6bb4da
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 "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
v6 -> v7:
- Rebase on next-20230519 (A640/650 speedbin merged already)
- separate out the .get_timestamp cb for gmu wrapper
- check for gmu presence inside a6xx_llc_slices_(init|destroy) instead
of before calling them
- use REG_A6XX_RBBM_GPR0_CNTL instead of literal 0x18
- move a6xx_bus_clear
On 2023-05-20 03:28:46, Dmitry Baryshkov wrote:
> Simplify calculatoins around pixel_clk_rate division. Replace common
calculations*
> pattern of doing 64-bit multiplication and then a do_div() call with
> simpler mult_frac call.
>
> Signed-off-by: Dmitry Baryshkov
That's a cool function, I di
On 2023-05-20 03:28:45, Dmitry Baryshkov wrote:
> In dsi_calc_clk_rate_v2() there is no need to call dsi_get_pclk_rate().
> This functions has just been called and it's result is stored at
function (drop -s)
has just been called *inside dsi_calc_pclk()*
it's -> its
> msm_host->pixel_clk_rate. Use
On 2023-05-19 14:17:26, Jessica Zhang wrote:
> Currently, when compression is enabled, hdisplay is reduced via integer
> division. This causes issues for modes where the original hdisplay is
> not a multiple of 3.
>
> To fix this, use DIV_ROUND_UP to divide hdisplay.
>
> Reported-by: Marijn Suijt
33 matches
Mail list logo
