From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Dmitry Baryshkov" <lumag@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Rob Herring" <robh@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
kernel@collabora.com, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-doc@vger.kernel.org,
"Marius Vlad" <marius.vlad@collabora.com>
Subject: Re: [PATCH v7 03/22] drm: Add enum conversions between DRM_COLOR_FORMAT and HDMI_COLORSPACE
Date: Sat, 07 Feb 2026 20:55:16 +0100 [thread overview]
Message-ID: <2028270.PYKUYFuaPT@workhorse> (raw)
In-Reply-To: <20260206-angelic-crimson-bug-aaab40@houat>
On Friday, 6 February 2026 15:08:46 Central European Standard Time Maxime Ripard wrote:
> On Wed, Jan 21, 2026 at 03:45:10PM +0100, Nicolas Frattaroli wrote:
> > While the two enums have similar values, they're not identical, and
> > HDMI's enum is defined as per the HDMI standard.
> >
> > Add a simple conversion function from DRM to HDMI. Unexpected inputs
> > aren't handled in any clever way, DRM_COLOR_FORMAT_AUTO and any other
> > value that doesn't cleanly map to HDMI just gets returned as
> > HDMI_COLORSPACE_RGB.
> >
> > Add a second conversion function that gets a DRM_COLOR_FORMAT from an
> > HDMI_COLORSPACE as well. In this case, reserved HDMI values that can't
> > be converted will result in an -EINVAL return value.
> >
> > Co-developed-by: Marius Vlad <marius.vlad@collabora.com>
> > Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > include/drm/drm_connector.h | 54 +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index b5604dca728a..ffeb42f3b4a3 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -2612,6 +2612,60 @@ int drm_connector_attach_color_format_property(struct drm_connector *connector);
> >
> > const char *drm_get_color_format_name(enum drm_color_format color_fmt);
> >
> > +/**
> > + * drm_color_format_to_hdmi_colorspace - convert DRM color format to HDMI
> > + * @fmt: the &enum drm_color_format to convert
> > + *
> > + * Convert a given &enum drm_color_format to an equivalent
> > + * &enum hdmi_colorspace. For non-representable values and
> > + * %DRM_COLOR_FORMAT_AUTO, the value %HDMI_COLORSPACE_RGB is returned.
> > + *
> > + * Returns: the corresponding &enum hdmi_colorspace value
> > + */
> > +static inline enum hdmi_colorspace __pure
> > +drm_color_format_to_hdmi_colorspace(enum drm_color_format fmt)
> > +{
> > + switch (fmt) {
> > + default:
> > + case DRM_COLOR_FORMAT_AUTO:
> > + case DRM_COLOR_FORMAT_RGB444:
> > + return HDMI_COLORSPACE_RGB;
>
> I don't think that's correct. What auto ends up as totally depends on
> the atomic state it comes with.
>
> At the very least, you should output a warning there, because that case
> should never happen.
Yeah, my hope was to keep this function __pure so that the compiler
has maximum freedom to do whatever. With a WARN, it's got side-effects
now, and we're no longer pure. With a status return value and an output
parameter, it's no longer pure either, because the output parameter is
not local memory.
The limiting factor here is that as I understand correctly, I can't
really extend the hdmi_colorspace enum, as it's basically 1:1 from
the standard. Doing this would be the ideal solution, because we'd
keep the function pure and without surprise conversions happening.
Looking at hdmi_colorspace_get_name in drivers/video/hdmi.c, it returns
"Invalid" for any value not in the enum itself. Would it be allowable
to tack an HDMI_COLORSPACE_INVALID at the end of the enum with perhaps
a negative value, or is there a different approach you'd prefer?
I agree that the AUTO-to-RGB conversion shouldn't happen here, that's
a recipe for things implicitly relying on this behaviour, which isn't
great. (And I think I even do this in "hdmi-state-helper: Act on color
format DRM property", where thinking about it again I agree this isn't
super obvious and should be done explicitly instead.)
> > + case DRM_COLOR_FORMAT_YCBCR444:
> > + return HDMI_COLORSPACE_YUV444;
> > + case DRM_COLOR_FORMAT_YCBCR422:
> > + return HDMI_COLORSPACE_YUV422;
> > + case DRM_COLOR_FORMAT_YCBCR420:
> > + return HDMI_COLORSPACE_YUV420;
> > + }
> > +}
> > +
> > +/**
> > + * drm_color_format_from_hdmi_colorspace - convert HDMI color format to DRM
> > + * @fmt: the &enum hdmi_colorspace to convert
> > + *
> > + * Convert a given &enum hdmi_colorspace to an equivalent
> > + * &enum drm_color_format. For non-representable values,
> > + * %-EINVAL is returned.
> > + *
> > + * Returns: the corresponding &enum drm_color_format value, or %-EINVAL
> > + */
> > +static inline enum drm_color_format __pure
> > +drm_color_format_from_hdmi_colorspace(enum hdmi_colorspace fmt)
> > +{
> > + switch (fmt) {
> > + default:
> > + return -EINVAL;
>
> Wait, what?
>
> -EINVAL is not a valid value for your enum.
Not the only part of the kernel where we rely on the int-ness of
enums, but your complaint has been noted :) I guess this means
this approach won't fly for the opposite direction. Thankfully,
in this direction, we can extend the drm_color_format enum to
have an error value.
Kind regards,
Nicolas Frattaroli
>
> Maxime
>
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Dmitry Baryshkov" <lumag@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Rob Herring" <robh@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
kernel@collabora.com, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-doc@vger.kernel.org,
"Marius Vlad" <marius.vlad@collabora.com>
Subject: Re: [PATCH v7 03/22] drm: Add enum conversions between DRM_COLOR_FORMAT and HDMI_COLORSPACE
Date: Sat, 07 Feb 2026 20:55:16 +0100 [thread overview]
Message-ID: <2028270.PYKUYFuaPT@workhorse> (raw)
In-Reply-To: <20260206-angelic-crimson-bug-aaab40@houat>
On Friday, 6 February 2026 15:08:46 Central European Standard Time Maxime Ripard wrote:
> On Wed, Jan 21, 2026 at 03:45:10PM +0100, Nicolas Frattaroli wrote:
> > While the two enums have similar values, they're not identical, and
> > HDMI's enum is defined as per the HDMI standard.
> >
> > Add a simple conversion function from DRM to HDMI. Unexpected inputs
> > aren't handled in any clever way, DRM_COLOR_FORMAT_AUTO and any other
> > value that doesn't cleanly map to HDMI just gets returned as
> > HDMI_COLORSPACE_RGB.
> >
> > Add a second conversion function that gets a DRM_COLOR_FORMAT from an
> > HDMI_COLORSPACE as well. In this case, reserved HDMI values that can't
> > be converted will result in an -EINVAL return value.
> >
> > Co-developed-by: Marius Vlad <marius.vlad@collabora.com>
> > Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > include/drm/drm_connector.h | 54 +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index b5604dca728a..ffeb42f3b4a3 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -2612,6 +2612,60 @@ int drm_connector_attach_color_format_property(struct drm_connector *connector);
> >
> > const char *drm_get_color_format_name(enum drm_color_format color_fmt);
> >
> > +/**
> > + * drm_color_format_to_hdmi_colorspace - convert DRM color format to HDMI
> > + * @fmt: the &enum drm_color_format to convert
> > + *
> > + * Convert a given &enum drm_color_format to an equivalent
> > + * &enum hdmi_colorspace. For non-representable values and
> > + * %DRM_COLOR_FORMAT_AUTO, the value %HDMI_COLORSPACE_RGB is returned.
> > + *
> > + * Returns: the corresponding &enum hdmi_colorspace value
> > + */
> > +static inline enum hdmi_colorspace __pure
> > +drm_color_format_to_hdmi_colorspace(enum drm_color_format fmt)
> > +{
> > + switch (fmt) {
> > + default:
> > + case DRM_COLOR_FORMAT_AUTO:
> > + case DRM_COLOR_FORMAT_RGB444:
> > + return HDMI_COLORSPACE_RGB;
>
> I don't think that's correct. What auto ends up as totally depends on
> the atomic state it comes with.
>
> At the very least, you should output a warning there, because that case
> should never happen.
Yeah, my hope was to keep this function __pure so that the compiler
has maximum freedom to do whatever. With a WARN, it's got side-effects
now, and we're no longer pure. With a status return value and an output
parameter, it's no longer pure either, because the output parameter is
not local memory.
The limiting factor here is that as I understand correctly, I can't
really extend the hdmi_colorspace enum, as it's basically 1:1 from
the standard. Doing this would be the ideal solution, because we'd
keep the function pure and without surprise conversions happening.
Looking at hdmi_colorspace_get_name in drivers/video/hdmi.c, it returns
"Invalid" for any value not in the enum itself. Would it be allowable
to tack an HDMI_COLORSPACE_INVALID at the end of the enum with perhaps
a negative value, or is there a different approach you'd prefer?
I agree that the AUTO-to-RGB conversion shouldn't happen here, that's
a recipe for things implicitly relying on this behaviour, which isn't
great. (And I think I even do this in "hdmi-state-helper: Act on color
format DRM property", where thinking about it again I agree this isn't
super obvious and should be done explicitly instead.)
> > + case DRM_COLOR_FORMAT_YCBCR444:
> > + return HDMI_COLORSPACE_YUV444;
> > + case DRM_COLOR_FORMAT_YCBCR422:
> > + return HDMI_COLORSPACE_YUV422;
> > + case DRM_COLOR_FORMAT_YCBCR420:
> > + return HDMI_COLORSPACE_YUV420;
> > + }
> > +}
> > +
> > +/**
> > + * drm_color_format_from_hdmi_colorspace - convert HDMI color format to DRM
> > + * @fmt: the &enum hdmi_colorspace to convert
> > + *
> > + * Convert a given &enum hdmi_colorspace to an equivalent
> > + * &enum drm_color_format. For non-representable values,
> > + * %-EINVAL is returned.
> > + *
> > + * Returns: the corresponding &enum drm_color_format value, or %-EINVAL
> > + */
> > +static inline enum drm_color_format __pure
> > +drm_color_format_from_hdmi_colorspace(enum hdmi_colorspace fmt)
> > +{
> > + switch (fmt) {
> > + default:
> > + return -EINVAL;
>
> Wait, what?
>
> -EINVAL is not a valid value for your enum.
Not the only part of the kernel where we rely on the int-ness of
enums, but your complaint has been noted :) I guess this means
this approach won't fly for the opposite direction. Thankfully,
in this direction, we can extend the drm_color_format enum to
have an error value.
Kind regards,
Nicolas Frattaroli
>
> Maxime
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-02-09 8:41 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 14:45 [PATCH v7 00/22] Add new general DRM property "color format" Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 01/22] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 02/22] drm: Add new general DRM property "color format" Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-06 14:05 ` Maxime Ripard
2026-02-06 14:05 ` Maxime Ripard
2026-02-06 15:26 ` Nicolas Frattaroli
2026-02-06 15:26 ` Nicolas Frattaroli
2026-02-10 17:03 ` Maxime Ripard
2026-02-10 17:03 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 03/22] drm: Add enum conversions between DRM_COLOR_FORMAT and HDMI_COLORSPACE Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-06 14:08 ` Maxime Ripard
2026-02-06 14:08 ` Maxime Ripard
2026-02-07 19:55 ` Nicolas Frattaroli [this message]
2026-02-07 19:55 ` Nicolas Frattaroli
2026-02-10 17:24 ` Maxime Ripard
2026-02-10 17:24 ` Maxime Ripard
2026-02-11 17:10 ` Nicolas Frattaroli
2026-02-11 17:10 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 04/22] drm/bridge: Act on the DRM color format property Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 05/22] drm/display: hdmi-state-helper: Act on color format DRM property Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-06 14:16 ` Maxime Ripard
2026-02-06 14:16 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 06/22] drm/display: hdmi-state-helper: Try subsampling in mode_valid Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 07/22] drm/i915: Implement the "color format" DRM property Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 08/22] drm/amdgpu: Implement " Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 09/22] drm/rockchip: Add YUV422 output mode constants for VOP2 Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-22 6:30 ` Andy Yan
2026-01-22 6:30 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 10/22] drm/rockchip: vop2: Fix YUV444 output Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-22 8:28 ` Andy Yan
2026-01-22 8:28 ` Andy Yan
2026-01-22 12:59 ` [PATCH " Nicolas Frattaroli
2026-01-22 12:59 ` Nicolas Frattaroli
2026-01-23 1:29 ` Andy Yan
2026-01-23 1:29 ` Andy Yan
2026-02-07 19:31 ` Nicolas Frattaroli
2026-02-07 19:31 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 11/22] drm/rockchip: vop2: Add RK3576 to the RG swap special case Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-22 8:31 ` Andy Yan
2026-01-22 8:31 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 12/22] drm/rockchip: vop2: Recognise 10/12-bit YUV422 as YUV formats Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-22 8:42 ` Andy Yan
2026-01-22 8:42 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 13/22] drm/rockchip: vop2: Set correct output format for RK3576 YUV422 Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-22 8:44 ` Andy Yan
2026-01-22 8:44 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 14/22] drm/bridge: dw-hdmi-qp: Implement atomic_get_output_bus_fmts Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 15/22] drm/rockchip: dw_hdmi_qp: Implement "color format" DRM property Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 16/22] drm/rockchip: dw_hdmi_qp: Set supported_formats platdata Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 17/22] drm/connector: Register color format property on HDMI connectors Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 18/22] drm/tests: hdmi: Add tests for the color_format property Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-10 15:51 ` Maxime Ripard
2026-02-10 15:51 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 19/22] drm/tests: hdmi: Add tests for HDMI helper's mode_valid Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-10 15:52 ` Maxime Ripard
2026-02-10 15:52 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 20/22] drm/tests: edid: Add __maybe_unused attribute to EDID definitions Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-10 16:00 ` Maxime Ripard
2026-02-10 16:00 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 21/22] drm/tests: bridge: Add KUnit tests for bridge chain format selection Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-10 16:11 ` Maxime Ripard
2026-02-10 16:11 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 22/22] drm/bridge: Document " Nicolas Frattaroli
2026-01-21 14:45 ` Nicolas Frattaroli
2026-02-10 16:25 ` Maxime Ripard
2026-02-10 16:25 ` Maxime Ripard
2026-01-21 15:23 ` ✗ CI.checkpatch: warning for Add new general DRM property "color format" (rev4) Patchwork
2026-01-21 15:25 ` ✓ CI.KUnit: success " Patchwork
2026-01-21 15:43 ` ✗ CI.checksparse: warning " Patchwork
2026-01-21 16:07 ` ✓ Xe.CI.BAT: success " Patchwork
2026-01-21 16:34 ` ✓ i915.CI.BAT: " Patchwork
2026-01-21 23:46 ` ✓ Xe.CI.Full: " Patchwork
2026-01-22 3:00 ` ✓ i915.CI.Full: " Patchwork
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=2028270.PYKUYFuaPT@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marius.vlad@collabora.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=s.hauer@pengutronix.de \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
/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.