fix it. Once there are several
> > users, you have to fix all of them at the same time, patching
> > different drm subtrees. That complicates the life of maintainers.
> >
>
> Yes, understood. Its easier to fix it now if its really needed.
>
> Actually, I think the reason the size was passed was to make sure
> a valid struct dp_sdp *sdp was being passed.
The size is supposed to be the size of *hardware* buffer where this
gets written into. But looks like this wasn't done correctly when
the code was copy-pasted from the HDMI inforframe code.
--
Ville Syrjälä
Intel
On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote:
> On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä
> wrote:
> >
> > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> > > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshko
On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > The helper drm_atomic_helper_check_plane_state() runs several checks on
> > plane src and dst rectangles, including the check whether required
&
omic_helper_check_modeset(struct drm_device *dev,
> int
> drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
>struct drm_connector_state
> *conn_state);
> +int drm_atomic_helper_check_plane_noscale(struct drm_plane_state
> *plane_state,
> + const struct drm_crtc_state
> *crtc_state,
> + bool can_position,
> + bool can_update_disabled);
> +int drm_atomic_helper_check_plane_scale(struct drm_plane_state *plane_state,
> + int min_scale,
> + int max_scale);
> int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
> const struct drm_crtc_state *crtc_state,
> int min_scale,
> --
> 2.39.2
--
Ville Syrjälä
Intel
C_RANGE_CTA)
> >> - sdp->db[17] |= 0x80; /* DB17[7] */
> >> -
> >> - /* Content Type */
> >> - sdp->db[18] = vsc->content_type & 0x7;
> >> -
> >> -out:
> >> - return length;
> >> -}
> >> -
> >> static ssize_t
> >> intel_dp_hdr_metadata_infoframe_sdp_pack(struct drm_i915_private *i915,
> >> const struct hdmi_drm_infoframe
> >> *drm_infoframe,
> >> @@ -4269,8 +4202,8 @@ static void intel_write_dp_sdp(struct intel_encoder
> >> *encoder,
> >>
> >> switch (type) {
> >> case DP_SDP_VSC:
> >> - len = intel_dp_vsc_sdp_pack(_state->infoframes.vsc,
> >> ,
> >> - sizeof(sdp));
> >> + len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc,
> >> ,
> >> + sizeof(sdp));
> >> break;
> >> case HDMI_PACKET_TYPE_GAMUT_METADATA:
> >> len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
> >> @@ -4297,7 +4230,7 @@ void intel_write_dp_vsc_sdp(struct intel_encoder
> >> *encoder,
> >> struct dp_sdp sdp = {};
> >> ssize_t len;
> >>
> >> - len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> >> + len = drm_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> >>
> >> if (drm_WARN_ON(_priv->drm, len < 0))
> >> return;
> >> diff --git a/include/drm/display/drm_dp_helper.h
> >> b/include/drm/display/drm_dp_helper.h
> >> index 863b2e7add29..f8db34a2f7a5 100644
> >> --- a/include/drm/display/drm_dp_helper.h
> >> +++ b/include/drm/display/drm_dp_helper.h
> >> @@ -813,4 +813,7 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> >> int bpp_x16, unsigned long flags);
> >> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
> >>
> >> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> >> + struct dp_sdp *sdp, size_t size);
> >> +
> >> #endif /* _DRM_DP_HELPER_H_ */
> >> --
> >> 2.34.1
> >>
> >
> >
--
Ville Syrjälä
Intel
ng)
> + drm_kms_helper_disable_hpd(dev);
> +
> + cancel_delayed_work_sync(>mode_config.output_poll_work);
> +
> + dev->mode_config.poll_running = false;
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_disable);
>
> @@ -900,7 +895,12 @@ EXPORT_SYMBOL(drm_kms_helper_poll_init);
> */
> void drm_kms_helper_poll_fini(struct drm_device *dev)
> {
> - drm_kms_helper_poll_disable_fini(dev, true);
> + if (!dev->mode_config.poll_enabled)
> + return;
> +
> + drm_kms_helper_poll_disable(dev);
> +
> + dev->mode_config.poll_enabled = false;
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_fini);
>
> --
> 2.39.0
--
Ville Syrjälä
Intel
The word "calculate" seems pretty much redundant.
> +{
> + return 2 << (dsc->bits_per_component - 8);
> +}
> +
> #endif /* _DRM_DSC_HELPER_H_ */
>
>
> --
> 2.40.1
--
Ville Syrjälä
Intel
On Wed, Mar 08, 2023 at 03:33:48PM -0800, Rob Clark wrote:
> On Wed, Mar 8, 2023 at 1:23 PM Ville Syrjälä
> wrote:
> >
> > On Wed, Mar 08, 2023 at 12:02:42PM -0800, Abhinav Kumar wrote:
> > > For DRM property blobs created by user mode using
> > > drm_prope
blob = vzalloc(sizeof(struct drm_property_blob)+length);
> + else
> + blob = kvzalloc(sizeof(struct drm_property_blob)+length,
> GFP_KERNEL);
> +
> if (!blob)
> return ERR_PTR(-ENOMEM);
>
> --
> 2.7.4
--
Ville Syrjälä
Intel
On Fri, Mar 03, 2023 at 07:45:05AM -0800, Rob Clark wrote:
> On Fri, Mar 3, 2023 at 7:12 AM Ville Syrjälä
> wrote:
> >
> > On Thu, Mar 02, 2023 at 03:53:33PM -0800, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > For an atomic commit upda
On Fri, Mar 03, 2023 at 05:00:03PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 03, 2023 at 06:48:43AM -0800, Rob Clark wrote:
> > On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 03/03/2023 03:21, Rodrigo Vivi wrote:
> > &
elper_wait_for_fences - wait for fences stashed in plane state
> * @dev: DRM device
> @@ -1540,6 +1574,8 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
> *dev,
> struct drm_plane_state *new_plane_state;
> int i, ret;
>
> + set_fence_deadline(dev, state);
> +
> for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> if (!new_plane_state->fence)
> continue;
> --
> 2.39.1
--
Ville Syrjälä
Intel
ompleted(rq))
> > >> +return;
> > >> +
> > >> +if (i915_request_started(rq))
> > >> + return;
> > >
> > > why do we skip the boost if already started?
> > > don't we want to boost the freq anyway?
> >
> > I'd wager Rob is just copying the current i915 wait boost logic.
>
> Yup, and probably incorrectly.. Matt reported fewer boosts/sec
> compared to your RFC, this could be the bug
I don't think i915 calls drm_atomic_helper_wait_for_fences()
so that could explain something.
--
Ville Syrjälä
Intel
On Wed, Feb 22, 2023 at 07:44:42AM -0800, Rob Clark wrote:
> On Wed, Feb 22, 2023 at 1:57 AM Pekka Paalanen wrote:
> >
> > On Tue, 21 Feb 2023 09:50:20 -0800
> > Rob Clark wrote:
> >
> > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
> > > wrote:
On Tue, Feb 21, 2023 at 02:28:10PM -0800, Rob Clark wrote:
> On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> > > >
On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
>
On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > > On Mon, 20 Feb 2023 07:55:41 -0800
> > > Rob Clark wrote:
> &
On Tue, Feb 21, 2023 at 03:11:33PM +0200, Pekka Paalanen wrote:
> On Tue, 21 Feb 2023 15:01:35 +0200
> Ville Syrjälä wrote:
>
> > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > > On Mon, 20 Feb 2023 07:55:41 -0800
> > > Rob Clark wrote:
>
me);
> > > > +
> > > > static void send_vblank_event(struct drm_device *dev,
> > > > struct drm_pending_vblank_event *e,
> > > > u64 seq, ktime_t now)
> > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> > > > index 733a3e2d1d10..a63bc2c92f3c 100644
> > > > --- a/include/drm/drm_vblank.h
> > > > +++ b/include/drm/drm_vblank.h
> > > > @@ -230,6 +230,7 @@ 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_time(struct drm_crtc *crtc, ktime_t
> > > > *vblanktime);
> > > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> > > > struct drm_pending_vblank_event *e);
> > > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> > >
>
--
Ville Syrjälä
Intel
RGB
> > >> formats [1].
> > >
> > > Sure, but the driver can convert the format into whatever the hw
> > > wants. A 1x1 color conversion is not going to be problematic ;-)
> >
> > Hi Rob,
> >
> > Hm... that's also a fair point. Just wondering, is there any advantage
> > of having the driver convert the format, other than not having to
> > implement an extra format property?
> >
> > (In case we end up wrapping everything into a prop blob or something)
> >
>
> It keeps the uabi simpler.. for obvious reasons you don't want the
> driver to do cpu color conversion for an arbitrary size plane, which
> is why we go to all the complexity to expose formats and modifiers for
> "real" planes, but we are dealing with a single pixel value here,
> let's not make the uabi more complex than we need to. I'd propose
> making it float32[4] if float weren't a pita for kernel/uabi, but
> u16[4] or u32[4] should be fine, and drivers can translate that easily
> into whatever weird formats their hw wants for solid-fill.
u16[4] fits into a single u64 property value.
That was the plan for the background prop as well:
https://lore.kernel.org/all/20190703125442.gw5...@intel.com/T/
--
Ville Syrjälä
Intel
+-
> include/drm/drm_blend.h | 2 +
> include/drm/drm_plane.h | 28 ++
> 10 files changed, 188 insertions(+), 76 deletions(-)
>
> --
> 2.38.0
--
Ville Syrjälä
Intel
On Thu, May 05, 2022 at 08:53:12AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> wrote:
> >
> > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu
On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> wrote:
> >
> > On Wed, May 04, 2022 at 02:10:08PM -0400, Lyude Paul wrote:
> > > On Wed, 2022-05-04 at 09:04 -0700, Doug Anderson wrote:
> &
On Wed, May 04, 2022 at 02:10:08PM -0400, Lyude Paul wrote:
> On Wed, 2022-05-04 at 09:04 -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, May 4, 2022 at 5:21 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, May 03, 2022 at 04:21:08PM -0700, Doug
this. I think the panel should just get powred up
for AUX transfers. Otherwise you can't trust that eg. the /dev/aux
stuff is actually usable.
--
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
#__VA_ARGS__\
> }
Would it not be less convoluted to make the macro only provide
the initializers? So you'd get something like:
static const struct file_operations foo = {
DRM_GEM_FOPS,
.my_stuff = whatever,
};
>
> void drm_gem_object_release(struct drm_gem_object *obj);
> --
> 2.35.1
--
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() -->
panel-simple.c | 73 +-
> > include/drm/drm_panel.h| 15 ++-
> > 4 files changed, 190 insertions(+), 8 deletions(-)
>
> Pushed to drm-misc-next.
>
> 4bfe6c8f7c23 drm/panel-simple: Ad
cture where the driver is fully initialzied
before anything gets exposed to userspace.
--
Ville Syrjälä
Intel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
struct 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
&
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->sta
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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
<... ...> 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;
> identifier plane, state;
>
On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely poin
-off-by: Thomas Zimmermann
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_vblank.c| 27 +++
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> include/drm/drm_vblank.h| 10 +-
> 3 files changed, 9 insertions(+), 30 deletions(-)
>
On Thu, Jan 16, 2020 at 09:44:55AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 15.01.20 um 15:49 schrieb Ville Syrjälä:
> > On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote:
> >> @@ -2020,3 +2042,193 @@ int drm_crtc_queue_sequence_ioctl(struct
> >
pipe = crtc->pipe;
> int position;
> int vbl_start, vbl_end, hsync_start, htotal, vtotal;
> @@ -879,6 +881,14 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev,
> unsigned int index,
> return true;
> }
>
> +bool i915_crtc_get_vblank_timest
djusted_mode,
> + * drm_crtc_vblank_helper_get_vblank_timestamp(). We can't just access
> + * the hardware mode by e.g. looking at _crtc_state.adjusted_mode,
>* because that one is really hard to get from interrupt context.
>*/
> struct drm_display_mode hwmode;
> @@ -238,4 +238,22 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
> wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
> void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
> u32 max_vblank_count);
> +
> +/*
> + * Helpers for struct drm_crtc_funcs
> + */
> +
> +bool
> +drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> + struct drm_crtc *crtc, int *max_error, ktime_t *vblank_time,
> + bool in_vblank_irq,
> + bool (*get_scanout_position)(struct drm_crtc *crtc,
> + bool in_vblank_irq, int *vpos, int
> *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode *mode));
Ugly alignment. Could maybe add a typedef for the function pointer if it
otherwise gets super horrible with proper alignment.
> +bool drm_crtc_vblank_helper_get_vblank_timestamp(struct drm_crtc *crtc,
> + int *max_error,
> + ktime_t *vblank_time,
> + bool in_vblank_irq);
> +
> #endif
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
>vblank[pipe];
> - vblank_enabled = dev->vblank_disable_immediate &&
> READ_ONCE(vblank->enabled);
> + vblank_enabled = __vblank_disable_immediate(dev, pipe) &&
> + READ_ONCE(vblank->enabled);
>
> if (!vblank_enabled) {
> ret = drm_crtc_vblank_get(crtc);
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
e new
> >> i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin
> >> wrappers passing in the relevant get_scanout_position function.
> >
> > Of course. Will be in v2 of the series.
>
> Please give Ville (Cc'd) a moment before sending v2 in case he wants t
MODE_REFLECT_X |
> + DRM_MODE_REFLECT_Y);
> +
> drm_plane_enable_fb_damage_clips(plane);
>
> /* success! finalize initialization */
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@l
n where the bridges downstream of the first bridge don't care).
>
> >
> > There's then still the question of how to pick video vs command mode, but
> > imo better to start with implementing the transition behaviour correctly
> > first.
>
> Connector property? Possibly a
y has its associated ddc adapter. If a driver uses
> + * this field, then an appropriate symbolic link is created in connector
> + * sysfs directory to make it easy for the user to tell which i2c
> + * adapter is for a particular display.
> + */
> + struct i2c_
r->ycbcr_420_allowed = true;
>
> - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> -
> if (WARN_ON(port == PORT_A))
> return;
> intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
On Thu, Jun 20, 2019 at 10:25:42PM +0200, Sam Ravnborg wrote:
> Hi Ville.
>
> On Thu, Jun 20, 2019 at 09:50:48PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Decode the mode flags when printing the modeline so that I
> > no longer have to de
On Wed, Dec 05, 2018 at 08:40:34AM +0100, Andrzej Hajda wrote:
> On 04.12.2018 20:02, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> >> On 03.12.2018 22:48, Ville Syrjälä wrote:
> >>> On Thu, Nov 29, 2018 at 09:46:1
On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:38, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> >> On 21.11.2018 19:19, Laurent Pinchart wrote:
> >>> Hi Ville,
>
On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:48, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >> Quite late, hopefully not too late.
> >>
> >>
> >> On 21.11.2018 12:51, Vi
On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> Quite late, hopefully not too late.
>
>
> On 21.11.2018 12:51, Ville Syrjälä wrote:
> > On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>
> >>> return;
> >>&
On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> On 21.11.2018 19:19, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > Thank you for the patch.
> >
> > On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
> >> From: Ville Syrjä
On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> On Tue, 20 Nov 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by simply passing the connector
> > to drm_hdmi_avi_infoframe_from_display_mode() and
> > d
modeset locks held when calling disable().
> >
> I am sure it will take care of drm_crtc_vblank_on/off triggered within
> crtc_disable.
> My question was what was the expected behaviour when
> DRM_IOCTL_WAIT_VBLANK is
> called when crtc is disabled? the ioctl will try t
(crtc_state, 0, sizeof(*crtc_state));
> - crtc_state->base.crtc = >base;
> + __drm_atomic_helper_crtc_reset(>base, _state->base);
intel_crtc_init() could use the same treatment.
And intel_create_plane_state() could use the plane reset. In fact it
looks like we aren't intializing plane constant alpha at all. So it'll
start out as zero which probably isn't what most people would expect.
I also wonder if this patch shouldn't be split up more. Just in case
there's some unforseen regression somewhere I'd hate to see the
entire thing get reverted.
--
Ville Syrjälä
Intel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
should
> use drm_atomic_helper_shutdown() instead.
lgtm
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Rajesh Yadav
> Cc: Chandan Uddaraju
> Cc: Archit Taneja
> Cc: Jeykumar Sankaran
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Sinclair Y
RECT_FMT
> ", %4.4s ubwc %d\n", fb->base.id, DRM_RECT_ARG(),
> crtc->base.id, DRM_RECT_ARG(),
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
On Thu, Jun 28, 2018 at 04:13:06PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Changes from the previous version mainly involve Danoie's suggestion
Can't type today either: "Daniel's"
> of hiding the drm_encoder_find() in the iterator macro. I also polished
>
with a modeset.
The dirty_mutex only seems to offer any protection for
fb.dirty() against another fb.dirty()...
--
Ville Syrjälä
Intel OTC
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> This series first unifies all users of drm_atomic_helper_check_plane_state()
> to populate the clip rectangle with drm_mode_get_hv_timing(), and once
>
;
> plane->state = _state->base;
> plane->state->plane = plane;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> i
gt; + *
> + * Bitmask used to look for drm plane reflections.
> + */
> +#define DRM_MODE_REFLECT_MASK (\
> + DRM_MODE_REFLECT_X | \
> + DRM_MODE_REFLECT_Y)
> +
> +
> struct drm_mode_modeinfo {
> __u32 cl
pplies it's own driver-private flags in there.
This part worried me, but indeed radeon only passes the custom flag to
the scanout position hook. Patch lgtm
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> Cc: Mario Kleiner <mario.klei...@tuebingen.mpg.de>
> Cc
dev_err(dev->dev, "too many planes!\n");
> + return -EINVAL;
> + }
> +
> for (i = 0; i < cnt; i++) {
> - pstates[i].state->stage = STAGE_BASE + i;
> + pstates[i].state->stage = STAGE_BASE + i + bas
79 matches
Mail list logo
