From: Jani Nikula <jani.nikula@linux.intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Imre Deak <imre.deak@intel.com>
Subject: Re: [RFC PATCH 01/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/DP_RATE field macros
Date: Wed, 01 Oct 2025 12:57:31 +0300 [thread overview]
Message-ID: <da513f4b6dfc42b4e85de69ce25666d0b1447c73@intel.com> (raw)
In-Reply-To: <aNztFxlDWeuc13nn@black.igk.intel.com>
On Wed, 01 Oct 2025, Raag Jadav <raag.jadav@intel.com> wrote:
> On Wed, Oct 01, 2025 at 11:52:20AM +0300, Jani Nikula wrote:
>> On Wed, 01 Oct 2025, Mika Kahola <mika.kahola@intel.com> wrote:
>> > Signed-off-by: Imre Deak <imre.deak@intel.com>
>>
>> You need to add your Signed-off-by when sending someone else's patches.
>
> Isn't this only when the submitter has made adjustments to originally
> authored code?
No. You *always* need to add your Signed-off-by when contributing to the
kernel, regardless of whether you were involved in the development of
the patch, or just handling and transporting the patch. See (c) in [1].
BR,
Jani.
[1] https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-10-01 9:57 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 8:28 [RFC PATCH 00/39] drm/i915/display: Add MTL+ platforms to support dpll framework Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 01/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/DP_RATE field macros Mika Kahola
2025-10-01 8:52 ` Jani Nikula
2025-10-01 8:57 ` Raag Jadav
2025-10-01 9:57 ` Jani Nikula [this message]
2025-10-01 10:01 ` Kahola, Mika
2025-10-01 8:28 ` [RFC PATCH 02/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/IS_DP flag macro Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 03/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/CONTEXT_TOGGLE " Mika Kahola
2025-10-01 8:49 ` Jani Nikula
2025-10-01 8:28 ` [RFC PATCH 04/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/IS_HDMI_FRL " Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 05/39] drm/i915/display: Fix PHY_C20_VDR_CUSTOM_SERDES_RATE programming Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 06/39] drm/i915/display: Fix PHY_C20_VDR_HDMI_RATE programming Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 07/39] drm/i915/display: Add missing clock to C10 PHY state compute/HW readout Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 08/39] drm/i915/display: Rename TBT functions to be ICL specific Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 09/39] drm/i915/display: Factor out C10 msgbus access start/end helpers Mika Kahola
2025-10-01 8:55 ` Jani Nikula
2025-10-01 8:28 ` [RFC PATCH 10/39] drm/i915/display: Sanitize setting the Cx0 PLL use_c10 flag Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 11/39] drm/i915/display: Sanitize calculating C20 PLL state from tables Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 12/39] drm/i915/display: Track the C20 PHY VDR state in the PLL state Mika Kahola
2025-10-01 9:03 ` Jani Nikula
2025-10-01 8:28 ` [RFC PATCH 13/39] drm/i915/display: Move definition of Cx0 PHY functions earlier Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 14/39] drm/i915/display: Add macro to get DDI port width from a register value Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 15/39] drm/i915/display: Track the Cx0 PHY enabled lane count in the PLL state Mika Kahola
2025-10-01 9:13 ` Jani Nikula
2025-10-01 12:09 ` Imre Deak
2025-10-01 8:28 ` [RFC PATCH 16/39] drm/i915/display: Sanitize C10 PHY PLL SSC register setup Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 17/39] drm/i915/display: Read out the Cx0 PHY SSC enabled state Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 18/39] drm/i915/display: Determine Cx0 PLL DP mode from PLL state Mika Kahola
2025-10-01 9:16 ` Jani Nikula
2025-10-16 18:04 ` Ville Syrjälä
2025-10-20 10:51 ` Jani Nikula
2025-10-01 8:28 ` [RFC PATCH 19/39] drm/i915/display: Determine Cx0 PLL port clock " Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 20/39] drm/i915/display: Zero Cx0 PLL state before compute and HW readout Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 21/39] drm/i915/display: Print additional Cx0 PLL HW state Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 22/39] drm/i915/display: Remove state verification Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 23/39] drm/i915/display: PLL information for MTL+ Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 24/39] drm/i915/display: Update C10/C20 state calculation Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 25/39] drm/i915/display: Compute plls for MTL+ platform Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 26/39] drm/i915/display: MTL+ .get_dplls Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 27/39] drm/i915/display: MTL+ .put_dplls Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 28/39] drm/i915/display: Add .update_active_dpll Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 29/39] drm/i915/display: Add .update_dpll_ref_clks Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 30/39] drm/i915/display: Add .dump_hw_state Mika Kahola
2025-10-01 9:33 ` Jani Nikula
2025-10-02 9:12 ` Kahola, Mika
2025-10-01 8:28 ` [RFC PATCH 31/39] drm/i915/display: Add .compare_hw_state Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 32/39] drm/i915/display: Add .get_hw_state to MTL+ platforms Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 33/39] drm/i915/display: Add .get_freq " Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 34/39] drm/i915/display: Add .crtc_get_dpll hook Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 35/39] drm/i915/display: PLL verify debug state print Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 36/39] drm/i915/display: Add .enable_clock on DDI for MTL+ platforms Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 37/39] drm/i915/display: Get configuration for C10 and C20 Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 38/39] drm/i915/display: Add Thunderbolt support Mika Kahola
2025-10-01 8:28 ` [RFC PATCH 39/39] drm/i915/display: Enable dpll framework for MTL+ Mika Kahola
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=da513f4b6dfc42b4e85de69ce25666d0b1447c73@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=mika.kahola@intel.com \
--cc=raag.jadav@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox