On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Whenever we had a user object (n_placements > 0), we were ignoring
> > obj->mm.region and always putting obj->placements[0] as the requested
> > region. For LMEM+SMEM objects,
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin()
Instead of hand-rolling the same three calls in each function, pull them
into an i915_gem_object_create_user helper. Apart from re-ordering of
the placements array ENOMEM check, there should be no functional change.
v2 (Matthew Auld):
- Add the call to i915_gem_flush_free_objects() from
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to
Whenever we had a user object (n_placements > 0), we were ignoring
obj->mm.region and always putting obj->placements[0] as the requested
region. For LMEM+SMEM objects, this was causing them to get shoved into
LMEM on every i915_ttm_get_pages() even when SMEM was requested by, say,
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and
Since we don't allow changing the set of regions after creation, we can
make ext_set_placements() build up the region set directly in the
create_ext and assign it to the object later. This is similar to what
we did for contexts with the proto-context only simpler because there's
no funny object
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
v7:
- Drop "drm/i915/gem/ttm: Place new BOs in the requested region"
-
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Cc: Matthew Auld
On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>
> I can think of two ways to test the changes for MEMORY_DEVICE_GENERIC in
> this patch series in a way that is reproducible without special hardware and
> firmware:
>
> For the reference counting changes we could use the dax
On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
>
> __i915_gem_ttm_object_init() was ignoring the placement requests coming
> from the client and always placing all BOs in SMEM upon creation.
> Instead, compute the requested placement set from the object and pass
> that into
On Fri, Jul 16, 2021 at 6:21 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Instead of hand-rolling the same three calls in each function, pull them
> > into an i915_gem_object_create_user helper. Apart from re-ordering of
> > the placements array ENOMEM
On Fri, 16 Jul 2021 at 16:52, Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> > wrote:
> > >
> > > On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> > > >
> > > > Whenever we had a user object (n_placements
On Fri, Jul 16, 2021 at 6:12 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Since we don't allow changing the set of regions after creation, we can
> > make ext_set_placements() build up the region set directly in the
> > create_ext and assign it to the
On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
>
> On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> wrote:
> >
> > On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> > >
> > > Whenever we had a user object (n_placements > 0), we were ignoring
> > > obj->mm.region and always putting
Hi, Yongqiang:
Yongqiang Niu 於 2021年7月16日 週五 下午2:58寫道：
>
> add time-out cycle setting to make sure time-out interrupt irq
> will happened when instruction time-out for wait and poll
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 11 +++
> 1 file changed,
Commit 43636451db8c ("drm/tegra: Implement job submission part of new
UAPI") added the macro 'SUBMIT_ERR' that in turns makes use of the macro
'__VA_OPT__'. The '__VA_OPT__' macro is not supported by older versions
of GCC and so causes build failures when using older versions of GCC.
Fix this by
On Fri, Jul 16, 2021 at 3:06 AM Christian König
wrote:
>
> This reverts commit 85fd4a8a84316166640102676a356755ddec80e0.
>
> Daniel pointed out that even PROT_READ can cause a BUG_ON() with this.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
>
On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
>
> Whenever we had a user object (n_placements > 0), we were ignoring
> obj->mm.region and always putting obj->placements[0] as the requested
> region. For LMEM+SMEM objects, this was causing them to get shoved into
> LMEM on every
On 15/07/2021 11:15, Matthew Auld wrote:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using
On Fri, Jul 16, 2021 at 9:52 AM Tvrtko Ursulin
wrote:
>
>
> On 15/07/2021 11:15, Matthew Auld wrote:
> > The CPU domain should be static for discrete, and on DG1 we don't need
> > any flushing since everything is already coherent, so really all this
> > does is an object wait, for which we have
Hi Stefan,
On Wed, Jul 07, 2021 at 08:01:50PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 07.07.21 um 15:11 schrieb Maxime Ripard:
> > On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
> >> Hi Maxime,
> >>
> >> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
> >>> Hi Stefan,
> >>>
>
On 7/16/21 3:46 PM, Jon Hunter wrote:
Commit 43636451db8c ("drm/tegra: Implement job submission part of new
UAPI") added the macro 'SUBMIT_ERR' that in turns makes use of the macro
'__VA_OPT__'. The '__VA_OPT__' macro is not supported by older versions
of GCC and so causes build failures when
On Fri, Jul 16, 2021 at 8:18 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > __i915_gem_ttm_object_init() was ignoring the placement requests coming
> > from the client and always placing all BOs in SMEM upon creation.
> > Instead, compute the requested
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/repaper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/gm12u320.c | 19 +--
1 file changed, 5 insertions(+), 14
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_modeset.c | 29 -
1 file changed, 8 insertions(+), 21
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gud/gud_pipe.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff
Provide helpers that wrap dma_buf_{begin,end}_cpu_access() for all
GEM BOs attached to a framebuffer. Convert drivers and remove ugly
boilerplate code.
Thomas Zimmermann (7):
drm/gem: Provide drm_gem_fb_{begin,end}_cpu_access() helpers
drm/udl: Use framebuffer dma-buf helpers
drm/mipi-dbi:
Implement helpers drm_gem_fb_begin_cpu_access() and _end_cpu_access(),
which call the rsp dma-buf functions for all GEM BOs of the given
framebuffer.
Calls to dma_buf_end_cpu_access() can return an error code on failure,
while drm_gem_fb_end_cpu_access() does not. The latter runs during DRM's
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/st7586.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
There's one left-over reference to the imported attachment that we
keep. GEM BOs with imported attachment are considered uncached and
enables
On Thu, Jul 15, 2021 at 8:21 PM Kenneth Graunke wrote:
>
> On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
> >
> > On 15/07/2021 12:07, Daniel Vetter wrote:
> > > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> > >>
> > >> On 15/07/2021 11:15, Matthew Auld wrote:
On 15/07/2021 11:15, Matthew Auld wrote:
The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable
)
On Wed, Jul 14, 2021 at 6:32 PM Daniel Vetter wrote:
>
> On Wed, Jul 14, 2021 at 02:01:59PM +0800, Pi-Hsun Shih wrote:
> > Use pm_runtime_force_suspend and pm_runtime_force_resume to ensure that
> > anx7625 would always be powered off when suspended. Also update the
> > bridge enable hook to
Hi Thomas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on 4d00e2309398147acdbfefbe1deb4b0e78868466]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Provide-framebuffer-vmap-helpers/20210716-020508
base
On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
>
> Since we don't allow changing the set of regions after creation, we can
> make ext_set_placements() build up the region set directly in the
> create_ext and assign it to the object later. This is similar to what
> we did for contexts with
Hi Pi-Hsun,
On Fri, Jul 16, 2021 at 04:26:44PM +0800, Pi-Hsun Shih wrote:
> On Wed, Jul 14, 2021 at 6:32 PM Daniel Vetter wrote:
> > On Wed, Jul 14, 2021 at 02:01:59PM +0800, Pi-Hsun Shih wrote:
> > > Use pm_runtime_force_suspend and pm_runtime_force_resume to ensure that
> > > anx7625 would
From: "Ainux.Wang"
The function ast_get_modes() will also return 0, when it try to get the
edid, but it also do not get the edid.
Signed-off-by: Ainux.Wang
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c
Hi,
On Thu, Jul 15, 2021 at 08:01:29PM +0200, Thomas Zimmermann wrote:
> DRM uses a magic number of 4 for the maximum number of planes per color
> format. Declare this constant via DRM_FORMAT_MAX_PLANES and update the
> related code.
>
> Signed-off-by: Thomas Zimmermann
> ---
>
On Fri, Jul 16, 2021 at 2:58 PM Yongqiang Niu
wrote:
>
> add time-out cycle setting to make sure time-out interrupt irq
> will happened when instruction time-out for wait and poll
>
> Signed-off-by: Yongqiang Niu
Hi, it seems that this series is based on
Hi
Am 16.07.21 um 09:30 schrieb Maxime Ripard:
Hi,
On Thu, Jul 15, 2021 at 08:01:29PM +0200, Thomas Zimmermann wrote:
DRM uses a magic number of 4 for the maximum number of planes per color
format. Declare this constant via DRM_FORMAT_MAX_PLANES and update the
related code.
Signed-off-by:
On Fri, Jul 16, 2021 at 08:16:27AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series cleans up a bunch of lose ends in the vgaarb code.
>
> Diffstat:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +-
> drivers/gpu/drm/drm_irq.c |4
>
Hi
Am 16.07.21 um 11:55 schrieb ainux.w...@gmail.com:
From: "Ainux.Wang"
There is should a status when do not get edid.
Well, not really.
So, the problem is that VGA is not hotplug-able. It's supposed to be
connected when the computer gets switched on. And there's no interface
for
This reverts commit 85fd4a8a84316166640102676a356755ddec80e0.
Daniel pointed out that even PROT_READ can cause a BUG_ON() with this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_gem.c| 3 +--
Am 16.07.21 um 08:16 schrieb Christoph Hellwig:
The define is entirely unused.
Signed-off-by: Christoph Hellwig
I'm not an expert for this particular code, but at least of hand
everything you do here makes totally sense.
Whole series is Acked-by: Christian König
Regards,
Christian.
From: José Roberto de Souza
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
to do the
From: José Roberto de Souza
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
On Thu, Jul 15, 2021 at 09:10:31PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> session state might still be marked as alive after resume.
On 2021.07.14 21:20:41 -0300, Jason Gunthorpe wrote:
> The user can open multiple device FDs if it likes, however the open
> function calls vfio_register_notifier() on device global state. Calling
> vfio_register_notifier() twice will trigger a WARN_ON from
> notifier_chain_register() and the
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
to do the
From: José Roberto de Souza
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
Am 15.07.21 um 21:05 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings, which causes mmap to fail
in ttm_bo_mmap_obj.
As a workaround, clear VM_MAYWRITE for PROT_NONE-COW mappings. This
should prevent the
On 15/07/2021 19:21, Kenneth Graunke wrote:
On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
On 15/07/2021 12:07, Daniel Vetter wrote:
On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
On 15/07/2021 11:15, Matthew Auld wrote:
From: Chris Wilson
Jason
From: Dillon Min
Since the st,sf-tc240t-9370-t dts binding already exist in stm32f429-disco.dts
but, the panel driver didn't get accepted from mainline. it's time to submit
patch fot it.
This driver can support two different interface by different dts bindings:
- spi+dpi, use spi to configure
From: Dillon Min
Add documentation for "ilitek,ili9341" panel.
Signed-off-by: Dillon Min
---
.../bindings/display/panel/ilitek,ili9341.yaml | 69 ++
1 file changed, 69 insertions(+)
create mode 100644
DRM_SIMPLE_MODE(240, 320, 37, 49),
+};
+
+DEFINE_DRM_GEM_CMA_FOPS(ili9341_dbi_fops);
+
+static struct drm_driver ili9341_dbi_driver = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .fops = _dbi_fops,
+ DRM_GEM_CMA_DRIVER_OPS_VMAP,
+
On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
>
> Instead of hand-rolling the same three calls in each function, pull them
> into an i915_gem_object_create_user helper. Apart from re-ordering of
> the placements array ENOMEM check, the only functional change here
> should be that
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
to do the
Hi Dave & Daniel,
Lots of stuff this time around.
Enjoy!
~Maarten
drm-misc-next-2021-07-16:
drm-misc-next for v5.15:
UAPI Changes:
Cross-subsystem Changes:
- udmabuf: Add support for mapping hugepages
- Add dma-buf stats to sysfs.
- Assorted fixes to fbdev/omap2.
- dma-buf: Document
On Wed, 14 Jul 2021 12:11:37 +0200, Enric Balletbo i Serra wrote:
> Update device tree binding documentation for the dsi to add the optional
> property to reset the dsi controller.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2:
> - Added a new patch to describe the dsi reset
On 7/16/21 9:08 AM, Thomas Zimmermann wrote:
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
Acked-by: David Lechner
On Fri, Jul 16, 2021 at 01:17:12PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Changing the reset module parameter has no effect on a running GuC.
> The corresponding entry in the ADS must be updated and then the GuC
> informed via a Host2GuC message.
>
> The new debugfs interface to
On Fri, Jul 16, 2021 at 01:17:17PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> There are many ways in which the hangcheck selftest can fail. Very few
> of them actually printed an error message to say what happened. So,
> fill in the missing messages.
>
> Signed-off-by: John Harrison
On Fri, Jul 16, 2021 at 01:17:22PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Some testing environments and some heavier tests are slower than
> previous limits allowed for. For example, it can take multiple seconds
> for the 'context has been reset' notification handler to reach the
On Fri, Jul 16, 2021 at 01:17:21PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> When GuC submission is enabled, the GuC controls engine resets. Rather
> than explicitly triggering a reset, the driver must submit a hanging
> context to GuC and wait for the reset to occur.
>
>
On Fri, Jul 16, 2021 at 01:17:19PM -0700, Matthew Brost wrote:
> From: Rahul Kumar Singh
>
> When GuC submission is enabled, the GuC controls engine resets. Rather
> than explicitly triggering a reset, the driver must submit a hanging
> context to GuC and wait for the reset to occur.
>
>
Am 2021-07-16 um 11:07 a.m. schrieb Theodore Y. Ts'o:
> On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>> I can think of two ways to test the changes for MEMORY_DEVICE_GENERIC in
>> this patch series in a way that is reproducible without special hardware and
>> firmware:
>>
>> For
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Fixes: 537f9c84a427 ("drm/i915/pmu: Fix CPU hotplug with multiple GPUs")
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In i915_exit(), we check i915_pci_driver.driver.owner to detect if
i915_init exited early and don't tear anything down. However, we didn't
have proper tear-down paths for early exits in i915_init().
Most of the time, you would never notice this as driver init failures
are extremely rare and
Hi William,
Thanks for catching this.
On Fri, Jul 9, 2021 at 11:45 PM Will McVicker wrote:
>
> This is needed for fw_devlink to work properly with MIPI DSI devices.
> Without setting the device's fwnode, the sync state framework isn't able
> to properly track device links between the MIPI DSI
On Fri, Jul 16, 2021 at 01:46:00PM +0100, Jon Hunter wrote:
> Commit 43636451db8c ("drm/tegra: Implement job submission part of new
> UAPI") added the macro 'SUBMIT_ERR' that in turns makes use of the macro
> '__VA_OPT__'. The '__VA_OPT__' macro is not supported by older versions
> of GCC and so
On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> > > wrote:
> > > >
> > > > On Thu, 15 Jul 2021 at 23:39, Jason
Instead of requesting two separate clock and then handling them
separately in various places of the driver, use clk_bulk_*() API.
This permits handling devices with more than "bus"/"core" clock,
like ZynqMP, which has "gpu"/"gpu_pp0"/"gpu_pp1" all as separate
clock.
Signed-off-by: Marek Vasut
On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
>
> On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> > > >
> > > > On Fri, Jul 16, 2021 at 8:54 AM Matthew
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> Instead of hand-rolling the same three calls in each function, pull them
> into an i915_gem_object_create_user helper. Apart from re-ordering of
> the placements array ENOMEM check, there should be no functional change.
>
> v2 (Matthew
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> Whenever we had a user object (n_placements > 0), we were ignoring
> obj->mm.region and always putting obj->placements[0] as the requested
> region. For LMEM+SMEM objects, this was causing them to get shoved into
> LMEM on every
On Wed, 14 Jul 2021 12:19:36 +0200, Geert Uytterhoeven wrote:
> The "resets" property is not present on R-Car Gen1 SoCs.
> Supporting it would require migrating from renesas,cpg-clocks to
> renesas,cpg-mssr.
>
> Reflect this in the DT bindings by removing the global "required:
> resets". All
On 7/10/2021 10:47 AM, Michal Wajdeczko wrote:
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add param set h2g helpers to set the min and max frequencies
for use by SLPC.
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> Since we don't allow changing the set of regions after creation, we can
> make ext_set_placements() build up the region set directly in the
> create_ext and assign it to the object later. This is similar to what
> we did for contexts with
The new GuC interface introduces an MMIO H2G command,
INTEL_GUC_ACTION_RESET_CLIENT, which is used to implement suspend. This
MMIO tears down any active contexts generating a context reset G2H CTB
for each. Once that step completes the GuC tears down the CTB
channels. It is safe to suspend once
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine,
From: John Harrison
The driver must provide GuC with a list of mmio registers
that should be saved/restored during a GuC-based engine reset.
Unfortunately, the list must be dynamically allocated as its size is
variable. That means the driver must generate the list twice - once to
work out the
From: Rahul Kumar Singh
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Signed-off-by: Rahul Kumar Singh
Signed-off-by: John Harrison
Signed-off-by:
The GuC can implement execution qunatums, detect hung contexts and
other such things but it requires the timer expired interrupt to do so.
Signed-off-by: Matthew Brost
CC: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4
1 file changed, 4
From: John Harrison
In the case of a full GPU reset (e.g. because GuC has died or because
GuC's hang detection has been disabled), the driver can't rely on GuC
reporting the guilty context. Instead, the driver needs to scan all
active contexts and find one that is currently executing, as per the
We receive notification of an engine reset from GuC at its
completion. Meaning GuC has potentially cleared any HW state
we may have been interested in capturing. GuC resumes scheduling
on the engine post-reset, as the resets are meant to be transparent,
further muddling our error state.
There is
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
v2:
(Matthew)
- s/INTEL_GUC_SEND/INTEL_GUC_CT_SEND
v3:
(Matthew)
- Add G2H credit accounting to blocking path, add g2h_release_space
helper
(John H)
-
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen in i915. Instead, requests are
submitted
From: John Harrison
The media watchdog mechanism involves GuC doing a silent reset and
continue of the hung context. This requires the i915 driver provide a
golden context to GuC in the ADS.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_gt.c
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: John Harrison
There are many ways in which the hangcheck selftest can fail. Very few
of them actually printed an error message to say what happened. So,
fill in the missing messages.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
---
This adds GuC backend support for i915_request_cancel(), which in turn
makes CONFIG_DRM_I915_REQUEST_TIMEOUT work.
Signed-off-by: Matthew Brost
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 9 +
drivers/gpu/drm/i915/gt/intel_context.h | 7 +
From: Rahul Kumar Singh
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Signed-off-by: Rahul Kumar Singh
Signed-off-by: John Harrison
Signed-off-by:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
v2:
(Martin Peres / John H)
- Delete debug message when GuC is disabled by default on certain
platforms
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Implement a simple static mapping algorithm of the i915 priority levels
(int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
follows:
i915 level < 0 -> GuC low level (3)
i915 level == 0 -> GuC normal level (2)
i915 level < INT_MAX-> GuC high level(1)
From: John Harrison
Some testing environments and some heavier tests are slower than
previous limits allowed for. For example, it can take multiple seconds
for the 'context has been reset' notification handler to reach the
'kill the requests' code in the 'active' version of the 'reset
engines'
From: John Harrison
It is impossible to seal all race conditions of resets occurring
concurrent to other operations. At least, not without introducing
excesive mutex locking. Instead, don't complain if it occurs. In
particular, don't complain if trying to send a H2G during a reset.
Whatever the
1 - 100 of 148 matches
Mail list logo
