On Mon, Jul 13, 2015 at 11:49:01AM +0200, Maarten Lankhorst wrote:
> Op 13-07-15 om 11:45 schreef Daniel Vetter:
> > On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
> >> Op 13-07-15 om 11:13 schreef Daniel Vetter:
> >>> On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
> >>>> Op 08-07-15 om 22:12 schreef Daniel Vetter:
> >>>>> On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> >>>>>> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> >>>>>>> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> >>>>>>>> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> >>>>>>>>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> >>>>>>>>>> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> >>>>>>>>>>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >>>>>>>>>>>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>>>>>>>>>>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>>>>>>>>>>>>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> This allows the first atomic call during hw init to be a
> >>>>>>>>>>>>>>>> real modeset,
> >>>>>>>>>>>>>>>> which is useful for forcing a recalculation.
> >>>>>>>>>>>>>>> fbcon is optional, you can't rely on anything being done in
> >>>>>>>>>>>>>>> any specific
> >>>>>>>>>>>>>>> way. What exactly do you need this for, what's the
> >>>>>>>>>>>>>>> implications?
> >>>>>>>>>>>>>> In the hw readout I noticed some warnings when I wasn't
> >>>>>>>>>>>>>> setting any mode property in the readout.
> >>>>>>>>>>>>>> I want the first function to be the modeset, so we have a sane
> >>>>>>>>>>>>>> base to commit changes on.
> >>>>>>>>>>>>>> Ideally this whole function would have a atomic counterpart
> >>>>>>>>>>>>>> which does it in one go. :)
> >>>>>>>>>>>>> Yeah. Otoh as soon as we have atomic modeset working we can
> >>>>>>>>>>>>> replace all
> >>>>>>>>>>>>> the legacy entry points with atomic helpers, and then even
> >>>>>>>>>>>>> plane_disable
> >>>>>>>>>>>>> will be a full atomic modeset.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> What did fall apart with just touching properties/planes now?
> >>>>>>>>>>>> Also when i915 is fully atomic it calculates in
> >>>>>>>>>>>> intel_modeset_compute_config
> >>>>>>>>>>>> if a modeset is needed after the first atomic call. Right now
> >>>>>>>>>>>> because
> >>>>>>>>>>>> intel_modeset_compute_config is only called in set_config so
> >>>>>>>>>>>> this works as expected.
> >>>>>>>>>>>> Otherwise drm_plane_force_disable or rotate_0 will force a
> >>>>>>>>>>>> modeset,
> >>>>>>>>>>>> and if the final mode is different this will introduce a double
> >>>>>>>>>>>> modeset.
> >>>>>>>>>>> For expensive properties (i.e. a no-op changes causes something
> >>>>>>>>>>> that takes
> >>>>>>>>>>> time like modeset or vblank wait) we need to make sure we filter
> >>>>>>>>>>> them out
> >>>>>>>>>>> in atomic_check. Yeah not quite there yet with pure atomic, but
> >>>>>>>>>>> meanwhile
> >>>>>>>>>>> the existing legacy set_prop functions should all filter out
> >>>>>>>>>>> no-op changes
> >>>>>>>>>>> themselves. If we don't do that for rotation then that's a bug.
> >>>>>>>>>>>
> >>>>>>>>>>> Same for disabling planes harder, that shouldn't take time.
> >>>>>>>>>>> Especially
> >>>>>>>>>>> since fbcon only force-disable non-primary plane, and for driver
> >>>>>>>>>>> load
> >>>>>>>>>>> that's the exact thing we already do in the driver anyway.
> >>>>>>>>>> Something like this?
> >>>>>>>>>> ---
> >>>>>>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >>>>>>>>>> b/drivers/gpu/drm/drm_atomic_helper.c
> >>>>>>>>>> index a1d4e13f3908..2989232f4996 100644
> >>>>>>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>>>>>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>>>>>>>>> @@ -30,6 +30,7 @@
> >>>>>>>>>> #include <drm/drm_plane_helper.h>
> >>>>>>>>>> #include <drm/drm_crtc_helper.h>
> >>>>>>>>>> #include <drm/drm_atomic_helper.h>
> >>>>>>>>>> +#include "drm_crtc_internal.h"
> >>>>>>>>>> #include <linux/fence.h>
> >>>>>>>>>>
> >>>>>>>>>> /**
> >>>>>>>>>> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
> >>>>>>>>>> drm_crtc *crtc,
> >>>>>>>>>> {
> >>>>>>>>>> struct drm_atomic_state *state;
> >>>>>>>>>> struct drm_crtc_state *crtc_state;
> >>>>>>>>>> - int ret = 0;
> >>>>>>>>>> + uint64_t retval;
> >>>>>>>>>> + int ret;
> >>>>>>>>>> +
> >>>>>>>>>> + ret = drm_atomic_get_property(&crtc->base, property, &retval);
> >>>>>>>>>> + if (!ret && val == retval)
> >>>>>>>>>> + return 0;
> >>>>>>>>>>
> >>>>>>>>>> state = drm_atomic_state_alloc(crtc->dev);
> >>>>>>>>>> if (!state)
> >>>>>>>>>> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
> >>>>>>>>>> drm_plane *plane,
> >>>>>>>>>> {
> >>>>>>>>>> struct drm_atomic_state *state;
> >>>>>>>>>> struct drm_plane_state *plane_state;
> >>>>>>>>>> - int ret = 0;
> >>>>>>>>>> + uint64_t retval;
> >>>>>>>>>> + int ret;
> >>>>>>>>>> +
> >>>>>>>>>> + ret = drm_atomic_get_property(&plane->base, property, &retval);
> >>>>>>>>>> + if (!ret && val == retval)
> >>>>>>>>>> + return 0;
> >>>>>>>>>>
> >>>>>>>>>> state = drm_atomic_state_alloc(plane->dev);
> >>>>>>>>>> if (!state)
> >>>>>>>>>> @@ -1836,7 +1847,12 @@
> >>>>>>>>>> drm_atomic_helper_connector_set_property(struct drm_connector
> >>>>>>>>>> *connector,
> >>>>>>>>>> {
> >>>>>>>>>> struct drm_atomic_state *state;
> >>>>>>>>>> struct drm_connector_state *connector_state;
> >>>>>>>>>> - int ret = 0;
> >>>>>>>>>> + uint64_t retval;
> >>>>>>>>>> + int ret;
> >>>>>>>>>> +
> >>>>>>>>>> + ret = drm_atomic_get_property(&connector->base, property,
> >>>>>>>>>> &retval);
> >>>>>>>>>> + if (!ret && val == retval)
> >>>>>>>>>> + return 0;
> >>>>>>>>>>
> >>>>>>>>>> state = drm_atomic_state_alloc(connector->dev);
> >>>>>>>>>> if (!state)
> >>>>>>>>> The reason I didn't do this is that a prop change might still
> >>>>>>>>> result in no
> >>>>>>>>> hw state change (e.g. if you go automitic->explicit setting matching
> >>>>>>>>> automatic one). Hence I think we need to solve this in lower levels
> >>>>>>>>> anyway, i.e. in when computing the config. But it shouldn't cause
> >>>>>>>>> trouble
> >>>>>>>>> yet.
> >>>>>>>> Is that a ack or nack?
> >>>>>>> I think we shouldn't need this really for i915, and it might cover up
> >>>>>>> bugs. I prefer we just do the evade modeset logic you've implemented
> >>>>>>> once
> >>>>>>> we switch over to atomic props. Since atm we only have atomic props
> >>>>>>> which
> >>>>>>> get updated in pageflips we shouldn't have serious problems here yet
> >>>>>>> (for
> >>>>>>> setting the rotation prop to 0° again when fbdev starts up).
> >>>>>>>
> >>>>>>> Or do I miss something still here?
> >>>>>> Yes, if the hardware mode is incompatible with its calculated sw mode,
> >>>>>> and we set a different mode from fbdev you get 2 modesets instead of 1.
> >>>>> How does that happen? For setting the rotation property we should just
> >>>>> duplicate the current crtc state. Since there's no mode changing (they
> >>>>> should match perfectly no matter how botched the reconstruction is)
> >>>>> there
> >>>>> shouldn't be any need to recompute the config completely and discover
> >>>>> that
> >>>>> there's a mismatch. Which means we'll just do the plane update (which
> >>>>> might do a few silly mmios but shouldn't block) and that's it.
> >>>>>
> >>>>> At least that's what I'd expect - where does this fall apart?
> >>>> If crtc is active and primary fb visible, and converted to atomic:
> >>>>
> >>>> restore_fbdev_mode() ->
> >>>> drm_mode_plane_set_obj_prop() ->
> >>>> drm_atomic_helper_plane_set_property() ->
> >>>> drm_atomic_get_plane_state() ->
> >>>> drm_atomic_get_crtc_state()
> >>>> crtc state is part of the state, intel_modeset_pipe_config performs
> >>>> the initial check if modeset's needed. Lets assume yes:
> >>> "Let's assume yes" -> that's imo a bug, so where does this happen so that
> >>> we can fix it? Disabling a plane or setting a plane prop really shouldn't
> >>> result in a modeset. Well at least if it's not a plane prop that does
> >>> required a modeset (but I don't think we have any of those).
> >> From a driver point of view you wouldn't be able to distinguish it from a
> >> real modeset to the same mode. :(
> >> In both cases you have all planes added and the crtc.
> >>
> >> Thinking about it more there will be 1 thing saving us from a modeset,
> >> drm_atomic_crtc_check will reject enable without mode_blob for atomic
> >> drivers,
> >> so until the first mode is set all atomic updates to the crtc will be
> >> rejected.
> >>
> >> Unfortunately you will still get WARN_ON's for this, so a better
> >> solution's needed.
> > Ok I think I start to grasp what's wrong, the trouble is that we don't
> > have the mode stuff fully set up yet (which is part of fastboot), which
> > means we'll get a bogus crtc_state->mode_changed despite that nothing
> > really changed. Ugly.
> No, mode_changed would be harmless, with proper skip modeset support it can
> be converted to a noop.
> > Could we insert a dummy mode_blob to avoid the WARNs and the bogus
> > mode_changed instead? The problem really is that doing this here is just
> > plugging the one source of troubles you're seeing right now (fbcon), the
> > initial set_* calls could come from anything really in any order. So we
> > really better be able to cope.
> Doesn't this mean we should set a real mode read out from hw state instead?
Yeah I guess so. We simply need to make sure that we have a mismatch.
Your DRIVER_MODE approach seems like it should work out.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
