On Fri, Jan 17, 2025 at 11:40:15AM +, Simon Ser wrote:
> On Friday, January 17th, 2025 at 12:32, Ville Syrjälä
> wrote:
>
> > > + * When used with atomic uAPI, one event will be delivered per CRTC
> > > included in
> > > + * the atomic commit. A CRTC is
sharing a DP-MST connector).
>
> Signed-off-by: Simon Ser
> Cc: Simona Vetter
> Cc: Ville Syrjälä
> Cc: Pekka Paalanen
> Cc: David Turner
> ---
> include/uapi/drm/drm_mode.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/uapi/drm/dr
On Thu, Jan 16, 2025 at 04:24:26PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> > When converting to folios the cleanup path of shmem_get_pages() was
> > missed. When a DMA remap fails and the max segment size is greater than
> &
On Thu, Jan 16, 2025 at 09:36:42AM -0500, Brian Geffon wrote:
> On Thu, Jan 16, 2025 at 9:24 AM Ville Syrjälä
> wrote:
> >
> > On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> > > When converting to folios the cleanup path of shmem_get_pages() was
>
On Thu, Jan 16, 2025 at 04:24:26PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> > When converting to folios the cleanup path of shmem_get_pages() was
> > missed. When a DMA remap fails and the max segment size is greater than
> &
mapping_clear_unevictable(file_inode(obj->base.filp)->i_mapping);
> shmem_sg_free_table(pages, file_inode(obj->base.filp)->i_mapping,
> obj->mm.dirty, obj->mm.madv == I915_MADV_WILLNEED);
> kfree(pages);
> --
> 2.48.0.rc2.279.g1de40edade-goog
--
Ville Syrjälä
Intel
tlab.freedesktop.org/drm/i915/kernel/-/issues/13057
--
Ville Syrjälä
Intel
include/drm/drm_plane.h
> index dd718c62ac31..3c5c2c614af8 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -988,5 +988,9 @@ int drm_plane_create_scaling_filter_property(struct
> drm_plane *plane,
> int drm_plane_add_size_hints_property(struct drm_plane *plane,
> const struct drm_plane_size_hint *hints,
> int num_hints);
> +int drm_plane_create_format_blob(struct drm_device *dev,
> + struct drm_plane *plane, u64 *modifiers,
> + unsigned int modifier_count, u32 *formats,
> + unsigned int format_count, bool is_async);
>
> #endif
> --
> 2.25.1
--
Ville Syrjälä
Intel
On Wed, Nov 06, 2024 at 02:32:28PM +, Murthy, Arun R wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, November 6, 2024 7:31 PM
> > To: Murthy, Arun R
> > Cc: intel...@lists.freedesktop.org; intel-...@list
is plane */
> uint64_t *modifiers;
> /** @modifier_count: Size of the array pointed at by @modifier_count. */
> unsigned int modifier_count;
>
> + /** @modifiers: array of modifiers supported by this plane */
> + uint64_t *async_modifiers;
> + /** @modifier_count: Size of the array pointed at by @modifier_count. */
> + unsigned int async_modifier_count;
I'm not sure adding any of this is really useful. I think we could
just add a new .format_mod_supported_async() hook instead (which
could be implemented in terms of the current thing + something like
https://patchwork.freedesktop.org/patch/619047/?series=139807&rev=3
That would also be more flexible since it can allow specific
format+modifier combinations to be either accepted or rejected.
> +
> /**
>* @crtc:
>*
> --
> 2.25.1
--
Ville Syrjälä
Intel
(first three payload bytes are the OUI). It begs the
> question whether there should be higher level data and length helpers
> that identify and remove the tags (including extended tags and OUI
> stuff). For example, the actual data for HDMI VSDB starts at payload
> offset 3, as the first
*drm_crtc_vblank_crtc(struct
> drm_crtc *crtc);
> int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> bool drm_dev_has_vblank(const struct drm_device *dev);
> u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
> -u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> -ktime_t *vblanktime);
> int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime);
> void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> struct drm_pending_vblank_event *e);
> --
> 2.47.0
--
Ville Syrjälä
Intel
On Fri, Oct 25, 2024 at 12:57:50PM +0300, Jani Nikula wrote:
> On Thu, 03 Oct 2024, Ville Syrjälä wrote:
> > On Wed, Oct 02, 2024 at 09:21:59PM +0300, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> Hide the plane->fb/etc. footguns better by s
On Wed, Oct 02, 2024 at 09:21:58PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> An attempt to hide the drm_plane/crtc legacy state better.
>
> This also highlights the fact that a lot of supposedly
> atomic drivers are poking around in the legacy crtc state,
On Fri, Oct 25, 2024 at 04:28:18AM +, Murthy, Arun R wrote:
> > > Subject: Re: [PATCH] drm/i915/display: plane property for async
> > > supported modifiers
> > >
> > > On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> > > > On Wed,
On Tue, Oct 22, 2024 at 09:46:24AM +, CK Hu (胡俊光) wrote:
> Hi, Ville:
>
> On Thu, 2024-10-03 at 14:18 +0300, Ville Syrjala wrote:
> >
> > External email : Please do not click links or open attachments until you
> > have verified the sender or the conten
On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > > Create a i915 private plane property for sharing the async supported
> >
On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > Create a i915 private plane property for sharing the async supported
> > modifiers to the user.
> > UMD related discussion requesti
skl_universal_plane_create(struct drm_i915_private *dev_priv,
> enum pipe pipe, enum plane_id plane_id)
> @@ -2694,10 +2739,12 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> if (DISPLAY_VER(dev_priv) >= 12)
> drm_plane_enable_fb_damage_clips(&plane->base);
>
> - if (DISPLAY_VER(dev_priv) >= 11)
> + if (DISPLAY_VER(dev_priv) >= 11) {
> drm_plane_create_scaling_filter_property(&plane->base,
> BIT(DRM_SCALING_FILTER_DEFAULT)
> |
>
> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
> + intel_plane_attach_async_modifiers_property(plane);
> + }
>
> intel_plane_helper_add(plane);
>
> --
> 2.25.1
--
Ville Syrjälä
Intel
On Tue, Oct 08, 2024 at 10:33:44PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 07, 2024 at 09:36:13AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 03.10.24 um 13:33 schrieb Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > drm_client_firmw
Expansion ROM at 000c [virtual] [disabled] [size=128K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] Express Legacy Endpoint, IntMsgNum 0
> Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit+
> Kernel driver in use: radeon
> Kernel modules: radeon
>
> Regards,
> Erhard
--
Ville Syrjälä
Intel
On Mon, Oct 07, 2024 at 09:36:13AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.10.24 um 13:33 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > drm_client_firmware_config() is currently picking up the current
> > mode of the crtc via the legacy crtc->m
On Mon, Oct 07, 2024 at 09:43:47AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.10.24 um 13:33 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > Replace the 'unsigned int i' footguns with plain old signed
> > int. Avoids accidents if/when someone
On Mon, Oct 07, 2024 at 03:37:40PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.10.24 um 12:01 schrieb Ville Syrjälä:
> > On Fri, Oct 04, 2024 at 11:17:02AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 02.10.24 um 18:15 schrieb Luck, Tony:
On Fri, Oct 04, 2024 at 01:03:21PM +0200, Thomas Zimmermann wrote:
> Hi
>
> thanks for your help.
>
>
> Am 04.10.24 um 12:01 schrieb Ville Syrjälä:
> > On Fri, Oct 04, 2024 at 11:17:02AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 02.1
terrupt is never even
generated. In the latter case you could try using the
vsync interrupt instead.
--
Ville Syrjälä
Intel
any way so they should
stay identical after drm_atomic_helper_check_modeset()->mode_fixup()
has done the copy.
Reviewed-by: Ville Syrjälä
>
> [1]:https://lore.kernel.org/all/20241002182200.15363-1-ville.syrj...@linux.intel.com/
>
> Signed-off-by: Louis Chauvet
> ---
> drivers/gpu/drm/vkms/vkms_
On Thu, Oct 03, 2024 at 02:33:00PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_client_firmware_config() is currently picking up the current
> mode of the crtc via the legacy crtc->mode, which is not supposed
> to be used by atomic drivers at all. We can't
c_helper_update_legacy_modeset_state()
and I didn't bother looking for a better home for it when I split
it out. But seems like it should work fine as is.
>
> I tested kms_vblank, all of them are SUCCESS/SKIP, do you know other tests
> that can trigger bugs?
You would explicitly have to race commits against vblank_enable.
Could of course sprinkle sleep()s around to widen the race window
if you're really keen to hit it.
--
Ville Syrjälä
Intel
On Thu, Oct 03, 2024 at 02:33:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Bunch of variables are only needed inside loops and whatnot.
> Move them to a tighter scope to make the code less confusing.
>
> Also replace the 'unsigned int i' footguns with p
On Thu, Oct 03, 2024 at 02:38:35PM +0200, Louis Chauvet wrote:
> Le 02/10/24 - 21:22, Ville Syrjala a écrit :
> > From: Ville Syrjälä
> >
> > Atomic drivers shouldn't be using the legacy state stored
> > directly under drm_crtc. Move that junk into a 'legac
On Wed, Oct 02, 2024 at 09:21:59PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hide the plane->fb/etc. footguns better by stashing them inside
> a "legacy" sub struct.
>
> Eventually maybe we could turn 'legacy' into a pointer
> that only ex
. OTOH maybe I'll get the "broken"
gcc upgrade before I look at this code again, which would solve
that particular problem.
>
> > + static const char dp_dual_mode_hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN + 1] =
> > "DP-HDMI ADAPTOR\x04";
> >
> > return memcmp(hdmi_id, dp_dual_mode_hdmi_id,
> > - sizeof(dp_dual_mode_hdmi_id)) == 0;
> > + DP_DUAL_MODE_HDMI_ID_LEN) == 0;
> > }
> >
> > static bool is_type1_adaptor(uint8_t adaptor_id)
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
&&
> > fb->format->format == DRM_FORMAT_C8)
> > new_crtc_state->c8_planes |= BIT(plane->id);
> >
> > if (new_plane_state->uapi.visible || old_plane_state->uapi.visible)
> > new_crtc_state->update_planes |= BIT(plane->id);
> >
> > - if (new_plane_state->uapi.visible &&
> > + if (new_plane_state->uapi.visible && fb &&
> > intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier)) {
> > new_crtc_state->data_rate_y[plane->id] =
> > intel_plane_data_rate(new_crtc_state, new_plane_state,
> > 0);
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
On Fri, Sep 27, 2024 at 04:45:44PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 27, 2024 at 04:14:17PM +0300, Jani Nikula wrote:
> > On Fri, 27 Sep 2024, Ville Syrjälä wrote:
> > > On Fri, Sep 27, 2024 at 11:20:32AM +0300, Jani Nikula wrote:
> > >> On Fri,
On Fri, Sep 27, 2024 at 04:14:17PM +0300, Jani Nikula wrote:
> On Fri, 27 Sep 2024, Ville Syrjälä wrote:
> > On Fri, Sep 27, 2024 at 11:20:32AM +0300, Jani Nikula wrote:
> >> On Fri, 27 Sep 2024, Alessandro Zanni wrote:
> >> > This fix solves multiple Smatch errors:
ag(block),
> > edid_block_compute_checksum(block));
> > }
> > break;
> > case EDID_BLOCK_VERSION:
> > - pr_notice("EDID has major version %d, instead of 1\n",
> > + pr_notice_once("EDID has major version %d, instead of 1\n",
> > block->version);
> > break;
> > default:
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
e. I don't really care about those as I never plan to
turn the cursor blinking back on after turning it off via
udev.
--
Ville Syrjälä
Intel
ermanns R-b tag, so
> no action needed from your side for now.
Cool. Thanks.
--
Ville Syrjälä
Intel
On Mon, Sep 23, 2024 at 11:04:55PM +0200, Helge Deller wrote:
> On 9/23/24 17:57, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently setting cursor_blink attribute to 0 before any fb
> > devices are around does absolutely nothing. When fb devices appear
&
On Mon, Sep 23, 2024 at 09:46:03PM +0200, Helge Deller wrote:
> On 9/23/24 17:57, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Invert fbcon_cursor_noblink into fbcon_cursor_blink so that:
> > - it matches the sysfs attribute exactly
> > - avoids having to
d appreciate any feedback or discussion about this.
>
> References:
> 1. https://gitlab.freedesktop.org/drm/amd/-/issues/2200#note_2160244
> 2. https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/7542#note_1643183
> 3. https://forums.developer.nvidia.com/t/cant-enable-ulmb-2-on-wayland/277478
>
> Thanks,
> Vidith
--
Ville Syrjälä
Intel
easonable.
Reviewed-by: Ville Syrjälä
PS when grepping for drm_rect I noticed drm_atomic_plane_set_property()
is using it as the format of the fb_damage_clips blob. That
can't be right as drm_rect is an internal thing and should
not be used in the uapi.
>
> Signed-off-by: Thomas Zimmer
's hot path. The call to
> ->get_modes usually only runs after the connector status changes to
> connected, which rarely happens. It's also not time critical as no
> modeset has happened yet.
I don't see how you can really optimize polling with this because
the only way to figure out if the EDID changed is to read it.
Anyways, my gut feeling is that we need things in .detect()
because that's also where DPCD is read, and we defintiely need that
to do anything sensible. And dongles can also snoop the EDID reads
and I think even potentially change their DPCD based on that, so
having that go out of sync by skipping the EDID read might end up
with weird behaviour.
--
Ville Syrjälä
Intel
> validate_encoder_possible_clones() ensure the same, but during the
> > > encoder registration?
> >
> > The difference here is that validate_encoder_possible_clones() is only
> > called when the drm device is initially registered.
> >
> > The check here is to make sure that the encoders userspace is proposing
> > to be cloned are actually possible clones of each other. This might not
> > be necessary for drivers where all encoders are all possible clones of
> > each other. But for MSM (and CWB), real-time display encoders can only
> > be clones of writeback (and vice versa).
>
> I had the feeling that encoder_mask should already take care of that,
> but it seems I was wrong.
> Please extract this piece as a generic helper. I think it should be
> called from the generic atomic_check() codepath.
Yeah, if we are semi-assured that drivers aren't screwing up those
bitmasks anymore we could shove the cloning checks into
drm_atomic_helper_check_modeset(). It already checks possible_crtcs.
We could then throw out the equavalent code from i915 as well...
Are there decent IGTs to make sure the kernel properly rejects
illegal cloning configurations?
--
Ville Syrjälä
Intel
f the word in bytes 2..3, a
> 12-bit B component in the top 12 bits of the word
> + * in bytes 4..5, and a 12-bit A component in the top 12 bits of the word in
> bytes 6..7,
> + * with the bottom 4 bits of each word unused.
> + */
> +#define DRM_FORMAT_AXBXGXRX124124124124 fourcc_code('A', 'B', '1', '2')
> /* [63:0] A:x:B:x:G:x:R:x 12:4:12:4:12:4:12:4 */
> +
> +/*
> + * 4-component, 64bpp format that has a 14-bit R component in the top 14
> bits of the word in bytes 0..1,
> + * a 14-bit G component in the top 14 bits of the word in bytes 2..3, a
> 14-bit B component in the top 14 bits of the word
> + * in bytes 4..5, and a 14-bit A component in the top 14 bits of the word in
> bytes 6..7,
> + * with the bottom 2 bits of each word unused.
> + */
> +#define DRM_FORMAT_AXBXGXRX142142142142 fourcc_code('A', 'B', '1', '4')
> /* [63:0] A:x:B:x:G:x:R:x 14:2:14:2:14:2:14:2 */
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> --
> 2.34.1
--
Ville Syrjälä
Intel
On Wed, Jul 10, 2024 at 01:55:32PM +0200, Thorsten Blum wrote:
> On 10. Jul 2024, at 13:38, Ville Syrjälä
> wrote:
> > On Wed, Jul 10, 2024 at 09:46:51AM +0200, Thorsten Blum wrote:
> >> As the comment explains, the if check ensures that the divisor oa_period
> >
esn't need the
remainder?
> oa_freq_hz = tmp;
> } else
> oa_freq_hz = 0;
> --
> 2.45.2
--
Ville Syrjälä
Intel
On Tue, Jul 02, 2024 at 08:34:39PM -0600, jim.cro...@gmail.com wrote:
> On Tue, Jul 2, 2024 at 5:33 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 02, 2024 at 03:57:20PM -0600, Jim Cromie wrote:
> > > dyndbg's CLASSMAP-v1 api was broken; DECLARE_DYNDBG_CLASSMAP
; + "DRM_UT_DRIVER",
> + "DRM_UT_KMS",
> + "DRM_UT_PRIME",
> + "DRM_UT_ATOMIC",
> + "DRM_UT_VBL",
> + "DRM_UT_STATE",
> + "DRM_UT_LEASE",
> + "DRM_UT_DP",
> + "DRM_UT_DRMRES");
Looks like this stuff just ends up in an array, so presumably
it should be possible to use designated initializers to make this
less fragile?
--
Ville Syrjälä
Intel
On Wed, Jun 19, 2024 at 02:38:16PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > intel_surf_alignment() in particular has devolved into
> > a complete mess. Redesign the code so that
On Wed, Jun 19, 2024 at 02:38:16PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > intel_surf_alignment() in particular has devolved into
> > a complete mess. Redesign the code so that
mary plane will alwyas exist (drm_crtc_init() will create
one for the old drivers that don't do it explicitly). So you
should be able to convert radeon as well. And looks like some
pre-dc amdgpu stuff is in a similar situation.
That should presumably allow the old flag to be removed entirely?
Hmm, I suppose drm_getcap() would need a bit of work to eg. go
through all the planes to see if any of them support async flips.
>
> Do you know any other driver that should be updated to?
>
> >> include/drm/drm_plane.h | 5 +
> >> 8 files changed, 29 insertions(+), 4 deletions(-)
> >>
> >> --
> >> 2.45.2
> >>
> >
--
Ville Syrjälä
Intel
On Wed, Jun 12, 2024 at 11:47:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_surf_alignment() in particular has devolved into
> a complete mess. Redesign the code so that we can handle
> alignment restrictions in a nicer. Also adjust alignment
> for TGL+ to
anic notifier for this plane
> */
> struct kmsg_dumper kmsg_panic;
> +
> + /**
> + * @async_flip: indicates if a plane can do async flips
> + */
> + bool async_flip;
> };
>
> #define obj_to_plane(x) container_of(x, struct drm_plane, base)
> --
> 2.45.2
--
Ville Syrjälä
Intel
v_name() is what I added to all i915 display tracepoints.
--
Ville Syrjälä
Intel
drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -271,11 +271,13 @@ static void drm_client_match_edp_lid(struct
> > drm_device *dev,
> > if (connector->connector_type != DRM_MODE_CONNECTOR_eDP ||
> > !enabled[i])
> > continue;
> >
> > +#if defined(CONFIG_ACPI_BUTTON)
> > if (!acpi_lid_open()) {
> > drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
> > disabling\n",
> > connector->base.id, connector->name);
> > enabled[i] = false;
> > }
> > +#endif
> > }
> > }
>
> No. This is because
>
> CONFIG_DRM=y
> CONFIG_ACPI_BUTTON=m
>
> The pedantically correct fix is probably having DRM
>
> depends on ACPI_BUTTON || ACPI_BUTTON=n
>
> but seeing how i915 and xe just
>
> select ACPI_BUTTON if ACPI
Huh. We should nuke that as we haven't used this lid stuff in ages.
--
Ville Syrjälä
Intel
On Wed, May 29, 2024 at 09:45:55AM -0500, Mario Limonciello wrote:
> On 5/29/2024 09:14, Ville Syrjälä wrote:
> > On Tue, May 28, 2024 at 04:03:19PM -0500, Mario Limonciello wrote:
> >> If the lid on a laptop is closed when eDP connectors are populated
> >> then it remai
On Wed, May 29, 2024 at 12:37:30AM +0300, Imre Deak wrote:
> On Tue, May 28, 2024 at 10:38:06PM +0300, Ville Syrjälä wrote:
> > On Tue, May 28, 2024 at 02:27:52PM +0300, Imre Deak wrote:
> > > On Mon, May 13, 2024 at 08:59:37PM +0300, Ville Syrjala wrote:
> >
cs));
> memset(offsets, 0, connector_count * sizeof(*offsets));
>
> + drm_client_match_edp_lid(dev, connectors, connector_count,
> enabled);
> if (!drm_client_target_cloned(dev, connectors, connector_count,
> modes,
> offsets, enabled, width, height)
> &&
> !drm_client_target_preferred(dev, connectors,
> connector_count, modes,
> --
> 2.43.0
--
Ville Syrjälä
Intel
On Mon, May 27, 2024 at 05:29:09PM +0200, Alain Volmat wrote:
> Hi Ville,
>
> thank you for your patch.
>
> On Mon, Apr 08, 2024 at 08:04:12PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Allow sti to be built with COMPILE_TEST=y for greater
On Tue, May 28, 2024 at 02:27:52PM +0300, Imre Deak wrote:
> On Mon, May 13, 2024 at 08:59:37PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Different planes could have different alignment requirements
> > even for the same format/modifier. Collect the
On Tue, May 28, 2024 at 04:22:59PM +0300, Imre Deak wrote:
> On Mon, May 13, 2024 at 08:59:41PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we still use the SKL+ PLANE_SURF alignment even
> > for TGL+ even though the hardware no longer needs i
", i);
> imx_ldb->clk_sel[i] = devm_clk_get(imx_ldb->dev, clkname);
> if (IS_ERR(imx_ldb->clk_sel[i])) {
> ret = PTR_ERR(imx_ldb->clk_sel[i]);
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Tue, May 21, 2024 at 02:09:19PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2024 at 08:33:24PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by filtering out unwanted YCbCr 4:2:0
> > only modes prior to calling the c
On Fri, May 10, 2024 at 08:33:59PM +0300, Ville Syrjälä wrote:
> On Fri, May 10, 2024 at 12:09:51PM +0300, Jani Nikula wrote:
> > libdrm does not like the empty string for driver date. Use "0" instead,
> > which has been used by virtio previously.
> >
> >
ate_len, "");
> + err = drm_copy_field(version->date, &version->date_len, "0");
Does this also fix igt/core_getversion which is on fire now?
> if (!err)
> err = drm_copy_field(version->desc, &version->desc_len,
> dev->driver->desc);
> --
> 2.39.2
--
Ville Syrjälä
Intel
d && !obj_free_cb);
> + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb &&
> obj_type != DRM_MODE_OBJECT_PROPERTY);
>
> mutex_lock(&dev->mode_config.idr_mutex);
> ret = idr_alloc(&dev->mode_config.object_idr, register_obj ? obj : NULL,
> --
> 2.43.0
--
Ville Syrjälä
Intel
On Mon, Apr 08, 2024 at 08:04:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I got fed up having to build multiple architectures when
> doing subsystem wide refactoring. So I decided to attack
> the low hanging COMPILE_TEST=y fruit. Here are the
> results. All of
On Wed, May 08, 2024 at 12:12:32PM +0300, Jani Nikula wrote:
> On Mon, 08 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: intel-...@lists.freedeskt
On Wed, May 08, 2024 at 09:47:50AM -0400, Alex Deucher wrote:
> On Mon, Apr 8, 2024 at 3:06 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: Alex
moving the declaration anyways, so it shouldn't be more risky to
> do the rename as well?
I suppose. Not something I want to have to think about though.
I've pushed this to drm-misc-next with Harry's rb (thanks).
>
> I'm holding off the libdrm header update until we find a solution.
--
Ville Syrjälä
Intel
gt;
> Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
>
> Changes in v2:
> - removed checking the block size of the backlight
On Tue, Apr 09, 2024 at 06:02:49PM +0300, Dmitry Baryshkov wrote:
> On Mon, Apr 08, 2024 at 10:06:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier by providing a function that hands
> > out the the correct drm_vblank_crtc for a give
ion value.
>*/
> enum drm_hdmi_broadcast_rgb broadcast_rgb;
>
> + /**
> + * @is_full_range: Is the output supposed to use a full
> + * RGB Quantization Range or not?
> + */
> + bool is_full_range;
I would say limited range is the exception so I would suggest
flagging that instead. Feels a bit weird to flag the normal
case. Maybe the name should also include 'rgb' to make it clear
it only applies to RGB.
> +
> /**
>* @output_bpc: Bits per color channel to output.
>*/
> unsigned int output_bpc;
>
>
> --
> 2.44.0
--
Ville Syrjälä
Intel
* @drm_atomic_helper_connector_hdmi_check().
>*/
> struct {
> + /**
> + * @broadcast_rgb: Connector property to pass the
> + * Broadcast RGB selection value.
> + */
> + enum drm_hdmi_broadcast_rgb broadcast_rgb;
> +
> /**
>* @output_bpc: Bits per color channel to output.
>*/
> unsigned int output_bpc;
>
> @@ -1751,10 +1780,16 @@ struct drm_connector {
>* @privacy_screen_hw_state_property: Optional atomic property for the
>* connector to report the actual integrated privacy screen state.
>*/
> struct drm_property *privacy_screen_hw_state_property;
>
> + /**
> + * @broadcast_rgb_property: Connector property to set the
> + * Broadcast RGB selection to output with.
> + */
> + struct drm_property *broadcast_rgb_property;
> +
> #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
>
> /**
> @@ -2090,10 +2125,11 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mode_mask);
> int drm_connector_attach_vrr_capable_property(
> struct drm_connector *connector);
> +int drm_connector_attach_broadcast_rgb_property(struct drm_connector
> *connector);
> int drm_connector_attach_colorspace_property(struct drm_connector
> *connector);
> int drm_connector_attach_hdr_output_metadata_property(struct drm_connector
> *connector);
> bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state
> *old_state,
>struct drm_connector_state
> *new_state);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>
> --
> 2.44.0
--
Ville Syrjälä
Intel
_bpc);
> + old_conn_state->max_requested_bpc,
> + new_conn_state->max_requested_bpc);
>
> ret = drm_atomic_check_only(state);
> KUNIT_ASSERT_EQ(test, ret, 0);
>
> old_conn_state = drm_atomic_get_old_connector_s
++ b/include/drm/display/drm_hdmi_helper.h
> @@ -22,6 +22,10 @@ drm_hdmi_infoframe_set_hdr_metadata(struct
> hdmi_drm_infoframe *frame,
> const struct drm_connector_state
> *conn_state);
>
> void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
>const struct drm_connector_state
> *conn_state);
>
> +unsigned long long
> +drm_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> + unsigned int bpc, enum hdmi_colorspace fmt);
> +
> #endif
>
> --
> 2.44.0
--
Ville Syrjälä
Intel
On Wed, Apr 10, 2024 at 06:25:17PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 10, 2024 at 12:06:29PM +0300, Tomi Valkeinen wrote:
> > On 08/04/2024 20:04, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > __iowmb() isn't available on most arch
On Wed, Apr 10, 2024 at 12:06:29PM +0300, Tomi Valkeinen wrote:
> On 08/04/2024 20:04, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > __iowmb() isn't available on most architectures. Make
> > its use optional so that the driver can be built on
> > o
is that struct drm_edid_product_id and struct
> lvds_pnp_id describe identical data, albeit with slightly different
> member definitions.
>
> Cc: Ville Syrjälä
> Acked-by: Melissa Wen
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 43 ++
> *connector,
> const struct drm_edid *edid);
> int drm_edid_connector_add_modes(struct drm_connector *connector);
> bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> +void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> + struct drm_edid_product_id *id);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
nnector_add_modes(struct drm_connector
> *connector);
> bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> struct drm_edid_product_id *id);
> +void drm_edid_print_product_id(struct drm_printer *p,
> +const struct drm_edid_product_id *id, bool raw);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Mon, Apr 08, 2024 at 09:46:44AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.24 um 21:58 schrieb Ville Syrjälä:
> > On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
On Mon, Apr 08, 2024 at 08:04:20PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow omapdrm to be built with COMPILE_TEST=y for greater
> coverage.
>
> FIXME: Still borked due to ?
In fact not borked anymore. Just forgot to update
the commit message.
>
f modes, in the right drm debug
> category, and inline with the rest of the logging instead of split to
> multiple lines.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 6 +++---
>
->dev, hweight32(connector->possible_encoders) >
> 1);
> drm_connector_for_each_possible_encoder(connector, encoder)
> return encoder;
>
> @@ -564,8 +566,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> int ret;
On Fri, Apr 05, 2024 at 11:39:33PM +0300, Dmitry Baryshkov wrote:
> On Fri, 5 Apr 2024 at 22:17, Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> > > On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
On Fri, Apr 05, 2024 at 11:23:01AM +0300, Jani Nikula wrote:
> On Thu, 04 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Switch to the canonical [CONNECTOR:%d:%s] etc. format for
> > printing out kms objects.
>
> I've been pinging for revie
On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > Get rid of all the redundant debugs and just wait until the end
> > to print which mode (and of which type)
On Fri, Apr 05, 2024 at 06:32:46AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 04, 2024 at 11:33:28PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > crtc->mode is legacy junk and shouldn't really be used with
> > atomic drivers.
> >
>
On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The modes[] array contains pointers to modes on the connectors'
> > mode lists, which are pro
just at the end of it.
All this seems pretty much redundant. We already have
DRM_MODE_FMT/ARGS so people can include the mode in any
kind of format string they want.
I would just nuke drm_mode_print() and all its ilk and
let people format things themselves.
--
Ville Syrjälä
Intel
ot;customized" naming, but we need to reach
> an agreement.
>
> I raised the same question to Wolfram.
I don't know where that discussion happened, but my opinion
is NAK to "client". Life is already confusing enough with
these renames, so let's not make it even more confusing by
inventing new names nowhere to be found in the spec.
And let's especially not invent names that don't even fit
the purpose. "Client" makes me think of "client/server" or
some real world analogy. Neither of which seem to have any
resemblence to how the term would be used for i2c.
--
Ville Syrjälä
Intel
t; +
> switch (type) {
> case hwmon_energy:
> return hwm_energy_read(ddat, attr, val);
> @@ -850,5 +865,14 @@ void i915_hwmon_register(struct drm_i915_private *i915)
>
> void i915_hwmon_unregister(struct drm_i915_private *i915)
> {
> + struct i915_hwmon *hwmon = i915->hwmon;
> + struct intel_gt *gt;
> + int i;
> +
> + for_each_gt(gt, i915, i)
> + fetch_and_zero(&hwmon->ddat_gt[i].uncore);
> +
> + fetch_and_zero(&hwmon->ddat.uncore);
> +
> fetch_and_zero(&i915->hwmon);
> }
> --
> 2.43.0
--
Ville Syrjälä
Intel
On Mon, Mar 18, 2024 at 10:44:06PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Final final version I hope. Mainly for CI to test against the
> new IGTs.
>
> Real userspace implementation:
> https://gitlab.gnome.org/GNOME/mutter/
On Mon, Mar 18, 2024 at 02:49:47PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Mar 15, 2024 at 10:22:05AM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 11, 2024 at 03:49:48PM +0100, Maxime Ripard wrote:
> > > Infoframes in KMS is usually handled by a bunch of low-level he
l the defconfigs in drm-rerere also seem to fail here.
Neil, are you using some weird .config, or did you not actually
build test this before pushing?
PS. the drm-rerere defconfigs seem pretty outdated (eg. missing
tons of panel drivers). Would be good if someone could update
those to provide better coverage
--
Ville Syrjälä
Intel
On Mon, Mar 18, 2024 at 01:05:22PM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> Thanks for your review !
>
> On Fri, Mar 15, 2024 at 10:05:16AM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 11, 2024 at 03:49:42PM +0100, Maxime Ripard wrote:
> > > +static bool
> &g
On Wed, Feb 28, 2024 at 10:12:28AM +, Simon Ser wrote:
> On Tuesday, February 27th, 2024 at 20:35, Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > Add a new immutable plane property by which a plane can advertise
> > a handful of recommended
1 - 100 of 1421 matches
Mail list logo
