, though.
BR,
Jani.
> if (!buf) {
> ret = -ENOMEM;
> goto out_exit;
--
Jani Nikula, Intel
On Mon, 22 Sep 2025, Jani Nikula wrote:
> On Fri, 12 Sep 2025, Samasth Norway Ananda
> wrote:
>> Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
>> size calculations could overflow when handling user-controlled font
>> parameters.
>>
>
What was supposed to address an unlikely integer overflow seems to have
caused a real buffer overflow [1].
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15020
> + return -EINVAL;
>
> - new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
> + new_data = kmalloc(size, GFP_USER);
>
> if (!new_data)
> return -ENOMEM;
--
Jani Nikula, Intel
t; #define HAS_AS_SDP(__display)(DISPLAY_VER(__display) >= 13)
> #define HAS_BIGJOINER(__display) (DISPLAY_VER(__display) >= 11 &&
> HAS_DSC(__display))
> +#define HAS_CASF(__display) (DISPLAY_VER(__display) >= 20)
> #define HAS_CDCLK_CRAWL(__
gt;
> Got ack from kwin maintainer on the UAPI patch.
The Mutter part seems stuck, though.
Cc: Uma
BR,
Jani.
--
Jani Nikula, Intel
_alloc(edid, size);
> if (!drm_edid)
> - kfree(edid);
> + kvfree(edid);
>
> return drm_edid;
> }
> @@ -2568,7 +2568,7 @@ void drm_edid_free(const struct drm_edid *drm_edid)
> if (!drm_edid)
> return;
>
> - kfree(drm_edid->edid);
> + kvfree(drm_edid->edid);
> kfree(drm_edid);
> }
> EXPORT_SYMBOL(drm_edid_free);
--
Jani Nikula, Intel
On Tue, 09 Sep 2025, Jani Nikula wrote:
> On Thu, 07 Aug 2025, Nemesa Garg wrote:
>> Middleware MR link:
>> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3665
>> IGT patchwork link: https://patchwork.freedesktop.org/series/130218/
>>
>> Contin
harpening of some areas and potential loss of natural
> details.
I was planning on merging this, but AFAICT this is the newest
submission. Basically the CI results are 1½ months old, and I'd prefer
newer.
Also need to figure out which route to merge, drm-misc or drm-intel.
BR,
Jan
0x100 does not follow 0x090.
> As an experiment to understand the failure, I commented out the checksum
> validation code. Results with validation bypassed:
Running that, please grab the EDID from sysfs. edid-decode does a good
job of decoding, but also includes the hex in case we want to run it on
a newer or modified edid-decode.
BR,
Jani.
--
Jani Nikula, Intel
e know.
You need to post the revised patches. 'git rebase -i' is your friend
here.
BR,
Jani.
--
Jani Nikula, Intel
gt; +return BIT(size) & sizes;
>
> I would return here "!!(BIT(size) & sizes)", but it doesn't
> really matter.
If the patch had that, I'd ask to drop the superfluous negations and
parens...
BR,
Jani.
>
> Reviewed-by: Andi Shyti
>
> Andi
--
Jani Nikula, Intel
lude/drm/drm_gpu_frequency_trace.h
> @@ -42,6 +42,6 @@ static inline void trace_gpu_frequency(unsigned int state,
> unsigned int gpu_id)
>
> #ifdef CONFIG_DRM_GPU_FREQUENCY_TRACE
> #undef TRACE_INCLUDE_PATH
> -#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm
> +#define TRACE_INCLUDE_PATH ../../include/drm
> #include
> #endif
--
Jani Nikula, Intel
On Mon, 15 Sep 2025, Rodrigo Vivi wrote:
> On Mon, Sep 15, 2025 at 07:24:10PM +0200, Andi Shyti wrote:
>> 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 provide
Reviewed-by: Jani Nikula
and
Acked-by: Jani Nikula
for merging via whichever tree is convenient.
> ---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lm
th EDIDs, that
ship has sailed, and here we are.
Considering that a valid checksum isn't exactly a guarantee of valid
EDID data inside, I'm starting to lean towards just debug logging EDID
and DisplayID checksum errors, and using whatever data we can find
inside.
BR,
Jani.
--
Jani Nikula, Intel
On Mon, 15 Sep 2025, Jani Nikula wrote:
> That's not the complete EDID data, though. It's missing 6*16 bytes. If
> you go by the hex offsets, 0x100 does not follow 0x090.
Alternatively, there's extra garbage at the end. I'm not really sure
what happens because we ha
bb->ppgtt = (s->buf_addr_type == GTT_BUFFER) ? false : true;
> + bb->ppgtt = s->buf_addr_type != GTT_BUFFER;
>
> /*
>* The start_offset stores the batch buffer's start gma's
--
Jani Nikula, Intel
ency_trace.h"
This is a no go. You can't include drm headers with relative paths like
this. Basically none of the drm headers inside drivers/gpu/drm/ are for
drivers, they're internal. Indeed, they usually have _internal.h suffix
to emphasize that.
Headers for drivers need to be placed under include/drm/
BR,
Jani.
--
Jani Nikula, Intel
#x27;s a driver-level issue.
Please file a bug over at [1].
Thanks,
Jani.
[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
--
Jani Nikula, Intel
On Thu, 04 Sep 2025, Kees Cook wrote:
> On Thu, Sep 04, 2025 at 10:34:04AM +0300, Jani Nikula wrote:
>> On Wed, 03 Sep 2025, Kees Cook wrote:
>> > On Fri, Aug 29, 2025 at 08:46:01PM +0300, Jani Nikula wrote:
>> >> Move the range_overflows() and range_end
might get collisions later, but the reader of the code is mislead to
believe this is something in i2c.h.
BR,
Jani.
--
Jani Nikula, Intel
t9611c->edid_buf + block * 128, len);
The get edid block hook is supposed to read *one* block. Can't you
implement reading one block? This now reads the entire edid for every
block.
Again, better yet, i2c adapter implementation.
> +
> + return 0;
> +}
> +
> +static const struct drm_edid *lt9611c_bridge_edid_read(struct drm_bridge
> *bridge,
> +struct drm_connector
> *connector)
> +{
> + struct lt9611c *lt9611c = bridge_to_lt9611c(bridge);
> +
> + usleep_range(1, 2);
> + return drm_edid_read_custom(connector, lt9611c_get_edid_block, lt9611c);
> +}
--
Jani Nikula, Intel
On Wed, 03 Sep 2025, Kees Cook wrote:
> On Fri, Aug 29, 2025 at 08:46:01PM +0300, Jani Nikula wrote:
>> Move the range_overflows() and range_end_overflows() along with the _t
>> variants over from drm/i915 and drm/buddy to overflow.h.
>>
>> Cc: Kees Cook
>> Cc:
for a Reviewed- or Acked-by from
> people listed by `scripts/get_maintainer.pl --no-git-fallback -m --nol
> --norolestats`. but that command returns an empty string, so it will
> never allow me to push.
>
> How can I get that commit pushed to drm-misc-next?
>
> I think `dim push-branch -f` would work: am I supposed to use it?
Try 'dim -f push-branch'. The parameters after push-branch go to git,
and you don't want that.
BR,
Jani.
>
> (not sure my committer rights allow that)
>
> Luca
--
Jani Nikula, Intel
exandre Courbot
> Cc: Daniel Almeida
> Signed-off-by: Danilo Krummrich
FWIW,
Acked-by: Jani Nikula
> ---
> MAINTAINERS | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe168477caa4..1cd6597c7f1d 10
On Wed, 03 Sep 2025, "Murthy, Arun R" wrote:
> On 02-09-2025 15:46, Jani Nikula wrote:
>> On Tue, 02 Sep 2025, Arun R Murthy wrote:
>>> Add user readable error codes for failure cases in drm_atomic_ioctl() so
>>> that user can decode the error
ount of drm_objects if multiple drm_objects caused error
> + */
> +struct drm_mode_atomic_err_code {
> + __u64 failure_code;
> + __u64 failure_objs_ptr;
> + __u64 reserved;
> + __u32 count_objs;
> + char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN];
> +};
> +
> struct drm_mode_atomic {
> __u32 flags;
> __u32 count_objs;
--
Jani Nikula, Intel
uot;
> +
This file is also supposed to be an abstraction layer, and should not be
looking at intel framebuffer details.
*sad trombone*
Jocelyn, not your fault, it's our fault, and it's also a bunch more todo
items and refactoring for us. :(
BR;
Jani.
> #include "xe_bo.h"
> #include "intel_bo.h"
>
> @@ -59,3 +61,25 @@ void intel_bo_describe(struct seq_file *m, struct
> drm_gem_object *obj)
> {
> /* FIXME */
> }
> +
> +struct xe_panic_data {
> + struct page **pages;
> + int page;
> + void *vaddr;
> +};
> +
> +struct xe_framebuffer {
> + struct intel_framebuffer base;
> + struct xe_panic_data panic;
> +};
> +
> +struct intel_framebuffer *intel_bo_alloc_framebuffer(void)
> +{
> + struct xe_framebuffer *xe_fb;
> +
> + xe_fb = kzalloc(sizeof(*xe_fb), GFP_KERNEL);
> + if (xe_fb)
> + return &xe_fb->base;
> + return NULL;
> +}
> +
--
Jani Nikula, Intel
hics tests that stress memory.
>
> v3(Matthew):
> - Remove RB_EMPTY_NODE check in force_merge function.
> - Rename rb for loop macros to have less generic names and move to
> .c file.
> - Make the rb node rb and link field as union.
>
> v4(Jani Nikula):
> - Th
; +++ b/include/drm/drm_atomic.h
> @@ -1255,4 +1255,23 @@ struct drm_bridge_state *
> drm_atomic_get_new_bridge_state(const struct drm_atomic_state *state,
> struct drm_bridge *bridge);
>
> +/**
> + * drm_mode_atomic_add_error_msg - function to add error code and error
> string
> + *
> + * @err_code: pointer to struct drm_mode_atomic_err_code that stores the
> failure
> + * reason
> + * @failure_code: failure code in enum drm_mode_atomic_failure_codes
> + * @failure_string: failure reason string message
> + *
> + * Returns: void
> + */
> +static inline void drm_mode_atomic_add_error_msg(struct
> drm_mode_atomic_err_code *err_code,
> + __u64 failure_code,
> + char *failure_string)
So this should be "const char *format, ..." with printf format, with
printf format annotation, to help callers pass in other stuff than just
fixed strings.
This should be a proper function instead of static inline.
> +{
> + err_code->failure_code = failure_code;
> + strscpy_pad(err_code->failure_string, failure_string,
> + strlen(err_code->failure_string));
If the size is fixed, why do we just silently truncate the string? If
the message is for the user, it'll be ugly to emit truncated strings.
> +}
> +
> #endif /* DRM_ATOMIC_H_ */
--
Jani Nikula, Intel
Move the range_overflows() and range_end_overflows() along with the _t
variants over from drm/i915 and drm/buddy to overflow.h.
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_utils.h | 70
Document the macros in preparation for making them more generally
available.
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_utils.h | 46 +++
1 file changed, 46 insertions(+)
diff
Rename range_overflows_end() to range_end_overflows(), along with the _t
variant.
It's all rather subjective, but I think range_end_overflows() reads
better.
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/di
ically
pick the link text from the target heading) instead of manually adding
link texts and file references.
i.e.
.. _some_target:
Heading After Some Target
=
See :ref:`some_target`.
Will generate "See Heading After Some Target".
BR,
Jani.
--
Jani Nikula, Intel
_internal(mm, blocks);
> - return err;
> }
> - /* Free blocks for the next iteration */
> - drm_buddy_free_list_internal(mm, blocks);
> }
>
> return -ENOSPC;
> @@ -1266,6 +1308,7 @@ EXPORT_SYMBOL(drm_buddy_block_print);
> */
> void drm_buddy_print(struct drm_buddy *mm, struct drm_printer *p)
> {
> + enum free_tree tree;
> int order;
>
> drm_printf(p, "chunk_size: %lluKiB, total: %lluMiB, free: %lluMiB,
> clear_free: %lluMiB\n",
> @@ -1273,11 +1316,16 @@ void drm_buddy_print(struct drm_buddy *mm, struct
> drm_printer *p)
>
> for (order = mm->max_order; order >= 0; order--) {
> struct drm_buddy_block *block;
> + struct rb_root *root;
> u64 count = 0, free;
>
> - for_each_rb_free_block(block, &mm->free_tree[order], rb) {
> - BUG_ON(!drm_buddy_block_is_free(block));
> - count++;
> + for_each_free_tree(tree) {
> + root = &mm->free_trees[tree][order];
> +
> + for_each_rb_free_block(block, root, rb) {
> + BUG_ON(!drm_buddy_block_is_free(block));
> + count++;
> + }
> }
>
> drm_printf(p, "order-%2d ", order);
> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
> index 091823592034..2fc1cc7b78bf 100644
> --- a/include/drm/drm_buddy.h
> +++ b/include/drm/drm_buddy.h
> @@ -14,6 +14,12 @@
>
> #include
>
> +enum free_tree {
> + CLEAR_TREE = 0,
> + DIRTY_TREE,
> + MAX_FREE_TREES,
Those are quite generic enum and enumerator names for a very specific
header and usage.
And really this whole enum should be an implementation detail.
> +};
> +
> #define range_overflows(start, size, max) ({ \
> typeof(start) start__ = (start); \
> typeof(size) size__ = (size); \
> @@ -73,7 +79,7 @@ struct drm_buddy_block {
> */
> struct drm_buddy {
> /* Maintain a free list for each order. */
> - struct rb_root *free_tree;
> + struct rb_root *free_trees[MAX_FREE_TREES];
>
> /*
>* Maintain explicit binary tree(s) to track the allocation of the
--
Jani Nikula, Intel
@ -1120,7 +1191,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> }
> } while (1);
>
> - mark_allocated(block);
> + mark_allocated(mm, block);
> mm->avail -= drm_buddy_block_size(mm, block);
> if (drm_buddy_block_is_clear(block))
> mm->clear_avail -= drm_buddy_block_size(mm, block);
> @@ -1204,7 +1275,7 @@ void drm_buddy_print(struct drm_buddy *mm, struct
> drm_printer *p)
> struct drm_buddy_block *block;
> u64 count = 0, free;
>
> - list_for_each_entry(block, &mm->free_list[order], link) {
> + for_each_rb_free_block(block, &mm->free_tree[order], rb) {
> BUG_ON(!drm_buddy_block_is_free(block));
> count++;
> }
> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
> index 513837632b7d..091823592034 100644
> --- a/include/drm/drm_buddy.h
> +++ b/include/drm/drm_buddy.h
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -53,7 +54,11 @@ struct drm_buddy_block {
>* a list, if so desired. As soon as the block is freed with
>* drm_buddy_free* ownership is given back to the mm.
>*/
> - struct list_head link;
> + union {
> + struct rb_node rb;
> + struct list_head link;
> + };
> +
> struct list_head tmp_link;
> };
>
> @@ -68,7 +73,7 @@ struct drm_buddy_block {
> */
> struct drm_buddy {
> /* Maintain a free list for each order. */
> - struct list_head *free_list;
> + struct rb_root *free_tree;
>
> /*
>* Maintain explicit binary tree(s) to track the allocation of the
>
> base-commit: f4c75f975cf50fa2e1fd96c5aafe5aa62e55fbe4
--
Jani Nikula, Intel
ust a single place where
> we have both enum and string. Upon user adding new error codes if both
> enum and string are at a single place it would be easy for the user.
> Hence adding both in a single place using X macros.
>
> Its not mandatory to have a string for every enum, the string can be
> left empty if not required, or later in the driver user can overwrite
> the string as well.
See my reply [1] about fixed vs. non-fixed error messages.
I believe Xaver is also saying we don't want the fixed error messages,
and especially not in a uapi header.
BR,
Jani.
[1] https://lore.kernel.org/r/419591dda7158b3d56c40aac0df86ca499202...@intel.com
--
Jani Nikula, Intel
On Sat, 23 Aug 2025, "Murthy, Arun R" wrote:
> On 22-08-2025 16:07, Jani Nikula wrote:
>> On Fri, 22 Aug 2025, Arun R Murthy wrote:
>>> There can be multiple reasons for a failure in atomic_ioctl. Most often
>>> in these error conditions -EINVAL is return
> +++ b/include/drm/drm_modeset_lock.h
> @@ -75,7 +75,7 @@ struct drm_modeset_acquire_ctx {
> };
>
> /**
> - * struct drm_modeset_lock - used for locking modeset resources.
> + * @struct drm_modeset_lock - used for locking modeset resources.
> * @mutex: resource locking
> *
On Fri, 22 Aug 2025, Matthew Wilcox wrote:
> On Fri, Aug 22, 2025 at 10:36:24AM -0400, Sidhartha Kumar wrote:
>> On 8/22/25 8:33 AM, Jani Nikula wrote:
>> > It would be great if the commit messages mentioned whether the
>> > identifiers are expected to remain the same i
| 15 +++---
> drivers/gpu/drm/drm_mode_config.c| 3 +-
> drivers/gpu/drm/drm_syncobj.c| 64
> include/drm/drm_auth.h | 9 ++--
> include/drm/drm_device.h | 4 +-
> include/drm/drm_file.h | 6 +--
> include/drm/drm_mode_config.h| 12 ++---
> 12 files changed, 86 insertions(+), 143 deletions(-)
--
Jani Nikula, Intel
DESET;
>> return -EINVAL;
>> }
>>
>> @@ -6061,6 +6063,8 @@ static int intel_async_flip_check_hw(struct
>> intel_atomic_state *state, struct in
>> plane->base.base.id, plane->base.name,
>> &new_plane_state->hw.fb->format->format,
>> new_plane_state->hw.fb->modifier);
>> +state->base.error_code->failure_flags =
>> +DRM_MODE_ATOMIC_ASYNC_MODIFIER_NOT_SUPPORTED;
>> return -EINVAL;
>> }
>>
>>
>
--
Jani Nikula, Intel
tomic_ioctl(struct drm_device *dev,
> }
>
> out:
> + /* update the error code if any error to allow user handling it */
> + if (ret < 0 && arg->reserved) {
> + error_code_ptr = (struct drm_mode_atomic_err_code __user *)
> + (unsigned long)arg->reserved;
> +
> + strscpy_pad(error_code.failure_string,
> +
> drm_mode_atomic_failure_string[error_code.failure_flags],
> + sizeof(error_code.failure_string));
> +
> + if (copy_to_user(error_code_ptr, &error_code,
> sizeof(error_code)))
> + return -EFAULT;
> + }
> +
> + if (!state)
> + return ret;
> +
> complete_signaling(dev, state, fence_state, num_fences, !ret);
>
> if (ret == -EDEADLK) {
--
Jani Nikula, Intel
ter to the drm_object that caused error
> + * @reserved: reserved for future use
> + * @count_objs: count of drm_objects if multiple drm_objects caused error
> + */
> +struct drm_mode_atomic_err_code {
> + __u64 failure_flags;
> + __u64 failure_objs_ptr;
> + __u64 reserved;
> + __u32 count_objs;
> + char failure_string[DRM_MODE_ATOMIC_FAILURE_STRING_LEN];
> +};
> +
> struct drm_mode_atomic {
> __u32 flags;
> __u32 count_objs;
--
Jani Nikula, Intel
out-of-tree module.
IMO convenience for out-of-tree modules is not really a consideration,
because adding new user selectable kconfig options is an inconvenience
for in-tree users.
BR,
Jani.
--
Jani Nikula, Intel
ype:`exec`, op->addr,
>> op->range);\nbreak;\ncase DRIVER_OP_MAP:\n
>>ret = drm_gpuvm_sm_map_exec_lock(gpuvm, :c:type:`exec`,
>> num_fences,\n
>> op->addr, op->range,\n
>> obj, op->obj_offset);\nbreak
k;
> + * * }
> + * *
> + * * drm_exec_retry_on_contention(&exec);
> + * * if (ret)
> + * * return ret;
> + * * }
> + * * }
> + * * }
> *
> * This enables all locking to be performed before the driver begins
> modifying
> * the VM. This is safe to do in the case of overlapping DRIVER_VM_BIND_OPs,
> --
> 2.39.5
> signed-off-by:Sidharth Seela
--
Jani Nikula, Intel
/display/intel_display_debugfs.c | 5 ++---
> drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
> 2 files changed, 4 insertions(+), 6 deletions(-)
--
Jani Nikula, Intel
On Thu, 07 Aug 2025, Qianfeng Rong wrote:
> GFP_NOWAIT already includes __GFP_NOWARN, so let's remove the redundant
> __GFP_NOWARN.
>
> Signed-off-by: Qianfeng Rong
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 4 ++--
> 1 file changed, 2
On Thu, 07 Aug 2025, Qianfeng Rong wrote:
> GFP_NOWAIT already includes __GFP_NOWARN, so let's remove the redundant
> __GFP_NOWARN.
>
> Signed-off-by: Qianfeng Rong
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
/i915/i915_active.c
> @@ -727,7 +727,7 @@ int i915_request_await_active(struct i915_request *rq,
> static int sw_await_fence(void *arg, struct dma_fence *fence)
> {
> return i915_sw_fence_await_dma_fence(arg, fence, 0,
> - GFP_NOWAIT | __GFP_NOWARN);
> + GFP_NOWAIT);
> }
>
> int i915_sw_fence_await_active(struct i915_sw_fence *fence,
--
Jani Nikula, Intel
struct intel_guc *guc = log_to_guc(log);
> + struct drm_i915_private *i915 = guc_to_i915(guc);
> +
> + drmm_mutex_init(&i915->drm, &log->relay.lock);
> INIT_WORK(&log->relay.flush_work, copy_debug_logs_work);
> log->relay.started = false;
> }
--
Jani Nikula, Intel
ject_free;
> + if (err) {
> + i915_gem_object_free(obj);
> + return ERR_PTR(err);
> + }
>
> trace_i915_gem_object_create(obj);
> return obj;
> -
> -err_object_free:
> - i915_gem_object_free(obj);
> - return ERR_PTR(err);
> }
>
> struct drm_i915_gem_object *
--
Jani Nikula, Intel
5/display: Set C10_VDR_CTRL_MSGBUS_ACCESS before phy reg read
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--
Jani Nikula, Intel
eac3b092
> git bisect bad
> The merge base ba5afb9a84df2e6b26a1b6389b98849cd16ea757 is bad.
> This means the bug has been fixed between
> ba5afb9a84df2e6b26a1b6389b98849cd16ea757 and
> [1b1934dbbdcf9aa2d507932ff488cec47999cf3f
> 61da593f4458f25c59f65cfd9ba1bda570db5db7
> 6fc5460ed8dd0edf29e7c5c
[1].
BR,
Jani.
[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
--
Jani Nikula, Intel
acation email
catch-up.
BR,
Jani.
--
Jani Nikula, Intel
* @link_bpc_property: Current connector link bpc set by the driver
> + *
> + * This property can be used to retrieve the current link bpc from
> + * connector_state::hdmi:output_bpc
It doesn't have to be just HDMI, does it?
> + */
> + struct drm_property *link_bpc_property;
> +
> /** @privacy_screen: drm_privacy_screen for this connector, or NULL. */
> struct drm_privacy_screen *privacy_screen;
--
Jani Nikula, Intel
nheritance, and IMO the pragmatic approach is to let *drivers* do what
they want, instead of having a midlayer helper design force something on
them.
BR,
Jani.
--
Jani Nikula, Intel
uct drm_panel_follower
> *follower)
>
> mutex_lock(&panel->follower_lock);
>
> - if (panel->prepared) {
> + if ((panel->prepared && !follower->after_panel_enabled) ||
> + (panel->enabled && follower->after_panel_enabled)) {
> ret = follower->funcs->panel_unpreparing(follower);
> if (ret < 0)
> dev_info(panel->dev, "%ps failed: %d\n",
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 843fb756a2950..aa9b6218702fd 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -183,6 +183,14 @@ struct drm_panel_follower {
>* The panel we're dependent on; set by drm_panel_add_follower().
>*/
> struct drm_panel *panel;
> +
> + /**
> + * @after_panel_enabled
> + *
> + * If true then this panel follower should be powered after the panel
> + * and the backlight are enabled, instead of after panel is prepared.
> + */
> + bool after_panel_enabled;
> };
>
> /**
--
Jani Nikula, Intel
On Wed, 30 Jul 2025, Jani Nikula wrote:
> On Thu, 24 Jul 2025, Nemesa Garg wrote:
>> Add HAS_CASF macro to check whether platform supports
>> the content adaptive sharpness capability or not.
>>
>> v2: Update commit message[Ankit]
>>
>> Signed-off-by: Neme
F(__display) (DISPLAY_VER(__display) >= 20)
> #define HAS_CDCLK_CRAWL(__display)
> (DISPLAY_INFO(__display)->has_cdclk_crawl)
> #define HAS_CDCLK_SQUASH(__display)
> (DISPLAY_INFO(__display)->has_cdclk_squash)
> #define HAS_CMRR(__display) (DISPLAY_VER(__display) >= 20)
--
Jani Nikula, Intel
On Tue, 29 Jul 2025, Andy Mindful wrote:
> Please let me know if any further information or testing is required.
Likely the quickest way to find the root cause is to bisect the issue.
BR,
Jani.
--
Jani Nikula, Intel
them gracefully. A test could verify this. Not
> a blocker for this series, of course.
Going through old mails... I'll note that EDIDs in general contain so
much garbage that we simply can't reject them if there are issues. They
do need to be handled gracefully, of course.
BR,
Jani.
--
Jani Nikula, Intel
(display->funcs.color->load_plane_csc_matrix)
> + display->funcs.color->load_plane_csc_matrix(dsb, plane_state);
> }
>
> void intel_color_plane_program_pipeline(struct intel_dsb *dsb,
--
Jani Nikula, Intel
ne_colorop *intel_colorop_alloc(void);
> struct intel_plane_colorop *intel_plane_colorop_create(enum
> intel_color_block id);
> int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
> drm_prop_enum_list *list);
> +int intel_plane_color_init(struct drm_plane *plane);
Maybe this all deserves a separate file, intel_plane_color.[ch] or something?
>
> #endif /* __INTEL_COLOR_H__ */
--
Jani Nikula, Intel
intel_color_block;
>
> void intel_color_init_hooks(struct intel_display *display);
> @@ -43,5 +45,6 @@ bool intel_color_lut_equal(const struct intel_crtc_state
> *crtc_state,
> void intel_color_assert_luts(const struct intel_crtc_state *crtc_state);
> struct intel_plane_colorop *intel_colorop_alloc(void);
> struct intel_plane_colorop *intel_plane_colorop_create(enum
> intel_color_block id);
> +int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
> drm_prop_enum_list *list);
>
> #endif /* __INTEL_COLOR_H__ */
--
Jani Nikula, Intel
(const struct intel_crtc_state
> *crtc_state,
> const struct drm_property_blob *blob2,
> bool is_pre_csc_lut);
> void intel_color_assert_luts(const struct intel_crtc_state *crtc_state);
> +struct intel_plane_colorop *intel_colorop_alloc(void);
> +struct intel_plane_colorop *intel_plane_colorop_create(enum
> intel_color_block id);
The naming seems inconsistent.
>
> #endif /* __INTEL_COLOR_H__ */
--
Jani Nikula, Intel
struct drm_property_blob *data;
> + } hw;
> +};
> +
> static inline struct intel_encoder *
> intel_attached_encoder(struct intel_connector *connector)
> {
--
Jani Nikula, Intel
ng? The name of the struct is
intel_color_block.
> +enum intel_color_block {
> + CB_PLANE_PRE_CSC_LUT,
> + CB_PLANE_CSC,
> + CB_PLANE_POST_CSC_LUT,
> +
> + I915_MAX_CB
Why I915? This has less and less to do with i915 nowadays. Maybe all of
these should be INTEL_ prefixed?
> +};
> +
> #endif /* __INTEL_DISPLAY_LIMITS_H__ */
--
Jani Nikula, Intel
r display
drm/i915/wcl: C10 phy connected to port A and B
drm/i915/xe3lpd: Extend WA 16023981245 for display 30.02
Hans de Goede (1):
drm/i915/dsi: Fix NULL pointer deref in vlv_dphy_param_init()
Jani Nikula (37):
drm/i915/vrr: fix register file style
drm
ERT_RESET, instead the deassert
> is done at the beginning of MIPI_SEQ_INIT_OTP, which is exactly what
> the fixup from vlv_fixup_mipi_sequences() fixes up.
>
> Extend it to also apply to v2 sequences, this fixes the panel not working
> on the Acer Iconia One 8 A1-840.
I believe you have the mos
PaT7H8w2hlveoEYa4DDtITGkyd9o57LE=
>
> This is was dmesg from 2nd (and in the same time last) boot. The next boot
> (i. e. kexec) was unsuccessful. Corresponding config:
>
> https://zerobin.net/?009c807e1df41af8#gnmrswlbaFbdPTuzNq6NFkQd/Jhb3Ds0ZlLiwNanXnc=
>
> If you want results from all expirements, here is a link:
> https://filebin.net/45g2757b2iwaeen7 (1 Mb, expires after 7 days). Usually
> expirements come with full reproducer script.
>
> But what I described above is already enough, I think this link is not needed.
>
> I will be available for testing in coming days, then I will switch to other
> things, and so will not be available for testing.
> If you want more time, then, please, ask for it, i. e. say me something like
> "Please, be available for testing in more 10 days".
>
> --
> Askar Safin
> https://types.pl/@safinaskar
>
--
Jani Nikula, Intel
en backmerged to drm after -rc1 instead of cross-merging that
directly to drm.
Regardless, for merging the i915 changes via whichever tree,
Acked-by: Jani Nikula
--
Jani Nikula, Intel
; cache what we need for internal usage. That change was initially a
> pure fix, do you recommend changing all of this in this change, or in
> a follow-up one.
If there's a follow-up, I really *really* think it should be to rewrite
EDID reading in anx7625.c altogether. The current thing is busted in
more ways than I have time to enumerate right now. And it's not because
I'm in a huge rush. Just look at sp_tx_edid_read() and the functions it
calls.
The end result should be based on providing a straightforward read_block
callback for drm_edid_read_custom().
I've actually started this a few times myself, but it's a bit much for
someone without the hardware to test it, nor skin in the game. The
current code is too complex to trivially refactor.
BR,
Jani.
--
Jani Nikula, Intel
RM_DEBUG_SELFTEST
> + select DRM_KUNIT_TEST
> select DMABUF_SELFTESTS
> select SW_SYNC # signaling validation framework (igt/syncobj*)
> select DRM_I915_WERROR
--
Jani Nikula, Intel
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -554,6 +554,7 @@ DRM specific patterns. Note that ENOTTY has the slightly
> unintuitive meaning of
> .. kernel-doc:: include/drm/drm_ioctl.h
> :internal:
>
> +.. c:namespace:: gpu_drm
> .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
> :export:
--
Jani Nikula, Intel
Enable backlight control using luminance
> drm/i915/backlight: Use drm helper to initialize edp backlight
> drm/i915/backlight: Use drm helper to set edp backlight
> drm/i915/backlight: Use drm_edp_backlight_enable
Acked-by: Jani Nikula
for merging the last three patches via drm-misc.
On Wed, 25 Jun 2025, Luca Ceresoli wrote:
> This op does not pass any pointer to the DSI device, so the DSI host driver
> cannot store it.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Jani Nikula
for merging via whichever tree you find suitable.
> ---
> drivers/gpu/drm/i915
ei_cl_device_id mei_late_bind_tbl[] = {
>> +{ .uuid = MEI_GUID_MKHI, .version = MEI_CL_VERSION_ANY },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(mei, mei_late_bind_tbl);
>> +
>> +static struct mei_cl_driver mei_late_bind_driver = {
>> +.id_table = mei_late_bind_tbl,
>> +.name = KBUILD_MODNAME,
>> +.probe = mei_late_bind_probe,
>> +.remove = mei_late_bind_remove,
>> +};
>> +
>> +module_mei_cl_driver(mei_late_bind_driver);
>> +
>> +MODULE_AUTHOR("Intel Corporation");
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("MEI Late Binding");
>> diff --git a/include/drm/intel/i915_component.h
>> b/include/drm/intel/i915_component.h
>> index 4ea3b17aa143..4945044d41e6 100644
>> --- a/include/drm/intel/i915_component.h
>> +++ b/include/drm/intel/i915_component.h
>> @@ -31,6 +31,7 @@ enum i915_component_type {
>> I915_COMPONENT_HDCP,
>> I915_COMPONENT_PXP,
>> I915_COMPONENT_GSC_PROXY,
>> +I915_COMPONENT_LATE_BIND,
>> };
>>
>> /* MAX_PORT is the number of port
>> diff --git a/include/drm/intel/late_bind_mei_interface.h
>> b/include/drm/intel/late_bind_mei_interface.h
>> new file mode 100644
>> index ..2c53657ce91b
>> --- /dev/null
>> +++ b/include/drm/intel/late_bind_mei_interface.h
>> @@ -0,0 +1,50 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright (c) 2025 Intel Corporation */
>> +
>> +#ifndef _LATE_BIND_MEI_INTERFACE_H_
>> +#define _LATE_BIND_MEI_INTERFACE_H_
>> +
>> +#include
>> +
>> +struct device;
>> +struct module;
>> +
>> +/**
>> + * Late Binding flags
>> + * Persistent across warm reset
>> + */
>> +#define CSC_LATE_BINDING_FLAGS_IS_PERSISTENTBIT(0)
>> +
>> +/**
>> + * xe_late_bind_fw_type - enum to determine late binding fw type */
>> +enum late_bind_type {
>> +CSC_LATE_BINDING_TYPE_FAN_CONTROL = 1, };
>> +
>> +/**
>> + * struct late_bind_component_ops - ops for Late Binding services.
>> + * @owner: Module providing the ops
>> + * @push_config: Sends a config to FW.
>> + */
>> +struct late_bind_component_ops {
>> +struct module *owner;
>> +
>> +/**
>> + * @push_config: Sends a config to FW.
>> + * @dev: device struct corresponding to the mei device
>> + * @type: payload type
>> + * @flags: payload flags
>> + * @payload: payload buffer
>> + * @payload_size: payload buffer size
>> + *
>> + * Return: 0 success, negative errno value on transport failure,
>> + * positive status returned by FW
>> + */
>> +int (*push_config)(struct device *dev, u32 type, u32 flags,
>> + const void *payload, size_t payload_size); };
>> +
>> +#endif /* _LATE_BIND_MEI_INTERFACE_H_ */
>> --
>> 2.34.1
>
--
Jani Nikula, Intel
ATUS
drm/edid: Define the quirks in an enum list
drm/edid: Add support for quirks visible to DRM core and drivers
drm/dp: Add an EDID quirk for the DPCD register access probe
drm/i915/dp: Disable the AUX DPCD probe quirk if it's not required
Jani Nikula (46):
drm
t; Is include/linux/hw_bitfield.h a cromulent choice, or should we go with
> include/linux/hw_bits.h?
I'll let y'all fight it out.
> Furthermore, should it be FIELD_PREP_WM16_CONST or FIELD_PREP_CONST_WM16?
> I'm personally partial to the former.
Ditto.
> And finally, is it okay if I leave out refactoring Intel's
> _MASKED_FIELD() or should I see if I can at least replace its
> implementation while I'm at it?
I think you can just let us deal with that afterwards. You have enough
users already.
BR,
Jani.
>
> For less opinionated changes, I'll also change all the `U` literal
> suffixes to `UL` wherever I've added them. As I understand it, it doesn't
> really make a difference in these instances, but `UL` is more prevalent
> in the kernel.
>
> Kind regards,
> Nicolas Frattaroli
>
>
--
Jani Nikula, Intel
On Fri, 13 Jun 2025, Tvrtko Ursulin wrote:
> On 13/06/2025 11:09, Jani Nikula wrote:
>> On Wed, 04 Jun 2025, Simona Vetter wrote:
>>> On Wed, Jun 04, 2025 at 05:36:22PM +0200, Simona Vetter wrote:
>> This regressed one of our CI IGT tests [1].
>>
>&g
>> > + if (!dma_buf)
>> > + return;
>> > +
>> >mutex_lock(&prime_fpriv->lock);
>> >
>> > - rb = prime_fpriv->handles.rb_node;
>> > + rb = prime_fpriv->dmabufs.rb_node;
>> >while (rb) {
>> >struct drm_prime_member *member;
>> >
>> > - member = rb_entry(rb, struct drm_prime_member, handle_rb);
>> > - if (member->handle == handle) {
>> > - rb_erase(&member->handle_rb, &prime_fpriv->handles);
>> > + member = rb_entry(rb, struct drm_prime_member, dmabuf_rb);
>> > + if (member->dma_buf == dma_buf && member->handle == handle) {
>> >rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs);
>> >
>> >dma_buf_put(member->dma_buf);
>> >kfree(member);
>> >break;
>> > - } else if (member->handle < handle) {
>> > + } else if (member->dma_buf < dma_buf) {
>> >rb = rb->rb_right;
>> >} else {
>> >rb = rb->rb_left;
>> > @@ -446,12 +412,6 @@ struct dma_buf *drm_gem_prime_handle_to_dmabuf(struct
>> > drm_device *dev,
>> >goto out_unlock;
>> >}
>> >
>> > - dmabuf = drm_prime_lookup_buf_by_handle(&file_priv->prime, handle);
>> > - if (dmabuf) {
>> > - get_dma_buf(dmabuf);
>> > - goto out;
>> > - }
>> > -
>> >mutex_lock(&dev->object_name_lock);
>> >/* re-export the original imported/exported object */
>> >if (obj->dma_buf) {
>> > --
>> > 2.34.1
>> >
>>
>> --
>> Simona Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
--
Jani Nikula, Intel
> \
> + ( \
> + FIELD_PREP_CONST(_mask, _val) | \
> + (BUILD_BUG_ON_ZERO(const_true((u64) (_mask) > U16_MAX)) + \
> + ((_mask) << 16)) \
> + )
> +
> /**
> * FIELD_GET() - extract a bitfield element
> * @_mask: shifted mask defining the field's length and position
--
Jani Nikula, Intel
: c472d828348c ("drm/nouveau/gsp: move subdev/engine impls to
subdev/gsp/rm/r535/")
Cc: Ben Skeggs
Signed-off-by: Jani Nikula
---
Documentation/gpu/nouveau.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/nouveau.rst b/Documentation/gpu/nouveau
The drm panel funcs should be static, fix it.
Fixes: 3fdd5bfbd638 ("drm/i915/panel: register drm_panel and call
prepare/unprepare for ICL+ DSI")
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
submission method out of the three that's affected, and needs to be
> rephrased, I believe, while still kept short enough. Maybe "Fix *legacy*
> timeline held on VMA alloc error" (with the 'left' word dropped)?
>
> Thanks,
> Janusz
>
>>
>> Andi
>>
>
>
>
>
--
Jani Nikula, Intel
On Tue, 10 Jun 2025, "Kahola, Mika" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Imre
>> Deak
>> Sent: Monday, 9 June 2025 15.56
>> To: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org;
>> dri-devel@lists.free
On Fri, 06 Jun 2025, Jani Nikula wrote:
> Hi all -
>
> This series expands panel follower to ACPI, and enables drm_panel on
> i915.
>
> Patch 1 makes panel follower matching independent of DT, making it also
> work with ACPI. Similar to DT, you can use a _DSD "panel&q
ents (Doug, Arun)
- s/IS_ERR_OR_NULL/IS_ERR/ (Doug)
Suggested-by: Heikki Krogerus
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Maxime Ripard
Cc: Doug Anderson
Cc: Lee Shawn C
Tested-by: Lee Shawn C
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
Reviewed-by: Arun R Murthy
Signed-of
On Mon, 09 Jun 2025, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 6, 2025 at 2:06 AM Jani Nikula wrote:
>>
>> Use firmware node based lookups for panel followers, to make the code
>> independent of OF and device tree, and make it work also for ACPI with
>> an ap
On Tue, 10 Jun 2025, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Jani
>> Nikula
>> Sent: Friday, June 6, 2025 2:35 PM
>> To: dri-devel@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org; inte
On Tue, 10 Jun 2025, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Jani
>> Nikula
>> Sent: Friday, June 6, 2025 2:35 PM
>> To: dri-devel@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org; inte
On Fri, 06 Jun 2025, Imre Deak wrote:
> On Fri, Jun 06, 2025 at 04:50:03PM +0300, Imre Deak wrote:
>> On Fri, Jun 06, 2025 at 04:44:37PM +0300, Jani Nikula wrote:
>> > On Thu, 05 Jun 2025, Imre Deak wrote:
>> > > Reading DPCD registers has side-effects
.
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 ++
> drivers/gpu/drm/i915/display/intel_hotplug.c | 10 ++
> 3 files
et;
> +
> + offset = y * sb->pitch[0] + x * sb->format->cpp[0];
> +
> + new_page = offset >> PAGE_SHIFT;
> + offset = offset % PAGE_SIZE;
> + if (new_page != xe_panic_page) {
> + xe_panic_kunmap();
> + xe_panic_page = new_page;
> + xe_panic_vaddr = ttm_bo_kmap_try_from_panic(&xe_panic_bo->ttm,
> + xe_panic_page);
> + }
> + if (xe_panic_vaddr) {
> + u32 *pix = xe_panic_vaddr + offset;
> + *pix = color;
> + }
> +}
> +
> +int intel_bo_panic_setup(struct drm_gem_object *obj, struct
> drm_scanout_buffer *sb)
> +{
> + struct xe_bo *bo = gem_to_xe_bo(obj);
> +
> + xe_panic_bo = bo;
> + sb->set_pixel = xe_panic_page_set_pixel;
> + return 0;
> +}
> +
> +void intel_bo_panic_finish(struct drm_gem_object *obj)
> +{
> + xe_panic_kunmap();
> + xe_panic_page = -1;
> +}
--
Jani Nikula, Intel
]. Thanks
for your feedback, and for bearing with me.
BR,
Jani.
[1] https://lore.kernel.org/r/cover.1749199013.git.jani.nik...@intel.com
--
Jani Nikula, Intel
el_prepare() and drm_panel_unprepare() functions for
ICL+ DSI, so that followers get notified of the panel power state
changes. This can later be expanded to VLV+ DSI and eDP.
Cc: Maxime Ripard
Cc: Heikki Krogerus
Cc: Lee Shawn C
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display
m with panel
followers, please?
BR,
Jani.
Jani Nikula (4):
drm/panel: use fwnode based lookups for panel followers
drm/i915/panel: add panel register/unregister
drm/i915/panel: register drm_panel and call prepare/unprepare for ICL+
DSI
drm/i915/panel: sync panel prepared state
1 - 100 of 2460 matches
Mail list logo
