All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: "open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
Date: Mon, 30 Jan 2017 00:36:23 +0100	[thread overview]
Message-ID: <7144543.znLMLUJXpB@phil> (raw)
In-Reply-To: <CAOesGMjq3uPqaWjMkEkqXs9W90XTwXknjheZNdYsOaGu4fw9_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Olof,

Am Sonntag, 29. Januar 2017, 14:40:53 CET schrieb Olof Johansson:
> On Tue, Nov 15, 2016 at 2:38 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > The General Register Files are an area of registers containing a lot
> > of single-bit settings for numerous components as well full components
> > like usbphy control. Therefore all used components are accessed
> > via the syscon provided by the grf nodes or from the sub-devices
> > created through the simple-mfd created from the grf node.
> > 
> > Some settings are not used by anything but will need to be set up
> > according to expectations on the kernel side.
> > 
> > Best example is the force_jtag setting, which defaults to on and
> > results in the soc switching the pin-outputs between jtag and sdmmc
> > automatically depending on the card-detect status. This conflicts
> > heavily with how the dw_mmc driver expects to do its work and also
> > with the clock-controller, which has most likely deactivated the
> > jtag clock due to it being unused.
> > 
> > So far the handling of this setting was living in the mach-rockchip
> > code for the arm32-based rk3288 but that of course doesn't work
> > for arm64 socs and would also look ugly for further arm32 socs.
> > 
> > Also always disabling this setting is quite specific to linux and
> > its subsystems, other operating systems might prefer other settings,
> > so that the bootloader cannot really set a sane default for all.
> > 
> > So introduce a top-level driver for the grf that handles these
> > settings that need to be a certain way but nobody cares about.
> > 
> > Other needed settings might surface in the future and can then
> > be added here, but only as a last option. Ideally general GRF
> > settings should be handled in the driver needing them.
> > 
> > Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> > ---
> > 
> >  drivers/soc/rockchip/Kconfig  |  10 ++++
> >  drivers/soc/rockchip/Makefile |   1 +
> >  drivers/soc/rockchip/grf.c    | 134
> >  ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 145
> >  insertions(+)
> >  create mode 100644 drivers/soc/rockchip/grf.c
> > 
> > diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> > index 7140ff8..20da55d 100644
> > --- a/drivers/soc/rockchip/Kconfig
> > +++ b/drivers/soc/rockchip/Kconfig
> > @@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
> > 
> >  #
> >  # Rockchip Soc drivers
> >  #
> > 
> > +
> > +config ROCKCHIP_GRF
> > +       bool
> > +       default y
> > +       help
> > +         The General Register Files are a central component providing
> > +         special additional settings registers for a lot of
> > soc-components. +         In a lot of cases there also need to be default
> > settings initialized +         to make some of them conform to
> > expectations of the kernel. +
> > 
> >  config ROCKCHIP_PM_DOMAINS
> >  
> >          bool "Rockchip generic power domain"
> >          depends on PM
> > 
> > diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> > index 3d73d06..c851fa0 100644
> > --- a/drivers/soc/rockchip/Makefile
> > +++ b/drivers/soc/rockchip/Makefile
> > @@ -1,4 +1,5 @@
> > 
> >  #
> >  # Rockchip Soc drivers
> >  #
> > 
> > +obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> > 
> >  obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> > 
> > diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
> > new file mode 100644
> > index 0000000..0c85476a
> > --- /dev/null
> > +++ b/drivers/soc/rockchip/grf.c
> > @@ -0,0 +1,134 @@
> > +/*
> > + * Rockchip Generic Register Files setup
> > + *
> > + * Copyright (c) 2016 Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/regmap.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +
> > +#define HIWORD_UPDATE(val, mask, shift) \
> > +               ((val) << (shift) | (mask) << ((shift) + 16))
> > +
> > +struct rockchip_grf_value {
> > +       const char *desc;
> > +       u32 reg;
> > +       u32 val;
> > +};
> > +
> > +struct rockchip_grf_info {
> > +       const struct rockchip_grf_value *values;
> > +       int num_values;
> > +};
> > +
> > +#define RK3036_GRF_SOC_CON0            0x140
> > +
> > +static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
> > +       /*
> > +        * Disable auto jtag/sdmmc switching that causes issues with the
> > +        * clock-framework and the mmc controllers making them unreliable.
> > +        */
> > +       { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11)
> > },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3036_grf __initconst = {
> > +       .values = rk3036_defaults,
> > +       .num_values = ARRAY_SIZE(rk3036_defaults),
> > +};
> > +
> > +#define RK3288_GRF_SOC_CON0            0x244
> > +
> > +static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
> > +       { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12)
> > },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3288_grf __initconst = {
> > +       .values = rk3288_defaults,
> > +       .num_values = ARRAY_SIZE(rk3288_defaults),
> > +};
> > +
> > +#define RK3368_GRF_SOC_CON15           0x43c
> > +
> > +static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
> > +       { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13)
> > }, +};
> > +
> > +static const struct rockchip_grf_info rk3368_grf __initconst = {
> > +       .values = rk3368_defaults,
> > +       .num_values = ARRAY_SIZE(rk3368_defaults),
> > +};
> > +
> > +#define RK3399_GRF_SOC_CON7            0xe21c
> > +
> > +static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
> > +       { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12)
> > },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3399_grf __initconst = {
> > +       .values = rk3399_defaults,
> > +       .num_values = ARRAY_SIZE(rk3399_defaults),
> > +};
> > +
> > +static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
> > +       {
> > +               .compatible = "rockchip,rk3036-grf",
> > +               .data = (void *)&rk3036_grf,
> > +       }, {
> > +               .compatible = "rockchip,rk3288-grf",
> > +               .data = (void *)&rk3288_grf,
> > +       }, {
> > +               .compatible = "rockchip,rk3368-grf",
> > +               .data = (void *)&rk3368_grf,
> > +       }, {
> > +               .compatible = "rockchip,rk3399-grf",
> > +               .data = (void *)&rk3399_grf,
> > +       },
> > +       { /* sentinel */ },
> > +};
> 
> I often come in after there's already been discussion on a topic, and
> don't always find all of it, so let me know if this has already been
> considered and not chosen for some reason:

