ends on INTEL_PLATFORM_DEVICES || !(X86 && ACPI)
^
Did you mean X86_PLATFORM_DEVICES here?
With that, Reviewed-by: Lucas De Marchi
I see several drivers selecting
X86_PLATFORM_DEVICES though. Maybe they should also be translated to
dependencies instead?
$
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
On Fri, May 23, 2025 at 06:32:43AM +1000, Dave Airlie wrote:
On Fri, 23 May 2025 at 01:10, Lucas De Marchi wrote:
On Thu, May 22, 2025 at 04:52:18PM +1000, Dave Airlie wrote:
>From: Dave Airlie
>
>This reduces this struct from 16 to 8 bytes, and it gets embedded
>into a l
ructs like guc_gt_system_info.
In this particular case it doesn't give unaligned address, but we should
probably then protect iosys_map from doing the wrong thing.
So, if we are keeping this patch, we should probably protect
initially-unaligned addresses and the iosys_map_incr() call?
thanks
gem_object_open. The impl of the
update_* functions could also be in the form
static void update_...()
{
#if IS_ENABLED(CONFIG_...)
#endif
}
thanks
Lucas De Marchi
+ .open = xe_gem_object_open,
+#endif
.close = xe_gem_object_close,
.mmap = drm_gem_ttm_mmap,
.
the series:
Reviewed-by: Lucas De Marchi
We will probably have quite a few conflicts in drm-xe-next as there are
some changes touching those vmaps, but we can handle those.
Lucas De Marchi
Dave.
ess. But I have no idea why exactly
this is hand rolling the read.
It seems we'd benefit from also having fixed-types (at least u32) in
iosys_map so drivers don't seem tempted to do this.
Lucas De Marchi
}
static inline void xe_map_write32(struct xe_device *xe, struct iosys_map *m
p);
this looks wrong as we then lose the __iomem. Or is this dead code and
it's never iomem? Anyway, pre-existent issue unrelated to this patch.
Lucas De Marchi
else
- bo->kptr = bo->map.vaddr;
+ bo->kptr = iosys_map_ptr(&bo->m
ere are just a few cases in which we'd
have a direct translation to existing API... so I wouldn't make this
internal when they are clearly needed externally.
Lucas De Marchi
Best regards
Thomas
/**
* IOSYS_MAP_INIT_VADDR - Initializes struct iosys_map to an address in system
memo
T |
MI_SRM_ADD_CS_OFFSET);
xe_map_write32(xe, cmd, ENGINE_ID(0).addr);
...
maybe we could add an iosys_map_wr_many() that would be a variadic
version with offset incr and hopefully the check for is_iomem in a
single place. Another option would be a local buffer that we memcpy at
the end.
+Thomas Zimmerman
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
On Tue, 22 Apr 2025 12:59:43 +0300, Dafna Hirschfeld wrote:
> the pages pointer is not used, remove it
>
>
Applied to drm-misc-next, thanks!
[1/1] drm/gpusvm: remove unused pages pointer
commit: a912b0c8b5eabd9b70dc24cc97a167eb7287a20a
Best regards,
--
Lucas De Marchi
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
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
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
On Tue, Apr 08, 2025 at 04:57:44PM +0200, Maxime Ripard wrote:
Hi Lucas,
On Tue, Apr 08, 2025 at 09:34:22AM -0500, Lucas De Marchi wrote:
On Tue, Apr 08, 2025 at 02:20:06PM +0200, Maxime Ripard wrote:
> Commit 9d7d7c3c9a19 ("panel/auo-a030jtn01: Use refcounted allocation in
&g
this thread before the patch series mentioned in IRC
to fix it. The additional patch needed is probably something like in
https://lore.kernel.org/dri-devel/nyrjnvctqnk6f3x5q7rlmy5nb7iopoti56pgh43zqknici5ms4@cibpldh7epra/
?
Lucas De Marchi
alloc"
[drivers/gpu/drm/panel/panel-auo-a030jtn01.ko] undefined!
because that entire block is:
#ifdef CONFIG_OF
Based on the header, I think the intention wasn't to add those functions
there, right? Moving it outside the ifdef at least fixes the build for
me.
Lucas De Marchi
--
ld be
configured with the new repositories.
Note that we are taking the opportunity to be explicit on the protocol,
adding the ssh:// and dropping the entry without it. It's clearer and
less entries to maintain.
Signed-off-by: Lucas De Marchi
---
nightly.conf | 25 ---
zero to fix the bug.
Fixes: e1fc39a92332 ("drm/shmem-helper: Use refcount_t for vmap_use_count")
Reported-by: Lucas De Marchi
Closes:
https://lore.kernel.org/dri-devel/20250403105053.788b0...@collabora.com/T/#m3dca6d81bedc8d6146a56b82694624fbc6fa4c96
Signed-off-by: Dmitry Osipenko
T
pu
on top)
makes the warning go away. Any idea what's going on?
Lucas De Marchi
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):
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
&
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
;& DRM_XE [=m]=m
[=m] && HAS_IOPORT [=y]
DRM_XE_DISPLAY requires FB_IOMEM_HELPERS, but the dependency FB_CORE is
missing, selecting FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION is set as
other drm drivers.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Sign
which ends up with DRM_CLIENT_LIB
selecting FB_CORE when DRM_FBDEV_EMULATION is set. Does that fixes it
for you?
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
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
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 Fri, Mar 07, 2025 at 05:14:28PM -0800, Lucas De Marchi wrote:
Due to wrong `.. kernel-doc` directive in Documentation/gpu/rfc/gpusvm.rst
the documentation was actually not parsing anything from
drivers/gpu/drm/drm_gpusvm.c. This fixes the kernel-doc include and all
warnings/errors created
thew Brost
Signed-off-by: Lucas De Marchi
---
Changes in v2:
- Unindent paragraph that shouldn't be part of "Device Memory
Operations"
- Link to v1:
https://lore.kernel.org/r/20250307-fix-svm-kerneldoc-v1-1-c786f73ae...@intel.com
---
Documentation/gpu/rfc/gpusvm.rst |
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
expected driver components for an SVM
+ * implementation as detailed below.
I think you have an extra indentation here.
With this fixed:
Reviewed-by: Matthew Brost
right... on a quick read I thought it was related to "Device Memory
Operations". I will unindent it.
thanks
Lucas De Marchi
König
Cc: Matthew Brost
Cc: Thomas Hellström
Reported-by: Stephen Rothwell
Closes:
https://lore.kernel.org/intel-xe/20250307195239.57abc...@canb.auug.org.au/
Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
Signed-off-by: Lucas De Marchi
---
Documentati
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
On Thu, Feb 27, 2025 at 08:39:21AM -0500, Tamir Duberstein wrote:
Hi Lucas, chiming in here since I also care about building on macOS.
On Mon, Feb 24, 2025 at 10:05 AM Lucas De Marchi
wrote:
Is this the approach taken for other similar issues you had? Note that
argv[0] and
rm driver. I think we probably want to add a
config that depends on INTEL_VSEC rather than selecting it like this.
At the very least we need and `if x86` and also make sure the driver
works without that part.
Lucas De Marchi
help
Experimental driver for Intel Xe series GPUs
--
2.30.2
On Wed, Feb 26, 2025 at 10:28:56AM -0600, Lucas De Marchi wrote:
On Wed, Feb 26, 2025 at 04:05:24PM +, Colin Ian King wrote:
In the case where a set of checks on xe->info.platform don't assign
a value to pointer def the pointer remains uninitialized and hence
can fail the follow
to NULL.
Fixes: 292b1a8a5054 ("drm/xe: Stop ignoring errors from xe_heci_gsc_init()")
Signed-off-by: Colin Ian King
Reviewed-by: Lucas De Marchi
thanks
Lucas De Marchi
---
drivers/gpu/drm/xe/xe_heci_gsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
On Tue, Feb 25, 2025 at 08:18:42PM -0800, Matthew Brost wrote:
On Tue, Feb 25, 2025 at 09:13:09PM -0600, Lucas De Marchi wrote:
On Wed, Feb 26, 2025 at 10:00:18AM +0800, Mingcong Bai via B4 Relay wrote:
> From: Mingcong Bai
>
> The bo/ttm interfaces with kernel memory mapping from
eed some additional fixes leading to this
function. Example:
xe_gem_create_ioctl()
{
...
if (XE_IOCTL_DBG(xe, args->size & ~PAGE_MASK))
return -EINVAL;
...
}
Lucas De Marchi
bo->flags = flags;
bo->cpu_caching = cpu_caching;
b
] drm/xe/uapi: Use hint for guc to set GT frequency
On Mon, Feb 24, 2025 at 09:43:09AM -0600, Lucas De Marchi wrote:
>On Wed, Feb 12, 2025 at 05:08:30PM +0530, Tejas Upadhyay wrote:
>>Allow user to provide a low latency hint. When set, KMD sends a hint
>>to GuC which results in speci
On Mon, Feb 24, 2025 at 09:43:09AM -0600, Lucas De Marchi wrote:
On Wed, Feb 12, 2025 at 05:08:30PM +0530, Tejas Upadhyay wrote:
Allow user to provide a low latency hint. When set, KMD sends a hint
to GuC which results in special handling for that process. SLPC will
ramp the GT frequency
.
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
c = 1,
+ .num_eng_per_bb = 1,
+ .instances = to_user_pointer(&instance),
+ };
+ ioctl(fd, DRM_IOCTL_XE_EXEC_QUEUE_CREATE, &exec_queue_create);
how does this driver-specific doc make sense in this file?
Lucas De Marchi
I was expecting you'd take the acks and merge it all through a single
tree since you received push back on the need to build the kernel in
macOS. Is this the only thing missing and you'd want it to go through
drm?
Lucas De Marchi
On Thu, Feb 20, 2025 at 01:24:20PM +0100, Greg Kroah-Hartman wrote:
On Wed, Feb 12, 2025 at 12:05:37PM -0800, Lucas De Marchi wrote:
When releasing a device, if the release action causes a group to be
released, a warning is emitted because it can't find the group. This
happens be
aoxiang Li
Reviewed-by: Lucas De Marchi
thanks
Lucas De Marchi
---
drivers/gpu/drm/xe/xe_gt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
index 5d6fb79957b6..0f42bbcb8d42 100644
--- a/drivers/gpu/drm/xe/xe_gt.c
+++ b/drivers/
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
Now that component drivers are compatible with devm, switch to using it
instead of our own.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/display/xe_display.c | 4 ++--
drivers/gpu/drm/xe/xe_gsc_proxy.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a
It returns the last open group, not the last group.
Signed-off-by: Lucas De Marchi
---
drivers/base/devres.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index b955a2f9520bf..d8a733ea5e1ac 100644
--- a/drivers/base
just to show it being used in xe,
but they require
https://lore.kernel.org/intel-xe/20250212193600.475089-1-lucas.demar...@intel.com/.
If this is acceptable I may even drop the first patch of that series and
convert it straight to devm rather than with an intermediate step.
Lucas De Marchi (6
Like when binding component, add a debug message to the unbinding case
to make it easy to track the lifecycle. This also includes the component
pointer since that is used to open a group in devres, making it easier
to track the resources.
Signed-off-by: Lucas De Marchi
---
drivers/base
res group corresponding to the hdcp component cannot be
found. Just ignore this corner case: if the dev->devres_head is empty
and the caller is trying to remove a group, it's likely in the process
of device cleanup so just ignore it instead of warning.
Signed-off-by: Lucas De Marchi
---
Th
Remove the setting to NULL so it's possible to obtain the xe pointer
from callbacks like the component unbind from device_unbind_cleanup(),
i.e. after xe_pci_remove() already finished.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_device_sysfs.c | 6 --
drivers/gpu/drm/xe/xe_pci
Now that devres supports component driver cleanup during driver removal
cleanup, the xe custom support for removal callbacks is not needed
anymore. Drop it.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_device.c | 79
drivers/gpu/drm/xe/xe_device.h
.` assign err, too.
On the the error handling we do:
if (err)
fence = ERR_PTR(err);
So I'm not seeing the bug mentioned.
Lucas De Marchi
Initialize fence to NULL at declaration.
Fixes: dcdd6b84d9ac ("drm/xe/pxp: Allocate PXP execution resources")
Sign
a xe_gt_info() to the kernel log and just
letting the 2 calls above add garbage to the devcoredump - whoever is
processing the devcoredump later may have no clue about that log
message.. but I'm also not seeing why we need XE_FORCEWAKE_ALL in those
calls. Aren&#x
*/
please add an usage example here is it's where people trying to use the
interface will look at rather than the kernel-doc. But this seems not
used
+#define xe_force_wake_scope_has_domain(domain) \
+ (xe_force_wake_ref_has_domain(scope.fw_ref, domain))
extra paranthesis here?
Lucas De Marchi
+
#endif
--
2.47.1
0; i < XE_ENGINE_CLASS_MAX; ++i)
+ xe_hw_fence_irq_finish(>->fence_irq[i]);
+ return err;
this however is moving to the opposite direction from
https://lore.kernel.org/intel-xe/20250131223140.4144292-6-lucas.demar...@intel.com/
Lucas De Marchi
}
/**
--
2.47.1
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
27;t explicitly need
> drm_device.h would bump into build errors and be forced to include the
> latter.
>
> [...]
Applied to drm-misc-fixes, thanks!
[1/1] drm/print: Include drm_device.h
commit: e0f63bc68f59d281e2d06e596f6c1bd9382a15cd
Best regards,
--
Lucas De Marchi
On Fri, Jan 17, 2025 at 12:42:48PM -0500, Rodrigo Vivi wrote:
On Fri, Jan 17, 2025 at 08:45:29AM -0800, Lucas De Marchi wrote:
When the xe driver was added, it didn't extend the exclude entries for
drm-misc, as done in commit 5a44d50f0072 ("MAINTAINERS: Update drm-misc
entry to
When the xe driver was added, it didn't extend the exclude entries for
drm-misc, as done in commit 5a44d50f0072 ("MAINTAINERS: Update drm-misc
entry to match all drivers"). Exclude it like is done for i915 and other
drivers with dedicated maintainers.
Signed-off-by:
ow if it'd
be interesting for them when using xe.
Lucas De Marchi
On Thu, Dec 19, 2024 at 04:00:08PM +0200, Kai Vehmanen wrote:
Hi,
On Fri, 13 Dec 2024, Lucas De Marchi wrote:
Thanks Kai to pointing me to this thread, trying to revive it.
Also adding dri-devel as it may be relevant there and Maarten who worked
on the xe integration recently
ack, given
NTEL_VSEC ?
Yes, that should work if it gets phrased correctly.
Something like
config DRM_XE_DGFX_PMT_SUPPORT
bool "X86 PMT support"
depends on DRM_XE && INTEL_VSEC
depends on DRM_XE=m || INTEL_VSEC=y
depends on X86 || COMPILE_TEST
that looks good to me.
thanks
Lucas De Marchi
onent, would it be hard to escalate that event to handle it
the same as a hotplug? Because from this thread it seems usb/pci hotplug
is already available.
thanks
Lucas De Marchi
One thing I can think of is to perform like the vga_switcheroo
handling in hda_intel.c; it's essentially a forced r
only user. Now we already have 3, so I think it makes sense to go
through drm-misc... I looked at the possible conflicts in i915 and xe
and they are minimal.
thanks
Lucas De Marchi
[1]
https://lore.kernel.org/dri-devel/20241128153707.1294347-1-raag.ja...@intel.com/
André Almeida (1):
drm/a
Hi Dave and Simona,
A few more drm-xe fixes for this week.
thanks
Lucas De Marchi
drm-xe-fixes-2024-11-14:
Driver Changes:
- Fix unlock on exec ioctl error path (Matthew Brost)
- Fix hibernation on LNL due to ggtt getting lost
(Matthew Brost / Matthew Auld)
- Fix missing runtime PM in OA
On Thu, Nov 14, 2024 at 04:30:19PM +0100, Christian König wrote:
XE switched over to drm_exec quite some time ago.
Signed-off-by: Christian König
Acked-by: Lucas De Marchi
I guess you will want to apply this through drm-misc so you can merge
the last commit. Otherwise let me know and I
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc7. Still busier than I'd like for an rc7, but
needed particularly for LNL.
thanks,
Lucas De Marchi
drm-xe-fixes-2024-11-08:
Driver Changes:
- Fix ccs_mode setting for Xe2 and later (Balasubramani)
- Synchronize ccs_mode setting with client cre
On Mon, Nov 04, 2024 at 12:04:30PM -0600, Lucas De Marchi wrote:
On Sat, Nov 02, 2024 at 11:22:03AM +0900, Gyeyoung Baek wrote:
if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement
to "https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html";.
v2: I modified this to print when only cond is true.
v3: Modify to evaluate cond only once.
v4: There was a mistake in v3, send this again.
Signed-off-by: Gyeyoung Baek
Reviewed-by: Lucas De Marchi
I will apply this to dr
turn;
|
| __drm_dev_vprintk(dev, KERN_DEBUG, p->origin, p->prefix, vaf);
as otherwise it complains category is unused.
Lucas De Marchi
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc6. Two important fixes for LNL and one missing
hpd enabling. This last one brought in a refactor as dependency,
otherwise it would cause some headache with conflicts.
thanks
Lucas De Marchi
drm-xe-fixes-2024-10-31:
Driver Changes:
- Fix missing HPD
On Wed, Oct 23, 2024 at 12:07:58AM -0500, Lucas De Marchi wrote:
On Tue, Oct 22, 2024 at 11:52:10PM +0200, Peter Zijlstra wrote:
On Fri, Oct 18, 2024 at 02:46:31PM -0500, Lucas De Marchi wrote:
I will give this a try with i915 and/or xe.
Less horrible version here:
git://git.kernel.org/pub
-next")
Dave, this is only in drm-next. It doesn't show up in drm-xe-next
or in drm-tip neither since it's undone by the next merge of
drm-next into drm-tip. Can you take it directly in drm-next?
Acked-by: Lucas De Marchi
thanks
Lucas De Marchi
Signed-off-by: Geert Uytterho
d was
false.
It looks like keeping cond outside and the statement expr to cover only
the call to drm_dbg would work.
Lucas De Marchi
#endif
--
2.34.1
xe_gt_err(gt, "Timed out wait for G2H, fence %u, action %04x,
done %s",
|g2h_fence.seqno, action[0],
str_yes_no(g2h_fence.done));
| xa_erase(&ct->fence_lookup, g2h_fence.seqno);
| ->>>>>>> c9ff14d0339a (
On Tue, Oct 22, 2024 at 11:52:10PM +0200, Peter Zijlstra wrote:
On Fri, Oct 18, 2024 at 02:46:31PM -0500, Lucas De Marchi wrote:
I will give this a try with i915 and/or xe.
Less horrible version here:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git
perf/pmu-unregister
I&#x
;
+ if (!event)
+ break;
+
+ pmu_detach_event(pmu, event);
+ put_event(event);
+ }
+
+ /*
+* wait for pending _free_event()s
+*/
+ wait_var_event(pmu, pmu_empty(pmu));
ok... so now we are synchro
On Wed, Oct 16, 2024 at 10:51:02AM +0200, Peter Zijlstra wrote:
On Tue, Oct 08, 2024 at 01:34:57PM -0500, Lucas De Marchi wrote:
+static int parse_device(const char __user *ubuf, size_t size, u32 *instance)
+{
+ char buf[16];
+ ssize_t len;
+
+ if (size > sizeof(buf)
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc4. Mostly some error path fixes and locking
adjustements. Timestamp bit width fixes delta time calculations in
userspace and one display fix for tile4 modifier in LNL/BMG.
thanks
Lucas De Marchi
drm-xe-fixes-2024-10-17:
Driver Changes:
- New
On Mon, Oct 14, 2024 at 05:26:19PM -0700, Jeff Johnson wrote:
On 10/8/24 11:34, Lucas De Marchi wrote:
...
+module_init(dummy_init);
+module_exit(dummy_exit);
+
+MODULE_AUTHOR("Lucas De Marchi ");
+MODULE_LICENSE("GPL");
Since commit 1fffe7a34c89 ("script: modpost
On Mon, Oct 14, 2024 at 09:25:19PM +0200, Peter Zijlstra wrote:
On Mon, Oct 14, 2024 at 01:20:34PM -0500, Lucas De Marchi wrote:
On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote:
> I'm confused.. probably because I still don't have any clue about
> drivers and
On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote:
On Tue, Oct 08, 2024 at 01:34:59PM -0500, Lucas De Marchi wrote:
If a pmu is unregistered while there's an active event, perf will still
access the pmu via event->pmu, even after the event is destroyed. This
makes it diffi
On Fri, Oct 11, 2024 at 03:21:18PM -0700, Umesh Nerlige Ramappa wrote:
On Tue, Oct 08, 2024 at 01:34:56PM -0500, Lucas De Marchi wrote:
v2 of my attempt at fixing how i915 interacts with perf events.
v1 -
https://lore.kernel.org/all/20240722210648.80892-1-lucas.demar...@intel.com/
From other
On Tue, Oct 08, 2024 at 01:34:56PM -0500, Lucas De Marchi wrote:
v2 of my attempt at fixing how i915 interacts with perf events.
v1 -
https://lore.kernel.org/all/20240722210648.80892-1-lucas.demar...@intel.com/
From other people:
1)
https://lore.kernel.org/lkml/20240115170120.662220-1
Hi Dave and Simona,
A few drm-xe fixes for 6.12-rc3.
thanks
Lucas De Marchi
drm-xe-fixes-2024-10-10:
Driver Changes:
- Fix error checking with xa_store() (Matthe Auld)
- Fix missing freq restore on GSC load error (Vinay)
- Fix wedged_mode file permission (Matt Roper)
- Fix use-after-free in ct
1 - 100 of 1047 matches
Mail list logo
