ed they could
try to handle short replies more correctly and keep retrying
the remaining bytes (assuming that is the correct way to
handle them). Although with those black holes I guess
you'd eventually have to give up anyway before having
transferred all the bytes.
--
Ville Syrjälä
Intel
On Fri, Jan 24, 2025 at 04:37:39PM +0100, Simona Vetter wrote:
> On Fri, Jan 24, 2025 at 03:12:41PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 24, 2025 at 01:59:15PM +0100, Simona Vetter wrote:
> > > On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> > > &
On Fri, Jan 24, 2025 at 01:59:15PM +0100, Simona Vetter wrote:
> On Fri, Jan 24, 2025 at 02:10:54PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 24, 2025 at 01:14:18PM +0200, Dmitry Baryshkov wrote:
> > > There are several drivers which attempt to upgrading the commit to the
&
rerequisite-change-id: 20241222-drm-dirty-modeset-88079bd27ae6:v2
> prerequisite-patch-id: 0c61aabfcd13651203f476985380cbf4d3c299e6
> prerequisite-patch-id: c6026f08011c288fd301676e9fa6f46d0cc1dab7
> prerequisite-patch-id: b0cb06d5c88791d6e4755d879ced0d5050aa3cbf
> prerequisite-patch-id: fd72ddde9dba0df053113bc505c213961a9760da
>
> Best regards,
> --
> Dmitry Baryshkov
--
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,
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: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
> 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
sy to 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
&
5aea94e 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -52,6 +52,13 @@ int drm_atomic_helper_check_modeset(struct drm_device *dev,
> int
> drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
>
t; >> - 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(&crtc_state->infoframes.vsc,
> >> &sdp,
> >> - sizeof(sdp));
> >> + len = drm_dp_vsc_sdp_pack(&crtc_state->infoframes.vsc,
> >> &sdp,
> >> + 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, &sdp, sizeof(sdp));
> >> + len = drm_dp_vsc_sdp_pack(vsc, &sdp, sizeof(sdp));
> >>
> >> if (drm_WARN_ON(&dev_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
if (dev->mode_config.poll_running)
> + drm_kms_helper_disable_hpd(dev);
> +
> + cancel_delayed_work_sync(&dev->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
be const. 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 updating a sin
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:
> > &
/**
> * drm_atomic_helper_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:
>
rm_crtc_next_vblank_time);
> > > > +
> > > > 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
iations of 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
es sense for the transfer to fail.
I don't agree with 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
rm_mode_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_update_edid_propert
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
ctor->dev, "%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
vo_connector->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
the start.
> drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
> return 0;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
re are significant
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:
> > > > H
k_all() --> 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()
/gpu/drm/panel/panel-simple.c | 73 +-
> > include/drm/drm_panel.h| 15 ++-
> > 4 files changed, 190 insertions(+), 8 deletions(-)
>
> Pushed to drm-misc-next.
>
> 4bfe6c8f7c23 drm/p
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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
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
&
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
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
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
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(-)
>
unt);
>
> +/*
> + * Helpers for struct drm_crtc_funcs
> + */
> +
> typedef bool (*drm_vblank_get_scanout_position_func)(struct drm_crtc *crtc,
>bool in_vblank_irq,
>int *vpos, int *hpos,
> @@ -259,5 +263,9 @@
> drm_crtc_vblank_helper_get_vblank_timestamp_internal(struct drm_crtc *crtc,
>bool in_vblank_irq,
>
> drm_vblank_get_scanout_position_func get_scanout_position,
>
> drm_vblank_get_scanout_position_legacy_func get_scanout_position_legacy);
> +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
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
> >
_crtc(dcrtc);
> enum pipe 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;
> }
>
>
splay mode. Only valid when @enabled
>* is set. This is used by helpers like
> - * drm_calc_vbltimestamp_from_scanoutpos(). We can't just access the
> - * hardware mode by e.g. looking at &drm_crtc_state.adjusted_mode,
> + * drm_crtc_vblank_helper_get_vblank_ti
drm_crtc_index(crtc);
>
> vblank = &dev->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
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
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
bridge chain 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.
>
> Conne
ed ddc adapter.
> + * A connector usually 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
connector->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.1
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 decode
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 Wed, Dec 05, 2018 at 09:46:40AM +0100, Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
&g
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älä
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
t case is covered by the 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 disab
>base);
> memset(crtc_state, 0, sizeof(*crtc_state));
> - crtc_state->base.crtc = &crtc->base;
> + __drm_atomic_helper_crtc_reset(&crtc->base, &crtc_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
ale, vscale);
Can't use drm_atomic_helper_check_plane_state() ?
> +
> DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FMT "->crtc%u " DRM_RECT_FMT
> ", %4.4s ubwc %d\n", fb->base.id, DRM_RECT_ARG(&src),
> crtc->base.id, DRM_RECT_ARG(&dst
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 als
ng called concurrently 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ä
>
> 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
> everything is unified the clip rectan
ruct drm_plane *plane)
>*/
> omap_state->zorder = plane->type == DRM_PLANE_TYPE_PRIMARY
> ? 0 : omap_plane->id;
> - omap_state->base.rotation = DRM_ROTATE_0;
> + omap_state->base.rotation = DRM_MODE_ROTATE_0;
>
>
ASK
> + *
> + * 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 {
> __u
On Thu, Mar 30, 2017 at 03:27:57PM +0200, Daniel Vetter wrote:
> On Thu, Mar 30, 2017 at 2:03 PM, Ville Syrjälä
> wrote:
> > On Wed, Mar 22, 2017 at 09:56:12PM +0100, Daniel Vetter wrote:
> >> If we restrict this helper to only kms drivers (which is the case) we
> >>
unsigned int flags, int *vpos, int *hpos,
> ktime_t *stime, ktime_t *etime,
> const struct drm_display_mode *mode);
> -bool vc4_crtc_get_vblank_timestamp(struct drm_device *dev, unsigned int
> crtc_id,
> -
so supplies 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ä
>
> Cc: Mario Kleiner
> Cc: Eric Anholt
> Cc: Rob Clark
> Cc: linux
property(struct
> > >> drm_plane *plane,
> > >> } while (0)
> > >>
> > >> GET_PROPERTY(zpos, ZPOS, uint8_t);
> > >> + GET_PROPERTY(alpha, ALPHA, uint8_t);
> > >>
> > >> dev_err(dev->de
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_B
org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Signed-off-by: Joonas Lahtinen
Patch lgtm
Reviewed-by: Ville Syrjälä
Will conflict badly with my stuff, however.
> ---
95 matches
Mail list logo
