[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces
On Wed, Nov 5, 2014 at 4:44 PM, Daniel Vetter wrote:
> I've applied all the other nits, replies to the more interesting bits
> below.
>
> On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
>> > + if (new_encoder != connector_state->best_encoder) {
>>
>> nit: If you just returned early when the encoder doesn't change, you can save
>> indentation and line breaks.
>
> Hm, that would mean either a goto (I don't like that for non-exceptional
> control flow) or duplicating the debug output. I'll go with the latter and
> frob it a bit.
>
I think you can just move the debug output above the new_encoder ==
connector_state->best_encoder check.
>> > + return ret;
>> > +
>> > + has_connectors = drm_atomic_connectors_for_crtc(state,
>> > + crtc);
>> > +
>> > + if (crtc_state->enable != has_connectors) {
>>
>> This makes me a little nervous. Even though has_connectors is a bool,
>> drm_atomic_connectors_for_crtc returns an int, and this seems like something
>> that someone might "fix" in the future.
>>
>> [PATCH] drm/atomic: Use proper type for drm_atomic_connectors_for_crtc
>
> Hm, yeah. I'll rename to num_connectors and add a !!. The idea of
> returning an int and not just a bool is that drivers might care if there's
> more than one, i.e. for cloned setups. At least i915 has some special
> considerations for that in some cases.
>
Makes sense, it just jumped out at me as something that might not be
future-safe.
>
>> > + ret = drm_crtc_vblank_get(crtc);
>> > + if (ret != 0)
>> > + continue;
>> > +
>> > + old_crtc_state->enable = true;
>> > + old_crtc_state->last_vblank_count = drm_vblank_count(dev, i);
>>
>> I think you should collect last_vblank_count before drm_crtc_vblank_get
>
> vblank_get should block on anything, and I'm not sure whether the
> drm_vblank_count can't just fall over if vblank_get fails (since
> vblank_get before vblank_count is the pattern drm_irq.c uses iirc). So I'd
> prefer it this way round just for paranoia. So I think I'll stick with
> this scheme. The waiting is only done once we've grabbed all the vblank
> count, and that's the important part to ensure we don't wait for too long.
>
> This really is just all part of the "generic code has no idea about the
> dpms state of a crtc". I'll plan to fix that with the missing dpms on
> atomic pieces.
Ok, sounds reasonable. The fixup in your tree looks good, feel free to
add my R-b when you squash.
Sean
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces
I've applied all the other nits, replies to the more interesting bits
below.
On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
> > + if (new_encoder != connector_state->best_encoder) {
>
> nit: If you just returned early when the encoder doesn't change, you can save
> indentation and line breaks.
Hm, that would mean either a goto (I don't like that for non-exceptional
control flow) or duplicating the debug output. I'll go with the latter and
frob it a bit.
> > + return ret;
> > +
> > + has_connectors = drm_atomic_connectors_for_crtc(state,
> > + crtc);
> > +
> > + if (crtc_state->enable != has_connectors) {
>
> This makes me a little nervous. Even though has_connectors is a bool,
> drm_atomic_connectors_for_crtc returns an int, and this seems like something
> that someone might "fix" in the future.
>
> [PATCH] drm/atomic: Use proper type for drm_atomic_connectors_for_crtc
Hm, yeah. I'll rename to num_connectors and add a !!. The idea of
returning an int and not just a bool is that drivers might care if there's
more than one, i.e. for cloned setups. At least i915 has some special
considerations for that in some cases.
> > + ret = drm_crtc_vblank_get(crtc);
> > + if (ret != 0)
> > + continue;
> > +
> > + old_crtc_state->enable = true;
> > + old_crtc_state->last_vblank_count = drm_vblank_count(dev, i);
>
> I think you should collect last_vblank_count before drm_crtc_vblank_get
vblank_get should block on anything, and I'm not sure whether the
drm_vblank_count can't just fall over if vblank_get fails (since
vblank_get before vblank_count is the pattern drm_irq.c uses iirc). So I'd
prefer it this way round just for paranoia. So I think I'll stick with
this scheme. The waiting is only done once we've grabbed all the vblank
count, and that's the important part to ensure we don't wait for too long.
This really is just all part of the "generic code has no idea about the
dpms state of a crtc". I'll plan to fix that with the missing dpms on
atomic pieces.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces
On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote: > So this is finally the integration of the crtc and plane helper > interfaces into the atomic helper functions. > > In the check function we now have a few steps: > > - First we update the output routing and figure out which crtcs need a > full mode set. Suitable encoders are selected using ->best_encoder, > with the same semantics as the crtc helpers of implicitly disabling > all connectors currently using the encoder. > > - Then we pull all other connectors into the state update which feed > from a crtc which changes. This must be done do catch mode changes > and similar updates - atomic updates are differences on top of the > current state. > > - Then we call all the various ->mode_fixup to compute the adjusted > mode. Note that here we have a slight semantic difference compared > to the crtc helpers: We have not yet updated the encoder->crtc link > when calling the encoder's ->mode_fixup function. But that's a > requirement when converting to atomic since we want to prepare the > entire state completely contained with the over drm_atomic_state > structure. So this must be carefully checked when converting drivers > over to atomic helpers. > > - Finally we do call the atomic_check functions on planes and crtcs. > > The commit function is also quite a beast: > > - The only step that can fail is done first, namely pinning the > framebuffers. After that we cross the point of no return, an async > commit would push all that into the worker thread. > > - The disabling of encoders and connectors is a bit tricky, since > depending upon the final state we need to select different crtc > helper functions. > > - Software tracking is a bit clarified compared to the crtc helpers: > We commit the software state before starting to touch the hardware, > like crtc helpers. But since we just swap them we still have the old > state (i.e. the current hw state) around, which is really handy to > write simple disable functions. So no more > drm_crtc_helper_disable_all_unused_functions kind of fun because > we're leaving unused crtcs/encoders behind. Everything gets shut > down in-order now, which is one of the key differences of the i915 > helpers compared to crtc helpers and a really nice additional > guarantee. > > - Like with the plane helpers the atomic commit function waits for one > vblank to pass before calling the framebuffer cleanup function. > > Compared to Rob's helper approach there's a bunch of upsides: > > - All the interfaces which can fail are called in the ->check hook > (i.e. ->best_match and the various ->mode_fixup hooks). This means > that drivers can just reuse those functions and don't need to move > everything into ->atomic_check callbacks. If drivers have no need > for additional constraint checking beyong their existing crtc s/beyong/beyond/ > helper callbacks they don't need to do anything. > > - The actual commit operation is properly stage: First we prepare > framebuffers, which can potentially still fail (due to memory > exhausting). This is important for the async case, where this must > be done synchronously to correctly return errors. > > - The output configuration changes (done with crtc helper functions) > and the plane update (using atomic plane helpers) are correctly > interleaved: First we shut down any crtcs that need changing, then > we update planes and finally we enable everything again. Hardware > without GO bits must be more careful with ordering, which this > sequence enables. > > - Also for hardware with shared output resources (like display PLLs) > we first must shut down the old configuration before we can enable > the new one. Otherwise we can hit an impossible intermediate state > where there's not enough PLLs (which is the point behind atomic > updates). > > v2: > - Ensure that users of ->check update crtc_state->enable correctly. > - Update the legacy state in crtc/plane structures. Eventually we want > to remove that, but for now the drm core still expects this (especially > the plane->fb pointer). > > v3: A few changes for better async handling: > > - Reorder the software side state commit so that it happens all before > we touch the hardware. This way async support becomes very easy > since we can punt all the actual hw touching to a worker thread. And > as long as we synchronize with that thread (flushing or cancelling, > depending upon what the driver can handle) before we commit the next > software state there's no need for any locking in the worker thread > at all. Which greatly simplifies things. > > And as long as we synchronize with all relevant threads we can have > a lot of them (e.g. per-crtc for per-crtc updates) running in > parallel. > > - Expose pre/post plane commit steps separately. We need to expose the > actual hw commit step anyway for drivers to be able to implement > async
[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces
So this is finally the integration of the crtc and plane helper interfaces into the atomic helper functions. In the check function we now have a few steps: - First we update the output routing and figure out which crtcs need a full mode set. Suitable encoders are selected using ->best_encoder, with the same semantics as the crtc helpers of implicitly disabling all connectors currently using the encoder. - Then we pull all other connectors into the state update which feed from a crtc which changes. This must be done do catch mode changes and similar updates - atomic updates are differences on top of the current state. - Then we call all the various ->mode_fixup to compute the adjusted mode. Note that here we have a slight semantic difference compared to the crtc helpers: We have not yet updated the encoder->crtc link when calling the encoder's ->mode_fixup function. But that's a requirement when converting to atomic since we want to prepare the entire state completely contained with the over drm_atomic_state structure. So this must be carefully checked when converting drivers over to atomic helpers. - Finally we do call the atomic_check functions on planes and crtcs. The commit function is also quite a beast: - The only step that can fail is done first, namely pinning the framebuffers. After that we cross the point of no return, an async commit would push all that into the worker thread. - The disabling of encoders and connectors is a bit tricky, since depending upon the final state we need to select different crtc helper functions. - Software tracking is a bit clarified compared to the crtc helpers: We commit the software state before starting to touch the hardware, like crtc helpers. But since we just swap them we still have the old state (i.e. the current hw state) around, which is really handy to write simple disable functions. So no more drm_crtc_helper_disable_all_unused_functions kind of fun because we're leaving unused crtcs/encoders behind. Everything gets shut down in-order now, which is one of the key differences of the i915 helpers compared to crtc helpers and a really nice additional guarantee. - Like with the plane helpers the atomic commit function waits for one vblank to pass before calling the framebuffer cleanup function. Compared to Rob's helper approach there's a bunch of upsides: - All the interfaces which can fail are called in the ->check hook (i.e. ->best_match and the various ->mode_fixup hooks). This means that drivers can just reuse those functions and don't need to move everything into ->atomic_check callbacks. If drivers have no need for additional constraint checking beyong their existing crtc helper callbacks they don't need to do anything. - The actual commit operation is properly stage: First we prepare framebuffers, which can potentially still fail (due to memory exhausting). This is important for the async case, where this must be done synchronously to correctly return errors. - The output configuration changes (done with crtc helper functions) and the plane update (using atomic plane helpers) are correctly interleaved: First we shut down any crtcs that need changing, then we update planes and finally we enable everything again. Hardware without GO bits must be more careful with ordering, which this sequence enables. - Also for hardware with shared output resources (like display PLLs) we first must shut down the old configuration before we can enable the new one. Otherwise we can hit an impossible intermediate state where there's not enough PLLs (which is the point behind atomic updates). v2: - Ensure that users of ->check update crtc_state->enable correctly. - Update the legacy state in crtc/plane structures. Eventually we want to remove that, but for now the drm core still expects this (especially the plane->fb pointer). v3: A few changes for better async handling: - Reorder the software side state commit so that it happens all before we touch the hardware. This way async support becomes very easy since we can punt all the actual hw touching to a worker thread. And as long as we synchronize with that thread (flushing or cancelling, depending upon what the driver can handle) before we commit the next software state there's no need for any locking in the worker thread at all. Which greatly simplifies things. And as long as we synchronize with all relevant threads we can have a lot of them (e.g. per-crtc for per-crtc updates) running in parallel. - Expose pre/post plane commit steps separately. We need to expose the actual hw commit step anyway for drivers to be able to implement asynchronous commit workers. But if we expose pre/post and plane commit steps individually we allow drivers to selectively use atomic helpers. - I've forgotten to call encoder/bridge ->mode_set functions, fix this. v4: Add debug output and fix a mixup between
