", 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
p;& !obj_free_cb);
> + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb &&
> obj_type != DRM_MODE_OBJECT_PROPERTY);
>
> mutex_lock(>mode_config.idr_mutex);
> ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
> --
> 2.43.0
--
Ville Syrjälä
Intel
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
ach
> 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; ncrtcs; i++)
> + ((u32 *)__get_dynamic_array(crtcs))[i] = crtcs[i];
> + __entry->ncrtcs = ncrtcs;
> + __entry->flags = flags;
> + ),
> + TP_printk("file=%p, pid=%8d, flags=%08x, crtcs=%s", __entry->file,
> + pid_nr(__entry->file->pid), __entry->flags,
> + __print_array(__get_dynamic_array(crtcs),
> __entry->ncrtcs, 4))
> +);
> +
> #endif /* _DRM_TRACE_H_ */
>
> /* This part must be outside protection */
> --
> 2.40.1
--
Ville Syrjälä
Intel
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> On 2/14/2024 17:13, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the
+ /**
> + * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> + * This is only applicable to eDP and LVDS displays.
> + */
> + bool acpi_edid_allowed;
Aren't there other bools/small stuff in there for tighter packing?
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7923bc00dc7a..1c1ee927de9c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -459,5 +459,6 @@ bool drm_edid_is_digital(const struct drm_edid *drm_edid);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector);
>
> #endif /* __DRM_EDID_H__ */
> --
> 2.34.1
--
Ville Syrjälä
Intel
On Wed, Jan 24, 2024 at 11:14:40AM -0300, André Almeida wrote:
> Hi Ville,
>
> Em 19/01/2024 15:25, Ville Syrjälä escreveu:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
>
{
> .atomic_duplicate_state = amdgpu_dm_plane_drm_plane_duplicate_state,
> .atomic_destroy_state = amdgpu_dm_plane_drm_plane_destroy_state,
> .format_mod_supported = amdgpu_dm_plane_format_mod_supported,
> + .check_async_props = amdgpu_dm_plane_check_async_props,
> };
>
> int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,
> --
> 2.43.0
--
Ville Syrjälä
Intel
t;pbn_div.full =
> dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
Why doesn't that dfixed stuff return the correct type?
Anyways looks mostly mechanical
Reviewed-by: Ville Syrjälä
>
> if (!state->duplicated) {
> int max_bpc = conn_sta
On Mon, Oct 16, 2023 at 10:00:51PM +, Simon Ser wrote:
> On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
> wrote:
>
> > On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote:
> >
> > > On Mon, 16 Oct 2023 15:42:16 +0200
> > > And
:
> >
> > Flipping to the same FB_ID will result in a immediate flip as if it was
> > changing to a different one, with no effect on the image but effecting
> > the reported frame rate.
>
> Re-setting FB_ID to its current value is a special case regardless of
> PAGE_FLIP_ASYNC, is it not?
No. The rule has so far been that all side effects are observed
even if you flip to the same fb. And that is one of my annoyances
with this proposal. The rules will now be different for async flips
vs. everything else.
The other issues (mainly relating to hardware where not all planes
support async flips) I've already highlighted in some earlier mail.
--
Ville Syrjälä
Intel
>
> + /* BenQ GW2765 */
> + EDID_QUIRK('B', 'N', 'Q', 0x78d6, EDID_QUIRK_FORCE_8BPC),
> +
> /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc
> panel */
> EDID_QUIRK('B', 'O', 'E', 0x78b, EDID_QUIRK_FORCE_6BPC),
>
> --
> 2.42.0
--
Ville Syrjälä
Intel
eau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1336,6 +1336,8 @@ nv50_mstm_service(struct nouveau_drm *drm,
> if (!handled)
> break;
>
> + /* MSG_RDY ack is done in drm*/
> + esi[1] &= ~(DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY);
> rc = drm_dp_dpcd_write(aux, DP_SINK_COUNT_ESI + 1, [1],
> 3);
> if (rc != 3) {
> --
> 2.37.3
--
Ville Syrjälä
Intel
On Fri, Mar 17, 2023 at 07:47:52PM +0100, Sebastian Wick wrote:
> On Fri, Mar 17, 2023 at 7:38 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote:
> > > On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
> > > wrote:
On Fri, Mar 17, 2023 at 06:40:53PM +0100, Sebastian Wick wrote:
> On Fri, Mar 17, 2023 at 5:34 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> > > On Fri, 17 Mar 2023 16:14:38 +0200
> > > Ville Syrjälä wrote
On Fri, Mar 17, 2023 at 05:37:51PM +0200, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 16:14:38 +0200
> Ville Syrjälä wrote:
>
> > On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> > > On Fri, 17 Mar 2023 14:50:40 +0200
> > > Ville Syrjälä wrote
On Fri, Mar 17, 2023 at 03:35:53PM +0200, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 14:50:40 +0200
> Ville Syrjälä wrote:
>
> > On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> > > On Fri, 17 Mar 2023 01:01:38 +0200
> > > Ville Syrjälä wrote
On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
> On Fri, 17 Mar 2023 01:01:38 +0200
> Ville Syrjälä wrote:
>
> > On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> > > On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> > > wrote:
On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> wrote:
> >
> > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > Ville Syrjälä wrote
On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> On Thu, 16 Mar 2023 12:47:51 +0200
> Ville Syrjälä wrote:
>
> > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > Ville Syrjälä wrote
On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> On Thu, 16 Mar 2023 11:50:27 +0200
> Ville Syrjälä wrote:
>
> > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland
> > >
> + } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > + connector_type == DRM_MODE_CONNECTOR_eDP) {
> > + if
> > (!drm_mode_create_dp_colorspace_property(>base,
> > supported_colorspaces))
> > +
> > drm_connector_attach_colorspace_property(>base);
> > + }
> > +
> > if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > connector_type == DRM_MODE_CONNECTOR_eDP) {
> > --
> > 2.39.2
> >
--
Ville Syrjälä
Intel
On Fri, Mar 10, 2023 at 07:48:04PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2023 at 04:30:27PM -0500, Hamza Mahfooz wrote:
> > We should be checking if drm_dp_dpcd_read() returns the size that we are
> > asking it to read instead of just checking if it is greater than zer
> 0;
> + return !WARN_ON(drm_dp_dpcd_read(>dm_dp_aux.aux, address,
> + data, size) != size);
Just FYI there are devices out there that violate the DP spec and reads
from specific DPCD registers simply fail instead of returning the
expected 0.
> }
>
> bool dm_helpers_dp_write_dpcd(
> --
> 2.39.2
--
Ville Syrjälä
Intel
; > - leave BT2020_RGB the new default BT2020
> > >
> > > Signed-off-by: Joshua Ashton
> > > Signed-off-by: Harry Wentland
> > > Reviewed-by: Harry Wentland
> > >
> > > Cc: Pekka Paalanen
> > > Cc: Sebastian Wick
>
On Wed, Feb 15, 2023 at 12:01:25PM +0200, Pekka Paalanen wrote:
> On Tue, 14 Feb 2023 22:10:35 +0200
> Ville Syrjälä wrote:
>
> > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
>
> ...
>
> > > We also have to figure out how a user space which
On Tue, Feb 14, 2023 at 10:18:49PM +0100, Sebastian Wick wrote:
> On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
> > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland
> > > wrote:
On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
> On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
> >
> >
> >
> > On 2/14/23 10:49, Sebastian Wick wrote:
> > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
> > > wrote:
> >
> This is probably a complex problem, so there should be no need to solve
> it before a 3D LUT interface can land, given old elements already have
> the issue.
Yeah, I think all the precision stuff is all better handled by
eg. the proposed GAMMA_MODE property or something similar.
It's going to be needed for 1D LUTs as well. 1D LUTs would
also need it to expose diffrent LUT sizes with different
precision tradeoffs.
As for the 3D LUT blob, I don't think the blob needs any
strides/etc. either. I had none of that for my i915 version:
https://github.com/vsyrjala/linux/commits/3dlut
Just the LUT entries + blob size is sufficient. At least
for cube shaped LUTs. Dunno if anyone would have a need
for something else?
The two things the are absolutely needed:
- Position of the LUT in the pipeline. We've already
seen at least two variants of this IIRC, so we'll
likely need to define a unique property for each tap
point.
- The order the elements are stored in the blob. I didn't
check if all the already known hw (amdgpu, i915, rcar-du,
were there also others?) would agree on this or not.
If yes, maybe just follow the hw order for all those,
and if not, then I guess flip a few coins.
--
Ville Syrjälä
Intel
eople actually depend on that we should probably have tests to
make sure no one breaks it by accident.
--
Ville Syrjälä
Intel
On Wed, Feb 08, 2023 at 11:18:42AM +0200, Pekka Paalanen wrote:
> On Fri, 3 Feb 2023 16:02:51 +0200
> Ville Syrjälä wrote:
>
> > On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote:
> > > On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä
> > > wrote:
>
On Sat, Feb 04, 2023 at 06:09:45AM +, Joshua Ashton wrote:
>
>
> On 2/3/23 19:34, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote:
> >> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
> >>> On Fri, Feb
On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
> > >
> > >
> > > On 2/3/23 11:00, Ville Syrjälä wrote:
> &
On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
> >
> >
> > On 2/3/23 11:00, Ville Syrjälä wrote:
> > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> > >
On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 11:00, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> >>
> >>
> >> On 2/3/23 10:19, Ville Syrjälä wrote:
> >>> On
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 10:19, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
> >>
> >>
> >> On 2/3/23 07:59, Sebastian Wick wrote:
> >>> On F
On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 07:59, Sebastian Wick wrote:
> > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> > wrote:
> >>
> >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
> >>
On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote:
> On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Feb 03, 2023 at 01:59:07PM +0100, Sebastian Wick wrote:
> > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> > > wrote:
On Fri, Feb 03, 2023 at 01:59:07PM +0100, Sebastian Wick wrote:
> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
> > > Userspace has no way of controlling or knowing the pixel e
ectively 'removed' by this change, but that was not
> possible to be taken advantage of anyway, as there is currently no
> pixel_encoding control so it would not be possible to output
> linear YCbCr.
>
> Signed-off-by: Joshua Ashton
>
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: v
On Fri, Jan 13, 2023 at 04:11:48PM +0100, Sam Ravnborg wrote:
> Hi Ville,
> On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > > Include in source files that need it. Some of DRM's
&
modifier
> 0x%llx\n",
> + >pixel_format, r->modifier[0]);
> + return -EINVAL;
> + }
Like I said this is still wrong for the !modifiers case.
> +
> return 0;
> }
>
> --
> 2.39.0
--
Ville Syrjälä
Intel
gt; diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> index a8a98c91b13c..866d1bf5530e 100644
> --- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> +++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> --
> 2.39.0
--
Ville Syrjälä
Intel
mann
Reviewed-by: Ville Syrjälä
> ---
> include/drm/drm_fb_helper.h | 5 -
> include/drm/drm_modeset_helper_vtables.h | 6 +-
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
&
gt; #include
> #include
^ bunch of other unnecessary headers there as well.
Reviewed-by: Ville Syrjälä
>
> -#include
> -
> #include
> #include
> #include
> --
> 2.39.0
--
Ville Syrjälä
Intel
o that we can test some more experimental stuff which is
hidden behind BROKEN for normal users.
> + depends on BROKEN # chicken-egg initial enable problem
> depends on DRM
> depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> depends on JUMP_LABEL
> --
> 2.38.1
--
Ville Syrjälä
Intel
On Mon, Oct 31, 2022 at 08:20:54PM -0400, Jason Baron wrote:
>
>
> On 10/31/22 6:11 PM, jim.cro...@gmail.com wrote:
> > On Mon, Oct 31, 2022 at 7:07 AM Ville Syrjälä
> > wrote:
> >> On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> >>
On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 2:10 PM Ville Syrjälä
> wrote:
> >
> > On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> >
On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> wrote:
> >
> > On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at
On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
> >
> >
> >
> > On 10/21/22 05:18, Jani Nikula wrote:
> > > On Thu, 20 Oct 2022, Ville Syrjälä wrote:
> > >> On Sat,
commits of V6 on which Dan gave his Reviewed-by.
> >
> > If these are good to apply, I'll rebase and repost the rest separately.
>
> All now queued up, thanks.
This stuff broke i915 debugs. When I first load i915 no debug prints are
produced. If I then go fiddle around in /sys/module/drm/parameters/debug
the debug prints start to suddenly work.
--
Ville Syrjälä
Intel
On Mon, Oct 03, 2022 at 11:48:49AM +0300, Pekka Paalanen wrote:
> On Fri, 30 Sep 2022 18:45:09 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> > > On Fri, 30 Sep 2022 18:09:55 +0300
> > > Ville Syrjälä w
On Fri, Sep 30, 2022 at 06:45:09PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> > On Fri, 30 Sep 2022 18:09:55 +0300
> > Ville Syrjälä wrote:
> >
> > > That would actively discourage people from even attempting the
On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> On Fri, 30 Sep 2022 18:09:55 +0300
> Ville Syrjälä wrote:
>
> > That would actively discourage people from even attempting the
> > "just dump all the state into the ioctl" approach with async flips
On Fri, Sep 30, 2022 at 05:19:07PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 30, 2022 at 04:52:56PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 29, 2022 at 06:43:15PM +, Simon Ser wrote:
> > > This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> > > co
On Fri, Sep 30, 2022 at 04:52:56PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 29, 2022 at 06:43:15PM +, Simon Ser wrote:
> > This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> > commits, aka. "immediate flip" (which might result in tearing).
> >
On Fri, Sep 30, 2022 at 01:56:25PM +, Simon Ser wrote:
> On Friday, September 30th, 2022 at 15:53, Ville Syrjälä
> wrote:
>
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > &
m/nouveau/nouveau_display.c | 1 +
> drivers/gpu/drm/vc4/vc4_kms.c | 1 +
> include/drm/drm_mode_config.h | 11
> include/uapi/drm/drm.h| 10 ++-
> include/uapi/drm/drm_mode.h | 16 +++
> 11 files changed, 88 insertions(+), 4 deletions(-)
>
> --
> 2.37.3
>
--
Ville Syrjälä
Intel
hton
> Cc: Melissa Wen
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 +
> drivers/gpu/drm/i915/display/intel_display.c |
herefore a failing async flip cannot prepare the next flip
> > to be async, meaning async will never work.
>
> I'd blame it on bad hw, and make it one special quirk in the driver,
> just like it does now.
>
> Ville, thoughts?
I suppose it might be worth mentioning that special case here,
to avoid people getting confused why the first async flip was
accepted but took a full frame to complete.
--
Ville Syrjälä
Intel
On Tue, Aug 30, 2022 at 11:40:10AM +0300, Pekka Paalanen wrote:
> On Tue, 30 Aug 2022 11:08:22 +0300
> Ville Syrjälä wrote:
>
> > On Mon, Aug 29, 2022 at 04:01:44PM +, Simon Ser wrote:
> > > On Friday, August 26th, 2022 at 10:19, Ville Syrjälä
> > > wrote
On Mon, Aug 29, 2022 at 04:01:44PM +, Simon Ser wrote:
> On Friday, August 26th, 2022 at 10:19, Ville Syrjälä
> wrote:
>
> > On Wed, Aug 24, 2022 at 03:08:55PM +, Simon Ser wrote:
> > > This new kernel capability indicates whether async page-flips are
> > &
E 0x14
> +/**
> + * DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
> + *
> + * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC for atomic
> + * commits.
> + */
> +#define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP 0x15
>
> /* DRM_IOCTL_GET_CAP ioctl argument type */
> struct drm_get_cap {
> --
> 2.37.2
>
--
Ville Syrjälä
Intel
amma LUT in the pipeline, which is
where I placed it in my branch.
There is now some discussion happening about exposing some
kind of color pipeline description/configuration properties:
https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11
--
Ville Syrjälä
Intel
(*sads)[j].channels = sad[0] & 0x7;
> @@ -4897,6 +4878,9 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
> **sads)
> break;
> }
> }
> + cea_db_iter_end();
> +
> + DRM_DEBUG_KMS("Found %d Short Audio Descriptors\n", count);
>
> return count;
> }
> --
> 2.30.2
--
Ville Syrjälä
Intel
On Wed, Mar 23, 2022 at 01:39:44PM +0300, Dmitry Baryshkov wrote:
> On 22/03/2022 01:37, Ville Syrjälä wrote:
> > On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
> >> On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
> >> wrote:
> >>>
> &g
On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
> On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
> > > drm: Add drm_mode_init()
> > > drm/bridge: Use
de_init() for on-stack modes
> drm/rockchip: Use drm_mode_copy()
> drm/sti: Use drm_mode_copy()
> drm/tilcdc: Use drm_mode_copy()
> drm/i915: Use drm_mode_init() for on-stack modes
> drm/i915: Use drm_mode_copy()
> drm: Use drm_mode_init() for on-stack modes
> drm: Use drm_mode_copy()
--
Ville Syrjälä
Intel
> + dev->mode_config.panel_orientation_property = prop;
Leak when called multiple times. I guess you could just put
this into drm_connector_create_standard_properties() instead
and avoid that issue entirely.
--
Ville Syrjälä
Intel
und 0x%x\n",
> @@ -162,7 +162,7 @@ static int check_partial_mapping(struct
> drm_i915_gem_object *obj,
> }
> *cpu = 0;
> drm_clflush_virt_range(cpu, sizeof(*cpu));
> - kunmap(p);
> + kunmap_local(cpu);
>
> out:
> __i915_vma_put(vma);
--
Ville Syrjälä
Intel
t;> PAGE_SHIFT;
> + start = max(start, range->start) >> PAGE_SHIFT;
> last = (last < (range->end - 1) ? last : range->end - 1) >> PAGE_SHIFT;
There's an open coded min() on the very next line.
> pr_debug("[0x%lx 0x%lx] range[0x%lx 0x%lx] notifier[0x%lx 0x%lx] %d\n",
>start, last, range->start >> PAGE_SHIFT,
> --
> 1.8.3.1
--
Ville Syrjälä
Intel
On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 02, 2021 at 03:59:32PM +0
On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(stru
t; - if (pipe_config->port_clock > 34) {
> + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) {
> pipe_config->hdmi_scrambling = true;
> pipe_config->hdmi_high_tmds_clock_ratio = true;
> }
All of that is HDMI 2.0 stuff. So this just makes it all super
confusing IMO. Nak.
--
Ville Syrjälä
Intel
On Fri, Oct 22, 2021 at 03:01:52PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote:
> > On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
&g
On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote:
> On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
> > > drm_get_edid() internally calls to drm_connector_up
intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> connector->display_info.is_hdmi;
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
> connector->display_info.is_hdmi;
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
--
Ville Syrjälä
Intel
ev, "%s: EDID invalid.\n",
> + connector->name);
Could you respin this to use the standard [CONNECTOR:%d:%s] form
while at it? Or I guess a patch to mass convert the whole drm_edid.c
might be another option.
Patch looks good.
Reviewed-by: Ville Syrjälä
> return 0;
> }
>
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > According to the documentation, drm_add_edid_modes
> > > "...
;
> A helper like this belongs in drm, not i915. Seems useful in other
> drivers too.
Not sure it's actually helpful for i915. We end up having to root around
in the display_info in a lot of places anyway. So a helper for single
boolean seems a bit out of place perhaps.
--
Ville Syrjälä
Intel
nnector->is_hdmi) {
> - intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> intel_connector_is_hdmi_monitor(connector);
FYI there's a third copy of this in intel_dp.c
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
--
Ville Syrjälä
Intel
drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
> return 0;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
ant
changes coming in via drm-misc they usually will cause conflicts for
people during drm-tip rebuild. Also I would expect to see an ack
requested from i915 maintainers for merging anything significant via
drm-misc, which I don't think happened in this case.
--
Ville Syrjälä
Intel
On Sat, Oct 02, 2021 at 07:28:02PM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> > On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 01, 2021 at 04:
On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > On F
On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > >
() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > drm/gma500: cleanup: drm_modeset_lock_all() -->
On Tue, Jun 08, 2021 at 07:19:31PM +0200, Werner Sembach wrote:
>
> Am 07.06.21 um 22:33 schrieb Werner Sembach:
> > Am 07.06.21 um 08:47 schrieb Werner Sembach:
> >>
> >> Am 04.06.21 um 19:30 schrieb Ville Syrjälä:
> >>> On Fri, Jun 04, 2021
n entirely different driver that
> has no dependency on the HDMI controller one.
>
> I think it would be best to do that assignment in atomic_check. That
> way, if the userspace does a commit with DRM_MODE_ATOMIC_TEST_ONLY it
> would know what the output state would have been like.
DRM_MODE_ATOMIC_TEST_ONLY isn't allowed to change anything.
--
Ville Syrjälä
Intel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Mon, Jun 07, 2021 at 08:46:47AM +0200, Werner Sembach wrote:
>
> Am 04.06.21 um 19:26 schrieb Ville Syrjälä:
> > On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach wrote:
> >> Add a new general drm property "active bpc" which can be used by graph
drm_object_attach_property(>base,
>
> connector->dev->mode_config.hdr_output_metadata_property, 0);
>
> - if (!HAS_GMCH(dev_priv))
> + if (!HAS_GMCH(dev_priv)) {
> drm_connector_attach_max_bpc_property(connector, 8, 12);
> + drm_connector_attach_active_bpc_property(connector, 8, 12);
> + }
> }
>
> /*
> --
> 2.25.1
--
Ville Syrjälä
Intel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
t; + */
> + struct drm_property *active_bpc_property;
> +
> #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_wi
On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> On Wed, 12 May 2021 16:04:16 +0300
> Ville Syrjälä wrote:
>
> > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
> > > Hello,
> > >
> > > In addition to the existing &qu
up to implement it.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the
> concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the best way to store the new vendor agnostic settings?
On Sat, Mar 20, 2021 at 04:09:47AM +0200, Ville Syrjälä wrote:
> On Fri, Mar 19, 2021 at 10:45:10PM +0100, Mario Kleiner wrote:
> > On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wro
On Mon, Apr 26, 2021 at 02:56:26PM -0400, Harry Wentland wrote:
> On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
> > On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> >> From: Bhawanpreet Lakha
> >>
> >> Add the following color encodings
> >
a LUTs for each plane.
But considering how poor the current gamma uapi is we've thrown
around some ideas how to allow the kernel to properly expose the
hw capabilities. This is one of those ideas:
https://lists.freedesktop.org/archives/dri-devel/2019-April/212886.html
I think that basic idea could be also
1 - 100 of 202 matches
Mail list logo
