cled off and directly on again in quick
> > succession.
> >
> > Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
> > call to avoid the panel staying black after a quick off + on cycle.
> >
> > Cc: Ville Syrjälä
> > Fixes: fe0f1e3bfdfe
; + * @format_type_ptr: Pointer to ``__u32`` array of formats that are
> + * supported by the plane. These formats do not require modifiers.
> + */
> __u64 format_type_ptr;
> };
>
> --
> 2.31.1
>
> ________
t; + * must use the plane IN_FORMATS blob property.
>*/
Addfb2+modifiers predates the IN_FORMATS blob, so this doesn't
match reality.
> __u64 format_type_ptr;
> };
> --
> 2.31.1
>
> __________
On Wed, Apr 07, 2021 at 03:50:35PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/7/21 2:34 PM, Ville Syrjälä wrote:
> > On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/25/21 12:48 PM, Hans de Goede wrote:
> >>&
internal sentinel value to
> > denote end-of-array entries.
> >
> > In practice it wont pass because we validate the modifiers against the
> > advertised list.
We don't actually. If the driver provides the .format_mod_supported()
hook then it's up to the driver to va
er find.F;
position PA;
@@
F(...) {
<+...
ALLOC@PA(...)
...+>
}
@script:python depends on alloc@
ps << find.PS;
pa << alloc.PA;
@@
coccilib.report.print_report(ps[0], "struct")
coccilib.report.print_report(pa[0], "alloc")
That could of course miss a b
amp;sep, ","));) {
> bool enable = true;
> @@ -86,7 +85,6 @@ static int mitigations_set(const char *val, const struct
> kernel_param *kp)
> break;
> }
> }
> - kfree(str);
> if (err)
> return err;
>
> --
> 2.31.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Apr 16, 2021 at 06:27:23PM +0200, Mario Kleiner wrote:
> On Mon, Mar 22, 2021 at 4:52 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Mar 19, 2021 at 10:03:12PM +0100, Mario Kleiner wrote:
> > > Hi,
> > >
> > > this patch series adds the fourcc'
r a while now we've tried to
move towards an architecture where the driver is fully initialzied
before anything gets exposed to userspace.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Apr 21, 2021 at 01:20:31PM +0800, Kai-Heng Feng wrote:
> Screen flickers on Innolux eDP 1.3 panel when clock rate 54 is in use.
>
> According to the panel vendor, though clock rate 54 is advertised,
> but the max clock rate it really supports is 27.
>
On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> On Wed, Apr 21, 2021 at 06:34:01PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we try to detect a symmetric memory configurations
> > using a magic DCC2_MODIFIED_ENHANC
On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> On Wed, Apr 21, 2021 at 06:34:01PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we try to detect a symmetric memory configurations
> > using a magic DCC2_MODIFIED_ENHANC
o discover which “_DSM” Functions are
supported. It may only return success if the return value accurately
lists supported Functions."
But what you're apparently saying is that calling this changes
the behaviour of the system somehow? That is troubling.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm_object_attach_property(&connector->base, prop,
> - info->panel_orientation);
> + drm_object_property_set_value(&connector->base, prop,
> + info->panel_orientation);
> return 0;
> }
> EXPORT_SYMBOL(drm_connector_set_panel_orientation);
> --
> 2.31.1.498.g6c1eba8ee3d-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Apr 26, 2021 at 07:10:06PM +0800, Kai-Heng Feng wrote:
> On Fri, Apr 23, 2021 at 8:41 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 23, 2021 at 12:46:54PM +0800, Kai-Heng Feng wrote:
> > > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 21, 2021 at 06:34:01PM +0300, Ville Syrjala wrote:
> >
le degamma/gamma 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
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
> >
explicitly?
Looks like you missed auto_retire()?
> intel_overlay_last_flip_retire(struct i915_active *active)
> {
> struct intel_overlay *overlay =
> --
> 2.30.2
>
> ___
> dri-devel mailing list
> dri
On Thu, Apr 29, 2021 at 07:31:43PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > __i915_active_call annotation is required on the retire callback to ensure
> > correct function alignm
> drm_gem_object_put(objs[i]);
> ret = -EINVAL;
> goto err_gem_object_put;
> --
> 2.31.1
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/
ed = ret;
> +
> + ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state, true);
> + if (ret)
> + return ret;
> +
> + if (pipe_config->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> +
pcd) ||
> - dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
> - !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + if (!drm_dp_is_branch(dpcd) || dpcd[DP_DPCD_REV] < DP_DPCD_REV_10)
BTW that DPCD_REV check looks rather wrong.
Reviewed-by: Ville Syrjälä
>
* some branches do it we need to handle it regardless.
> + */
> len = drm_dp_downstream_port_count(dpcd);
> + if (!len)
> + return 0;
> +
Seems sane enough.
Reviewed-by: Ville Syrjälä
> if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INF
figuration, and typically on older panels
> + * these values correspond to the native resolution of the
> + * panel.
>*/
> limits.min_lane_count = limits.max_lane_count;
> limits.min_clock = limits.max_clock;
> --
> 2.31.1
--
Ville Syrjälä
Intel
generally designed to support only a single
> + * clock and lane configuration, and typically on older panels
> + * these values correspond to the native resolution of the
> + * panel.
>*/
> limits.min_lane_count = limits.max_lane_count;
> limits.min_clock = limits.max_clock;
> --
> 2.32.0
--
Ville Syrjälä
Intel
return 135;
> + case DP_LINK_BW_20:
> + return 200;
> + default:
> + /* Spec says link_rate = link_bw * 0.27Gbps */
> + return link_bw * 27000;
> + }
> }
> EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
IZE])
> {
> - u8 dpcd_ext[6];
> + u8 dpcd_ext[DP_MAIN_LINK_CHANNEL_CODING + 1];
Why are we even reading less of this than the normal receiver caps?
> int ret;
>
> /*
> --
> 2.20.1
--
Ville Syrjälä
Intel
On Wed, Aug 18, 2021 at 09:10:39PM +0300, Jani Nikula wrote:
> The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
> vswing and pre-emphasis.
>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gp
). Anyway, looking into it again the first bad commit is
>
> ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
>
> With that commit the display is not detected anymore, one commit
> before that it still works. So this one seems to be broken.
>
> Ville,
l back to the old max strategy on failure")
> Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
> everything")
> Suggested-by: Ville Syrjälä
> Signed-off-by: Kai-Heng Feng
Slapped a cc:stable on it and pushed to drm-intel-next. Thanks.
> -
Only to avoid
> unused-but-set-variable warning */, 1))
In this case you can just switch the code to use
for_each_old_plane_in_state() instead.
>
> /**
> * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an
> atomic
> --
> 2.27.0
>
> ______
gt; > > > we are discussing the topic, such checks would be really nice. I'm
> > > > > curious if such checks already exist.
> > >
> > >
> > > Thanks,
> > > pq
> > >
> > > > > > > > ---
> > >
On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > So basically we see this warning only in case of bigjoiner when
> >
0] x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616 fourcc_code('A', 'R', '4', '8') /*
> [63:0] A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616 fourcc_code('A', 'B', '4', '8') /*
> [63:0] A:B:G:R 16:16:16:16 little endian */
These look reasonable enough to me. IIRC we should be able to expose
them on some recent Intel hw as well.
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 04:56:24PM +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 wrote:
> > > These are 16 bits per color channel unsigned normalized formats.
>
commit/a25d4802074b13a8d5f7edc96ae45469ecbac3c4
We should also add support for these formats into igt.a Should
be semi-easy by just adding the suitable float<->uint16
conversion stuff.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@li
e possible to get this information in here instead
> to all the vlv with dsi...
>
> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>
> Jani?
> Ville?
We need to figure out why the panel doesn't start up again. If it has
problems with this then
On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> >> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> >>> Hi,
&g
On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> >>
On Tue, Mar 23, 2021 at 11:39:09AM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/2/21 3:51 PM, Ville Syrjälä wrote:
> > On Tue, Mar 02, 2021 at 01:00:40PM +0100, Hans de Goede wrote:
> >> As explained by a long comment block, on VLV intel_setup_outputs()
> >> somet
On Wed, Mar 24, 2021 at 03:10:59PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/24/21 3:02 PM, Ville Syrjälä wrote:
> > On Tue, Mar 23, 2021 at 11:39:09AM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/2/21 3:51 PM, Ville Syrjälä wrote:
> >>
we restore fence registers
>
> This means that a global reset also thrashes mmaps, but it's a global
> reset we're talking about here, everything is thrash anyway. Plus/minus
> fenced gtt mmaps really doesn't change the tally.
My recollection is that GPU reset doesn&#x
> Like, we have intel_print_wm_latency() for debug logging and
> wm_latency_show() for debugfs, and there's a bunch of duplication and
> ugh.
There is all this ancient stuff in review limbo...
https://patchwork.freedesktop.org/series/50802/
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Mar 24, 2021 at 06:16:44PM +0100, Daniel Vetter wrote:
> On Wed, Mar 24, 2021 at 07:15:36PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 24, 2021 at 06:00:12PM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 04:50:52PM +0100, Maarten Lankhorst wrote:
> > &g
On Thu, Mar 25, 2021 at 03:01:29PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 11:27:59PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > >
gh to convey the necessary information.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
Though after looking at the current users it looks to me like
we're missing some block length checks. In particular
drm_parse_tiled_block() looks suspect. Judging by what I wrote
in cea
On Mon, Mar 29, 2021 at 04:37:22PM +0300, Jani Nikula wrote:
> Avoid any confusion with High Dynamic Range. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_displayid.c | 10 +-
> include/drm/drm_displayid.
rm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
> - drm_connector_update_edid_property(connector, edid);
> return edid;
> }
> EXPORT_SYMBOL(drm_get_edid);
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
fiers = nouveau_display(dev)->format_modifiers;
> +
> + ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
> format, nformat,
> +format_modifiers, type, "%s-%d", name,
> index);
> if (ret)
t need the <... ...> style here? It's been a while since
I did any serious cocci so I'm getting a bit rusty on the details...
Otherwise looks great
Reviewed-by: Ville Syrjälä
> }
>
> @ adds_old_state @
> identifier plane_atomic_func.func;
> identifi
are 'state'
as
symbol moves_new_state_old_state.state;
That would probably make the intent a bit more obvious, even with
the dependency. Or does a dependency somehow automagically imply
that?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jan 25, 2021 at 11:52:18AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Fri, Jan 22, 2021 at 02:15:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> > > Some drivers are storing the plane->state p
we even check any of the client provided values, or do we?
EOTF I think we do check, but IMO that check should probably just be
nuked as well if we don't bother checking anything else.
I was in fact going to suggest nuking this entire hdr_sink_metadata
parsing as unused, but
t,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> - .format_mod_supported = drm_simple_kms_format_mod_supported,
This will now cause also this driver to repor
gt; The max source rate is:
>
> intel_dp->source_rates[intel_dp->num_source_rates - 1].
>
> No need to do the if ladder here at all. If you like, you can add a
> helper:
>
> int intel_dp_max_source_rate(struct intel_dp *intel_dp)
> {
> return intel_dp->source_rates[intel_dp->num_source_rates - 1];
> }
Using the max source rate isn't super great either. A bit better
than the current mess though.
The correct fix would be to let the driver provide the actually
used link_rate+lane_count to the MST code during atomic_check(),
instead of trying to guess what the driver is going to use.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jan 25, 2021 at 04:32:48PM +0100, Mario Kleiner wrote:
> On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä
> wrote:
>
> > On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > > The check was introduced to make sure that only the
> > > DRM_FORMA
truct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state, plane);
> ...
> }
>
> @ include depends on adds_new_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
&
>
> Here goes drm-intel-next-2021-01-27:
>
...
> - Async flips for all ilk+ platforms (Ville)
Not quite yet. Still missing one rb so couldn't push the full thing.
So still limited to skl+ I'm afraid.
--
Ville Syrjälä
Intel
l_dp_init_connector(struct intel_digital_port
> *dig_port,
> (temp & ~0xf) | 0xd);
> }
>
> + intel_dp->frl.is_trained = false;
> + intel_dp->frl.trained_rate_gbps = 0;
> +
> return true;
>
> fail:
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index b871a09b6901..58b76a20459c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -144,4 +144,6 @@ bool intel_dp_initial_fastset_check(struct intel_encoder
> *encoder,
> void intel_dp_sync_state(struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state);
>
> +void intel_dp_check_frl_training(struct intel_dp *intel_dp);
> +
> #endif /* __INTEL_DP_H__ */
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
msg->size, msg->buffer);
> + break;
> +
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> {
>
On Tue, Feb 02, 2021 at 12:09:47PM +0530, Nautiyal, Ankit K wrote:
> Hi Ville,
>
> Please find my responses inline.
>
> On 2/2/2021 2:08 AM, Ville Syrjälä wrote:
> > On Fri, Dec 18, 2020 at 04:07:17PM +0530, Ankit Nautiyal wrote:
> >> This patch adds function
he old
crtc to the state already.
>
> crtc_state->connector_mask &=
> ~drm_connector_mask(conn_state->connector);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://list
On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > drm_vblank_restore() exists because certain power saving states
> > can clobber the hardware frame count
On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >
> > On 01/02/2021 23:13, Ville Syrjälä wrote:
> > > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > >> From: Hans Verkuil
>
On Fri, Feb 05, 2021 at 02:46:44PM +0100, Hans Verkuil wrote:
> On 05/02/2021 14:24, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> >> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >>>
> >>> On 01/02/2021 23:1
On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> >
t to avoid using stale values */
> -
> memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
>
> + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14)
> + return;
> +
Can't check the spec, but makes sense that this stuff is only valid
fo
_ready_hpd);
> bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux);
> int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
> - bool concurrent_mode);
> + enum dp_pcon_frl_train_mode frl_mode);
> int drm_dp_pcon_frl_configure_2(struct drm_dp_aux *aux, int max_frl_mask,
> - bool extended_train_mode);
> + enum dp_pcon_frl_train_type frl_type);
> int drm_dp_pcon_reset_frl_config(struct drm_dp_aux *aux);
> int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
>
> --
> 2.29.2
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_dp->frl.trained_rate_gbps = 0;
If we don't need it in the ddi path we don't need it here.
Reviewed-by: Ville Syrjälä
> }
>
> static void g4x_disable_dp(struct intel_atomic_state *state,
> --
> 2.29.2
--
Ville Syrjälä
Intel
_
On Fri, Feb 05, 2021 at 12:07:41PM -0800, Navare, Manasi wrote:
> On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote:
> > > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E.
>
On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > > &
On Mon, Feb 08, 2021 at 10:56:36AM +0100, Daniel Vetter wrote:
> On Fri, Feb 05, 2021 at 11:19:19PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote:
> > > &
On Mon, Feb 08, 2021 at 06:43:53PM +0100, Daniel Vetter wrote:
> On Mon, Feb 8, 2021 at 5:58 PM Ville Syrjälä
> wrote:
> >
> > On Mon, Feb 08, 2021 at 10:56:36AM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 05, 2021 at 11:19:19PM +0200, Ville Syrjälä wrote:
> >
e hooked up and
> + * &drm_driver.vblank_disable_immediate must be set to indicate the
> + * time-stamping functions are race-free against vblank hardware counter
> + * increments.
Looks good. Might prevent someone from shooting themselves in
the foot.
Reviewed-by: Ville Sy
On Tue, Feb 09, 2021 at 11:07:53AM +0100, Daniel Vetter wrote:
> On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > drm_vblank_restore() exists because certain power saving states
> > can clobber the hardware frame count
re all crtcs
that are not logically enabled in the warn? Not sure if that
could allow something to slit through that people want it to
catch?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
(3 << 2)
> #define PIPEMISC_DITHER_TYPE_SP(0 << 2)
> @@ -7668,6 +7668,7 @@ enum {
> #define GAMMA_MODE_MODE_12BIT (2 << 0)
> #define GAMMA_MODE_MODE_SPLIT (3 << 0) /* ivb-bdw */
> #define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3
On Thu, Feb 11, 2021 at 04:14:02PM +, Daniel Stone wrote:
> On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
> wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset ==
> > >
ht we used in when passing it as an argument to
intel_get_hpd_pins(), but looks like that's not the case.
I guess we should unify this stuff by either removing both
these typedefs and adjusting intel_hpd_hotplug_enables()
accordingly, or we should use the typedef in intel_get_hpd_pins() as
well
ux->dev is there, could also use dev_dbg et al. in the mean time. They
> handle NULL dev gracefully too if the driver didn't set that.
Last I looked aux->dev was random. Some drivers point it at the
connector vs. some at the the pci/platform device.
--
Ville Syrjälä
Intel
___
On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_vblank_restore() exists because certain power saving states
> can clobber the hardware frame counter. The way it does this is
> by guesstimating how many frames were missed purely
On Fri, Feb 19, 2021 at 04:08:09PM +0100, Daniel Vetter wrote:
> On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > drm_vblank_restore() exists because certain power saving states
> > can clobber the hardware frame count
if (req_type == DP_CONNECTION_STATUS_NOTIFY ||
> - req_type == DP_RESOURCE_STATUS_NOTIFY)
> + req_type == DP_RESOURCE_STATUS_NOTIFY ||
> + req_type == DP_CLEAR_PAYLOAD_ID_TABLE)
> hdr->broadcast = 1;
Looks correct.
Reviewed-by: Ville Syrjälä
Hmm. L
> +
> if (mstb->lct > 1)
> memcpy(hdr->rad, mstb->rad, mstb->lct / 2);
We should also do something about RAD no?
>
> --
> 2.17.1
>
> _______
> dri-devel mailing list
> dri-devel@lists.fr
On Mon, Feb 22, 2021 at 07:02:03PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 22, 2021 at 12:00:26PM +0800, Wayne Lin wrote:
> > [Why & How]
> > According to DP spec, broadcast message LCT equals to 1 and LCR equals
> > to 6. Current implementation is incorrect. Fix i
nt index, u32 val, const struct atyfb_par *par)
> +{ }
> +
> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> +{
> + return 0;
> +}
> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
>
> #ifdef CONFIG_FB_ATY_GENERI
On Tue, Feb 23, 2021 at 05:32:36AM +, Lin, Wayne wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Tuesday, February 23, 2021 1:00 AM
> > To: Lin, Wayne
> > Cc: dri-devel@lists.freedesktop.org; Brol,
On Tue, Feb 23, 2021 at 05:32:32AM +, Lin, Wayne wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Tuesday, February 23, 2021 1:09 AM
> > To: Lin, Wayne
> > Cc: Brol, Eryk ; Zhuo, Qingqing ;
> > sta...@v
On Wed, Feb 24, 2021 at 11:59:45AM -0800, Randy Dunlap wrote:
> On 2/22/21 9:44 AM, Ville Syrjälä wrote:
> > On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> >> Fix build errors when these functions are not defined.
> >>
> >> ../drivers/video
On Thu, Feb 25, 2021 at 04:05:37PM -0800, Randy Dunlap wrote:
> Include PPC_PMAC in the configs that use aty_ld_lcd() and
> aty_st_lcd() implementations so that the PM code may work
> correctly for PPC_PMAC.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Randy Dunlap
> Cc
c01064ab R08: 55d68f44ba60 R09:
> R10: 55d68f44ba60 R11: 0246 R12: 55d68f5e0010
> R13: 000e R14: 0000 R15: 55d68e2275c0
> ---[ end trace d18216ba28a2f0e8 ]---
>
> ___
&g
outputs() thinks port B may be used for eDP and calls
> + * intel_dp_init() to check.
> + */
> + for (pipe = PIPE_A; pipe <= PIPE_B; pipe++) {
> + if (!(pipes & (1 << pipe)))
> + continue;
> +
> + if (intel_de
On Fri, Feb 26, 2021 at 09:30:08AM -0800, Randy Dunlap wrote:
> Include PPC_PMAC in the configs that use aty_ld_lcd() and
> aty_st_lcd() implementations so that the PM code may work
> correctly for PPC_PMAC.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Randy Dunlap
> Cc
On Mon, Mar 01, 2021 at 07:20:59PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote:
> >
> > On my test box with latest v5.12-rc1, running with all trace events
> > enabled, I consistently trigger this warning.
> >
> &g
ed the register masks for these options, instead of enum. (Ville)
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 24 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 10 --
> inclu
nclude/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -93,11 +93,11 @@ struct displayid_detailed_timing_block {
> };
>
> #define for_each_displayid_db(displayid, block, idx, length) \
> - for ((block) = (struct displayid_b
; should be needed solely within drm.ko.
>
> No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/Makefile| 2 +-
> drivers/gpu/drm/drm_displayid.c | 59 +++
NULL;
> + iter->edid = NULL;
> + return NULL;
> + }
> +
> + /* next block in section */
> + iter->idx += sizeof(struct displayid_block) + block->num_bytes;
ditto
Loo
1 - 100 of 4031 matches
Mail list logo
