ttm->num_pages is uint32_t which was causing very large buffers to
only populate a truncated size.
This fixes gem_create@create-clear igt test on large memory systems.
Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_
The pull request you sent on Fri, 10 Dec 2021 14:28:53 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9b302ffe4e8d7e62f3170aa0097ff979880ba61d
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
Add a static entry in the x86 table, to detect and wait for
privacy-screen on some ChromeOS platforms.
Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
shall return EPROBE_DEFER until a platform driver act
This adds the ACPI driver for the ChromeOS privacy screen that is
present on some chromeos devices.
Note that I found that ACPI drivers are bound to their devices AFTER
the drm probe. So on chromebooks with privacy-screen, this causes a
probe deferral for i915 driver, which results in a delay of a
Hi Nikolaus,
Le ven., déc. 10 2021 at 10:53:18 -0600, Rob Herring
a écrit :
On Thu, Dec 02, 2021 at 07:39:48PM +0100, H. Nikolaus Schaller wrote:
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
We a
This is a revert of commits
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
timeline->mutex")
6dcb85a0ad990 ("drm/i915: Hold irq-off for the entire fake lock period")
The existin
On Wed, 08 Dec 2021 09:33:37 +0800, Tommy Haung wrote:
> Add new CRT reset define for ast2600.
>
> Reported-by: kernel test robot
> Signed-off-by: Tommy Haung
> ---
> include/dt-bindings/clock/ast2600-clock.h | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
When an application having open file access to a node forks, its shared
mappings also get reflected in the address space of child process even
though it cannot access them with the object permissions applied. With the
existing permission checks on the gem objects, it might be reasonable to
also cre
On 2021-12-09 4:04 p.m., Yann Dirson wrote:
Thanks for this. It's really good to see this.
Reviewed-by: Harry Wentland
Hearfully seconded, let's get this rolling :)
Reviewed-by: Yann Dirson
Series applied to amd-staging-drm-next
Thanks a lot!
Harry
On 2021-12-09 09:20, Rodrigo S
On Fri, Dec 10, 2021 at 11:29 AM Tim Harvey wrote:
>
> On Fri, Dec 10, 2021 at 10:41 AM Dave Stevenson
> wrote:
> >
> > On Fri, 10 Dec 2021 at 18:20, Tim Harvey wrote:
> > >
> > > On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey wrote:
> > > >
> > > > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
Hi Dave, Daniel,
More stuff for 5.17.
The following changes since commit 70897848730470cc477d5d89e6222c0f6a9ac173:
drm/amdgpu/display: Only set vblank_disable_immediate when PSR is not enabled
(2021-12-01 16:00:58 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.o
From: Ira Weiny
kmap() is being deprecated and these usages are all local to the thread
so there is no reason kmap_local_page() can't be used.
Replace kmap() calls with kmap_local_page().
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
drivers/gpu/drm
From: Ira Weiny
kmap() is being deprecated. These maps are thread local and can be
replaced with kmap_local_page().
Replace kmap() with kmap_local_page()
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -
From: Ira Weiny
This series starts by converting the last easy kmap() uses to
kmap_local_page().
There is one more call to kmap() wrapped in ttm_bo_kmap_ttm(). Unfortunately,
ttm_bo_kmap_ttm() is called in a number of different ways including some which
are not thread local. I have a patch to
From: Ira Weiny
The default case leaves the buffer object mapped in error.
Add radeon_bo_kunmap() to that case to ensure the mapping is cleaned up.
Signed-off-by: Ira Weiny
---
NOTE: It seems like this function could use a fair bit of refactoring
but this is the easiest way to fix the actual
From: Ira Weiny
kmap() is being deprecated and this usage is local to the thread. Use
kmap_local_page() instead.
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/driv
From: Ira Weiny
kmap() is being deprecated. So this comment could be misleading in the
future.
Change this comment to point to using kmap_local_page(). While here
remove 'we' from the comment.
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++--
1 file changed, 2 inse
From: Ira Weiny
kmap() is being deprecated and these instances are easy to convert to
kmap_local_page().
Furthermore, in gma_crtc_cursor_set() use the memcpy_from_page() helper
instead of an open coded use of kmap_local_page().
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/gma500/gma_display.c
From: Ira Weiny
The default case leaves the buffer object mapped in error.
Add amdgpu_bo_kunmap() to that case to ensure the mapping is cleaned up.
Signed-off-by: Ira Weiny
---
NOTE: It seems like this function could use a fair bit of refactoring
but this is the easiest way to fix the actual
Hi Vinod,
On 2021-11-16 11:52:55, Vinod Koul wrote:
> When DSC is enabled, we need to configure DSI registers accordingly and
> configure the respective stream compression registers.
>
> Add support to calculate the register setting based on DSC params and
> timing information and configure these
On Fri, Dec 10, 2021 at 6:49 PM Jagan Teki wrote:
>
> devm_drm_of_get_bridge is capable of looking up the downstream
> bridge and panel and trying to add a panel bridge if the panel
> is found.
>
> Replace explicit finding calls with devm_drm_of_get_bridge.
>
> Cc: Philipp Zabel
> Cc: Chun-Kuang
Some of the newer platforms use a bigger RSA key to authenticate the GuC,
which is provided to the HW via a ggtt-pinned object instead of mmio.
While doing the changes for this I've also spotted an inconsistency in
the error status of the fw on init failure, so I've added a path to fix
that as wel
The FAILURE state of uc_fw currently implies that the fw is loadable
(i.e init completed), so we can't use it for init failures and instead
need a dedicated error code.
Note that this currently does not cause any issues because if we fail to
init any of the firmwares we abort the load, but better
Some of the newer HW will use bigger RSA keys to authenticate the GuC
binary. On those platforms the HW will read the key from memory instead
of the RSA registers, so we need to copy it in a dedicated vma, like we
do for the HuC. The address of the key is provided to the HW via the
first RSA regist
From: Michal Wajdeczko
Future GuC/HuC firmwares might be signed with different key sizes.
Don't assume that it must be always 2048 bits long.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7
Prevent a build format warning by using the correct format specifier
to print size_t data.
Fixes this build warning:
../drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:33: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 4 has type ‘size_t {aka unsigned
int}’ [-Wformat=]
Fixes:
On 12/9/2021 8:40 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits.
On Sat, Dec 11, 2021 at 1:07 AM Linus Walleij wrote:
> On Fri, Dec 10, 2021 at 6:49 PM Jagan Teki wrote:
> > - dev_info(dev, "connected to panel\n");
> > - d->panel = panel;
>
> How does this assignment happen after your patch?
> I'm using that...
>
> devm_drm_of_get_
On 2021-12-10 10:13 a.m., Christian König wrote:
Am 10.12.21 um 15:25 schrieb Guilherme G. Piccoli:
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
Why not just reload the driver after kexec?
Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the
On 2021-12-10 4:48 p.m., Rajneesh Bhardwaj wrote:
When an application having open file access to a node forks, its shared
mappings also get reflected in the address space of child process even
though it cannot access them with the object permissions applied. With the
existing permission checks on
Testing the stealing of guc ids is hard from user spaec as we have 64k
guc_ids. Add a selftest, which artificially reduces the number of guc
ids, and forces a steal. Details of test has comment in code so will not
repeat here.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
1 file changed, 2 inse
Patches 1 & 2 address bugs in stealing of guc_ids and patch 7 tests this
path.
Patches 4-6 address some issues with the CTs exposed by the selftest in
patch 7. Basically if a lot of contexts were all deregistered all at
once, the CT channel could deadlock.
Patch 3 is a small fix that is already r
A full GT reset can race with the last context put resulting in the
context ref count being zero but the destroyed bit not yet being set.
Remove GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zero.
Reviewed-by: Daniele Ceraolo Spurio
Si
Previously assigned whole guc_id structure (list, spin lock) which is
incorrect, only assign the guc_id.id.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+)
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking waiting on H2G space from inside an IRQ
spinl
Print CT state (H2G + G2H head / tail pointers, credits) on CT
deadlock.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
Let's be paranoid and kick the G2H tasklet, which dequeues messages, if
G2H credit are exhausted.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/dr
On 12/10/2021 16:56, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking w
On 12/10/2021 16:56, Matthew Brost wrote:
Previously assigned whole guc_id structure (list, spin lock) which is
incorrect, only assign the guc_id.id.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/
On Fri, Dec 10, 2021 at 05:07:12PM -0800, John Harrison wrote:
> On 12/10/2021 16:56, Matthew Brost wrote:
> > From: John Harrison
> >
> > While attempting to debug a CT deadlock issue in various CI failures
> > (most easily reproduced with gem_ctx_create/basic-files), I was seeing
> > CPU deadlo
On 12/10/2021 16:56, Matthew Brost wrote:
Testing the stealing of guc ids is hard from user spaec as we have 64k
spaec -> space
guc_ids. Add a selftest, which artificially reduces the number of guc
ids, and forces a steal. Details of test has comment in code so will not
has -> are
But would
On 12/10/2021 16:56, Matthew Brost wrote:
Print CT state (H2G + G2H head / tail pointers, credits) on CT
deadlock.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gp
On 12/10/2021 17:43, John Harrison wrote:
On 12/10/2021 16:56, Matthew Brost wrote:
Print CT state (H2G + G2H head / tail pointers, credits) on CT
deadlock.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 +
1 file change
On Fri, Dec 10, 2021 at 05:45:05PM -0800, John Harrison wrote:
> On 12/10/2021 17:43, John Harrison wrote:
> > On 12/10/2021 16:56, Matthew Brost wrote:
> > > Print CT state (H2G + G2H head / tail pointers, credits) on CT
> > > deadlock.
> > >
> > > Signed-off-by: Matthew Brost
> > Reviewed-by: J
On Fri, Dec 10, 2021 at 05:33:02PM -0800, John Harrison wrote:
> On 12/10/2021 16:56, Matthew Brost wrote:
> > Testing the stealing of guc ids is hard from user spaec as we have 64k
> spaec -> space
>
> > guc_ids. Add a selftest, which artificially reduces the number of guc
> > ids, and forces a s
On Fri, Dec 10, 2021 at 05:33:02PM -0800, John Harrison wrote:
> On 12/10/2021 16:56, Matthew Brost wrote:
> > Testing the stealing of guc ids is hard from user spaec as we have 64k
> spaec -> space
>
> > guc_ids. Add a selftest, which artificially reduces the number of guc
> > ids, and forces a s
Hi Linus,
On Sat, Dec 11, 2021 at 5:37 AM Linus Walleij wrote:
>
> On Fri, Dec 10, 2021 at 6:49 PM Jagan Teki wrote:
> >
> > devm_drm_of_get_bridge is capable of looking up the downstream
> > bridge and panel and trying to add a panel bridge if the panel
> > is found.
> >
> > Replace explicit fi
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits. That means reading the log from graphics memory many times -
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigge
From: John Harrison
Allow engine resets on RCS, report problems with engine resets,
improve GuC log usability.
Signed-off-by: John Harrison
John Harrison (4):
drm/i915/guc: Speed up GuC log dumps
drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM
drm/i915/guc: Flag an error if an
From: John Harrison
A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in G
From: John Harrison
If GuC encounters an error during engine reset, the i915 driver
promotes to full GT reset. This includes an info message about why the
reset is happening. However, that is not treated as a failure by any
of the CI systems because resets are an expected occurrance during
testin
101 - 153 of 153 matches
Mail list logo
