On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
>
>
> On 09.06.2021 19:36, John Harrison wrote:
> > On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> >> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> >>> From: Michal Wajdeczko
> >>>
> >>> Definition of the CTB registration
On Wed, Jun 09, 2021 at 09:36:36PM -0700, Matthew Brost wrote:
> As part of enabling GuC submission [1] we need to update to the latest
> and greatest firmware. This series does that. This is a destructive
> change. e.g. Without all the patches in this series it will break the
> i915 driver. As
From: John Harrison
Signed-off-by: John Harrison
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
From: Michal Wajdeczko
Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.
Both HEAD and TAIL are now in dwords.
Add some ABI documentation and implement required changes.
v2:
(Daniele)
- Drop GUC_CTB_STATUS_NO_BACKCHANNEL,
From: John Harrison
GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
the option for it to be larger.
Signed-off-by: Matthew Brost
Signed-off-by: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 15 ---
From: Michal Wajdeczko
Once CTB descriptor is found in error state, either set by GuC
or us, there is no need continue checking descriptor any more,
we can rely on our internal flag.
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: Piotr Piórkowski
---
From: Michal Wajdeczko
CTB pool is now maintained internally by the GuC as part of its
"private data". No need to allocate separate buffer and pass it
to GuC as yet another ADS.
Signed-off-by: Matthew Brost #v4
Signed-off-by: Michal Wajdeczko
Cc: Janusz Krzysztofik
---
From: Michal Wajdeczko
GuC ABI documentation is now ready to be included in i915.rst
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Cc: Piotr Piórkowski
---
Documentation/gpu/i915.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/gpu/i915.rst
From: Michal Wajdeczko
New GuC does not require it any more.
Reviewed-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: Piotr Piórkowski
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +---
2 files changed, 1
From: Michal Wajdeczko
Format of the STATUS dword in CTB response message now follows
definition of the HXG header. Update our code and remove any
obsolete legacy definitions.
GuC: 55.0.0
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Acked-by: Piotr Piórkowski
Reviewed-by:
From: John Harrison
GuC firmware v53.0.0 introduced per context scheduling policies. This
includes changes to some of the ADS structures which are required to
load the firmware even if not using GuC submission.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
From: Michal Wajdeczko
The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.
Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.
Since some of the new MMIO actions may use DATA0
From: Michal Wajdeczko
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: Michał Winiarski
---
From: Michal Wajdeczko
Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.
v2:
(Checkpoint)
- Fix warnings
(Daniele)
- Drop FIXME
(John H)
- Drop value in kernel doc, just use define
Signed-off-by: Michal Wajdeczko
From: Michal Wajdeczko
Format of the CTB messages has changed:
- support for multiple formats
- message fence is now part of the header
- reuse of unified HXG message formats
v2:
(Daniele)
- Better comment in ct_write()
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Cc:
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. This is a destructive
change. e.g. Without all the patches in this series it will break the
i915 driver. As such, after we review most of these patches they will
squashed into a
On Mon, Jun 07, 2021 at 07:20:01PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > Format of the CTB messages has changed:
> > - support for multiple formats
> > - message fence is now part of the header
> > - reuse
Hi Dave, Daniel,
Fixes for 5.13.
The following changes since commit 614124bea77e452aa6df7a8714e8bc820b489922:
Linux 5.13-rc5 (2021-06-06 15:47:27 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.13-2021-06-09
for you to
On Wed, Jun 9, 2021 at 11:33 PM Dave Airlie wrote:
>
> On Thu, 10 Jun 2021 at 13:23, Alex Deucher wrote:
> >
> > On Wed, Jun 9, 2021 at 11:10 PM Dave Airlie wrote:
> > >
> > > From: Dave Airlie
> > >
> > > This fixes 32-bit arm build due to lack of 64-bit divides.
> > >
> > > Fixes:
On Thu, 10 Jun 2021 at 13:23, Alex Deucher wrote:
>
> On Wed, Jun 9, 2021 at 11:10 PM Dave Airlie wrote:
> >
> > From: Dave Airlie
> >
> > This fixes 32-bit arm build due to lack of 64-bit divides.
> >
> > Fixes: cb1c81467af3 ("drm/ttm: flip the switch for driver allocated
> > resources v2")
>
On Wed, Jun 9, 2021 at 11:10 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This fixes 32-bit arm build due to lack of 64-bit divides.
>
> Fixes: cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources
> v2")
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
>
Hi Dave, Daniel,
More new stuff for 5.14.
The following changes since commit 5745d647d5563d3e9d32013ad4e5c629acff04d7:
Merge tag 'amd-drm-next-5.14-2021-06-02' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-06-04 06:13:57
+1000)
are available in the Git repository at:
From: Dave Airlie
This fixes 32-bit arm build due to lack of 64-bit divides.
Fixes: cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources
v2")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, 9 Jun 2021 at 09:30, Arnd Bergmann wrote:
>
> On Tue, Jun 8, 2021 at 6:49 PM Hans Verkuil wrote:
> > On 08/06/2021 18:14, Arnd Bergmann wrote:
> >
> > Right now it is inherent to the driver. It is probably possible to drop
> > support
> > for video overlay devices if CONFIG_FB=n, but it
On Thursday, 10 June 2021 2:05:06 AM AEST Peter Xu wrote:
> On Wed, Jun 09, 2021 at 07:38:04PM +1000, Alistair Popple wrote:
> > On Wednesday, 9 June 2021 4:33:52 AM AEST Peter Xu wrote:
> > > On Mon, Jun 07, 2021 at 05:58:52PM +1000, Alistair Popple wrote:
[...]
> > For thp this means we could
On Wed, Jun 09, 2021 at 04:14:05PM +0200, Michal Wajdeczko wrote:
>
>
> On 07.06.2021 19:31, Matthew Brost wrote:
> > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 27/05/2021 15:35, Matthew Brost wrote:
> >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin
On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 07/06/2021 18:31, Matthew Brost wrote:
> > > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> > >>
> > >> On 27/05/2021 15:35, Matthew Brost
Handling of the interrupt callback lists is done in dpu_core_irq.c,
under the "cb_lock" spinlock. When these operations results in the need
for enableing or disabling the IRQ in the hardware the code jumps to
dpu_hw_interrupts.c, which protects its operations with "irq_lock"
spinlock.
When an
On Wed, Jun 09, 2021 at 03:58:38PM +0200, Michal Wajdeczko wrote:
>
>
> On 08.06.2021 10:39, Tvrtko Ursulin wrote:
> >
> > On 07/06/2021 18:31, Matthew Brost wrote:
> >> On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> >>>
> >>> On 27/05/2021 15:35, Matthew Brost wrote:
>
On 6/9/21 8:00 PM, Leandro Ribeiro wrote:
> Add a small description and document struct fields of
> drm_mode_get_plane.
>
> Signed-off-by: Leandro Ribeiro
> ---
> include/uapi/drm/drm_mode.h | 36
> 1 file changed, 36 insertions(+)
>
> diff --git
Add a small description and document struct fields of
drm_mode_get_plane.
Signed-off-by: Leandro Ribeiro
---
include/uapi/drm/drm_mode.h | 36
1 file changed, 36 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index
In this patch we add a section to document what userspace should do to
find out the CRTC index. This is important as they may be many places in
the documentation that need this, so it's better to just point to this
section and avoid repetition.
Signed-off-by: Leandro Ribeiro
---
v2: possible_crtcs field is a bitmask, not a pointer. Suggested by
Ville Syrjälä
v3: document how userspace should find out CRTC index. Also,
document that field 'gamma_size' represents the number of
entries in the lookup table. Suggested by Pekka Paalanen
and Daniel Vetter
v4: document IN
On Tue, Jun 08, 2021 at 03:53:28PM -0400, Jonathan Marek wrote:
> Document a new phy-type property which will be used to determine whether
> the phy should operate in D-PHY or C-PHY mode.
>
> Signed-off-by: Jonathan Marek
> ---
> .../devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 4
On Tue, Jun 8, 2021 at 8:20 AM Jordan Crouse wrote:
>
> On Tue, Jun 01, 2021 at 03:47:25PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Wire up support to stall the SMMU on iova fault, and collect a devcore-
> > dump snapshot for easier debugging of faults.
> >
> > Currently this is
On Tue, Jun 8, 2021 at 8:12 AM Jordan Crouse wrote:
>
> On Tue, Jun 01, 2021 at 03:47:24PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > For collecting devcoredumps with the SMMU stalled after an iova fault,
> > we need to skip the parts of the GPU state which are normally collected
> >
Hi Dave and Daniel,
Here goes the last pull request towards 5.14.
Mostly it is ADL-P enabling related and a few other things.
drm-intel-next-2021-06-09:
Cross-subsystem Changes:
- x86/gpu: add JasperLake to gen11 early quirks
(Although the patch lacks the Ack info, it has been Acked by
This helper existed to handle the weird corner-cases caused by using
SLAB_TYPESAFE_BY_RCU for backing dma_fence. Now that no one is using
that anymore (i915 was the only real user), dma_fence_get_rcu is
sufficient. The one slightly annoying thing we have to deal with here
is that
The only real-world user of SLAB_TYPESAFE_BY_RCU was i915 and it doesn't
use that anymore so there's no need to be testing it in selftests.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Christian König
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/dma-buf/st-dma-fence-chain.c |
Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request
tracking via RCU"), the i915 driver has used SLAB_TYPESAFE_BY_RCU (it
was called SLAB_DESTROY_BY_RCU at the time) in order to allow RCU on
i915_request. As nifty as SLAB_TYPESAFE_BY_RCU may be, it comes with
some serious
Instead of attempting to recycle a request in to the cache when it
retires, stuff a new one in the cache every time we allocate a request
for some other reason.
Signed-off-by: Jason Ekstrand
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
This appears to break encapsulation by moving an intel_engine_cs
function to a i915_request file. However, this function is
intrinsically tied to the lifetime rules and allocation scheme of
i915_request and having it in intel_engine_cs.c leaks details of
i915_request. We have an abstraction leak
Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request
tracking via RCU"), the i915 driver has used SLAB_TYPESAFE_BY_RCU (it
was called SLAB_DESTROY_BY_RCU at the time) in order to allow RCU on
i915_request. As nifty as SLAB_TYPESAFE_BY_RCU may be, it comes with
some serious
Mention that connectors need to be referenced manually if they are
to be accessed after the iteration has progressed or ended.
Signed-off-by: Simon Ser
---
include/drm/drm_connector.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_connector.h
When link-status changes, send a hotplug uevent which contains the
connector and property ID. That way, user-space can more easily
figure out that only the link-status property of this connector has
been updated.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1
If an hotplug event only updates a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git
When updating a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 ++--
2 files
In drm_connector_register, use drm_sysfs_connector_hotplug_event
instead of drm_sysfs_hotplug_event, because the hotplug event
only updates a single connector.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 23 +++
include/drm/drm_probe_helper.h | 1 +
2 files changed, 24 insertions(+)
diff --git
This function sends a hotplug uevent with a CONNECTOR property.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_sysfs.c | 25 +
include/drm/drm_sysfs.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
When a uevent only updates a single connector, add a CONNECTOR property
to the uevent. This allows user-space to ignore other connectors when
handling the uevent. This is purely an optimization, drivers can still
send a uevent without the CONNECTOR property.
The CONNECTOR property is already set
set_encoder_mode callback is completely unused now. Drop it from
msm_kms_func().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_kms.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 086a2d59b8c8..9484e8b62630
Move a call to mdp5_encoder_set_intf_mode() after
msm_dsi_modeset_init(), removing set_encoder_mode callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
None of the display drivers now implement set_encoder_mode callback.
Stop calling it from the modeset init code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
None of the display drivers now implement set_encoder_mode callback.
Stop calling it from the modeset init code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 2 --
drivers/gpu/drm/msm/dsi/dsi.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_manager.c | 12
Move setting up encoders from set_encoder_mode to
_dpu_kms_initialize_dsi() / _dpu_kms_initialize_displayport(). This
allows us to support not only "single DSI" and "dual DSI" but also "two
independent DSI" configurations. In future this would also help adding
support for multiple DP connectors.
Add two helper functions to be used by display drivers for setting up
encoders.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++
drivers/gpu/drm/msm/dsi/dsi_manager.c | 14 ++
drivers/gpu/drm/msm/msm_drv.h | 12 ++--
3 files
This patchseries adds support for independent DSI config to DPU1 display
subdriver. This results in ability to drop one of msm_kms_funcs
callbacks.
This code was tested on RB5 (dpu, dsi). Neither DP nor MDP5 changes were
tested (thus the RFC tag).
Applied. Thanks!
On Wed, Jun 9, 2021 at 2:48 PM Rodrigo Siqueira
wrote:
>
> On 06/09, Wan Jiabing wrote:
> > Fix the following coccicheck warning:
> > ./drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c:
> > 3539:12-42: duplicated argument to && or ||
> >
Applied. Thanks!
On Wed, Jun 9, 2021 at 2:43 PM Rodrigo Siqueira
wrote:
>
> On 06/08, Wan Jiabing wrote:
> > Fix the following checkincludes.pl warning:
> > ./drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> > 35 #include "dce110_hw_sequencer.h"
> > 69 #include
Applied. Thanks!
On Wed, Jun 9, 2021 at 6:09 AM Jiapeng Chong
wrote:
>
> Use ARRAY_SIZE instead of dividing sizeof array with sizeof an
> element.
>
> Clean up the following coccicheck warning:
>
> ./drivers/gpu/drm/amd/display/dc/core/dc_resource.c:448:47-48: WARNING:
> Use ARRAY_SIZE.
>
>
Move the call to dsi_mgr_phy_enable after checking whether the DSI
interface is slave, so that PHY enablement happens together with the
host enablement.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
Applied. Thanks!
On Wed, Jun 9, 2021 at 6:05 AM Jiapeng Chong
wrote:
>
> Clean up the following includecheck warning:
>
> ./drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c: clk_mgr.h is
> included more than once.
>
> No functional change.
>
> Reported-by: Abaci Robot
> Signed-off-by:
Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
continuous clock mode in the 7nm DSI PHYs.
Signed-off-by: Dmitry Baryshkov
---
Chanes since v3:
- Invert the DSI_LANE_CTRL_HS_REQ_SEL_PHY bit logic, as
On 09.06.2021 19:36, John Harrison wrote:
> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>> From: Michal Wajdeczko
>>>
>>> Definition of the CTB registration action has changed.
>>> Add some ABI documentation and implement required changes.
On Wednesday 09 June 2021 11:21:05 Christian König wrote:
> Am 09.06.21 um 09:10 schrieb Ondrej Zary:
> > On Wednesday 09 June 2021, Christian König wrote:
> >> Am 09.06.21 um 08:57 schrieb Ondrej Zary:
> >>> [SNIP]
> Thanks for the heads up. So the problem with my patch is already fixed,
>
On 08.06.2021 03:23, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko
>>
On Mon, Jun 07, 2021 at 03:42:19PM -0500, Alex Sierra wrote:
> +++ b/include/linux/dax.h
> @@ -243,6 +243,16 @@ static inline bool dax_mapping(struct address_space
> *mapping)
> return mapping->host && IS_DAX(mapping->host);
> }
>
> +static inline bool dax_layout_is_idle_page(struct page
On 06/09, Wan Jiabing wrote:
> Fix the following coccicheck warning:
> ./drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c:
> 3539:12-42: duplicated argument to && or ||
> ./drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c:
> 5677:87-123: duplicated argument to && or ||
On 06/08, Wan Jiabing wrote:
> Fix the following checkincludes.pl warning:
> ./drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> 35 #include "dce110_hw_sequencer.h"
> 69 #include "dce110_hw_sequencer.h"
>
>
> Signed-off-by: Wan Jiabing
> ---
>
If the VMM's (Qemu) memory backend is backed up by memfd + Hugepages
(hugetlbfs and not THP), we have to first find the hugepage(s) where
the Guest allocations are located and then extract the regular 4k
sized subpages from them.
v2: Ensure that the subpage and hugepage offsets are calculated
On Wed, Jun 09, 2021 at 03:58:26PM +0200, Christian König wrote:
> Am 09.06.21 um 15:19 schrieb Daniel Vetter:
> > [SNIP]
> > > Yeah, we call this the lightweight and the heavyweight tlb flush.
> > >
> > > The lighweight can be used when you are sure that you don't have any of
> > > the
> > >
On 6/3/2021 9:48 AM, Matthew Brost wrote:
From: John Harrison
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing everything off.
Although, note that right
On 08.06.2021 02:59, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Definition of the CTB descriptor has changed, leaving only
>> minimal shared fields like HEAD/TAIL/STATUS.
>>
>> Both HEAD and TAIL are now in dwords.
>>
>> Add
On Fri, Mar 26, 2021 at 03:51:31PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Rather than open-coding the vendor extraction operation, use the newly
> introduced helper macro.
>
> Signed-off-by: Thierry Reding
On the first two patches:
Reviewed-by: Daniel Vetter
> ---
>
On 6/9/21 8:29 PM, Christian König wrote:
TTMs buffer objects are based on GEM objects for quite a while
and rely on initializing those fields before initializing the TTM BO.
Noveau now doesn't init the GEM object for internally allocated BOs,
Nouveau
so make sure that we at least
Only for verifying the previous patch with I-G-T. DO NOT MERGE!
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
All the proto-context stuff for context creation exists to allow older
userspace drivers to set VMs and engine sets via SET_CONTEXT_PARAM.
Drivers need to update to use CONTEXT_CREATE_EXT_* for this going
forward. Force the issue by blocking the old mechanism on any future
hardware generations.
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
What we really want to check is that size of the engines array, i.e.
args->size - sizeof(*user) is divisible by the element size, i.e.
sizeof(*user->engines) because that's what's required for computing the
array length right below the check. However, we're currently not doing
this and instead
When the APIs were added to manage VMs more directly from userspace, the
questionable choice was made to allow changing out the VM on a context
at any time. This is horribly racy and there's absolutely no reason why
any userspace would want to do this outside of testing that exact race.
By
When the APIs were added to manage the engine set on a GEM context
directly from userspace, the questionable choice was made to allow
changing the engine set on a context at any time. This is horribly racy
and there's absolutely no reason why any userspace would want to do this
outside of trying
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
There's an extra bit of fun here when it comes to
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
This is the VM equivalent of i915_gem_context_lookup. It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c |
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was
1 - 100 of 248 matches
Mail list logo
