+ Tvrtko
Quoting Jani Nikula (2021-04-14 13:06:42)
> On Wed, 14 Apr 2021, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote:
> > On Tue, 13 Apr 2021, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote:
> >> On Mon, 12 Apr 2021, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote:
> >>> Like was done for the display part that parted ways with INTEL_GEN(),
> >>> replacing with DISPLAY_VER(), do a similar conversion for the rest of
> >>> the driver.
> >>>
> >>> v1.1: Remove .ko that was incorrectly added as part of patch 11, making it
> >>> very big and not going through the mailing list. Sorry for those in CC
> >>> who received it.
> >>>
> >>> v2:
> >>> - Add "drm/i915/display: rename display version macros" to rename
> >>> macro and repurpose it: s/IS_DISPLAY_RANGE/IS_DISPLAY_VER/ and convert
> >>> the current users of IS_DISPLAY_VER to use direct comparison
> >>> - Group display patches to easily apply independently
> >>
> >> I like the direction here. Even as the version checks diversify, we
> >> manage to simplify and reduce the macros.
> >>
> >> I think we're going to have to queueu this via a topic branch, and merge
> >> that to both drm-intel-next and drm-intel-gt-next. The next time the
> >> branches can sync up is just too far away at this point, and the
> >> conflicts may be really nasty to solve later.
> >>
> >> That does mean having to solve the conflict with 70bfb30743d5
> >> ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") which is in din but not
> >> dign. The topic branch would be based on:
> >>
> >> $ git merge-base drm-intel/drm-intel-next drm-intel/drm-intel-gt-next
> >> 9c0fed84d5750e1eea6c664e073ffa2534a17743
> >>
> >> There are two (crappy?) ideas to make that easier. 1) revert
> >> 70bfb30743d5 from din and add it to the topic branch instead, 2) don't
> >> revert it but cherry-pick it to the topic branch also.
> >>
> >> Cc: Joonas and Daniel for their input on this as well.
> >
> > I've created the topic branch topic/intel-gen-to-ver where the series
> > should be applied.
> >
> > However, for the reasons above, it does not apply as-is, and the merge
> > will conflict slightly.
> >
> > Also, I think Ville's fixes [1] should land on the topic branch *first*
> > because they need to be propagated to drm-intel-next-fixes.
>
> I went ahead and:
>
> * Created the topic branch topic/intel-gen-to-ver with the merge-base
> mentioned above.
>
> * Cherry-picked 70bfb30743d5 on the topic branch to avoid major
> conflicts, as suggested by Daniel on IRC.
>
> * Reviewed and applied Ville's series [1] on the topic branch.
>
> * Reviewed and applied this series on the topic branch.
>
> - There were a couple of tiny conflicts between patch 3 and Ville's
> series, and I fixed the conflicts while applying.
>
> - I also fixed my comment nitpicks while applying.
>
> - I usually refrain from doing any changes while applying, but in this
> case I considered the changes very small, and did not want to delay
> this any further.
>
> Please chime in now if you have issues with this series! Explicit acks
> would be much appreciated; they can be added to the topic merge commit.
I think GT_VER() would be preferred over the more ambiguous GRAPHICS_VER()
and would better align with the attempt to consolidate the naming
difference between display and GT.
The GPU as whole is referred to as Intel Graphics, so otherwise will be
easy to draw wrong conclusions for 3rd parties looking at the code.
With GT_VER() or something else more distinctive this is:
Acked-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Regards, Joonas
>
> I hope to send the pull request and get this merged by Thursday, to
> avoid creating more conflicts.
>
>
> BR,
> Jani.
>
> >
> >
> > [1] https://lore.kernel.org/intel-gfx/20210412054607.18133-1-ville.syrjala@xxxxxxxxxxxxxxx/
>
> --
> Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
