-by: Jyothi Kumar Seerapu
Ping on this patch. I'm sorry, but going to take it in the next
few days if I don't hear from you, this patch has been waiting
for a very long time.
Thanks,
Andi
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
merged to drm-intel-next.
Thank you,
Andi
drm_vma_node_allow_once(&mmo->vma_node, file);
> + if (file) {
> + err = drm_vma_node_allow_once(&mmo->vma_node, file);
> + if (err)
> + goto err;
> + }
I agree with the change.
Thank you,
Andi
> return mmo;
>
> err:
> --
> 2.43.0
n for tiny changes.
> Jyothi Kumar Seerapu (2):
> dmaengine: qcom: gpi: Add GPI Block event interrupt support
We still need Vinod's comments here...
> i2c: i2c-qcom-geni: Add Block event interrupt support
... and Mukesh and Viken's ack here.
Thanks,
Andi
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
ar() to simplify code.
> >
> > Signed-off-by: Ilpo Järvinen
> > Acked-by: Christian König
>
> Reviewed-by: Jani Nikula
>
> and
>
> Acked-by: Jani Nikula
Just for some random noise on commit log's bureaucracy: why do we
need both Ack and R-b? I think R-b covers Ack making it
redundant. Right?
Andi
nen
> Acked-by: Christian König
Reviewed-by: Andi Shyti
Thanks,
Andi
ceed, I can already apply your first
patch so that it gets included in the Wednesday's pull request.
While the second patch, that is not a fix, has plenty of time and
can wait the backmerge.
Andi
(*) 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and
write_iter")
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
/* make sure interrupt handler will see changes */
> + smp_mb();
Are we sure we need the barriers here? Can you please explain
better what you are trying to achieve?
My idea of barriers was to use in order to avoid converting
everything into atomic, which doesn't necessarily mean that it's
the best solution, it was just a thought.
But maybe I misunderstood your intention.
Andi
/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
he tasklet? :-)
Would it make sense to add something like:
@@ -1338,6 +1338,9 @@ static void ct_receive_tasklet_func(struct tasklet_struct
*t)
{
struct intel_guc_ct *ct = from_tasklet(ct, t, receive_tasklet);
+ if (!atomic_read(&guc->interrupts.enabled))
+ return;
+
ct_try_receive_message(ct);
}
BTW, have you tried adding a simple memory barrier (even though
in the i915 community people dislike memory barriers, but with a
proper explanation it might save us all this churn).
Thanks,
Andi
that when in interrupt context you are already
running in atomic, so that probably you don't need to have an
additional atomic access to variables.
Andi
> Signed-off-by: Zhanjun Dong
> Cc: Daniele Ceraolo Spurio
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
per branch after the weekly pull request.
Thanks,
Andi
s that there are no new third party K8
chipsets anymore.
-Andi
d the
old 4GB IOMMU anyways, and for low speed ones it's fine to use swiotlb
instead.
-Andi
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
stm32f7_i2c_disable_dma_req(i2c_dev);
> dmaengine_terminate_async(dma->chan_using);
> + dma_unmap_single(i2c_dev->dev, dma->dma_buf,
> dma->dma_len,
> +
ma->dma_len,
> + dma->dma_buf = dma_map_single(dev, buf, dma->dma_len,
> dma->dma_data_dir);
> if (dma_mapping_error(chan_dev, dma->dma_buf)) {
this one should be "dev" too, which renders t
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]
):
> i2c: stm32: fix the device used for the DMA map
> i2c: stm32f7: unmap DMA mapped buffer
> i2c: stm32f7: support i2c_*_dma_safe_msg_buf APIs
any chance you can take a look at this series?
Thanks,
Andi
>
> drivers/i2c/busses/i2c-stm32.c | 2 +-
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:
> >
ver
> "drm/i915/ring_submission:" file name in the commit title.
good observation, I missed it. I agree with Nitin on this, it can
be fixed before merging.
Andi
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
> Even now, userspace/sysadmin could already essentially use setuid helper
> process that will only report the memory statistics.
>
> So I'm not really fully convinced this is needed at all.
yeah! What is the real use case? Who is the userspace client?
There are already way
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
he allocation type to match
> the assignment.
>
> Signed-off-by: Kees Cook
merged to drm-intel-gt-next.
Thanks,
Andi
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
. Ensure the CCS engine workaround is applied only once
2. Remove the I915_ENGINE_FIRST_RENDER_COMPUTE flag
Thanks,
Andi
[*] 1bfc03b13752 ("drm/i915: Remove special handling for !RCS_MASK()")
Changelog:
==
v1 -> v2
- During workaround set-up, avoid
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
that this applies in two cases: it's true for
the first CCS we encounter and also for the only RCS. Arshad
noticed that we end up applying the workaround twice.
So the !RCS_MASK(gt) check is still needed.
Alternatively, as Matt suggested, we could assign
I915_ENGINE_FIRST_RENDER_COMPUTE only to the RCS.
I have a slight preference for the way it was done before because
it make the logic clearer.
Thanks,
Andi
> It was supposed to mean the same thing... but doesn't as engine->instance
> starts from 0 for each class.
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
hnical concerns could be
raised and discussed on the mailing list.
IGT tests for this work exist but haven't been submitted yet.
Thanks to Chris for the reviews, to Arshad for the work we've
done together over the past few weeks, and to Michal for his
invaluable input from the userspace side.
+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
aring the tests?
> [1] XDP->DRM pixelflut: https://labitat.dk/wiki/Pixelflut-XDR
>
> Signed-off-by: Asbjørn Sloth Tønnesen
thanks, reviewed and merged to drm-intel-gt-next.
Andi
uot; (maintainer:DMA BUFFER SHARING
FRAMEWORK)
linux-me...@vger.kernel.org (open list:DMA BUFFER SHARING FRAMEWORK)
dri-devel@lists.freedesktop.org (open list:DMA BUFFER SHARING FRAMEWORK)
I added them now, but you might still be asked to resend.
Said that, at a first glance, I don't have a
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
text race against
> CT-loss")
I moved Fixes: above your SoB.
> Cc: # v6.9+
Anyway, good catch, but please, remember next time to relly add
in Cc the stable kernel mailing list, the guc guys in Cc for GuC
related patches and the author of the patch you are fixing.
Reviewed and merged in drm-intel-gt-next.
Thanks,
Andi
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
ings that come to my mind, maybe there are smarter ways
of doing it). This way we could skip some of the _unregister()
steps.
Andi
> > - 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
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?
Thanks,
Andi
> continue;
>
> if (!folio_mapped(folio) && folio_clear_dirty_for_io(folio)) {
> --
> 2.47.2
rly.
>
> Fixes: 480ae79537b2 ("drm/i915/selftests: Prepare gtt tests for obj->mm.lock
> removal")
> Signed-off-by: Krzysztof Karas
> Reviewed-by: Mikolaj Wasiak
reviewed and merged.
Thanks,
Andi
folio = filemap_lock_folio(mapping, i);
> - if (!folio)
> + if (IS_ERR(folio))
ops! Thanks, Dan
Reviewed-by: Andi Shyti
Andi
;drm/i915: Support for GuC interrupts")
> > > > Cc: # v4.10+
> > > >
> > > > Could you please split this patch in the four different patches
> > > > that 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...
> I agree with Daniele, these fixes is not needed.
yeah, with such a low reproduction rate, if it's not a
catastrofic failure the Fixes: tag is not really needed and
therefore you don't need to split the patch anymore.
Still we need to understand whether this patch really fixes the
issue.
Thanks,
Andi
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 message
nel to send data. But when lpi2c is in DMA RX mode, TX and RX channel
> are both enabled, TX channel is used to send RX cmd and RX channel is
> used to receive data.
>
> Signed-off-by: Carlos Song
> Signed-off-by: Frank Li
merged to i2c/i2c-host.
Thanks,
Andi
linked case.
>
> I've done some testing and got a confirmation that the issue I'm trying to
> address in the first place requires a timeout almost twice as long as the
> longest preemption timeout.
>
> I propose the following correction:
>
> - if (intel_gt_wait_for_idle(gt, HZ * 3) == -ETIME) {
> + /* 2 x longest preempt timeout, experimentally determined */
> + if (intel_gt_wait_for_idle(gt, 2 * timeout_ms * HZ / 1000) == -ETIME) {
with this change, I merge your patch to drm-intel-next.
Thanks,
Andi
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
plicit 2 * preempt_timeout / 1000 ?
It was clear that you were doubling it, but what's more
interesting to know (perhaps in a comment) is why you are
choosing to use the double of the timeout_ms instead of other
values.
Makes sense?
Thanks,
Andi
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?
Thanks,
Andi
>
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
1 - 100 of 1159 matches
Mail list logo
