drm/i915: Optimize icl+ universal plane programming

On icl+ all plane registers are armed by PLANE_SURF, so we can
move almost everything over into the update_noarm() hook.

The PLANE_CTL write has to stay in the icl_update_arm() hook though
as it still exhibits the somewhat annoying self-arming behaviour
when the plane transitioning from disabled to enabled.

We could either do a full split for skl+ vs. icl+, or we could try
some other kind of split where we'd eg. keep most things in the skl+
functions and call them from the icl+ functions. I think a full split
is probably the cleaner approach since we've anyway accumulated quite
a bit of icl+ specific things, so that is what I opted to do.

Some i915_update_info stats for tgl:
before:                             after:
Updates: 5043                       Updates: 5043
       |                                   |
   1us |                               1us |
       |**                                 |***
   4us |******                         4us |********
       |**********                         |***********
  16us |***********                   16us |**********
       |****                               |*
  66us |                              66us |
       |                                   |
 262us |                             262us |
       |                                   |
   1ms |                               1ms |
       |                                   |
   4ms |                               4ms |
       |                                   |
  17ms |                              17ms |
       |                                   |
Min update: 3494ns                  Min update: 2983ns
Max update: 49491ns                 Max update: 39986ns
Average update: 18031ns             Average update: 13423ns
Overruns > 100us: 0                 Overruns > 100us: 0

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-2-ville.syrjala@linux.intel.com


Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>