CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable the auxiliary driver
sample) unless a driver happens to do it for us.
Signed-off-by: Alexandre Courbot
---
samples/rust/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 de
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_DRM) unless
another driver happens to do it for us.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nova/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletio
I noticed this after trying to understand why my minimal Nova defconfig
was not selecting NOVA_CORE anymore and why I couldn't even find it in
menuconfig.
CONFIG_AUXILIARY_BUS cannot be enabled directly and must be selected by
another module. Options that depend on it thus cannot be enabled unless
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_CORE) unless
another driver happens to do it for us.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/nova-core/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 delet
Am Donnerstag, 15. Mai 2025, 00:24:52 CEST schrieb Marco Felsch:
> Make use of dev_err_probe() to easily spot issues via the debugfs or
> kernel log. No functional changes.
>
> Signed-off-by: Marco Felsch
Reviewed-by: Alexander Stein
> ---
> drivers/gpu/drm/bridge/fsl-ldb.c | 19 ++---
On Wed, May 14, 2025 at 05:27:44PM +0200, Bartosz Golaszewski wrote:
> On Wed, 14 May 2025 at 11:37, Sumit Garg wrote:
> >
> > Hi Amir,
> >
> > I am still unable to get the QCOMTEE driver to work on db845c. As I can
> > see machine: "qcom,sdm845" is not supported for tzmem based on SHM
> > brigde
> I have to admit I'm pretty clueless about the gpu driver internals and
> can't really judge how feasible this is. But from a cgroup POV, if you
> want proper memory isolation between groups, it seems to me that's the
> direction you'd have to take this in.
Thanks for this insight, I think you ha
On Thu, May 15, 2025 at 02:17:27AM +0530, ALOK TIWARI wrote:
>
>
> > + * DEPT(DEPendency Tracker) - Runtime dependency tracker
> > + *
> > + * Started by Byungchul Park :
> > + *
> > + * Copyright (c) 2020 LG Electronics, Inc., Byungchul Park
> > + *
> > + * DEPT provides a general way to detect
On Wed, May 14, 2025 at 08:14:26PM -0400, Waiman Long wrote:
> On 5/13/25 6:06 AM, Byungchul Park wrote:
> > llist_head and llist_node can be used by very primitives. For example,
>
> I suppose you mean "every primitives". Right? However, the term "primitive"
> may sound strange. Maybe just saying
Previously we only signaled finished fence which may cause some
submission's dependency cannot be cleared the cause benchmark hang.
Signal both scheduled fence and finished fence could fix this issue.
Signed-off-by: Lin.Cao
---
drivers/gpu/drm/scheduler/sched_entity.c | 1 +
1 file changed, 1 in
On Wed, May 14, 2025 at 04:52:29PM -0700, Jessica Zhang wrote:
> Drop the unused maxwidth field from the dpu_lm_sub_blks struct
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 -
> 2 files chan
On Wed, May 14, 2025 at 04:52:33PM -0700, Jessica Zhang wrote:
> Remove the now-unused max_mixer_width field from the HW catalog
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_14_msm8937.h | 1
On Wed, May 14, 2025 at 04:52:31PM -0700, Jessica Zhang wrote:
> Validate requested mode and topology based on the PINGPONG or DSC encoder
> max width. In addition, drop MAX_HDISPLAY_SPLIT and base LM reservation
> off of PINGPONG or DSC encoder max width
Separate commit for num_lm, please.
>
>
On Wed, May 14, 2025 at 04:52:30PM -0700, Jessica Zhang wrote:
> Add max_dsc_encoder_width to dpu_caps struct and max_linewidth to
> dpu_pingpong_cfg for all chipsets within the HW catalog.
>
> Note: The max supported PINGPONG width was 4096 but increased to 5120
> after DPU 6.x. In addition, DPU
On Thu, 15 May 2025 at 02:52, Jessica Zhang
wrote:
>
> Since the max mixer width is not a strict hardware limit, use the actual
Is it? What is the actual max width that the mixer can support?
> hardware limit (the writeback maxlinewidth) to filter modes.
>
> Signed-off-by: Jessica Zhang
> ---
>
On 5/13/25 6:06 AM, Byungchul Park wrote:
llist_head and llist_node can be used by very primitives. For example,
I suppose you mean "every primitives". Right? However, the term
"primitive" may sound strange. Maybe just saying that it is used by some
other header files.
Cheers,
Longman
dep
Drop the unused maxwidth field from the dpu_lm_sub_blks struct
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalo
Remove the now-unused max_mixer_width field from the HW catalog
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_14_msm8937.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_15_msm8917.h | 1 -
drivers
Since the max mixer width is not a strict hardware limit, use the actual
hardware limit (the writeback maxlinewidth) to filter modes.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers
Validate requested mode and topology based on the PINGPONG or DSC encoder
max width. In addition, drop MAX_HDISPLAY_SPLIT and base LM reservation
off of PINGPONG or DSC encoder max width
As noted in the patch, while DPU 8.x+ supports a max linewidth of 8960
for PINGPONG_0, there is some additional
Add max_dsc_encoder_width to dpu_caps struct and max_linewidth to
dpu_pingpong_cfg for all chipsets within the HW catalog.
Note: The max supported PINGPONG width was 4096 but increased to 5120
after DPU 6.x. In addition, DPU 8.x+ increases the max supported width
of PINGPONG_0 specifically to 8960
Currently, the DPU driver bases LM reservation off of the maximum
supported width for the layer mixer and an arbitrary MAX_HDISPLAY_SPLIT.
However, these limits are not hardware limits meaning that a single LM
can support higher resolutions.
Switch to basing LM reservation off of PINGPONG and DSC
Hi, Dave & Daniel:
This includes:
1. Prepare for support MT8195/88 HDMIv2 and DDCv2
2. DPI: Cleanups and add support for more formats
3. Cleanups and sanitization
4. Replace custom compare_dev with component_compare_of
Regards,
Chun-Kuang.
The following changes since commit 0af2f6be1b4281385b618
Hi Laurent,
On 25-05-15, Laurent Pinchart wrote:
> Hi Marco,
>
> On Thu, May 15, 2025 at 12:24:53AM +0200, Marco Felsch wrote:
> > Make use of __free(device_node) to simplify the of_node_put() error
> > handling paths. No functional changes.
> >
> > Signed-off-by: Marco Felsch
> > ---
> > driv
Hi Laurent,
On 25-05-15, Laurent Pinchart wrote:
> Hi Marco,
>
> Thank you for the patch.
>
> On Thu, May 15, 2025 at 12:24:51AM +0200, Marco Felsch wrote:
> > Make use of the drm_bridge::driver_private data instead of
> > container_of() wrapper.
>
> I suppose this is a personal preference, but
Hi Marco,
Thank you for the patch.
On Thu, May 15, 2025 at 12:24:51AM +0200, Marco Felsch wrote:
> Make use of the drm_bridge::driver_private data instead of
> container_of() wrapper.
I suppose this is a personal preference, but I like usage of
container_of() better. In my opinion it conveys bet
Hi Marco,
On Thu, May 15, 2025 at 12:24:53AM +0200, Marco Felsch wrote:
> Make use of __free(device_node) to simplify the of_node_put() error
> handling paths. No functional changes.
>
> Signed-off-by: Marco Felsch
> ---
> drivers/gpu/drm/bridge/fsl-ldb.c | 24 +---
> 1 file
Hi Marco,
Thank you for the patch.
On Thu, May 15, 2025 at 12:24:52AM +0200, Marco Felsch wrote:
> Make use of dev_err_probe() to easily spot issues via the debugfs or
> kernel log. No functional changes.
>
> Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/
Make use of __free(device_node) to simplify the of_node_put() error
handling paths. No functional changes.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/fsl-ldb.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/fsl-ldb
Hi,
just a small series to cleanup the fsl-ldb lvds bridge driver a bit.
Regards,
Marco
Marco Felsch (3):
drm/bridge: fsl-ldb: make use of driver_private
drm/bridge: fsl-ldb: make use of dev_err_probe
drm/bridge: fsl-ldb: simplify device_node error handling
drivers/gpu/drm/bridge/fsl-ldb
Make use of the drm_bridge::driver_private data instead of
container_of() wrapper.
No functional changes.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/fsl-ldb.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/driver
Make use of dev_err_probe() to easily spot issues via the debugfs or
kernel log. No functional changes.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/fsl-ldb.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/dri
On Wed, May 14, 2025 at 2:00 PM Song Liu wrote:
>
> On Tue, May 13, 2025 at 9:36 AM T.J. Mercier wrote:
> >
> > Use the same test buffers as the traditional iterator and a new BPF map
> > to verify the test buffers can be found with the open coded dmabuf
> > iterator.
> >
> > Signed-off-by: T.J.
On Wed, May 14, 2025 at 1:53 PM Song Liu wrote:
>
> On Tue, May 13, 2025 at 9:36 AM T.J. Mercier wrote:
> >
> > This test creates a udmabuf, and a dmabuf from the system dmabuf heap,
> > and uses a BPF program that prints dmabuf metadata with the new
> > dmabuf_iter to verify they can be found.
>
On Wed, May 14, 2025 at 4:48 PM Leonardo Gomes
wrote:
>
> Adjust get_value function in hw_hpd.c file to have
> prefix to help in ftrace, the name change from
> 'get_value' to 'dal_hw_gpio_get_value'
This won't compile. dal_hw_gpio_get_value is already defined in
drivers/gpu/drm/amd/display/dc/gp
On Fri, 25 Apr 2025 12:51:50 +0300, Dmitry Baryshkov wrote:
> The LCDC controller uses pixel clock provided by the multimedia clock
> controller (mmcc) instead of using LVDS PHY clock directly. Link LVDS
> clocks properly, taking MMCC into account.
>
> MDP4 uses custom code to handle LVDS panel.
On Tue, May 13, 2025 at 9:36 AM T.J. Mercier wrote:
>
> Use the same test buffers as the traditional iterator and a new BPF map
> to verify the test buffers can be found with the open coded dmabuf
> iterator.
>
> Signed-off-by: T.J. Mercier
> Acked-by: Christian König
> Acked-by: Song Liu
> ---
On Tue, May 13, 2025 at 9:36 AM T.J. Mercier wrote:
>
> This test creates a udmabuf, and a dmabuf from the system dmabuf heap,
> and uses a BPF program that prints dmabuf metadata with the new
> dmabuf_iter to verify they can be found.
>
> Signed-off-by: T.J. Mercier
> Acked-by: Christian König
In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x8000,
cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's
then passed to fb_cvt_hperiod(), where it's used as a divider -- division
by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to
av
+ * DEPT(DEPendency Tracker) - Runtime dependency tracker
+ *
+ * Started by Byungchul Park :
+ *
+ * Copyright (c) 2020 LG Electronics, Inc., Byungchul Park
+ *
+ * DEPT provides a general way to detect deadlock possibility in runtime
+ * and the interest is not limited to typical lock but t
On 14/05/2025 23:05, Konrad Dybcio wrote:
On 5/14/25 9:23 PM, Dmitry Baryshkov wrote:
On Wed, May 14, 2025 at 05:10:33PM +0200, Konrad Dybcio wrote:
From: Konrad Dybcio
The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
swizzling) is what we want on this platform (and others
On Wed, May 14, 2025 at 10:09:35PM +0200, Konrad Dybcio wrote:
> On 5/14/25 9:24 PM, Dmitry Baryshkov wrote:
> > On Wed, May 14, 2025 at 05:10:34PM +0200, Konrad Dybcio wrote:
> >> From: Konrad Dybcio
> >>
> >> Make the values a bit more meaningful.
> >
> > Not sure if it's more meaningful or not
On 14/05/2025 17:19, Melissa Wen wrote:
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/
On Wed, May 14, 2025 at 05:10:32PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> On A663 (SA8775P) the value matches exactly.
>
> On A610, the value matches on SM6115, but is different on SM6125. That
> turns out not to be a problem, as the bits that differ aren't even
> interpreted.
We
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
v3:
- remove uneccessary include (jani)
- use dc_edid_sink_edid_free in link_detection
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 6 ++
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.h | 1 +
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it available at the DRM level
by wrapping exi
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
v3:
- rebase on top of asdn
Signed-off-by: Rodrigo Siqueira
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
v3:
- remove superfulous cast (jani)
Signed-off-by: Rodrigo Siqueira
Co-developer--by: Melissa W
drm_edid_connector_update() updates display info, filling ELD with audio
info from Short-Audio Descriptors in the last step of
update_dislay_info(). Our goal is stopping using raw edid, so we can
extract SAD from drm_eld instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
There is an opaque obj in Linux/DRM to encapsulate edid data as
`drm_edid`. This obj isn't present in other platforms but we need to
pass it through DC when adding sink. To pass this data without
compromise the independence of DC code, make some DC functions accept
edid data as private options.
Si
drm_edid_connector_update() updates display info, filling ELD with
speaker allocation data in the last step of update_dislay_info(). Our
goal is stopping using raw edid, so we can extract SADB from drm_eld
instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
.../drm/amd/d
Make sure the drm_edid container stored in aconnector is freed when
destroying the aconnector.
Fixes: 48edb2a4 ("drm/amd/display: switch amdgpu_dm_connector to use struct
drm_edid")
Reviewed-by: Mario Limonciello
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 18 +++
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15
Hi,
Siqueira and I have been working on a solution to reduce the usage of
drm_edid_raw in the AMD display driver, since the current guideline in
the DRM subsystem is to stop handling raw edid data in driver-specific
implementation and use opaque `drm_edid` object with common-code
helpers.
In shor
Original drm_edid_get_monitor_name encapsulates raw edid in drm_edid and
then call get_monitor_name. AMD still stores the display name for
debugging, but it is migrating to drm_edid, on the other hand,
drm_dp_mst_topology and sil-sii8620 still use the raw edid version.
Split drm_edid_get_monitor_n
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/d
Groundwork that allocates a temporary drm_edid from raw edid to take
advantage of DRM common-code helpers instead of driver-specific code.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
Hi Dmitry,
It turned out that attaching backing during restoring process was skipped due to
obj->attach == true condition, which is the reason for the err messages you
reported.
I had tested my patch on slightly older virtio-gpu driver that didn't have this
flag
(was added by one of your commits
>
> The lock might be held already by the driver or by TTM when things are called
> from TTM callbacks.
>
> This is why GPUVM never takes locks by itself, but asserts that the correct
> lock
> is held.
>
> I think we really want to get proof by the driver by providing lock guard
> references.
On 5/14/25 9:24 PM, Dmitry Baryshkov wrote:
> On Wed, May 14, 2025 at 05:10:34PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio
>>
>> Make the values a bit more meaningful.
>
> Not sure if it's more meaningful or not. In the end, we all can read hex
> masks.
0x1d7efc35
magic constants are n
On Wed, 14 May 2025 17:47:12 +0800
Xu Yilun wrote:
> On Tue, May 13, 2025 at 01:03:15PM +0300, Zhi Wang wrote:
> > On Mon, 12 May 2025 11:06:17 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy
> > > wrote:
> > >
> > > > > > I'm surprised
On 5/14/25 9:23 PM, Dmitry Baryshkov wrote:
> On Wed, May 14, 2025 at 05:10:33PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio
>>
>> The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
>> swizzling) is what we want on this platform (and others with a UBWC
>> 1.0 encoder).
>>
On Wed, May 14, 2025 at 12:15 PM Dmitry Baryshkov
wrote:
>
> On Wed, May 14, 2025 at 05:10:27PM +0200, Konrad Dybcio wrote:
> > From: Konrad Dybcio
> >
> > This bit is set iff the UBWC version is 1.0. That notably does not
> > include QCM2290's "no UBWC".
> >
> > Signed-off-by: Konrad Dybcio
> >
From: Rob Clark
As with devcoredump, we need to iterate the VMAs to figure out what to
dump.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drive
On Wed, May 14, 2025 at 05:10:35PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> In preparation to resolve the issue of hardcoding HBB, throw a warning
> if the value is being overwritten in the GPU driver.
>
> The HBB value is directly correlated with the memory configuration.
> On plat
On Wed, May 14, 2025 at 05:10:34PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Make the values a bit more meaningful.
Not sure if it's more meaningful or not. In the end, we all can read hex
masks.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/ubwc_config.c | 33 +++
On Wed, May 14, 2025 at 05:10:33PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
> swizzling) is what we want on this platform (and others with a UBWC
> 1.0 encoder).
>
> Fix it to make mesa happy (the hardware doesn't
On Wed, May 14, 2025 at 05:10:31PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Now that Adreno specifics are out of the way, use the common config
> (but leave the HBB hardcoding in place until that is wired up on the
> other side).
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gp
On Wed, May 14, 2025 at 05:10:30PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> It's only necessary for some lower end parts.
> Also rename it to min_acc_len_64b to denote that if set, the minimum
> access length is 64 bits, 32b otherwise.
>
> Signed-off-by: Konrad Dybcio
> ---
> driv
On Wed, May 14, 2025 at 05:10:25PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The bit must be set to 1 if the UBWC encoder version is >= 3.0, drop it
> as a separate field.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++-
> 1 file cha
On Wed, May 14, 2025 at 05:10:29PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> It's supposed to be on when the UBWC encoder version is >= 4.0.
> Drop the per-GPU assignments.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 ++-
> 1 file changed,
On Wed, May 14, 2025 at 05:10:28PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> ubwc_swizzle is a bitmask. Check for a bit to make it more obvious.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Wed, May 14, 2025 at 05:10:27PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> This bit is set iff the UBWC version is 1.0. That notably does not
> include QCM2290's "no UBWC".
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file changed, 1
On Wed, May 14, 2025 at 05:10:26PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Instead of setting it on a gpu-per-gpu basis, converge it to the
> intended "is A650 family or A7xx".
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++-
> 1 f
On Wed, May 14, 2025 at 05:10:23PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> As discussed a lot in the past, the UBWC config must be coherent across
> a number of IP blocks (currently display and GPU, but it also may/will
> concern camera/video as the drivers evolve).
>
> So far, we'
On Wed, May 14, 2025 at 05:10:22PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The Adreno part of the driver exposes this value to userspace, and the
> SMEM data source also presents a x+13 value. Keep things coherent and
> make the value uniform across them.
>
> Signed-off-by: Konrad
On Wed, May 14, 2025 at 05:10:21PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Add a file that will serve as a single source of truth for UBWC
> configuration data for various multimedia blocks.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/Kconfig | 8 ++
> drive
From: Rob Clark
In the next commit, a way for userspace to opt-in to userspace managed
VM is added. For this to work, we need to defer creation of the VM
until it is needed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c
From: Rob Clark
Most of the driver code doesn't need to reach in to msm specific fields,
so just use the drm_gpuvm/drm_gpuva types directly. This should
hopefully improve commonality with other drivers and make the code
easier to understand.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/ad
Hi Dave, Simona,
Fixes for 6.15.
The following changes since commit 82f2b0b97b36ee3fcddf0f0780a9a0825d52fec3:
Linux 6.15-rc6 (2025-05-11 14:54:11 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.15-2025-05-14
for you to fe
From: Rob Clark
Add a VM_BIND ioctl for binding/unbinding buffers into a VM. This is
only supported if userspace has opted in to MSM_PARAM_EN_VM_BIND.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c|1 +
drivers/gpu/drm/msm/msm_drv.h|4 +-
drivers/gpu/drm/ms
From: Rob Clark
If userspace has opted-in to VM_BIND, then GPU hangs and VM_BIND errors
will mark the VM as unusable.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 17 +
drivers/gpu/drm/msm/msm_gem_submit.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c|
From: Rob Clark
We'll re-use this in the vm_bind path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 12 ++--
drivers/gpu/drm/msm/msm_gem.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem
From: Rob Clark
Bump version to signal to userspace that VM_BIND is supported.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bdf775897de8..7100
From: Rob Clark
It is standing in the way of drm_gpuvm / VM_BIND support. Not to
mention frequently broken and rarely tested. And I think only needed
for a 10yr old not quite upstream SoC (msm8974).
Maybe we can add support back in later, but I'm doubtful.
Signed-off-by: Rob Clark
---
drive
From: Rob Clark
Any place we wait for a BO to become idle, we should use BOOKKEEP usage,
to ensure that it waits for _any_ activity.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 +-
2 files changed, 4 insertions(+),
From: Rob Clark
Now that we've dropped vram carveout support, we can collapse vma
allocation and initialization. This better matches how things work
with drm_gpuvm.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 30 +++---
drivers/gpu/drm/msm/msm_gem.h
On 13.05.25 19:48, Liam R. Howlett wrote:
* David Hildenbrand [250512 08:34]:
The "memramp() shrinking" scenario no longer applies, so let's remove
that now-unnecessary handling.
Reviewed-by: Lorenzo Stoakes
Acked-by: Ingo Molnar # x86 bits
Signed-off-by: David Hildenbrand
small comment,
From: Rob Clark
See commit a414fe3a2129 ("drm/msm/gem: Drop obj lock in
msm_gem_free_object()") for justification.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gpuvm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/d
On Wednesday, 14 May 2025 17:18:22 Central European Summer Time Tomeu Vizoso
wrote:
> Hi Nicolas,
>
> Thanks for looking at this. Some thoughts below:
>
> On Fri, Apr 25, 2025 at 8:50 PM Nicolas Frattaroli
> wrote:
> >
> > On Tuesday, 25 February 2025 08:55:47 Central European Summer Time Tomeu
From: Rob Clark
Add a SET_PARAM for userspace to request to manage to the VM itself,
instead of getting a kernel managed VM.
In order to transition to a userspace managed VM, this param must be set
before any mappings are created.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_g
From: Rob Clark
Buffers that are not shared between contexts can share a single resv
object. This way drm_gpuvm will not track them as external objects, and
submit-time validating overhead will be O(1) for all N non-shared BOs,
instead of O(n).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm
From: Rob Clark
This resolves a potential deadlock vs msm_gem_vm_close(). Otherwise for
_NO_SHARE buffers msm_gem_describe() could be trying to acquire the
shared vm resv, while already holding priv->obj_lock. But _vm_close()
might drop the last reference to a GEM obj while already holding the
From: Rob Clark
In this case, we need to iterate the VMAs looking for ones with
MSM_VMA_DUMP flag.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 96 ++-
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c
From: Rob Clark
We'll be re-using these for the VM_BIND ioctl.
Also, rename a few things in the uapi header to reflect that syncobj use
is not specific to the submit ioctl.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/msm_gem_submit.c | 192 ++
From: Rob Clark
Add PRR (Partial Resident Region) is a bypass address which make GPU
writes go to /dev/null and reads return zero. This is used to implement
vulkan sparse residency.
To support PRR/NULL mappings, we allocate a page to reserve a physical
address which we know will not be used as
From: Rob Clark
In situations where mapping/unmapping sequence can be controlled by
userspace, attempting to map over a region that has not yet been
unmapped is an error. But not something that should spam dmesg.
Now that there is a quirk, we can also drop the selftest_running
flag, and use the
From: Rob Clark
Only needs to be supported for iopgtables mmu, the other cases are
either only used for kernel managed mappings (where offset is always
zero) or devices which do not support sparse bindings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpummu.c | 5 -
drive
1 - 100 of 244 matches
Mail list logo
