On Mon, 11 Jan 2021, Aditya Swarup <aditya.swarup@xxxxxxxxx> wrote: > On 1/11/21 12:13 PM, Jani Nikula wrote: >> On Fri, 08 Jan 2021, Matt Roper <matthew.d.roper@xxxxxxxxx> wrote: >> FWIW I have a wip series changing the whole thing to abstract steppings >> enums that are shared between platforms, but it's in a bit of limbo >> because the previous revid changes were applied to drm-intel-gt-next, >> and it's fallen pretty far out of sync with drm-intel-next. All of this >> really belongs to drm-intel-next, but can't do that until the branches >> sync up again. >> >> My series also completely hides the arrays into a separate .c file, >> because the externs with direct array access are turning into >> nightmare. The ARRAY_SIZE() checks rely on the extern declaration and >> the actual array definition to have the sizes in sync, but the compiler >> does not check that. Really. >> >> IDK, feels like this merging this series is going to be extra churn. > > We need ADLS support on drm-tip by WW05 and I don't think this should change anything > as far as rebase is concerned as it will be just deletion of this entire section to move > into the separate stepping/revid file in your implementation. Fine, let's take the churn, no big deal. However, I think you'll find drm-intel-next and drm-intel-gt-next are currently too far from each other to even have a sensible topic branch baseline: $ git merge-base drm-intel/drm-intel-next drm-intel/drm-intel-gt-next 31b05212360cbf3af3c2e1b7f42e176e0eebedb5 Even if you do the minimal cherry-pick to drm-intel-next to be able to apply this series, you'll still end up with really bad merge trouble to get the platform support back to drm-intel-gt-next, and I presume that's what you'll need. And that means a topic branch. And that means: 1) New drm-intel-gt-next pull request 2) Have that merged to drm-next 3) Have drm-next backmerged to drm-intel-next to have a sensible baseline. > I think as a stop gap and to achieve the goal of ADLS patches being pushed in, these patches > look good enough. If extern/array declaration was a concern, why were the KBL/TGL pathces accepted > in the first place? Really, they should not have been. It's just poor design, and difficult to maintain long term. Data is not an interface. The driver is too big to bypass abstractions for this. See this: $ git grep -w extern -- drivers/gpu/drm/i915 > I will be happy to help with the rebase but the process of pushing > ADLS patches is stuck because of this. It's stuck because our -next branches are too far apart. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
