On 28/05/2021 02:03, Paul Cercueil wrote:
The previous commit wrongly assumed that dma_mmap_wc() could be replaced
by pgprot_writecombine() + dma_mmap_pages(). It did work on my setup,
but did not work everywhere.
Use dma_mmap_wc() when the buffer has the write-combine cache attribute,
and
The error code returned from intel_context_create() should be propagated
instead of 0, as done elsewhere in this function.
Fixes: 50d16d44cce4 ("drm/i915/selftests: Exercise context switching in
parallel")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
On Thursday, 27 May 2021 11:04:57 PM AEST Peter Xu wrote:
> On Thu, May 27, 2021 at 01:35:39PM +1000, Alistair Popple wrote:
> > > > + *
> > > > + * @MMU_NOTIFY_EXCLUSIVE: to signal a device driver that the device
> > > > will
> > > > no + * longer have exclusive access to the page. May ignore the
On 5/26/2021 10:58, Matthew Brost wrote:
On Wed, May 26, 2021 at 02:36:18PM +0200, Michal Wajdeczko wrote:
On 26.05.2021 08:42, Matthew Brost wrote:
Ensure H2G buffer updates are visible before descriptor tail updates by
inserting a barrier between the H2G buffer update and the tail. The
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
-
drm/i915/dg1: Add HWMON power support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON entries are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote:
> Goes through all the drivers and deletes the default hook since it's
> the default now.
>
> Signed-off-by: Daniel Vetter
> Cc: Joel Stanley
> Cc: Andrew Jeffery
> Cc: "Noralf Trønnes"
> Cc: Linus Walleij
> Cc: Emma Anholt
> Cc: David
On Tue, May 25, 2021 at 2:02 AM Douglas Anderson wrote:
> Now that we have an eDP controller that lists aux-bus, we can safely
> add an example to the aux-bus bindings.
>
> NOTE: this example is just a copy of the one in the 'ti-sn65dsi86'
> one. It feels useful to have the example in both
On Tue, May 25, 2021 at 2:02 AM Douglas Anderson wrote:
> The patch ("dt-bindings: drm: Introduce the DP AUX bus") talks about
> how using the DP AUX bus is better than learning how to slice
> bread. Let's add it to the ti-sn65dsi86 bindings.
>
> Signed-off-by: Douglas Anderson
(...)
>
On Mon, May 24, 2021 at 3:19 PM Maxime Ripard wrote:
> The new gpiod interface takes care of parsing the GPIO flags and to
> return the logical value when accessing an active-low GPIO, so switching
> to it simplifies a lot the driver.
>
> Signed-off-by: Maxime Ripard
Thanks for fixing this!
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
-
drm/i915/dg1: Add HWMON power support
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON entries are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
On 21/05/2021 15:49, Vinod Koul wrote:
Display Stream Compression (DSC) is one of the hw blocks in dpu, so add
support by adding hw blocks for DSC
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/Makefile | 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 26 +++
On 21/05/2021 15:49, Vinod Koul wrote:
DSC needs some configuration from device tree, add support to read and
store these params and add DSC structures in msm_drv
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 170 +
On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo wrote:
>
> On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote:
> >
> > Hello Jeff,
> >
> > On 21-05-21, 08:09, Jeffrey Hugo wrote:
> > > On Fri, May 21, 2021 at 6:50 AM Vinod Koul wrote:
> > > >
> > > > Display Stream Compression (DSC) compresses the
Attach a top-level bridge to each encoder, which will be used for
negociating the bus format and flags.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 98 ++-
1 file changed, 77 insertions(+), 21 deletions(-)
diff --git
A lot of devices with an Ingenic SoC have a weird LCD panel attached,
where the pixels are not square. For instance, the AUO A030JTN01 and
Innolux EJ030NA panels have a resolution of 320x480 with a 4:3 aspect
ratio.
All userspace applications are built with the assumption that the
pixels are
Add boilerplate code to support a custom "ingenic_gem_object". Empty for
now, but it will be useful later when subsequent patches will introduce
object-specific driver data.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 15 ---
1 file changed, 12
Add a ingenic_drm_gem_fb_destroy() function, which currently only calls
gem_fb_destroy(), but will be extended in a subsequent patch.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff
When using C8 color mode, make sure that the palette is always uploaded
before a frame; otherwise the very first frame will have wrong colors.
Do that by changing the link order of the DMA descriptors.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 45
Setting the DMA descriptor chain register in the probe function has been
fine until now, because we only ever had one descriptor per foreground.
As the driver will soon have real descriptor chains, and the DMA
descriptor chain register updates itself to point to the current
descriptor being
The IPU scaling information is computed in the plane's ".atomic_check"
callback, and used in the ".atomic_update" callback. As such, it is
state-specific, and should be moved to the private state structure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 73
This information is carried from the ".atomic_check" to the
".atomic_commit_tail"; as such it is state-specific, and should be moved
to the private state structure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 ---
1 file changed, 37
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to
put state-specific information in their respective private structure.
Add boilerplate code to support private objects in the two drivers, so
that state-specific information can be put in the state-specific private
structure.
Instead of having one 'hwdesc' variable for the plane #0 and one for the
plane #1, use a 'hwdesc[2]' array, where the DMA hardware descriptors
are indexed by the plane's number.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 38 ---
1 file
The priv->ipu_plane would get a different value further down the code,
without the first assigned value being read first; so the first
assignation can be dropped.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
Hi,
Here is a set of 11 patches for the ingenic-drm driver.
Patches 1-7 are mostly generic cleanups, which will grease up the way
for bigger changes to be introduced.
Patch 3 adds support for a private state structure, which is then used
to store state-specific information, which was previously
Hi,
On Wed, May 26, 2021 at 10:08 PM Krishna Manikandan
wrote:
>
> Crtc perf update from frame event work can result in
> wrong bandwidth and clock update from dpu if the work
> is scheduled after the swap state has happened.
>
> Avoid such issues by moving perf update to complete
> commit once
From: Alex Sierra
pages in device mapping refcounts are 1-based, instead
of 0-based. If refcount 1, means it can be freed.
This logic is not set for Generic memory type. Therefore,
its release is threated as a normal page, instead of
the callback device driver release it.
Signed-off-by: Alex
From: Alex Sierra
This support is only for generic type anonymous memory.
Generic type with zone device pages require to take an extra reference,
as it's done with device private type.
Also, support added to migrate pages meta-data for generic device type.
Signed-off-by: Alex Sierra
---
From: Alex Sierra
Helper to check if zone device page is generic type.
Signed-off-by: Alex Sierra
---
include/linux/mm.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c9900aedc195..1af7b9b76948 100644
--- a/include/linux/mm.h
+++
From: Alex Sierra
Generic device type memory on VRAM to RAM migration,
has similar access as System RAM from the CPU. This flag sets
the source from the sender. Which in Generic type case,
should be set as SYSTEM.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
From: Alex Sierra
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_GENERIC to create the device
AMD is building a system architecture for the Frontier supercomputer with
a coherent interconnect between CPUs and GPUs. This hardware architecture
allows the CPUs to coherently access GPU device memory. We have hardware
in our labs and we are working with our partner HPE on the BIOS, firmware
and
The previous commit wrongly assumed that dma_mmap_wc() could be replaced
by pgprot_writecombine() + dma_mmap_pages(). It did work on my setup,
but did not work everywhere.
Use dma_mmap_wc() when the buffer has the write-combine cache attribute,
and dma_mmap_pages() when it has the non-coherent
On 2021-05-27 15:03, Dmitry Baryshkov wrote:
Fix following warnings generated when either DP or DSI support is
disabled:
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:141:3: error:
implicit declaration of function 'msm_dp_snapshot'; did you mean
'msm_dsi_snapshot'?
Fix following warnings generated when either DP or DSI support is
disabled:
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:141:3: error: implicit
declaration of function 'msm_dp_snapshot'; did you mean 'msm_dsi_snapshot'?
[-Werror=implicit-function-declaration]
Hi,
Since Christian believes that we can't deadlock the kernel with some
changes there, we just need to make everything nice for userspace too.
Instead of explaining how it will work, I will explain the cases where
future hardware (and its kernel driver) will break existing userspace in
order to
Hi,
On Thu, May 27, 2021 at 5:21 AM wrote:
>
> >> @@ -171,6 +172,19 @@ struct panel_desc {
> >>
> >> /** @connector_type: LVDS, eDP, DSI, DPI, etc. */
> >> int connector_type;
> >> +
> >> + /**
> >> +* @uses_dpcd_backlight: Panel supports eDP dpcd backlight
> >>
> The main outstanding questing is the proper name. Performance monitoring
> ("PERMON") is the name used by kbase, but it's jargon-y and risks
> confusion with performance counters, an orthogonal mechanism. Cycle
> count is more descriptive and matches the actual hardware name, but
> obscures that
From: Alex Sierra
Keep track of all the pages inside of pranges referenced to
the same svm_bo. This is done, by using the ref count inside this object.
This makes sure the object has freed after the last prange is not longer
at any GPU. Including references shared between a parent and child
From: Alex Sierra
This is for debug purposes only.
It conditionally generates partial migrations to test mixed
CPU/GPU memory domain pages in a prange easily.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 14 ++
1 file changed, 14 insertions(+)
diff
From: Alex Sierra
actual_loc should not be used anymore, as pranges
could have mixed locations (VRAM & SYSRAM) at the
same time.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 12 +---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 71 ++--
2 files
From: Alex Sierra
Migration skipped for pages that are already in VRAM
domain. These could be the result of previous partial
migrations to SYS RAM, and prefetch back to VRAM.
Ex. Coherent pages in VRAM that were not written/invalidated after
a copy-on-write.
Signed-off-by: Alex Sierra
---
From: Alex Sierra
Invalid pages can be the result of pages that have been migrated
already due to copy-on-write procedure or pages that were never
migrated to VRAM in first place. This is not an issue anymore,
as pranges now support mixed memory domains (CPU/GPU).
Signed-off-by: Alex Sierra
From: Alex Sierra
[Why]
svm ranges can have mixed pages from device or system memory.
A good example is, after a prange has been allocated in VRAM and a
copy-on-write is triggered by a fork. This invalidates some pages
inside the prange. Endding up in mixed pages.
[How]
By classifying each page
From: Alex Sierra
svm_range_prefault is called right before migrations to VRAM,
to make sure pages are resident in system memory before the migration.
With partial migrations, this reference is used by hmm range get pages
to avoid migrating pages that are already in the same VRAM domain.
From: Alex Sierra
Get the proper owner reference for amdgpu_hmm_range_get_pages function.
This is useful for partial migrations. To avoid migrating back to
system memory, VRAM pages, that are accessible by all devices in the
same memory domain.
Ex. multiple devices in the same hive.
From: Alex Sierra
The parameter is used in the dev_private_owner to decide if device
pages in the range require to be migrated back to system memory, based
if they are or not in the same memory domain.
In this case, this reference could come from the same memory domain
with devices connected to
From: Alex Sierra
pgmap owner member at the svm migrate init could be referenced
to either adev or hive, depending on device topology.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 3 +++
2 files changed, 6
t drm_driver panfrost_drm_driver = {
.fops = _drm_driver_fops,
.name = "panfrost",
.desc = "panfrost DRM",
- .date = "20180908",
+ .date = &quo
From: Alyssa Rosenzweig
Wrap the underlying CYCLE_COUNT_START/STOP commands in a safe interface
that ensures the commands are only issued where required by guarding
behind an atomic counter. In particular, we need to be careful about
races between multiple in-flight jobs, where only some require
From: Alyssa Rosenzweig
Add additional values of GPU_COMMAND required to enable and disable the
cycle (and timestamp) counters. Values from mali_kbase.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Alyssa Rosenzweig
Extend the Panfrost UABI with a new job requirement for cycle counters
(and GPU timestamps, by extension). This requirement is used in
userspace to implement ARB_shader_clock, an OpenGL extension reporting
the GPU cycle count within a shader. The same mechanism will be
From: Alyssa Rosenzweig
Mali has hardware cycle counters (and GPU timestamps) available for
profiling. These are exposed in various ways:
- Kernel: As CYCLE_COUNT and TIMESTAMP registers
- Job chain: As WRITE_VALUE descriptors
- Shader (Midgard): As LD_SPECIAL selectors
- Shader (Bifrost): As
On Tue, 2021-05-25 at 10:59 +1000, Sam McNally wrote:
> With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> topology.
>
> When tunneling CEC through an MST port, CEC IRQs are delivered via a
> sink event notify message; when a sink event notify message is received,
> trigger
On Tue, 2021-05-25 at 10:59 +1000, Sam McNally wrote:
> Up requests are decoded by drm_dp_sideband_parse_req(), which operates
> on a drm_dp_sideband_msg_rx, unlike down requests. Expand the existing
> self-test helper sideband_msg_req_encode_decode() to copy the message
> contents and length from
On Thu, May 06, 2021 at 12:13:38PM -0700, Matthew Brost wrote:
> 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: Michal Wajdeczko
>
This reverts commit b739f125e4ebd73d10ed30a856574e13649119ed.
We are unfortunately seeing more issues like we did in 293837b9ac8d
("Revert "i915: fix remap_io_sg to verify the pgprot""), except this is
now for the vm_fault_gtt path, where we are now hitting the same
BUG_ON(!pte_none(*pte)):
On Thu, May 27, 2021 at 11:26:41AM -0500, Jason Ekstrand wrote:
> 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
On Thu, May 27, 2021 at 11:26:40AM -0500, Jason Ekstrand wrote:
> 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
On Thu, May 27, 2021 at 10:17:20AM -0700, John Harrison wrote:
> On 5/25/2021 23:42, Matthew Brost wrote:
> > Drop the variable guc->interrupts.enabled as this variable is just
> > leading to bugs creeping into the code.
> >
> > e.g. A full GPU reset disables the GuC interrupts but forgot to
https://bugzilla.kernel.org/show_bug.cgi?id=212957
Dennis Foster (m...@dennisfoster.us) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 5/25/2021 23:42, Matthew Brost wrote:
Drop the variable guc->interrupts.enabled as this variable is just
leading to bugs creeping into the code.
e.g. A full GPU reset disables the GuC interrupts but forgot to clear
guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
On 5/27/2021 01:53, Tvrtko Ursulin wrote:
On 26/05/2021 19:45, John Harrison wrote:
On 5/26/2021 01:40, Tvrtko Ursulin wrote:
On 25/05/2021 18:52, Matthew Brost wrote:
On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote:
On 06/05/2021 20:14, Matthew Brost wrote:
From: John
On 5/27/21 9:41 AM, Tom Lendacky wrote:
> On 5/27/21 8:02 AM, Christoph Hellwig wrote:
>> On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote:
>>> You convert this call site with swiotlb_init_io_tlb_mem() which did not
>>> do the set_memory_decrypted()+memset(). Is this okay or should
This is already fixed in the patch from Zhen Lei.
> -Original Message-
> From: Christophe JAILLET
> Sent: Wednesday, May 26, 2021 11:10 PM
> To: Chrisanthus, Anitha ; Dea, Edmund J
> ; airl...@linux.ie; dan...@ffwll.ch;
> s...@ravnborg.org
> Cc: dri-devel@lists.freedesktop.org;
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
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed,
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
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
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
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
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
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
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
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
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
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
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
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
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
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 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
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +-
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
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
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 API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would
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
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
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and
Previously, we were storing the ring size in the ring pointer before it
was actually allocated. We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE
On Thu, 27 May 2021, Konrad Dybcio wrote:
> Hi,
>
> > Why are you Reviewing/Acking a patch that was applied on the 10th?
>
> Forgive me if it turns out I'm blind, but I can't see the patch
> being in either -next, backlight/for-next, or 5.13-rc3. Perhaps it
> was omitted after all?
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.13-rc3 next-20210527]
[cannot apply to drm/drm-next]
[If your patch
Hi,
> Why are you Reviewing/Acking a patch that was applied on the 10th?
Forgive me if it turns out I'm blind, but I can't see the patch being in either
-next, backlight/for-next, or 5.13-rc3. Perhaps it was omitted after all?
Konrad
1 - 100 of 233 matches
Mail list logo
