[Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs

Jani Nikula jani.nikula at linux.intel.com
Tue Jan 12 16:18:03 UTC 2021

On Mon, 11 Jan 2021, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
> On Mon, Jan 11, 2021 at 10:13:15PM +0200, Jani Nikula wrote:
>>On Fri, 08 Jan 2021, Matt Roper <matthew.d.roper at intel.com> wrote:
> in the end both sides will need that (even if it was a mistake to merge
> it in drm-intel-gt-next).  I got an ack from Rodrigo to actually
> cherry-pick the single patch we are missing so this can unblock both
> merging this patch (after rebasing) and you can continue your series.

cherry-picking the one patch is not enough. The -next branches are too
far apart to start applying ADL-S patches in either branch. Doing so
will lead to way too bad merge conflicts.

Which just means the cherry-pick won't help, as you'll need a topic
branch with a sensible baseline to merge the ADL-S support to both
branches. Now the merge-base is too far away.

>>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.
> not following what the ARRAY_SIZE is not checking. It actually is, since
> the declaration is explicitly telling the size of the array. If the
> definition had more items, you'd get a compilation error.

Mmmh, I tested this, but can't reproduce now. Never mind. *shrug*.

>>IDK, feels like this merging this series is going to be extra churn.
> I'm not against the refactor you're talking about, but this seems an
> improvement to unblock the ADL-S patches that are pending. The patches
> could also be split to remove this dependency, but I'm not sure it's
> worth it.

Please let's first get the branches back in sync, and then create a
topic branch for ADL-S, and merge it to both. Everything else will lead
to tears.


Jani Nikula, Intel Open Source Graphics Center

More information about the Intel-gfx mailing list