From: Jani Nikula <jani.nikula@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
Date: Tue, 12 Jan 2021 18:18:03 +0200 [thread overview]
Message-ID: <87r1mqt9hg.fsf@intel.com> (raw)
In-Reply-To: <20210112020409.ev7hs4rngooeyorp@ldmartin-desk1>
On Mon, 11 Jan 2021, Lucas De Marchi <lucas.demarchi@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@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.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-01-12 16:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 23:18 [Intel-gfx] [PATCH 0/2] Use TGL stepping info and add ADLS platform changes Aditya Swarup
2021-01-08 23:18 ` [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs Aditya Swarup
2021-01-08 23:44 ` Matt Roper
2021-01-11 20:13 ` Jani Nikula
2021-01-11 20:18 ` Jani Nikula
2021-01-11 20:57 ` Matt Roper
2021-01-11 21:25 ` Lucas De Marchi
2021-01-12 16:24 ` Jani Nikula
2021-01-12 17:16 ` Matt Roper
2021-01-12 17:33 ` Vivi, Rodrigo
2021-01-12 17:39 ` Jani Nikula
2021-01-11 22:58 ` Aditya Swarup
2021-01-12 16:32 ` Jani Nikula
2021-01-11 20:20 ` Aditya Swarup
2021-01-12 16:11 ` Jani Nikula
2021-01-12 2:04 ` Lucas De Marchi
2021-01-12 16:18 ` Jani Nikula [this message]
2021-01-08 23:18 ` [Intel-gfx] [PATCH 2/2] drm/i915/adl_s: Add ADL-S platform info and PCI ids Aditya Swarup
2021-01-09 0:20 ` Matt Roper
2021-01-11 19:37 ` Aditya Swarup
2021-01-09 2:21 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Use TGL stepping info and add ADLS platform changes Patchwork
2021-01-09 2:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-01-09 10:58 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-01-11 19:29 [Intel-gfx] [PATCH 0/2] " Aditya Swarup
2021-01-11 19:29 ` [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs Aditya Swarup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r1mqt9hg.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.