So far only Doug had the time to look at this, so I'm happy about discussing 
my approach more.


> I get a little worried when you see these per-SoC tables build up in
> the kernel. It means there'll need to be additions here for a bunch of
> different SoCs.

We also add clock drivers (which are essentially only tables listing the 
clock-hirarchy) on a per-soc basis. In clk-land the move was the other way 
around, because it was deemed that defining clocks in the devicetree does not 
scale :-) .


> Would it be possible to describe this directly in the DT instead? If
> nothing else, something like
> 
> function-regs = < array of regs >
> function-values = < array of values >
> function-names = < array of names >
> 
> Not ideal either, especially if abused into a random poke table, but
> it won't require per-SoC changes to the kernel. If we keep the binding
> under close eyes we can hopefully avoid abuse.
> 
> Given that Rockchip is still working on new SoCs, this list will just
> grow and doing it in-kernel will stop scaling at some point.

As explained in the commit message, this is meant as a last resort for 
settings that no driver can be responsible for in a sensible way and that are 
Linux-specific and thus cannot be set in firmware for everybody. Most GRF-
specific settings are already done by the specific drivers needing them.

I.e. you see the mmc/jtag thing, which is getting disabled because the Linux 
mmc subsystem gets a hickup if the pinmux is changed by the soc to early after 
card eject. Other OSes might like that behaviour.

As the dts is meant to be for everyone I don't see how that could be sanely 
defined for things.


Another option would be to burden the rockchip mmc-driver with that specific 
setting, but then the mmc-driver (and possible other drivers if needed) would 
need per-soc additions, resulting in the same scaling problem.
Having one per-soc list at least keeps in one place :-) .


If you really dislike the current approach, we can of course postpone it for 
now though.


Heiko

WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
Date: Mon, 30 Jan 2017 00:36:23 +0100	[thread overview]
Message-ID: <7144543.znLMLUJXpB@phil> (raw)
In-Reply-To: <CAOesGMjq3uPqaWjMkEkqXs9W90XTwXknjheZNdYsOaGu4fw9_g@mail.gmail.com>

Hi Olof,

