Hi Vinod,
On Thu, Sep 25, 2025 at 05:30:34PM +0530, Jyothi Kumar Seerapu wrote:
> From: Jyothi Kumar Seerapu
>
> GSI hardware generates an interrupt for each transfer completion.
> For multiple messages within a single transfer, this results in
> N interrupts for N messages, leading to significa
From: Andi Shyti
Return the actual error code from vfio_set_irqs_validate_and_prepare()
instead of always collapsing to -EINVAL. While the helper
currently returns -EINVAL in most cases, passing through the real
error code is more future-proof.
While at it, drop the stray 'intel:' p
Hi Madhur,
On Wed, Sep 24, 2025 at 01:20:51AM +0530, Madhur Kumar wrote:
> Follow the advice in Documentation/filesystems/sysfs.rst:
> show() should only use sysfs_emit() or sysfs_emit_at() when formatting
> the value to be returned to user space.
>
> Signed-off-by: Madhur Kumar
merged to drm-i
Hi Alexandr,
Please, verision the patch: this is [PATCH v2].
On Wed, Sep 24, 2025 at 03:48:50PM +0300, Alexandr Sapozhnkiov wrote:
> Return value of function drm_vma_node_allow_once(),
> called at i915_gem_mman.c:672, is not checked.
You've been asked to improve the commit log, but you didn't.
Hi Jyothi,
I'm sorry, but this is not a resend, but this is a v8. Other
than:
1. commit log in patch 1: removed duplicate sentence
2. use proper types when calling geni_i2c_gpi_unmap() inside
geni_i2c_gpi_multi_desc_unmap()
is there anything else?
Please, next increase the version even for t
r
Reviewed-by: Andi Shyti
Thanks,
Andi
ise
> + * %false.
> + */
> +bool pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size)
> +{
> + u64 sizes = pci_rebar_get_possible_sizes(pdev, bar);
> +
> + return BIT(size) & sizes;
I would return here "!!(BIT(size) & sizes)", but it doesn't
really matter.
Reviewed-by: Andi Shyti
Andi
Hi Taotao,
Both patches merged to drm-intel-gt-next.
Thank you,
Andi
On Fri, Aug 22, 2025 at 03:06:59AM +, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen
>
> Without O_LARGEFILE, file->f_op->write_iter calls
> generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
> causing -E
Hi,
On Mon, Sep 15, 2025 at 03:42:23PM +0300, Jani Nikula wrote:
> On Mon, 15 Sep 2025, Ilpo Järvinen wrote:
> > PCI core provides pci_rebar_size_supported() that helps in checking if
> > a BAR Size is supported for the BAR or not. Use it in
> > i915_resize_lmem_bar() to simplify code.
> >
> > Si
nen
> Acked-by: Christian König
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Taotao,
> > Without O_LARGEFILE, file->f_op->write_iter calls
> > generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
> > causing -EFBIG on large writes.
> >
> > In shmem_pwrite(), this error is later masked as -EIO due to the error
> > handling order, leading to igt failur
SoC the driver
> and bindings were written for.
>
> This block is compatible with t8103, so just add the new per-SoC
> compatible using apple,t8103-i2c as base.
>
> [1]:
> https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe8...@kernel.org/
>
> S
> WARNING opportunity for memdup_user
>
> No functional changes intended.
>
> Signed-off-by: Thorsten Blum
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Rodrigo,
On Fri, Aug 22, 2025 at 12:30:02PM -0400, Rodrigo Vivi wrote:
> On Tue, Aug 19, 2025 at 04:55:29PM -0100, Andi Shyti wrote:
> > From: Andi Shyti
> >
> > Coverity warns that 'cap' may be used uninitialised. If pcode
> > is disabled there is
Hi Zhanjun,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index 75e802e10be2..21804eec8320 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -20,7 +20,7 @@
>
> static void guc_irq_handl
/lore.kernel.org/oe-lkp/202508081029.343192ec-...@intel.com
> Fixes: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and
> write_iter")
> Signed-off-by: Taotao Chen
looks good to me:
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Zhanjun,
...
> > On Tue, Aug 19, 2025 at 12:00:10PM -0400, Zhanjun Dong wrote:
> > > Boolean flag access from interrupt context might have synchronous issue on
> >
> > /synchronous/synchronization/
> > /issue/issues/
> >
> > > multiple processor platform, flage modified by one core might be
Hi Zhanjun,
On Tue, Aug 19, 2025 at 12:00:10PM -0400, Zhanjun Dong wrote:
> Boolean flag access from interrupt context might have synchronous issue on
/synchronous/synchronization/
/issue/issues/
> multiple processor platform, flage modified by one core might be read as an
/flage/flags/
> old
From: Andi Shyti
Coverity warns that 'cap' may be used uninitialised. If pcode
is disabled there is no need to go through the hassle of a
pcode read or taking a PM reference.
Check skip_pcode early in the function and return if it is set.
No change for platforms where pcode is enable
struct
> dma_buf.vaddr_ptr")
> Signed-off-by: Nitin Gote
+Thomas and the dri-devel mailing list.
In any case, your patch makes sense to me:
Reviewed-by: Andi Shyti
Andi
> ---
> include/linux/iosys-map.h | 7 +--
> 1 file changed, 1 insertion(+), 6 delet
Hi Clement,
Thanks for following up on the reviews.
> Clément Le Goffic (3):
> i2c: stm32: fix the device used for the DMA map
> i2c: stm32f7: unmap DMA mapped buffer
I applied the two above in i2c/i2c-host-fixes. I'm not sure we
need the "Fixes:" tag in the first patch, though, as w
Hi Clement,
On Mon, Jun 30, 2025 at 02:55:15PM +0200, Clément Le Goffic wrote:
> Use the i2c-core-base APIs to allocate a DMA safe buffer when needed.
same here, I don't understand anything... you could have written
"do some coding" and it would have been the same :-)
Thanks,
Andi
Hi Clement,
On Mon, Jun 30, 2025 at 02:55:14PM +0200, Clément Le Goffic wrote:
> Fix an issue where the mapped DMA buffer was not unmapped.
"Fix an issue..." is too generic. Can you be more specific? Where
was it mapped? Where was it left unmapped?
Please, do consider that the user needs to unde
Hi Clement,
...
> @@ -118,7 +118,7 @@ int stm32_i2c_prep_dma_xfer(struct device *dev, struct
> stm32_i2c_dma *dma,
> dma->dma_len = len;
> chan_dev = dma->chan_using->device->dev;
>
> - dma->dma_buf = dma_map_single(chan_dev, buf, dma->dma_len,
> + dma->dma_buf = dma_map_si
Hi Janusz,
merged to drm-intel-gt-next.
Thanks,
Andi
On Wed, Jun 11, 2025 at 12:42:13PM +0200, Janusz Krzysztofik wrote:
> The following error has been reported sporadically by CI when a test
> unbinds the i915 driver on a ring submission platform:
>
> <4> [239.330153] [ cut here ]-
Pierre-Yves, Alain,
On Mon, Jun 16, 2025 at 10:53:53AM +0200, Clément Le Goffic wrote:
> This patch series aims to fix some issues inside the driver's DMA
> handling.
> It also uses newer I2C DMA API.
>
> Signed-off-by: Clément Le Goffic
> ---
> Clément Le Goffic (3):
> i2c: stm32: fix the
Hi Janusz,
On Thu, Jun 12, 2025 at 11:45:46AM +0200, Janusz Krzysztofik wrote:
> On Thursday, 12 June 2025 11:35:31 CEST Jani Nikula wrote:
> > On Thu, 12 Jun 2025, Janusz Krzysztofik
> > wrote:
> > > On Wednesday, 11 June 2025 22:54:40 CEST Andi Shyti wrote:
> >
Hi Nitin,
On Wed, Jun 11, 2025 at 03:45:30PM +, Gote, Nitin R wrote:
> [...]
> > Subject: [PATCH] drm/i915/ring_submission: Fix timeline left held on VMA
> > alloc
> > error
> >
>
> Generally, it's preferred to use "drm/i915/gt:" file path over
> "drm/i915/ring_submission:" file name in th
the legacy timeline only after successful allocation of the context
> engine's VMA.
>
> v2: Add a note on other submission methods (Krzysztof Karas):
> Both execlists and GuC submission use lrc_alloc() which seems free
> from a similar issue.
>
> Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context")
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
> Cc: Chris Wilson
> Cc: Matthew Auld
> Cc: Krzysztof Karas
> Reviewed-by: Sebastian Brzezinka
> Reviewed-by: Krzysztof Niemiec
> Signed-off-by: Janusz Krzysztofik
Yeah, it basically needed a cleanup before returning error.
Reviewed-by: Andi Shyti
You are still missing
Cc: # v5.4+
Thanks,
Andi
Hi,
On Tue, May 20, 2025 at 06:01:12PM +0300, Joonas Lahtinen wrote:
> Quoting Krzysztof Niemiec (2025-05-19 18:34:14)
> > This series introduces a way for applications to read local memory
> > information via files in the sysfs. So far the only way to do this was
> > via i915_query ioctl. This is
callers such as sync_file, and our internal code paths, we can drop the
> similar protection from i915_fence_get_timeline_name().
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Tvrtko,
On Thu, May 15, 2025 at 10:50:00AM +0100, Tvrtko Ursulin wrote:
> Access the dma-fence internals via the previously added helpers.
>
> Signed-off-by: Tvrtko Ursulin
> Reviewed-by: Christian König
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Danila,
On Wed, Apr 23, 2025 at 12:31:24AM +0300, Danila Tikhonov wrote:
> Add the SM7150 CCI device string compatible.
>
> Signed-off-by: Danila Tikhonov
Acked-by: Andi Shyti
Thanks,
Andi
Hi Kees,
On Fri, Apr 25, 2025 at 11:13:58PM -0700, Kees Cook wrote:
> In preparation for making the kmalloc family of allocators type aware,
> we need to make sure that the returned type from the allocation matches
> the type of the variable being assigned. (Before, the allocator would
> always re
truct i915_wa *". The returned type, while
> > > technically matching, will be const qualified. As there is no general
> > > way to remove const qualifiers, adjust the allocation type to match
> > > the assignment.
> > >
> > > Signed-off-by: Kees Cook
be used for determining engine validity.
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 28 +--
drivers/gpu/drm/i915/gt/intel_engine_user.c | 9 --
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
er into
> chunks of 8 messages internally and so interrupts are not expected for
> the first 7 message completions, only the last message triggers
> an interrupt, indicating the completion of 8 messages.
>
> This BEI mechanism enhances overall transfer efficiency.
>
> Signed-
Hi Janusz,
> Janusz Krzysztofik (3):
> drm/i915: Downgrade device register error if injected
> drm/i915: Fix PXP cleanup missing from probe error rewind
> drm/i915: Fix harmful driver register/unregister asymmetry
merged to drm-intel-next.
Thanks,
Andi
Hi,
On Fri, Mar 28, 2025 at 12:26:29AM +0100, Andi Shyti wrote:
> Replace multi-line SPDX license headers with single-line
> equivalents (// SPDX-License-Identifier: MIT or /* ... */ for
> headers), as preferred by current kernel coding style.
>
> Signed-off-by: Andi Shyti
merg
Replace multi-line SPDX license headers with single-line
equivalents (// SPDX-License-Identifier: MIT or /* ... */ for
headers), as preferred by current kernel coding style.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 3 +--
drivers/gpu/drm/i915/gem
On Thu, Mar 27, 2025 at 12:42:50PM +0200, Jani Nikula wrote:
> On Thu, 27 Mar 2025, Andi Shyti wrote:
> > From: Andi Shyti
> >
> > Some GPUs, like DG2, can host more than one CCS engine. Some
> > workarounds or enablements need to happen only once for all the
> &
From: Andi Shyti
Replace checks for I915_ENGINE_FIRST_RENDER_COMPUTE combined
with CCS_MASK() with the FIRST_CCS() helper. This improves
readability and ensures that certain CCS-specific actions, such
as enabling GEN12_RCU_MODE and calling xehp_enable_ccs_engines(),
are performed only once, on
From: Andi Shyti
All platforms supported by i915 have at least one RCS engine,
so there's no need to explicitly check for RCS or CCS presence.
Remove the redundant check and move the associated functions
to a more appropriate location in the code.
Signed-off-by: Andi Shyti
---
driver
to be moved earlier in
the file to avoid the need for a forward declaration.
Suggested-by: Arshad Mehmood
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 58 +++--
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Andi Shyti
The I915_ENGINE_FIRST_RENDER_COMPUTE flag is no longer used.
Its purpose has been replaced by the FIRST_CCS() helper, which
determines the first render or compute engine as needed.
Remove the flag definition and its assignment from
intel_engine_setup().
Suggested-by: Lucas De
checking for
FIRST_RENDER_COMPUTE, but move the logic to the CCS engine
section.
- Define the FIRST_CCS flag which checks for the CCS engine
with the lowest istance number.
- Remove the I915_ENGINE_FIRST_RENDER_COMPUTE flag and use
FIRST_CCS() instead for everyone using it.
Andi Shyti (6):
drm/
From: Andi Shyti
Enable the CCS engine when the first CCS is encountered in the
execlist setup, instead of checking for the
I915_ENGINE_FIRST_RENDER_COMPUTE flag.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Andi Shyti
Some GPUs, like DG2, can host more than one CCS engine. Some
workarounds or enablements need to happen only once for all the
engines in the GT—for example, on the engine with the lowest
instance.
The FIRST_CCS() helper first checks if the engine is a Compute
engine, and then
Hi Lucas,
> > > > @@ -2897,7 +2897,9 @@ engine_init_workarounds(struct intel_engine_cs
> > > > *engine, struct i915_wa_list *wal
> > > > */
> > > > if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE) {
> > > > general_render_compute_wa_init(engine, wal);
> > > >
On Tue, Mar 25, 2025 at 01:57:42PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2025-03-25 13:01:37)
> > When generating workarounds for the CCS engine, specifically for
> > setting the CCS mode related to compute load balancing, the
> > function 'ccs_engine_wa_mod
ute before applying
the workaround to avoid redundant programming.
Suggested-by: Arshad Mehmood
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/d
Hi Joonas,
thanks a lot for your reply!
On Tue, Mar 25, 2025 at 10:24:42AM +0200, Joonas Lahtinen wrote:
> Quoting Andi Shyti (2025-03-24 15:29:36)
> > Back in v3, this patch series was turned down due to community
> > policies regarding i915 GEM development. Since then, I ha
To support upcoming patches, we need to store the current mask
for active CCS engines.
Active engines refer to those exposed to userspace via the UABI
engine list.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 41 +++--
drivers/gpu/drm/i915/gt
when they are marked as RB_EMPTY.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.h| 12 +
drivers/gpu/drm/i915/gt/selftest_context.c| 6 +--
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 +-
.../drm/i915/gt/selftest_engine_heartbeat.c | 6 +--
drivers/gpu
e user can set the CCS mode to 1, 2, or 4,
depending on the desired number of exposed engines and the
required load balancing.
The interface will return -EBUSY if other clients are connected
to i915, or -EINVAL if an invalid value is set.
Signed-off-by: Andi Shyti
---
drivers/gpu/d
ure
successful compilation and maintain bisectability. This
annotation will be removed in subsequent commits.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 128
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mod
In preparation for upcoming patches, we need the ability to
create and remove individual sysfs files. To facilitate this,
extract from the intel_engines_add_sysfs() function the creation
of individual files.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/sysfs_engines.c | 75
user whims.
To ensure thread safety and prevent race conditions, we need to
protect the engine list with a mutex, thereby serializing access
to it.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +++
drivers/gpu/drm/i915/gt/intel_engine_user.c | 7
Upcoming commits will need to access engine-related kobjects to
enable the creation and destruction of sysfs interfaces at
runtime.
For this, store the "engine" directory (i915->sysfs_engine), the
engine files (gt->kobj), and the default data
(gt->kobj_defaults).
Signed
Implement a sysfs interface to show the number of available CCS
slices. The displayed number does not take into account the CCS
balancing mode.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 21 +
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 1
Following the decision to manage CCS engine creation within UABI
engines, the "cslices" variable in the "ccs" structure in the
"gt" is no longer needed. Remove it is now redundant.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c |
r.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 23 -
drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 ---
2 files changed, 14 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/d
For the upcoming changes we need a cleaner way to build the list
of uabi engines.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 -
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm
of engines generated.
No functional changes intended.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.c | 3 +++
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 16 +++-
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_type
nal changes are intended yet, as no mode higher than
'0' is currently being set.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 85 +
drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 2 +-
2 files changed, 72 insertions(+), 15 deletions(-)
en using a
register value that only enables a single CCS engine, typically
with an ID of '0'.
However, in upcoming patches, we will be utilizing multiple
engines, and it's crucial that we write the new value directly
without any masking.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i9
ly different
approach to adding and removing engines. in v1 physical engines
were directly added and removed, along with the memory allocated
to them, each time the user changed the CCS mode (from the
previous cover letter).
Andi Shyti (15):
drm/i915/gt: Avoid using masked workaround for CCS_MODE
+841,9 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> if (ret)
> goto out_cleanup_gem;
>
> - i915_driver_register(i915);
> + ret = i915_driver_register(i915);
> + if (ret)
> + goto out_cleanup_gem;
looks good!
Reviewed-by: Andi Shyti
Thanks,
Andi
...
on path.
>
> Fix it.
>
> Cc: Alan Previn
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
Thanks,
Andi
gt; Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Yuichiro,
On Mon, Feb 24, 2025 at 05:56:37PM +0900, Yuichiro Tsuji wrote:
> Fix typo in a comment.
>
> explaination -> explanation
>
> Signed-off-by: Yuichiro Tsuji
reviewed and merged, thanks.
Andi
Hi Asbjorn,
On Sat, Jun 29, 2024 at 06:25:06PM +, Asbjørn Sloth Tønnesen wrote:
> Implement i915_gem_vmap_object() and i915_gem_vunmap_object(),
> based on i915_gem_dmabuf_vmap() and i915_gem_dmabuf_vunmap().
>
> This enables a drm_client to use drm_client_buffer_vmap() and
> drm_client_buffe
Hi Nitin,
On Wed, Feb 26, 2025 at 09:25:34PM +0530, Nitin Gote wrote:
> Give the scheduler a chance to breath by calling cond_resched()
> as some of the loops may take some time on old machines (like apl/bsw/pnv),
> and so catch the attention of the watchdogs.
>
> Closes: https://gitlab.freedeskt
improved safety.
Signed-off-by: Andi Shyti
Reviewed-by: Krzysztof Karas
---
Cc: Nitin Gote
v1 -> v2:
- replaced kmap with the _local version also in the
intel_ggtt_fencing.c file. (Thanks Nitin)
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
drivers/gpu/drm/i915/gt/shmem_util
Hi Krzysztof,
On Thu, Jan 16, 2025 at 10:40:46AM +, Krzysztof Karas wrote:
> spin_lock/unlock() functions used in interrupt contexts could
> result in a deadlock, as seen in GitLab issue #13399:
> https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399,
I moved this link in the tag sect
Hi Krzysztof,
On Wed, Feb 12, 2025 at 12:50:17PM +0100, Krzysztof Niemiec wrote:
> On 2025-02-10 at 14:01:19 GMT, Andi Shyti wrote:
> > On Thu, Feb 06, 2025 at 07:07:38PM +0100, Janusz Krzysztofik wrote:
> > > We return immediately from i915_driver_register() if drm_dev_regi
Hi Janusz,
On Tue, Feb 11, 2025 at 01:12:37PM +0100, Janusz Krzysztofik wrote:
> On Monday, 10 February 2025 14:01:19 CET Andi Shyti wrote:
> > On Thu, Feb 06, 2025 at 07:07:38PM +0100, Janusz Krzysztofik wrote:
> > > We return immediately from i915_driver_register() i
-off-by: Thomas Weißschuh
Reviewed-by: Andi Shyti
Thanks,
Andi
-off-by: Thomas Weißschuh
Reviewed-by: Andi Shyti
Andi
-off-by: Thomas Weißschuh
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Janusz,
On Thu, Feb 06, 2025 at 07:07:38PM +0100, Janusz Krzysztofik wrote:
> We return immediately from i915_driver_register() if drm_dev_register()
> fails, skipping remaining registration steps. However, the _unregister()
> counterpart called at device remove knows nothing about that skip a
> > - if (!folio)
> > + if (IS_ERR(folio))
>
> I don't see this patch yet in -next yet (and of course not in
> drm-tip), which branch is it based on?
To be precise, not this patch, but the patch(*) that this is fixing :-)
Andi
(*) "drm/i915/gem: Convert __shmem_writeback() t
Hi Dan,
On Thu, Feb 06, 2025 at 11:17:02AM +0300, Dan Carpenter wrote:
> The filemap_lock_folio() function doesn't return NULL, it returns error
> pointers.
>
> Fixes: 25dd342f0cc8 ("drm/i915/gem: convert __shmem_writeback() to folios")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/i91
Hi Krzysztof,
On Thu, Jan 30, 2025 at 09:19:31AM +, Krzysztof Karas wrote:
> There is an error path in igt_ppgtt_alloc(), which leads
> to ww object being passed down to i915_gem_ww_ctx_fini() without
> initialization. Correct that by only putting ppgtt->vm and
> returning early.
>
> Fixes: 4
folio = filemap_lock_folio(mapping, i);
> - if (!folio)
> + if (IS_ERR(folio))
ops! Thanks, Dan
Reviewed-by: Andi Shyti
Andi
Hi,
> > Please, next time, do not remove the mailing and the other folks
> > you cc'ed.
> >
> > I'm adding back the mailing list and Daniele who has commented
> > before.
>
> Thanks, I also found my previous response click on "reply", not the "reply
> all".
no worries, happens :-)
> > > > > Cl
t address the four different fixes?
> Sure, will split it in next rev.
First of all we need to understand if those Fixes are really
needed or not. Daniele in his review has pointed out that...
> > >
> >
> > No blank lines in the tag section, please.
> >
page
> flag bit with PG_readahead.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: David Hildenbrand
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Kirill,
On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote:
> Use folios instead of pages.
>
> This is preparation for removing PG_reclaim.
>
> Signed-off-by: Kirill A. Shutemov
> Acked-by: David Hildenbrand
looks good:
Reviewed-by: Andi Shyti
Thanks,
Andi
)
Cc: # v4.10+
Could you please split this patch in the four different patches
that address the four different fixes?
>
No blank lines in the tag section, please.
> Signed-off-by: Zhanjun Dong
>
> ---
> Cc: Alan Previn
> Cc: Daniele Ceraolo Spurio
> Cc: Rodrigo Vivi
improved safety.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index bb696b29ee2c..365c4b8b04f4 100644
--- a/drivers/gpu
Hi,
this patch has been hanging here for a while, can we please have
someone from DMA and Qualcomm look at it?
Thanks,
Andi
On Tue, Dec 17, 2024 at 10:34:22PM +0530, Jyothi Kumar Seerapu wrote:
> The I2C driver gets an interrupt upon transfer completion.
> When handling multiple messages in a si
Hi Carlos,
On Mon, Nov 25, 2024 at 10:29:09PM +0800, carlos.s...@nxp.com wrote:
> From: Carlos Song
>
> Add eDMA mode support for LPI2C.
>
> There are some differences between TX DMA mode and RX DMA mode.
> LPI2C MTDR register is Controller Transmit Data Register.
> When lpi2c send data, it is
Hi Janusz,
> > > > > > +
> > > > > > cond_resched();
> > > > > >
> > > > > > - if (intel_gt_wait_for_idle(gt, HZ * 3) == -ETIME) {
> > > > > > + if (intel_gt_wait_for_idle(gt, HZ * timeout_ms / 500)
> > > > > > == -ETIME) {
> > > > >
> > > > > where is this 500
from a single failing test case. Let
> me verify if that works for the linked case.
As we agreed offline, I'm going to add this comment you suggested
to your change as a justification to the "/ 500":
/* 2x longest preempt timeout, experimentally determined */
With this:
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Janusz,
...
> > > +
> > > cond_resched();
> > >
> > > - if (intel_gt_wait_for_idle(gt, HZ * 3) == -ETIME) {
> > > + if (intel_gt_wait_for_idle(gt, HZ * timeout_ms / 500) == -
> ETIME) {
> >
> > where is this 500 coming from?
>
> / 1000 would convert it to seconds
Hi Janusz,
...
> for_each_gt(gt, i915, i) {
> + struct intel_engine_cs *engine;
> + unsigned long timeout_ms = 0;
> + unsigned int id;
> +
> if (intel_gt_is_wedged(gt))
> ret = -EIO;
>
> + for_each_engine(
Hi Jani,
On Thu, Dec 05, 2024 at 11:49:35AM +0200, Jani Nikula wrote:
> Use the drm_printer based printer to get the device specific printing of
> the hex dump, and avoid the manual loglevel hacking.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Andi Shyti
Thanks,
Andi
8 *buf, size_t len)
> -{
> - if (!drm_debug_enabled(DRM_UT_KMS))
> - return;
We lose this check now, anyway,
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Jani,
On Thu, Dec 05, 2024 at 11:49:33AM +0200, Jani Nikula wrote:
> Add a helper to print a hex dump to a struct drm_printer. There's no
> fancy formatting stuff, just 16 space-separated bytes per line, with an
> optional prefix.
>
> Signed-off-by: Jani Nikula
Rev
1 - 100 of 1145 matches
Mail list logo
