them.
Cc: Ville Syrjälä
Signed-off-by: Gustavo Sousa
Fixed the typo and pushed to drm-intel-next
thanks,
Lucas De Marchi
topology
There's a small conflict when applying drm-next and when applying
drm-xe-next on top of them, but should be trivial and already solved in
drm-tip.
thanks,
Lucas De Marchi.
The following changes since commit 347e9f5043c89695b01e66b3ed111755afcf1911:
Linux 6.16-rc6 (2025-07-13 14:
devcoredump
- Fix xe_pm_set_vram_threshold() doc
- Recommend new minor versions of GuC firmware
- Drop some workarounds on VF
- Do not use verbose GuC logging by default: it should be only for
debugging
thanks,
Lucas De Marchi
The following changes since commit d7b8f8e20813f0179d8ef519541a3527e7661d3a
)
- Fix wedging the device on signal (Matthew Brost)
thanks,
Lucas De Marchi
The following changes since commit d0b3b7b22dfa1f4b515fd3a295b3fd958f9e81af:
Linux 6.16-rc4 (2025-06-29 13:09:04 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/xe/kernel.git tags
On Thu, Jul 03, 2025 at 10:35:13AM +0300, Jani Nikula wrote:
On Mon, 30 Jun 2025, Lucas De Marchi wrote:
This reverts commit 41e750b906022da3e4fb9dc57bc17670a340ad23.
It's not used in CI anymore, probably for a very long time. So we don't
need maintain this in topic/core-for-CI.
lso merge before testing
and we've been including the change above to stop it from killing the
rest of our CI:
https://gitlab.freedesktop.org/drm/i915/kernel/-/commit/e9d0926aa1c6afcc920013c39d5bd6dd85f581fb
Lucas De Marchi
/msec etc that pairs nicely with USEC_PER_SEC
and friends, also used by tools like perf and are a little bit more
greppable than ms/us?
Lucas De Marchi
On Thu, Jul 03, 2025 at 09:08:54AM -0300, Gustavo Sousa wrote:
Quoting Ville Syrjälä (2025-07-02 18:49:30-03:00)
On Thu, Jul 03, 2025 at 12:29:37AM +0300, Ville Syrjälä wrote:
On Wed, Jul 02, 2025 at 03:25:21PM -0500, Lucas De Marchi wrote:
> On Wed, Jul 02, 2025 at 10:40:34PM +0300, Vi
On Thu, Jul 03, 2025 at 03:00:19PM +0530, Nautiyal, Ankit K wrote:
On 7/3/2025 3:19 AM, Ville Syrjälä wrote:
On Thu, Jul 03, 2025 at 12:29:37AM +0300, Ville Syrjälä wrote:
On Wed, Jul 02, 2025 at 03:25:21PM -0500, Lucas De Marchi wrote:
On Wed, Jul 02, 2025 at 10:40:34PM +0300, Ville Syrjälä
commit: d6a59ee852758bc69c4cc821954db277a2bd5b93
Lucas De Marchi
what the heck is going on.
what is the alternative? The current status quo checking by platform
and/or IP version, dissociated from the WA numbers?
Lucas De Marchi
+};
+
+bool __intel_display_wa(struct intel_display *display, enum intel_display_wa
wa);
+
+#define intel_display_w
y waiting it to either propagate
it in xe or have someone merge such a patch. I'm not sure about
removing the exponential backoff is a good thing overall, but if it's
needed then it needs to be justified to add a new function to pair with
read_poll_timeout(), not a custom driver function.
Lucas De Marchi
This reverts commit 41e750b906022da3e4fb9dc57bc17670a340ad23.
It's not used in CI anymore, probably for a very long time. So we don't
need maintain this in topic/core-for-CI.
Signed-off-by: Lucas De Marchi
---
kernel/trace/Kconfig | 7 ---
kernel/trace/trace.c | 4 +++-
2 files
On Wed, May 21, 2025 at 08:51:24PM +, Harry Austen wrote:
On Wed May 21, 2025 at 4:11 PM BST, Lucas De Marchi wrote:
On Wed, May 21, 2025 at 08:35:05AM +, Harry Austen wrote:
>On Mon May 19, 2025 at 4:14 PM BST, Maarten Lankhorst wrote:
>> Hey,
>>
>> On 2025-05-1
On Thu, Jun 26, 2025 at 01:56:23PM -0500, Lucas De Marchi wrote:
On Mon, Jun 23, 2025 at 02:43:46PM +0300, Jani Nikula wrote:
In preparation for dropping the dependency on struct intel_uncore or
struct xe_tile from display code, add a struct drm_device based
interface to pcode.
Cc: Lucas De
xt+0x9d0): first defined
here
not exclusive to i386... the pcode part used to be guarded by
CONFIG_DRM_XE_DISPLAY, but that is broken now. Possible fix discussed
in
https://lore.kernel.org/intel-xe/gbisrh7ep2gn2fxv7xz4g4sy75qjpmcr5yqdx5atlab2oxevlx@j3zwx3k4o4x4/
Lucas De Marchi
--
~Randy
On Mon, Jun 23, 2025 at 02:43:46PM +0300, Jani Nikula wrote:
In preparation for dropping the dependency on struct intel_uncore or
struct xe_tile from display code, add a struct drm_device based
interface to pcode.
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Signed-off-by
Marchi
for merging this through drm-misc tree.
Lucas De Marchi
x27;s not perfect. But there are
4.2k lines in i915_reg.h, and its refactoring has ground to a halt. This
is the big hammer that splits the file to two, and enables further
cleanup.
Cc: Suraj Kandpal
Cc: Ville Syrjälä
Cc: Lucas De Marchi
Signed-off-by: Jani Nikula
I skimmed over the register
or soc/, or no users anywhere, keep the macros
in i915_reg.h. This is done in groups of macros separated by blank
lines, moving the comments along with the groups.
I wonder if with this we couldn't end up moving wrong registers.
Maybe we should double check the address range too?
Lucas De Marchi
onize Panther Lake PCI IDs
thanks
Lucas De Marchi
The following changes since commit a5806cd506af5a7c19bcd596e4708b5c464bfd21:
Linux 6.15-rc7 (2025-05-18 13:57:29 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2025-05-23
fo
-by: Jani Nikula
Acked-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 1 +
drivers/gpu/drm/xe/display/xe_display.c | 1 +
drivers/gpu/drm/xe/display/xe_display_rpm.c | 1 +
drivers/gpu/drm/xe/display/xe_display_wa.c| 2 +-
drivers/gpu/drm
ction it will
call the cb, so intel_display_device_remove() was already
called at this point. Just return err.
Other than that, lgtm. Reviewed-by: Lucas De Marchi
Lucas De Marchi
abled, it must be built-in
too.
Also, allow DRM_XE_DISPLAY to be built-in. But only as long as DRM_I915
isn't, since that results in duplicate symbol errors.
Fixes: 08987a8b6820 ("drm/xe: Fix build with KUNIT=m")
Cc: Lucas De Marchi
Cc: Thomas Hellström
Cc: Jani Nikula
Signed-
not saving timestamp with lite restore enabled.
Thanks,
Lucas De Marchi
The following changes since commit 82f2b0b97b36ee3fcddf0f0780a9a0825d52fec3:
Linux 6.15-rc6 (2025-05-11 14:54:11 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/xe/kernel.git
tags/drm-xe-
Hi Dave and Sima,
Here's the drm-xe-fixes for 6.15-rc6.
drm-xe-fixes-2025-05-09:
Driver Changes:
- Prevent PF queue overflow
- Hold all forcewake during mocs test
- Remove GSC flush on reset path
- Fix forcewake put on error path
- Fix runtime warning when building without svm
thanks
Luc
anges:
- Eustall locking fix and disabling on VF
- Documentation fix kernel version supporting hwmon entries
- SVM fixes on error handling
thanks
Lucas De Marchi
The following changes since commit b4432656b36e5cc1d50a1f2dc15357543add530e:
Linux 6.15-rc4 (2025-04-27 15:19:23 -0700)
are available i
lt-in. But only as long as DRM_I915
isn't, since that results in duplicate symbol errors.
Fixes: 08987a8b6820 ("drm/xe: Fix build with KUNIT=m")
Cc: Lucas De Marchi
Cc: Thomas Hellström
Cc: Jani Nikula
Signed-off-by: Harry Austen
I didn't test this, but it makes sense to m
ll go through.
bspec 46034 shows this register as a masked register:
Access: Masked(R/W)
and documentation for bits 31:16 shows the mask.
Lucas De Marchi
*/
+ if (!FIRST_CCS(engine))
the problem you'd face is that if you fix this macro to also include
render, then you break it here.
Lucas De Marchi
+ return;
+
+ /*
+* Wa_14019159160: This workaround, along with others, leads to
+* significant challenges
implemented the macro exclusively using
CCS_MASK, so it only means compute and will skip applying the
workarounds on platforms that don't have compute but have render.
Lucas De Marchi
Remove the flag definition and its assignment from
intel_engine_setup().
Suggested-by: Lucas De Marchi
Signed-o
". And yes, if unofficial support
for PVC is desired, then that can't be done, but shifting it to be
always on CCS would be wrong too.
Lucas De Marchi
unconditionally
Thanks,
Lucas De Marchi
The following changes since commit 8ffd015db85fea3e15a77027fda6c02ced4d2444:
Linux 6.15-rc2 (2025-04-13 11:54:49 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2025-04-18
for you to fetch changes
include it
explicitly from i915_drv.h or xe_device_types.h.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
On Fri, Apr 11, 2025 at 12:54:13PM +0300, Jani Nikula wrote:
Make PCH detection part of display. For now, call it also for
!HAS_DISPLAY() to avoid functional changes here.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
gion.h"
-#include "intel_dmc_wl.h"
+#include "intel_pch.h"
why not merging intel_pch and intel_pch_display? Now that both are
under display/, there isn't much reason for the split, is there?
Lucas De Marchi
al or code change.
Signed-off-by: Rodrigo Vivi
Reviewed-by: Jani Nikula
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
Xe3
- Fix PM runtime get/put on sysfs files
- Fix u64 division on 32b
- Fix flickering due to missing L3 invalidations
- Fix missing error code return
thanks,
Lucas De Marchi
The following changes since commit 0af2f6be1b4281385b618cb86ad946eded089ac8:
Linux 6.15-rc1 (2025-04-06 13:11:33 -0700
This reverts commit 3f412047c54e28ecd50c10bdcec698f166c861e8.
Tentative removal from topic/core-for-CI.
Signed-off-by: Lucas De Marchi
---
drivers/ata/libata-core.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata
On Mon, 24 Mar 2025 19:28:40 -0700, Lucas De Marchi wrote:
> Improve DRAM type logging across platforms.
>
>
Applied to drm-intel-next. Thanks for reviewing!
[1/2] drm/i915/dram: Add missing INTEL_DRAM str conversions
commit: 8d4bd9bb138a72e5794d6597ee8d1f85f272ef63
[2/2] drm/
le pointer dereference after free
Lucas De Marchi (2):
drm/xe: Move survivability back to xe
drm/xe: Set survivability mode before heci init
Michal Wajdeczko (1):
drm/xe/vf: Don't check CTC_MODE[0] if VF
Vinay Belgaumkar (1):
drm/xe: Apply Wa_16023105232
Yue Haibing (1):
is meant to only be on the first engine of either
rcs or ccs (which share certain register domains), one engine.
It looks like that was broken by
commit 1bfc03b1375244f9029bb448ee8224b3b6dae99f
Author: Lucas De Marchi
yep, my bad.
Date: Tue Mar 19 23:03:03 2024 -0700
ine, wal);
> >
> > FIRST_RENDER_COMPUTE is meant to only be on the first engine of either
> > rcs or ccs (which share certain register domains), one engine.
> >
> > It looks like that was broken by
> >
> > commit 1bfc03b1375244f9029bb448ee8224b3b6dae99f
&
On Tue, Mar 25, 2025 at 11:03:13AM +0200, Jani Nikula wrote:
On Mon, 24 Mar 2025, Lucas De Marchi wrote:
On Mon, Mar 24, 2025 at 01:02:07PM -0700, Matt Roper wrote:
On Mon, Mar 24, 2025 at 10:22:33AM -0700, Lucas De Marchi wrote:
From: Vivek Kasireddy
Some SKUs of Xe2_HPD platforms (such
Some new dram types were added without adding the corresponding string
conversion, probably because it's not being used by recent platforms.
Add them, together with a BUILD_BUG_ON() to ensure it keeps in sync, in
preparation to make use of them in recent platforms.
Signed-off-by: Lucas De M
tains the behavior of skl_get_dram_info() that would log the
DRAM type even on failures.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/soc/intel_dram.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/soc/intel_dram.c
b/drivers/gpu/drm
Improve DRAM type logging across platforms.
Signed-off-by: Lucas De Marchi
---
Lucas De Marchi (2):
drm/i915/dram: Add missing INTEL_DRAM str conversions
drm/i915/dram: Consolidate logging of DRAM type
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/soc
On Mon, Mar 24, 2025 at 01:02:07PM -0700, Matt Roper wrote:
On Mon, Mar 24, 2025 at 10:22:33AM -0700, Lucas De Marchi wrote:
From: Vivek Kasireddy
Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type
with ECC enabled. We need to identify this scenario and add a new
case in
bandwidth.
Bspec: 64602
Cc: Matt Roper
Fixes: 3adcf970dc7e ("drm/xe/bmg: Drop force_probe requirement")
Cc: sta...@vger.kernel.org
Signed-off-by: Vivek Kasireddy
Signed-off-by: Lucas De Marchi
---
Changes in v2:
- Add a separate sa_info for the ecc case (Lucas)
- Link to
714.1041549-1-baolu...@linux.intel.com/
Thanks. FWIW I added this patch to our test branch in CI and the issue
is indeed not reproducing anymore.
Lucas De Marchi
l_display, but
otherwise this commit still applies.
Lucas De Marchi
i915->display.bw.max[0].deratedbw[i] =
- min(maxdebw, (100 - sa->derating) * bw / 100);
+ min(maxdebw, (100 - derating) * bw / 100);
cal order.
Emacs M-x sort-lines is the definition for me. ;)
`LANG=C sort -u` and it works in vim and anywhere else :). -u because
we also don't want duplicate lines.
Lucas De Marchi
On Thu, Mar 13, 2025 at 03:00:34PM +0900, Vincent Mailhol wrote:
On 13/03/2025 at 13:13, Lucas De Marchi wrote:
On Thu, Mar 06, 2025 at 08:29:56PM +0900, Vincent Mailhol via B4 Relay
wrote:
From: Vincent Mailhol
The definitions of GENMASK() and GENMASK_ULL() do not depend any more
on
would need another command to do "the right thing", for whatever
definition of "right" we want. Not sure if it's worth pursuing as the
sort is also used in other places like includes and build objects in
the Makefile. Would we change all of them?
Lucas De Marchi
Hi Dave and Sima,
Here's the drm-xe-next-fixes for this week targeting 6.15. Without the
kernel-doc fix, building the docs was broken and there is also a warning
fix microblaze arch. Others are "normal driver fixes".
thanks
Lucas De Marchi
drm-xe-next-fixes-2025-03-12:
Core
On Fri, Mar 07, 2025 at 02:10:28AM +0900, Vincent Mailhol wrote:
On 06/03/2025 at 23:34, Lucas De Marchi wrote:
On Thu, Mar 06, 2025 at 08:29:52PM +0900, Vincent Mailhol via B4 Relay
wrote:
(...)
it seems we now have 1 inconsistency that we comment why
GENMASK_U128() is not available in asm
, 21));
ditto
thanks
Lucas De Marchi
+ KUNIT_EXPECT_EQ(test, 0xull, __GENMASK_ULL(63, 0));
+}
+
static void genmask_test(struct kunit *test)
{
KUNIT_EXPECT_EQ(test, 1ul, GENMASK(0, 0));
@@ -93,6 +109,8 @@ static void genmask_input_check_test(struct kunit *test
On Thu, Mar 06, 2025 at 08:29:58PM +0900, Vincent Mailhol via B4 Relay wrote:
From: Vincent Mailhol
Add some additional tests in lib/test_bits.c to cover the expected
results of the fixed type BIT_U*() macros.
Signed-off-by: Vincent Mailhol
Reviewed-by: Lucas De Marchi
thanks
Lucas De
On Fri, Mar 07, 2025 at 08:51:03AM -0600, Lucas De Marchi wrote:
On Fri, Mar 07, 2025 at 02:02:15AM -0600, Lucas De Marchi wrote:
Hi Dave and Sima,
Last drm-xe-next pull request for 6.15. It comes with some big features
that we have been working on for some time: EU stall sampling and SVM.
The
On Fri, Mar 07, 2025 at 02:02:15AM -0600, Lucas De Marchi wrote:
Hi Dave and Sima,
Last drm-xe-next pull request for 6.15. It comes with some big features
that we have been working on for some time: EU stall sampling and SVM.
The latter also touches other subsystems and provides the common
and they look good to me.
thanks
Lucas De Marchi
drm-xe-next-2025-03-07:
UAPI Changes:
- Expose per-engine activity via perf pmu (Riana, Lucas, Umesh)
- Add support for EU stall sampling (Harish, Ashutosh)
- Allow userspace to provide low latency hint for submission (Tejas)
- GPU SVM and Xe SVM
ffice. Or perhaps we want
__GENMASK_Uxx() here?
If no objection, I have a preference for GENMASK_TYPE().
ack, GENMASK_TYPE() seems better.
thanks
Lucas De Marchi
d-by: Lucas De Marchi
thanks for picking up this series.
Lucas De Marchi
-#define GENMASK_INPUT_CHECK(h, l) 0
-#endif
#define GENMASK(h, l) \
(GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
#define GENMASK_ULL(h, l) \
(GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l))
-#if !define
at b4 does" rather
than a specific behavior in this forked patchwork instance is much
better. At least with b4 we can set expectations or have hope of
eventually tweaking it.
Lucas De Marchi
handling series revisions when only some of the patches in a series are
updated by way of replying
hat is fixable
even if we get it wrong in the beginning.
No opinion on the gitlab vs github as it's only used as interface to the
real CI that is happening. I think you can use what makes more sense for
CI team, but hopefully making it in a way that would not be a huge
effort to use somethin
intel_fb_pin_to_ggtt() by intel_fbdev anyway.
This fixes the fbdev device not working after resume.
Fixes: 67a98f7e27ba ("drm/xe/display: Re-use display vmas when possible")
Signed-off-by: Maarten Lankhorst
Cc: Lucas De Marchi
Reviewed-by: Lucas De Marchi
Lucas De Marchi
On Wed, Mar 05, 2025 at 11:39:50AM +0100, Maarten Lankhorst wrote:
On 2025-03-05 00:09, Lucas De Marchi wrote:
On Thu, Feb 20, 2025 at 06:17:01PM +0100, Maarten Lankhorst wrote:
Hey,
On 2025-02-20 16:43, Matthew Auld wrote:
On 20/02/2025 14:22, Lucas De Marchi wrote:
On Wed, Feb 19, 2025
On Thu, Feb 20, 2025 at 06:17:01PM +0100, Maarten Lankhorst wrote:
Hey,
On 2025-02-20 16:43, Matthew Auld wrote:
On 20/02/2025 14:22, Lucas De Marchi wrote:
On Wed, Feb 19, 2025 at 04:34:40PM +0100, Maarten Lankhorst wrote:
The fbdev vma is a normal unrotated VMA, so add ane explicit check
.
thanks
Lucas De Marchi
drm-xe-next-2025-02-24:
UAPI Changes:
- Add mmap support for PCI memory barrier (Tejas, Matthew Auld)
- Enable integration with perf pmu, exposing event counters: for now, just
GT C6 residency (Vinay, Lucas)
- Add "survivability mode" to allow putting the d
ay reference clock to determine GT CS frequency
+* is only relevant to pre-Xe2 platforms.
+*/
+ if (GRAPHICS_VER(xe) < 20 && ctc_reg & CTC_SOURCE_DIVIDE_LOGIC) {
+ freq = xe_display_get_refclk(xe);
can we go a step further and completely drop using the display ref
On Thu, Feb 20, 2025 at 11:47:21AM -0500, Liang, Kan wrote:
On 2025-02-20 10:36 a.m., Lucas De Marchi wrote:
On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
perf_msr_probe() to make the power/events/energy-gpu event non-visible.
When that happens, the msr always read 0
On Thu, Feb 20, 2025 at 08:28:01AM -0800, Dave Hansen wrote:
On 2/20/25 07:36, Lucas De Marchi wrote:
On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
perf_msr_probe() to make the power/events/energy-gpu event non-visible.
When that happens, the msr always read 0 until the
reading the MSR directly since it works after xe is loaded, but the
issue with not having the perf event is still there.
Closes: https://github.com/ulissesf/qmassa/issues/4
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4241
Signed-off-by: Lucas De Marchi
"needed" on suspend so they'd be saved by mm. The ggtt afair was one of
them. Or did we go with a different approach and I'm misremembering?
+Matthew Brost / +Matthew Auld
I think this was about commit dd886a63d6e2 ("drm/xe: Restore system
p. See CG_FUNCS in drivers/gpu/drm/i915/intel_clock_gating.c
The callers are the ones calling intel_clock_gating_init(), which is
both on display and gem sides. On the GEM side there's already and
eternal TODO comment:
* FIXME: break up the workarounds and apply them at the right time!
Luca
hed:
1) Survivability mode: to allow communication with mei and
possibly unbrick a device. Right now in xe we handle this
separately though: the driver needs to be initialized in this
mode
2) devcoredump: if there's a crash to be debugged with the help
On Tue, Jan 21, 2025 at 12:19:15PM -0500, Liang, Kan wrote:
On 2025-01-21 11:59 a.m., Lucas De Marchi wrote:
On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
On 2025-01-21 9:29 a.m., Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 08:42:41PM -0500, Liang, Kan wrote:
-static int
On Mon, Feb 10, 2025 at 06:16:58PM +0200, Ville Syrjälä wrote:
On Fri, Feb 07, 2025 at 04:41:11PM -0600, Lucas De Marchi wrote:
On Fri, Feb 07, 2025 at 11:54:03PM +0200, Ville Syrjälä wrote:
>From: Ville Syrjälä
>
>Something has changed in the hardware on LNL/BMG because
>HDM
{ 14, 0, &xe_lpdp_display },
{ 14, 1, &xe2_hpd_display },
...
}
So maybe we need to check for the full version >= 1401 instead?
+Matt Roper, +Gustavo who may know the right bspec to confirm this
change in behavior
Lucas De Marchi
Ville Syrjälä (3):
drm/i915: Fix scan
On Fri, 31 Jan 2025 15:11:32 -0800, Lucas De Marchi wrote:
> Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with
> a scope"), there's generic support for system-wide counters and
> integration with cpu hotplug.
>
> The i915 counters ar
igned-off-by: Rik van Riel
Reviewed-by: Christoph Hellwig
Signed-off-by: Lucas De Marchi
---
drivers/scsi/scsi_scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 087fcbfc9aaa3..96d7e1a9a7c7a 100644
--- a/drivers/scsi
On Sun, Feb 02, 2025 at 07:40:35PM +0900, Vincent Mailhol wrote:
Hi Lucas and Yury,
On 08/02/2024 at 16:45, Lucas De Marchi wrote:
ove the implementation of REG_GENMASK/REG_BIT to a more appropriate
place to be shared by i915, xe and possibly other parts of the kernel.
For now this re-defines
n we are close to remove the force_probe.
Lucas De Marchi
--
Gustavo Sousa
after that LGTM:
Reviewed-by: Krzysztof Karas
Krzysztof
use breakages.
Cc: Kan Liang
Cc: Peter Zijlstra (Intel)
Cc: Vinay Belgaumkar
Reviewed-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
v2: Expand commit message explanation to clarify what was discussed with
Kan, Tvrtko and Umesh in
https://patchwork.freedesktop.org/patch/
: Lucas De Marchi
Cc: Riana Tauro
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
tests/intel/xe_pmu.c | 176 +++
tests/meson.build| 1 +
2 files changed, 177 insertions(+)
create mode 100644 tests/intel/xe_pmu.c
diff --git a/tests/intel/xe_pmu.c
On Mon, Jan 27, 2025 at 02:33:00PM -0800, Vinay Belgaumkar wrote:
Functions to parse event ID and GT bit shift for PMU events.
v2: Review comments (Riana)
Cc: Riana Tauro
Cc: Lucas De Marchi
Cc: Kamil Konieczny
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
lib/igt_perf.c | 70
TRACE_SYSTEM xe
looking forward to the day this will be intel_display or i915_display,
but until then
Reviewed-by: Lucas De Marchi
is tracpoints above intentional? I'd say it's a typo, but it's repeated
4 times.
Lucas De Marchi
+#endif
#if !defined(__INTEL_DISPLAY_TRACE_
On Fri, Jan 24, 2025 at 04:46:21PM -0800, Umesh Nerlige Ramappa wrote:
Hi Lucas,
Mostly a bunch of questions since I think I am missing something.
On Tue, Jan 21, 2025 at 10:59:08AM -0600, Lucas De Marchi wrote:
On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
On 2025-01-21 9:29
On Thu, Jan 23, 2025 at 06:06:29PM +, Tvrtko Ursulin wrote:
On 23/01/2025 16:27, Lucas De Marchi wrote:
On Thu, Jan 23, 2025 at 09:43:35AM +, Tvrtko Ursulin wrote:
On 20/01/2025 22:57, Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01
On Thu, Jan 23, 2025 at 09:43:35AM +, Tvrtko Ursulin wrote:
On 20/01/2025 22:57, Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01-16 5:24 p.m., Lucas De Marchi wrote:
Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU w
On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
On 2025-01-21 9:29 a.m., Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 08:42:41PM -0500, Liang, Kan wrote:
-static int i915_pmu_cpu_offline(unsigned int cpu, struct hlist_node
*node)
-{
- struct i915_pmu *pmu = hlist_entry_safe
But it's still a behavior change. Please make it clear in the
description that the patch also changes/fixes the scope from core scope
to system-wide.
sure... do you have a suggestion how to test the hotplug? For testing
purposes, can I force the perf cpu assigned to be something other than
the
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01-16 5:24 p.m., Lucas De Marchi wrote:
Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with
a scope"), there's generic support for system-wide counters and
integration with cpu hotplug. S
On Fri, Jan 17, 2025 at 05:55:57PM +0200, Imre Deak wrote:
On Thu, Jan 16, 2025 at 02:38:34PM -0600, Lucas De Marchi wrote:
On Mon, Jan 13, 2025 at 07:40:59PM +0200, Imre Deak wrote:
> On Mon, Jan 13, 2025 at 06:38:34PM +0200, Jani Nikula wrote:
> > On Mon, 13 Jan 2025, Imre De
iang
Cc: Peter Zijlstra (Intel)
Cc: Vinay Belgaumkar
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_module.c | 2 -
drivers/gpu/drm/i915/i915_pmu.c| 114 +
drivers/gpu/drm/i915/i915_pmu.h| 11 ---
3 files changed, 1 insertion(+), 126 deletions(-
ons at all. Is it ever reasonable for the
user to disable this if USB4 is enabled?
On platforms that don't support DP tunneling, while supporting other
USB4 functionality (or for systems w/o any TypeC/DP connectors) it would
make sense to disable this option.
isn't this too fine grained? if we expose every single functionality of
the driver like this we will bury distros on configs and exponentially
explode the testing combination. And yes, this broke the build for me.
Lucas De Marchi
No such file or directory
12 | #include "intel_wakeref.h"
because we don't setup the right include directories.
We used to test in CI a display-disabled build, not sure what happened
with that.
Lucas De Marchi
+
obj-$(CONFIG_DRM_XE) += xe.o
obj-$(CONFIG_DRM_XE_KUNIT_TEST) += tests/
--
2.44.2
On Thu, Jan 16, 2025 at 03:30:51PM +0100, Francois Dugast wrote:
On Thu, Jan 16, 2025 at 08:26:36AM -0600, Lucas De Marchi wrote:
On Thu, Jan 16, 2025 at 01:45:32PM +0100, Francois Dugast wrote:
> Ensure all Xe driver files have a proper SPDX license identifier, add it
> in files where
otherwise, Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ */
+
#ifndef _I915_GEM_STOLEN_H_
#define _I915_GEM_STOLEN_H_
--
2.43.0
perf event already has a default function that returns 0, no need to
override with the same thing.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pmu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index
1 - 100 of 1653 matches
Mail list logo