Am Sonntag, 29. Januar 2017, 14:40:53 CET schrieb Olof Johansson:
> On Tue, Nov 15, 2016 at 2:38 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> > The General Register Files are an area of registers containing a lot
> > of single-bit settings for numerous components as well full components
> > like usbphy control. Therefore all used components are accessed
> > via the syscon provided by the grf nodes or from the sub-devices
> > created through the simple-mfd created from the grf node.
> > 
> > Some settings are not used by anything but will need to be set up
> > according to expectations on the kernel side.
> > 
> > Best example is the force_jtag setting, which defaults to on and
> > results in the soc switching the pin-outputs between jtag and sdmmc
> > automatically depending on the card-detect status. This conflicts
> > heavily with how the dw_mmc driver expects to do its work and also
> > with the clock-controller, which has most likely deactivated the
> > jtag clock due to it being unused.
> > 
> > So far the handling of this setting was living in the mach-rockchip
> > code for the arm32-based rk3288 but that of course doesn't work
> > for arm64 socs and would also look ugly for further arm32 socs.
> > 
> > Also always disabling this setting is quite specific to linux and
> > its subsystems, other operating systems might prefer other settings,
> > so that the bootloader cannot really set a sane default for all.
> > 
> > So introduce a top-level driver for the grf that handles these
> > settings that need to be a certain way but nobody cares about.
> > 
> > Other needed settings might surface in the future and can then
> > be added here, but only as a last option. Ideally general GRF
> > settings should be handled in the driver needing them.
> > 
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > 
> >  drivers/soc/rockchip/Kconfig  |  10 ++++
> >  drivers/soc/rockchip/Makefile |   1 +
> >  drivers/soc/rockchip/grf.c    | 134
> >  ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 145
> >  insertions(+)
> >  create mode 100644 drivers/soc/rockchip/grf.c
> > 
> > diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> > index 7140ff8..20da55d 100644
> > --- a/drivers/soc/rockchip/Kconfig
> > +++ b/drivers/soc/rockchip/Kconfig
> > @@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
> > 
> >  #
> >  # Rockchip Soc drivers
> >  #
> > 
> > +
> > +config ROCKCHIP_GRF
> > +       bool
> > +       default y
> > +       help
> > +         The General Register Files are a central component providing
> > +         special additional settings registers for a lot of
> > soc-components. +         In a lot of cases there also need to be default
> > settings initialized +         to make some of them conform to
> > expectations of the kernel. +
> > 
> >  config ROCKCHIP_PM_DOMAINS
> >  
> >          bool "Rockchip generic power domain"
> >          depends on PM
> > 
> > diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> > index 3d73d06..c851fa0 100644
> > --- a/drivers/soc/rockchip/Makefile
> > +++ b/drivers/soc/rockchip/Makefile
> > @@ -1,4 +1,5 @@
> > 
> >  #
> >  # Rockchip Soc drivers
> >  #
> > 
> > +obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> > 
> >  obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> > 
> > diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
> > new file mode 100644
> > index 0000000..0c85476a
> > --- /dev/null
> > +++ b/drivers/soc/rockchip/grf.c
> > @@ -0,0 +1,134 @@
> > +/*
> > + * Rockchip Generic Register Files setup
> > + *
> > + * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/regmap.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +
> > +#define HIWORD_UPDATE(val, mask, shift) \
> > +               ((val) << (shift) | (mask) << ((shift) + 16))
> > +
> > +struct rockchip_grf_value {
> > +       const char *desc;
> > +       u32 reg;
> > +       u32 val;
> > +};
> > +
> > +struct rockchip_grf_info {
> > +       const struct rockchip_grf_value *values;
> > +       int num_values;
> > +};
> > +
> > +#define RK3036_GRF_SOC_CON0            0x140
> > +
> > +static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
> > +       /*
> > +        * Disable auto jtag/sdmmc switching that causes issues with the
> > +        * clock-framework and the mmc controllers making them unreliable.
> > +        */
> > +       { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11)
> > },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3036_grf __initconst = {
> > +       .values = rk3036_defaults,
> > +       .num_values = ARRAY_SIZE(rk3036_defaults),
> > +};
> > +
> > +#define RK3288_GRF_SOC_CON0            0x244
> > +
> > +static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
> > +       { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12)
> > },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3288_grf __initconst = {
> > +       .values = rk3288_defaults,
> > +       .num_values = ARRAY_SIZE(rk3288_defaults),
> > +};
> > +
> > +#define RK3368_GRF_SOC_CON15           0x43c
> > +
> > +static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
> > +       { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13)
> > }, +};
> > +
> > +static const struct rockchip_grf_info rk3368_grf __initconst = {
> > +       .values = rk3368_defaults,
> > +       .num_values = ARRAY_SIZE(rk3368_defaults),
> > +};
> > +
> > +#define RK3399_GRF_SOC_CON7            0xe21c
> > +
> > +static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
> > +       { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12)
> > },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3399_grf __initconst = {
> > +       .values = rk3399_defaults,
> > +       .num_values = ARRAY_SIZE(rk3399_defaults),
> > +};
> > +
> > +static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
> > +       {
> > +               .compatible = "rockchip,rk3036-grf",
> > +               .data = (void *)&rk3036_grf,
> > +       }, {
> > +               .compatible = "rockchip,rk3288-grf",
> > +               .data = (void *)&rk3288_grf,
> > +       }, {
> > +               .compatible = "rockchip,rk3368-grf",
> > +               .data = (void *)&rk3368_grf,
> > +       }, {
> > +               .compatible = "rockchip,rk3399-grf",
> > +               .data = (void *)&rk3399_grf,
> > +       },
> > +       { /* sentinel */ },
> > +};
> 
> I often come in after there's already been discussion on a topic, and
> don't always find all of it, so let me know if this has already been
> considered and not chosen for some reason:

So far only Doug had the time to look at this, so I'm happy about discussing 
my approach more.


> I get a little worried when you see these per-SoC tables build up in
> the kernel. It means there'll need to be additions here for a bunch of
> different SoCs.

We also add clock drivers (which are essentially only tables listing the 
clock-hirarchy) on a per-soc basis. In clk-land the move was the other way 
around, because it was deemed that defining clocks in the devicetree does not 
scale :-) .


> Would it be possible to describe this directly in the DT instead? If
> nothing else, something like
> 
> function-regs = < array of regs >
> function-values = < array of values >
> function-names = < array of names >
> 
> Not ideal either, especially if abused into a random poke table, but
> it won't require per-SoC changes to the kernel. If we keep the binding
> under close eyes we can hopefully avoid abuse.
> 
> Given that Rockchip is still working on new SoCs, this list will just
> grow and doing it in-kernel will stop scaling at some point.

As explained in the commit message, this is meant as a last resort for 
settings that no driver can be responsible for in a sensible way and that are 
Linux-specific and thus cannot be set in firmware for everybody. Most GRF-
specific settings are already done by the specific drivers needing them.

I.e. you see the mmc/jtag thing, which is getting disabled because the Linux 
mmc subsystem gets a hickup if the pinmux is changed by the soc to early after 
card eject. Other OSes might like that behaviour.

As the dts is meant to be for everyone I don't see how that could be sanely 
defined for things.


Another option would be to burden the rockchip mmc-driver with that specific 
setting, but then the mmc-driver (and possible other drivers if needed) would 
need per-soc additions, resulting in the same scaling problem.
Having one per-soc list at least keeps in one place :-) .


If you really dislike the current approach, we can of course postpone it for 
now though.


Heiko

  parent reply	other threads:[~2017-01-29 23:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 22:38 [PATCH v2 0/3] Rockchip: generalize GRF setup Heiko Stuebner
2016-11-15 22:38 ` Heiko Stuebner
     [not found] ` <20161115223900.30728-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2016-11-15 22:38   ` [PATCH v2 1/3] dt-bindings: add used but undocumented rockchip grf compatible values Heiko Stuebner
2016-11-15 22:38     ` Heiko Stuebner
2016-11-15 22:38   ` [PATCH v2 2/3] soc: rockchip: add driver handling grf setup Heiko Stuebner
2016-11-15 22:38     ` Heiko Stuebner
     [not found]     ` <20161115223900.30728-3-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2016-11-16  9:33       ` Shawn Lin
2016-11-16  9:33         ` Shawn Lin
     [not found]         ` <95cd052e-7e0d-d13b-fedb-21f7b49d17bb-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-11-16  9:58           ` Heiko Stuebner
2016-11-16  9:58             ` Heiko Stuebner
2016-11-17  1:38             ` Shawn Lin
2016-11-17  1:38               ` Shawn Lin
     [not found]               ` <a01a1a8c-b01b-4335-b69c-bb99dec9d6d6-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-11-17  9:12                 ` Heiko Stuebner
2016-11-17  9:12                   ` Heiko Stuebner
2016-11-16 21:50       ` Doug Anderson
2016-11-16 21:50         ` Doug Anderson
2017-01-29 22:40     ` Olof Johansson
2017-01-29 22:40       ` Olof Johansson
     [not found]       ` <CAOesGMjq3uPqaWjMkEkqXs9W90XTwXknjheZNdYsOaGu4fw9_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-29 23:36         ` Heiko Stuebner [this message]
2017-01-29 23:36           ` Heiko Stuebner
2017-01-30  0:41           ` Olof Johansson
2017-01-30  0:41             ` Olof Johansson
     [not found]             ` <CAOesGMj_RdxVDzirT97KLkXRsyVcFh3Z8jZLNjn0ehAv0Qhmhg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-27  5:30               ` Heiko Stuebner
2017-02-27  5:30                 ` Heiko Stuebner
2017-03-09 23:28                 ` Brian Norris
2017-03-09 23:28                   ` Brian Norris
2016-11-15 22:39   ` [PATCH v2 3/3] ARM: rockchip: drop rk3288 jtag/mmc switch handling Heiko Stuebner
2016-11-15 22:39     ` Heiko Stuebner

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=7144543.znLMLUJXpB@phil \
    --to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
    --cc=shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
    /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.