Hi Danilo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on 48075a66fca613477ac1969b576a93ef5db0164f]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers/20230217-215101
base
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(-)
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 --
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
Hi Danilo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on 48075a66fca613477ac1969b576a93ef5db0164f]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers/20230217-215101
base
Hi Danilo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on 48075a66fca613477ac1969b576a93ef5db0164f]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers/20230217-215101
base
From: John Harrison
There are multiple ways in which the GuC load can fail. The driver was
reporting the status register as is, but not everyone can read the
matrix unfiltered. So add decoding of the common error cases.
Also, remove the comment about interrupt based load completion
checking bein
From: John Harrison
A failure to load the GuC is occasionally observed where the GuC log
actually showed that the GuC had loaded just fine. The implication
being that the load just took ever so slightly longer than the 200ms
timeout. Given that the actual time should be tens of milliseconds at
th
From: John Harrison
Add more decoding of the GuC load failures. Also include information
about GT frequency to see if timeouts are due to a failure to boost
the clocks. Finally, increase the timeout to accommodate situations
where the clock boost does fail.
Signed-off-by: John Harrison
John H
On Fri, Feb 17, 2023 at 12:45 PM Rodrigo Vivi wrote:
>
> On Fri, Feb 17, 2023 at 09:00:49AM -0800, Rob Clark wrote:
> > On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 17/02/2023 14:55, Rob Clark wrote:
> > > > On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
> > > >
Hi Dave, Daniel,
Fixes for 6.3. The big change here is the splitting of dc_link.c into
multiple smaller files.
The following changes since commit 69ed0c5d44d72051b13e65384e9d9354c45d5e14:
Revert "drm/amd/display: disable S/G display on DCN 3.1.4" (2023-02-03
15:42:42 -0500)
are available in
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kerne
From: John Harrison
Improve failure code handling during GuC intialisation.
v2: Fix function naming and improve on/off balancing (review feedback
from Daniele)
Signed-off-by: John Harrison
John Harrison (2):
drm/i915/guc: Improve clean up of busyness stats worker
drm/i915/guc: Fix missin
From: John Harrison
The stats worker thread management was mis-matched between
enable/disable call sites. Fix those up. Also, abstract the
cancel/enable code into a helper function rather than replicating in
multiple places.
v2: Rename the helpers and wrap the enable as well as the cancel
(revie
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:
Hi all,
[I thought I've sent this out earlier this week, but alas got stuck, kinda
bad timing now since I'm out next week but oh well]
So xe is a quite substantial thing, and I think we need a clear plan how to land
this or it will take forever, and managers will panic. Also I'm not a big fan of
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 Fri, Feb 17, 2023 at 09:00:49AM -0800, Rob Clark wrote:
> On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 17/02/2023 14:55, Rob Clark wrote:
> > > On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
> > > wrote:
> > >>
> > >>
> > >> On 16/02/2023 18:19, Rodrigo Vivi wrote:
>
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 1/24/2023 17:01, Ceraolo Spurio, Daniele wrote:
On 1/11/2023 5:54 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission reque
Applied. Thanks!
Alex
On Wed, Feb 15, 2023 at 8:09 PM Thomas Weißschuh wrote:
>
> Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> the driver core allows the usage of const struct kobj_type.
>
> Take advantage of this to constify the structure definitions to prevent
> modif
Applied. Thanks!
Alex
On Thu, Feb 16, 2023 at 1:59 AM Christian König
wrote:
>
> Am 16.02.23 um 02:07 schrieb Thomas Weißschuh:
> > Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
> > the driver core allows the usage of const struct kobj_type.
> >
> > Take advantage of this
On 1/24/2023 16:55, Ceraolo Spurio, Daniele wrote:
On 1/11/2023 5:54 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The stats worker thread management was mis-matched between
enable/disable call sites. Fix those up. Also, abstract the cancel
code into a helper function rather than re
Applied. Thanks!
Alex
On Fri, Feb 17, 2023 at 2:46 AM Jiapeng Chong
wrote:
>
> No functional modification involved.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:1199: warning:
> expecting prototype for dc_link_detect_connection_type(). Prototype was for
> link_detect_con
Am 17.02.23 um 20:38 schrieb Daniel Vetter:
On Fri, Feb 17, 2023 at 11:01:18AM +0100, Stanislaw Gruszka wrote:
On Fri, Feb 17, 2023 at 10:22:25AM +0100, Christian König wrote:
Am 16.02.23 um 20:54 schrieb Daniel Vetter:
On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
On Thu, 16 F
On Fri, Feb 17, 2023 at 04:22:04PM +, Simon Ser wrote:
> v2: mention caps, note that the IOCTLs might fail, document that
> user-space needs a data structure to keep track of the
> handles (Daniel V.)
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
Am 17.02.23 um 20:42 schrieb Daniel Vetter:
On Fri, Feb 17, 2023 at 04:55:27PM +0100, Christian König wrote:
Am 17.02.23 um 13:37 schrieb Jani Nikula:
On Fri, 17 Feb 2023, Christian König wrote:
If i915 have such structural problems then I strongly suggest to solve
them inside i915 and not ma
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.
Some vague evidences suggests this can go wrong. Try to prevent it by
holding the right mutex and clearing ->deferred_setup to make sure we
later on don't accidentally try to re-register the fbdev when the
driver thought it had it all cleaned up already.
v2: I realized that this is fundamentally b
On Fri, Feb 17, 2023 at 02:44:09PM +0100, Danilo Krummrich wrote:
> \#define SAMPLE_ITER(name, __mgr) \
> struct sample_iter name = { \
> .mas = __MA_STATE(&(__mgr)->mt, 0, 0),
This is usually called MA_STATE_INIT()
> #define sample_iter_for_each_range(it__, start__, end__) \
On Fri, Feb 17, 2023 at 04:55:27PM +0100, Christian König wrote:
> Am 17.02.23 um 13:37 schrieb Jani Nikula:
> > On Fri, 17 Feb 2023, Christian König
> > wrote:
> > > If i915 have such structural problems then I strongly suggest to solve
> > > them inside i915 and not make common code out of that
On Fri, Feb 17, 2023 at 02:44:10PM +0100, Danilo Krummrich wrote:
> Generic components making use of the maple tree (such as the
> DRM GPUVA Manager) delegate the responsibility of ensuring mutual
> exclusion to their users.
>
> While such components could inherit the concept of an external lock,
On Fri, Feb 17, 2023 at 11:01:18AM +0100, Stanislaw Gruszka wrote:
> On Fri, Feb 17, 2023 at 10:22:25AM +0100, Christian König wrote:
> > Am 16.02.23 um 20:54 schrieb Daniel Vetter:
> > > On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> > > > On Thu, 16 Feb 2023, Christian König wrot
On Fri, 17 Feb 2023 at 13:06, Christian König
wrote:
>
> Am 16.02.23 um 15:34 schrieb Daniel Vetter:
> > On Thu, Jan 26, 2023 at 03:30:31PM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 26.01.23 um 11:28 schrieb Christian König:
> >>> We reference dump buffers both by their handle as well a
MTL's primary GT can continue to use the same engine TLB invalidation
programming as past Xe_HP-based platforms. However the media GT needs
some special handling:
* Invalidation registers on the media GT are singleton registers
(unlike the primary GT where they are still MCR).
* Since the GSC
* Danilo Krummrich [230217 08:44]:
> Split up the MA_STATE() macro such that components using the maple tree
> can easily inherit from struct ma_state and build custom tree walk
> macros to hide their internals from users.
>
> Example:
>
> struct sample_iter {
> struct ma_state mas;
>
On 07/02/2023 10.09, Rasmus Villemoes wrote:
> I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
> to probe with these settings
>
[...]
> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
> that's a separate issue; when I boot with a monitor attached, i
* Danilo Krummrich [230217 08:44]:
> Generic components making use of the maple tree (such as the
> DRM GPUVA Manager) delegate the responsibility of ensuring mutual
> exclusion to their users.
>
> While such components could inherit the concept of an external lock,
> some users might just serial
Hi,
This series resolve some of the warnings that appear when compiling AMDGPU
with W=1.
Each patch is focused in a specific warning.
This is my First Patch for the GSoC Project Idea about increasing code
coverage of the DRM code[1].
Thanks for reviewing!
Best regards,
Arthur Grillo
[1]: http
On 2/16/2023 7:13 AM, Jacek Lawrynowicz wrote:
Hi,
On 06.02.2023 16:41, Jeffrey Hugo wrote:
Add the QAIC driver uapi file and core driver file that binds to the PCIe
device. The core driver file also creates the accel device and manages
all the interconnections between the different parts of t
Remove a couple of local variables that are only set but never used,
also remove an static utility function that is never used in consequence
of the variable removal.
This decrease the number of -Wunused-but-set-variable warnings.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/amd/display/dc/dcn3
Remove local variables that were just set but were never used. This
decrease the number of -Wunused-but-set-variable warnings.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_link_encoder.c | 3 +--
drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c | 7 -
Make implicit enum conversion to avoid -Wenum-conversion warning, such
as:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:4109:88:
warning: implicit conversion from ‘enum ’ to ‘enum
odm_combine_mode’ [-Wenum-conversion]
4109 |
On 2/17/2023 00:39, Hogander, Jouni wrote:
On Wed, 2023-02-15 at 17:10 -0800, john.c.harri...@intel.com wrote:
From: John Harrison
Instruction from hardware arch is that stolen memory and BAR mappings
are unsafe for use as ring buffers. There can be issues with cache
aliasing due to the CPU ac
On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
wrote:
>
>
> On 17/02/2023 14:55, Rob Clark wrote:
> > On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 16/02/2023 18:19, Rodrigo Vivi wrote:
> >>> On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
> On Fri, F
On Tue, 27 Dec 2022 09:10, "" wrote:
>This is a preparation for adding support for the ovl_adaptor sub driver
>Ovl_adaptor is a DRM sub driver, which doesn't have dma dev. Add
>dma_dev_get function for getting representative dma dev in ovl_adaptor.
>
>Signed-off-by: Nancy.Lin
>Reviewed-by: AngeloG
On Tue, 27 Dec 2022 09:10, "" wrote:
Hi Nancy.
I've been using your patches lately to test out the HDMI series on
mt8195 and I have hit a scheduling bug.
>Add ovl_adaptor driver for MT8195.
>Ovl_adaptor is an encapsulated module and designed for simplified
>DRM control flow. This module is compo
v2: mention caps, note that the IOCTLs might fail, document that
user-space needs a data structure to keep track of the
handles (Daniel V.)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Daniel Stone
---
include/uapi/drm/drm.h | 30 ++
1 file cha
There are two important details missing from the docs:
- If the memory object backing the FB already has a GEM handle,
it's not re-used, a new one is generated.
- Aliased planes will return the same GEM handle.
v2: document how user-space can obtain DMA-BUF FDs without leaking
handles (Pekka)
On Fri, Feb 17, 2023, at 16:38, Andrzej Hajda wrote:
> On 17.02.2023 13:46, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> With gcc-7 and earlier, there are lots of warnings like
>>
>> In file included from :0:0:
>> In function '__guc_context_policy_add_priority.isra.66',
>> inlined from
On 2/8/2023 3:01 PM, Jeffrey Hugo wrote:
On 2/6/2023 8:41 AM, Jeffrey Hugo wrote:
Regarding the open userspace (see the documentation patch), the UMD and
compiler are a week or so away from being posted in the indicated repos.
Just need to polish some documentation.
An update to this, the comp
On Fri, Feb 17, 2023 at 01:46:50PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With gcc-7 and earlier, there are lots of warnings like
>
> In file included from :0:0:
> In function '__guc_context_policy_add_priority.isra.66',
> inlined from '__guc_context_set_prio.isra.67' at
> dr
On 17/02/2023 14:55, Rob Clark wrote:
On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
wrote:
On 16/02/2023 18:19, Rodrigo Vivi wrote:
On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
In i915 we have t
Am 17.02.23 um 14:44 schrieb Danilo Krummrich:
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary
Am 17.02.23 um 13:37 schrieb Jani Nikula:
On Fri, 17 Feb 2023, Christian König wrote:
If i915 have such structural problems then I strongly suggest to solve
them inside i915 and not make common code out of that.
All other things aside, that's just a completely unnecessary and
unhelpful remark.
On 2/15/2023 5:11 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Sig
On 2/15/2023 5:11 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safe
On 17.02.2023 13:46, Arnd Bergmann wrote:
From: Arnd Bergmann
With gcc-7 and earlier, there are lots of warnings like
In file included from :0:0:
In function '__guc_context_policy_add_priority.isra.66',
inlined from '__guc_context_set_prio.isra.67' at
drivers/gpu/drm/i915/gt/uc/intel_guc
On Sat, Feb 04, 2023 at 09:30:37PM +0800, Pin-yen Lin wrote:
[..]
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
[..]
> +static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,
> + enum typec_orie
Hi
Am 17.02.23 um 15:42 schrieb Tomi Valkeinen:
On 09/02/2023 17:41, Thomas Zimmermann wrote:
Enable the primary plane for tidss hardware via atomic_enable.
Atomic helpers invoke this callback only when the plane becomes
active.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tid
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 Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
wrote:
>
>
> On 16/02/2023 18:19, Rodrigo Vivi wrote:
> > On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
> >> On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> >> wrote:
> >>>
> >>> From: Tvrtko Ursulin
> >>>
> >>> In i915 we have this co
On 09/02/2023 17:41, Thomas Zimmermann wrote:
Enable the primary plane for tidss hardware via atomic_enable.
Atomic helpers invoke this callback only when the plane becomes
active.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_plane.c | 11 +++
1 file changed, 11 i
On 09/02/2023 17:41, Thomas Zimmermann wrote:
Calls to dispc_plane_setup() and dispc_plane_enable() cannot fail.
Remove the return value.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_dispc.c | 12
drivers/gpu/drm/tidss/tidss_dispc.h | 8
drivers/gp
This is a note to let you know that I've just added the patch titled
drm: Disable dynamic debug as broken
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-disable-dynami
On 2/17/23 14:18, Christian König wrote:
Am 17.02.23 um 14:10 schrieb Thomas Hellström:
[SNIP]
Any chance you could do a quick performance comparison? If not,
anything against merging this without the amd / radeon changes
until we can land a simpler allocator?
Only if you can stick the a
uvmm provides the driver abstraction around the DRM GPU VA manager
connecting it to the nouveau infrastructure.
It handles the split and merge operations provided by the DRM GPU VA
manager for map operations colliding with existent mappings and takes
care of the driver specific locking around the
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that th
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the add
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and usersp
Initialize the GEM's DRM GPU VA manager interface in preparation for the
(u)vmm implementation, provided by subsequent commits, to make use of it.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouve
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a
Don't call drm_gem_object_get() unconditionally.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_exec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
index ed2106c22786..5713a589a6a3 100644
--- a/drivers/gpu/drm/drm_exec.c
+++
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job wo
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
Split up the MA_STATE() macro such that components using the maple tree
can easily inherit from struct ma_state and build custom tree walk
macros to hide their internals from users.
Example:
struct sample_iter {
struct ma_state mas;
struct sample_mgr *mgr;
struct sample_en
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c |
This patch series provides a new UAPI for the Nouveau driver in order to
support Vulkan features, such as sparse bindings and sparse residency.
Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to
keep track of GPU virtual address (VA) mappings in a more generic way.
The
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with auto
1 - 100 of 199 matches
Mail list logo
