From: Jani Nikula <jani.nikula@linux.intel.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: "Knop, Ryszard" <ryszard.knop@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"rk@dragonic.eu" <rk@dragonic.eu>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"daniel@fooishbar.org" <daniel@fooishbar.org>,
Sima Vetter <sima@ffwll.ch>
Subject: Re: Discussion: Moving away from Patchwork for Intel i915/Xe CI
Date: Thu, 06 Mar 2025 12:42:07 +0200 [thread overview]
Message-ID: <87frjqwidc.fsf@intel.com> (raw)
In-Reply-To: <20250305-nonchalant-fresh-stoat-61ea0a@lemur>
On Wed, 05 Mar 2025, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Wed, Mar 05, 2025 at 07:52:31PM +0200, Jani Nikula wrote:
>> > - For each new series on lore.kernel.org a bridge would create a PR by
>> > taking the latest mirrored drm-tip source, then applying a new series
>> > with `b4 shazam`.
>>
>> There's a small catch here. Patchwork is currently more clever about
>> handling series revisions when only some of the patches in a series are
>> updated by way of replying to the individual patch. For example [1][2].
>
> FWIW, b4 does partial rerolls already. E.g., using your own example:
Yay, I upgraded to 0.14 and so it does. Thanks!
The point I made is moot, and I agree with Lucas that we should align
with what b4 does.
> $ b4 am -o/tmp 20250305114820.3523077-2-imre.deak@intel.com
> [...]
> ---
> ✓ [PATCH v5->v6 1/6] drm/i915/hpd: Track HPD pins instead of ports for HPD pulse events
> + Reviewed-by: Jani Nikula <jani.nikula@intel.com> (✓ DKIM/intel.com)
> ✓ [PATCH v5->v6 2/6] drm/i915/hpd: Let an HPD pin be in the disabled state when handling missed IRQs
> + Reviewed-by: Jani Nikula <jani.nikula@intel.com> (✓ DKIM/intel.com)
> ✓ [PATCH v6 3/6] drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin
> ✓ [PATCH v5->v6 4/6] drm/i915/dp: Fix link training interrupted by a short HPD pulse
> + Reviewed-by: Jani Nikula <jani.nikula@intel.com> (✓ DKIM/intel.com)
> ✓ [PATCH v6 5/6] drm/i915/dp: Queue a link check after link training is complete
> ✓ [PATCH v5->v6 6/6] drm/i915/crt: Use intel_hpd_block/unblock() instead of intel_hpd_disable/enable()
> ---
> ✓ Signed: DKIM/intel.com
Side note, I often pipe messages from my MUA (notmuch-emacs) to b4, as
it nicely parses the mails and picks up the message-id from
there. Overall it works great. However, b4 seems to err on the side of
writing color codes to pipes, and I get this as output:
---
[32m✓[0m [PATCH v5->v6 1/6] drm/i915/hpd: Track HPD pins instead of ports for HPD pulse events
+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> ([32m✓[0m DKIM/intel.com)
[32m✓[0m [PATCH v5->v6 2/6] drm/i915/hpd: Let an HPD pin be in the disabled state when handling missed IRQs
+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> ([32m✓[0m DKIM/intel.com)
[32m✓[0m [PATCH v6 3/6] drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin
[32m✓[0m [PATCH v5->v6 4/6] drm/i915/dp: Fix link training interrupted by a short HPD pulse
+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> ([32m✓[0m DKIM/intel.com)
[32m✓[0m [PATCH v6 5/6] drm/i915/dp: Queue a link check after link training is complete
[32m✓[0m [PATCH v5->v6 6/6] drm/i915/crt: Use intel_hpd_block/unblock() instead of intel_hpd_disable/enable()
---
[32m✓[0m Signed: DKIM/intel.com
---
I haven't had the time to dig into b4 source on this, but it would be
great if it could automatically detect whether sending colors is the
right thing to do or not. Basically only emit color codes to interactive
terminals, unless forced also for pipes.
(Alternatively I could try to figure out how to enable colors on emacs
pipe output, but that's another rabbit hole...)
Thanks,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-03-06 10:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 16:51 Discussion: Moving away from Patchwork for Intel i915/Xe CI Knop, Ryszard
2025-03-05 17:30 ` Lucas De Marchi
2025-03-05 17:52 ` Jani Nikula
2025-03-05 19:33 ` Konstantin Ryabitsev
2025-03-06 10:42 ` Jani Nikula [this message]
2025-03-06 16:44 ` Konstantin Ryabitsev
2025-03-07 9:23 ` Jani Nikula
2025-03-05 19:54 ` Ryszard Knop
2025-03-06 10:48 ` Jani Nikula
2025-03-05 20:32 ` Lucas De Marchi
2025-03-06 8:20 ` Jani Nikula
2025-03-13 10:22 ` Jani Nikula
2025-03-13 10:40 ` Jani Nikula
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=87frjqwidc.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=daniel@fooishbar.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=konstantin@linuxfoundation.org \
--cc=lucas.demarchi@intel.com \
--cc=rk@dragonic.eu \
--cc=ryszard.knop@intel.com \
--cc=sima@ffwll.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox