From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Thierry Reding <treding@nvidia.com>
Cc: Rob Herring <robherring2@gmail.com>,
Yakir Yang <ykk@rock-chips.com>, Heiko Stuebner <heiko@sntech.de>,
Jingoo Han <jingoohan1@gmail.com>,
Fabio Estevam <fabio.estevam@freescale.com>,
Inki Dae <inki.dae@samsung.com>, Joe Perches <joe@perches.com>,
Sean Paul <seanpaul@google.com>, Takashi Iwai <tiwai@suse.de>,
dri-devel <dri-devel@lists.freedesktop.org>,
Andrzej Hajda <a.hajda@samsung.com>,
Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
Vincent Palatin <vpalatin@chromium.org>,
linux-rockchip@lists.infradead.org,
Kishon Vijay Abraham I <kishon@ti.com>,
David Airlie <airlied@linux.ie>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Doug Anderson <dianders@google.com>,
Rob Herring <robh+dt@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Mark Yao <mark.yao@rock-chips.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kyungmin Park <kyungmin.park@samsung.com>,
Daniel Kurtz <djkurtz@google.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Kumar Gala <galak@codeaurora.org>,
Ajay kumar <ajaynumb@gmail.com>,
Andy Yan <andy.yan@rock-chips.com>
Subject: Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Date: Tue, 25 Aug 2015 10:29:39 +0100 [thread overview]
Message-ID: <20150825092939.GM7557@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20150825091246.GA14034@ulmo.nvidia.com>
On Tue, Aug 25, 2015 at 11:12:48AM +0200, Thierry Reding wrote:
> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
> > It goes beyond bindings IMO. The use of the component framework or not
> > has been at the whim of driver writers as well. It is either used or
> > private APIs are created. I'm using components and my need for it
> > boils down to passing the struct drm_device pointer to the encoder.
> > Other components like panels and bridges have different ways to attach
> > to the DRM driver.
>
> I certainly support unification, but it needs to be reasonable. There
> are cases where a different structure for the binding work better than
> another and I think this always needs to be evaluated on a case by case
> basis.
It can't be a case-by-case basis.
The TDA998x encoder/connector is going to be component only. This is
a generic chip, which can be attached to the output of any parallel
RGB+sync+clock bus. In other words, it could appear anywhere.
Are you really saying that we need to support multiple schemes of
attaching the driver to DRM? That's totally insane IMHO.
The problem with the drm_encoder_slave stuff is that you can't sanely
attach of-nodes to the drm-created i2c device. Yes, you can parse
them from the DT file as a sub-node of the upper device, but that
then goes against the principle of the I2C bindings, which is to
list the I2C devices as a child below the I2C adapter node. If you
try and put the DT node there, then the OF code will create the I2C
device for you, and the drm_encoder_slave stuff won't have the
control it needs to communicate through the wrapped i2c_driver
stuff.
So, tda998x is going component-only, as that's the _only_ sane solution
for it.
Now, what happens when some other DRM driver wants to use the tda998x
driver, and its bindings are not compatible with the component helpers?
They're pretty much stuck up the creek without a paddle.
Case by case doesn't work unless you're talking about truely isolated
hardware where no one shares anything.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
To: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
Jingoo Han <jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Fabio Estevam
<fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>,
Sean Paul <seanpaul-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Gustavo Padovan
<gustavo.padovan-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>,
"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Vincent Palatin
<vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>,
David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Doug Anderson <dianders-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Date: Tue, 25 Aug 2015 10:29:39 +0100 [thread overview]
Message-ID: <20150825092939.GM7557@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20150825091246.GA14034-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
On Tue, Aug 25, 2015 at 11:12:48AM +0200, Thierry Reding wrote:
> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
> > It goes beyond bindings IMO. The use of the component framework or not
> > has been at the whim of driver writers as well. It is either used or
> > private APIs are created. I'm using components and my need for it
> > boils down to passing the struct drm_device pointer to the encoder.
> > Other components like panels and bridges have different ways to attach
> > to the DRM driver.
>
> I certainly support unification, but it needs to be reasonable. There
> are cases where a different structure for the binding work better than
> another and I think this always needs to be evaluated on a case by case
> basis.
It can't be a case-by-case basis.
The TDA998x encoder/connector is going to be component only. This is
a generic chip, which can be attached to the output of any parallel
RGB+sync+clock bus. In other words, it could appear anywhere.
Are you really saying that we need to support multiple schemes of
attaching the driver to DRM? That's totally insane IMHO.
The problem with the drm_encoder_slave stuff is that you can't sanely
attach of-nodes to the drm-created i2c device. Yes, you can parse
them from the DT file as a sub-node of the upper device, but that
then goes against the principle of the I2C bindings, which is to
list the I2C devices as a child below the I2C adapter node. If you
try and put the DT node there, then the OF code will create the I2C
device for you, and the drm_encoder_slave stuff won't have the
control it needs to communicate through the wrapped i2c_driver
stuff.
So, tda998x is going component-only, as that's the _only_ sane solution
for it.
Now, what happens when some other DRM driver wants to use the tda998x
driver, and its bindings are not compatible with the component helpers?
They're pretty much stuck up the creek without a paddle.
Case by case doesn't work unless you're talking about truely isolated
hardware where no one shares anything.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Date: Tue, 25 Aug 2015 10:29:39 +0100 [thread overview]
Message-ID: <20150825092939.GM7557@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20150825091246.GA14034@ulmo.nvidia.com>
On Tue, Aug 25, 2015 at 11:12:48AM +0200, Thierry Reding wrote:
> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
> > It goes beyond bindings IMO. The use of the component framework or not
> > has been at the whim of driver writers as well. It is either used or
> > private APIs are created. I'm using components and my need for it
> > boils down to passing the struct drm_device pointer to the encoder.
> > Other components like panels and bridges have different ways to attach
> > to the DRM driver.
>
> I certainly support unification, but it needs to be reasonable. There
> are cases where a different structure for the binding work better than
> another and I think this always needs to be evaluated on a case by case
> basis.
It can't be a case-by-case basis.
The TDA998x encoder/connector is going to be component only. This is
a generic chip, which can be attached to the output of any parallel
RGB+sync+clock bus. In other words, it could appear anywhere.
Are you really saying that we need to support multiple schemes of
attaching the driver to DRM? That's totally insane IMHO.
The problem with the drm_encoder_slave stuff is that you can't sanely
attach of-nodes to the drm-created i2c device. Yes, you can parse
them from the DT file as a sub-node of the upper device, but that
then goes against the principle of the I2C bindings, which is to
list the I2C devices as a child below the I2C adapter node. If you
try and put the DT node there, then the OF code will create the I2C
device for you, and the drm_encoder_slave stuff won't have the
control it needs to communicate through the wrapped i2c_driver
stuff.
So, tda998x is going component-only, as that's the _only_ sane solution
for it.
Now, what happens when some other DRM driver wants to use the tda998x
driver, and its bindings are not compatible with the component helpers?
They're pretty much stuck up the creek without a paddle.
Case by case doesn't work unless you're talking about truely isolated
hardware where no one shares anything.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2015-08-25 9:30 UTC|newest]
Thread overview: 187+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 14:48 [PATCH v3 0/14] Add Analogix Core Display Port Driver Yakir Yang
2015-08-19 14:48 ` Yakir Yang
2015-08-19 14:49 ` [PATCH v3 01/14] drm: exynos/dp: fix code style Yakir Yang
2015-08-19 14:49 ` Yakir Yang
2015-08-19 14:49 ` [PATCH v3 02/14] drm: exynos/dp: convert to drm bridge mode Yakir Yang
2015-08-19 14:49 ` Yakir Yang
2015-08-19 14:50 ` [PATCH v3 03/14] drm: bridge: analogix_dp: split exynos dp driver to bridge dir Yakir Yang
2015-08-19 14:50 ` Yakir Yang
2015-08-19 14:50 ` [PATCH v3 04/14] drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & colorimetry Yakir Yang
2015-08-19 14:50 ` Yakir Yang
2015-08-19 14:50 ` [PATCH v3 05/14] drm: bridge/analogix_dp: fix link_rate & lane_count bug Yakir Yang
2015-08-19 14:50 ` Yakir Yang
2015-08-20 7:22 ` Jingoo Han
2015-08-20 7:22 ` Jingoo Han
2015-08-20 7:22 ` Jingoo Han
2015-08-20 8:04 ` Yakir Yang
2015-08-20 8:04 ` Yakir Yang
2015-08-20 8:04 ` Yakir Yang
2015-08-19 14:50 ` [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Yakir Yang
2015-08-19 14:50 ` Yakir Yang
2015-08-23 23:23 ` Rob Herring
2015-08-23 23:23 ` Rob Herring
2015-08-23 23:23 ` Rob Herring
2015-08-24 0:43 ` Krzysztof Kozlowski
2015-08-24 0:43 ` Krzysztof Kozlowski
2015-08-24 0:43 ` Krzysztof Kozlowski
2015-08-24 2:42 ` Yakir Yang
2015-08-24 2:42 ` Yakir Yang
2015-08-24 4:20 ` Krzysztof Kozlowski
2015-08-24 4:20 ` Krzysztof Kozlowski
2015-08-24 4:20 ` Krzysztof Kozlowski
2015-08-24 12:48 ` Yakir Yang
2015-08-24 12:48 ` Yakir Yang
2015-08-24 12:48 ` Yakir Yang
2015-08-24 13:03 ` Heiko Stuebner
2015-08-24 13:03 ` Heiko Stuebner
2015-08-24 13:03 ` Heiko Stuebner
2015-08-25 1:37 ` Yakir Yang
2015-08-25 1:37 ` Yakir Yang
2015-08-25 1:37 ` Yakir Yang
2015-08-24 23:49 ` Krzysztof Kozlowski
2015-08-24 23:49 ` Krzysztof Kozlowski
2015-08-24 23:49 ` Krzysztof Kozlowski
[not found] ` <55DBAD90.3040901-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-08-25 1:32 ` Yakir Yang
2015-08-25 1:33 ` Yakir Yang
2015-08-25 1:33 ` Yakir Yang
2015-08-25 1:33 ` Yakir Yang
2015-08-25 1:35 ` Krzysztof Kozlowski
2015-08-25 1:35 ` Krzysztof Kozlowski
2015-08-25 1:35 ` Krzysztof Kozlowski
2015-08-24 7:40 ` Jingoo Han
2015-08-24 7:40 ` Jingoo Han
2015-08-24 7:40 ` Jingoo Han
2015-08-24 12:55 ` Yakir Yang
2015-08-24 12:55 ` Yakir Yang
2015-08-24 12:55 ` Yakir Yang
2015-08-24 2:19 ` Yakir Yang
2015-08-24 2:19 ` Yakir Yang
2015-08-24 12:57 ` Russell King - ARM Linux
2015-08-24 12:57 ` Russell King - ARM Linux
2015-08-24 12:57 ` Russell King - ARM Linux
2015-08-24 14:48 ` Rob Herring
2015-08-24 14:48 ` Rob Herring
2015-08-24 14:48 ` Rob Herring
2015-08-24 16:16 ` Heiko Stuebner
2015-08-24 16:16 ` Heiko Stuebner
2015-08-24 16:16 ` Heiko Stuebner
2015-08-25 1:21 ` Yakir Yang
2015-08-25 1:21 ` Yakir Yang
2015-08-25 1:21 ` Yakir Yang
2015-08-25 9:12 ` Thierry Reding
2015-08-25 9:12 ` Thierry Reding
2015-08-25 9:12 ` Thierry Reding
2015-08-25 9:29 ` Russell King - ARM Linux [this message]
2015-08-25 9:29 ` Russell King - ARM Linux
2015-08-25 9:29 ` Russell King - ARM Linux
2015-08-25 10:40 ` Thierry Reding
2015-08-25 10:40 ` Thierry Reding
2015-08-25 10:40 ` Thierry Reding
2015-08-25 10:52 ` Russell King - ARM Linux
2015-08-25 10:52 ` Russell King - ARM Linux
2015-08-25 10:52 ` Russell King - ARM Linux
2015-08-25 9:41 ` Yakir Yang
2015-08-25 9:41 ` Yakir Yang
2015-08-25 10:06 ` Thierry Reding
2015-08-25 10:06 ` Thierry Reding
2015-08-25 10:06 ` Thierry Reding
2015-08-25 14:02 ` Yakir Yang
2015-08-25 14:02 ` Yakir Yang
2015-08-25 9:15 ` Thierry Reding
2015-08-25 9:15 ` Thierry Reding
2015-08-25 9:15 ` Thierry Reding
2015-08-25 9:37 ` Yakir Yang
2015-08-25 9:37 ` Yakir Yang
2015-08-25 13:27 ` Rob Herring
2015-08-25 13:27 ` Rob Herring
2015-08-25 13:27 ` Rob Herring
2015-08-25 13:48 ` Yakir Yang
2015-08-25 14:16 ` Thierry Reding
2015-08-25 14:16 ` Thierry Reding
2015-08-25 14:16 ` Thierry Reding
2015-08-25 14:23 ` Yakir Yang
2015-08-25 14:23 ` Yakir Yang
2015-08-25 9:58 ` Thierry Reding
2015-08-25 9:58 ` Thierry Reding
2015-08-25 9:58 ` Thierry Reding
2015-08-25 14:03 ` Yakir Yang
2015-08-25 14:03 ` Yakir Yang
2015-08-25 14:21 ` Thierry Reding
2015-08-25 14:21 ` Thierry Reding
2015-08-25 14:21 ` Thierry Reding
2015-08-25 15:57 ` Russell King - ARM Linux
2015-08-25 15:57 ` Russell King - ARM Linux
2015-08-25 15:57 ` Russell King - ARM Linux
2015-08-19 14:50 ` [PATCH v3 07/14] drm: rockchip/dp: add rockchip platform dp driver Yakir Yang
2015-08-19 14:50 ` Yakir Yang
2015-08-19 14:50 ` Yakir Yang
2015-08-19 14:51 ` [PATCH v3 08/14] phy: Add driver for rockchip Display Port PHY Yakir Yang
2015-08-19 14:51 ` Yakir Yang
2015-08-20 4:40 ` Kishon Vijay Abraham I
2015-08-20 4:40 ` Kishon Vijay Abraham I
2015-08-20 4:40 ` Kishon Vijay Abraham I
2015-08-20 6:56 ` Yakir Yang
2015-08-20 7:01 ` Yakir Yang
2015-08-19 14:51 ` [PATCH v3 09/14] drm: bridge/analogix_dp: add platform device type support Yakir Yang
2015-08-19 14:51 ` Yakir Yang
2015-08-19 14:51 ` Yakir Yang
2015-08-19 14:51 ` [PATCH v3 10/14] drm: bridge: analogix_dp: add some rk3288 special registers setting Yakir Yang
2015-08-19 14:51 ` Yakir Yang
2015-08-19 14:51 ` [PATCH v3 11/14] drm: bridge: analogix_dp: try force hpd after plug in lookup failed Yakir Yang
2015-08-19 14:51 ` Yakir Yang
2015-08-19 14:52 ` [PATCH v3 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect Yakir Yang
2015-08-19 14:52 ` Yakir Yang
2015-08-19 14:52 ` Yakir Yang
2015-08-20 6:11 ` Jingoo Han
2015-08-20 6:11 ` Jingoo Han
2015-08-20 6:11 ` Jingoo Han
2015-08-20 8:02 ` Yakir Yang
2015-08-20 8:02 ` Yakir Yang
2015-08-20 8:02 ` Yakir Yang
2015-08-19 14:52 ` [PATCH v3 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function Yakir Yang
2015-08-19 14:52 ` Yakir Yang
2015-08-20 7:49 ` Jingoo Han
2015-08-20 7:49 ` Jingoo Han
2015-08-20 7:49 ` Jingoo Han
2015-08-20 8:18 ` Yakir Yang
2015-08-20 8:18 ` Yakir Yang
2015-08-20 8:18 ` Yakir Yang
2015-08-19 14:52 ` [PATCH v3 14/14] drm: bridge/analogix_dp: add edid modes parse in get_modes method Yakir Yang
2015-08-19 14:52 ` Yakir Yang
2015-08-19 23:54 ` [PATCH v3 0/14] Add Analogix Core Display Port Driver Dave Airlie
2015-08-19 23:54 ` Dave Airlie
2015-08-19 23:54 ` Dave Airlie
2015-08-20 1:02 ` Yakir Yang
2015-08-20 1:02 ` Yakir Yang
2015-08-20 1:02 ` Yakir Yang
2015-08-20 4:29 ` Archit Taneja
2015-08-20 4:29 ` Archit Taneja
2015-08-20 4:29 ` Archit Taneja
2015-08-20 5:54 ` Jingoo Han
2015-08-20 5:54 ` Jingoo Han
2015-08-20 5:54 ` Jingoo Han
2015-08-20 6:23 ` Yakir Yang
2015-08-20 6:23 ` Yakir Yang
2015-08-20 6:23 ` Yakir Yang
2015-08-20 6:55 ` Jingoo Han
2015-08-20 6:55 ` Jingoo Han
2015-08-20 6:55 ` Jingoo Han
2015-08-20 8:03 ` Yakir Yang
2015-08-20 8:03 ` Yakir Yang
2015-08-20 8:03 ` Yakir Yang
2015-08-21 8:20 ` Jingoo Han
2015-08-21 8:20 ` Jingoo Han
2015-08-21 8:20 ` Jingoo Han
2015-08-21 10:01 ` Yakir Yang
2015-08-21 11:24 ` Jingoo Han
2015-08-21 13:16 ` Thierry Reding
2015-08-21 13:16 ` Thierry Reding
2015-08-21 13:16 ` Thierry Reding
2015-08-22 10:13 ` Yakir Yang
2015-08-30 12:16 ` Romain Perier
2015-08-30 12:16 ` Romain Perier
2015-08-30 12:16 ` Romain Perier
2015-08-31 2:40 ` Yakir Yang
2015-08-31 2:40 ` Yakir Yang
2015-08-31 2:40 ` Yakir Yang
2015-08-22 9:42 ` Yakir Yang
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=20150825092939.GM7557@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=ajaynumb@gmail.com \
--cc=andy.yan@rock-chips.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@google.com \
--cc=djkurtz@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fabio.estevam@freescale.com \
--cc=galak@codeaurora.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=heiko@sntech.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=inki.dae@samsung.com \
--cc=jingoohan1@gmail.com \
--cc=joe@perches.com \
--cc=kishon@ti.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mark.yao@rock-chips.com \
--cc=p.zabel@pengutronix.de \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=robherring2@gmail.com \
--cc=seanpaul@google.com \
--cc=tiwai@suse.de \
--cc=treding@nvidia.com \
--cc=vpalatin@chromium.org \
--cc=ykk@rock-chips.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.