From: Lukasz Luba <lukasz.luba@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-imx@nxp.com,
Dietmar.Eggemann@arm.com, cw00.choi@samsung.com,
b.zolnierkie@samsung.com, rjw@rjwysocki.net,
sudeep.holla@arm.com, viresh.kumar@linaro.org, nm@ti.com,
sboyd@kernel.org, rui.zhang@intel.com,
amit.kucheria@verdurent.com, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, rostedt@goodmis.org,
qperret@google.com, bsegall@google.com, mgorman@suse.de,
shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com,
kernel@pengutronix.de, khilman@kernel.org, agross@kernel.org,
bjorn.andersson@linaro.org, robh@kernel.org,
matthias.bgg@gmail.com, steven.price@arm.com,
tomeu.vizoso@collabora.com, alyssa.rosenzweig@collabora.com,
airlied@linux.ie, daniel@ffwll.ch, liviu.dudau@arm.com,
lorenzo.pieralisi@arm.com, patrick.bellasi@matbug.net,
orjan.eide@arm.com, rdunlap@infradead.org, mka@chromium.org
Subject: Re: [PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model
Date: Thu, 23 Apr 2020 17:57:45 +0100 [thread overview]
Message-ID: <ff1c8cc5-f64d-6156-7d30-97b8426c6f99@arm.com> (raw)
In-Reply-To: <20200423151250.GB65632@linaro.org>
On 4/23/20 4:12 PM, Daniel Lezcano wrote:
> On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
>> Add support for other devices that CPUs. The registration function
>> does not require a valid cpumask pointer and is ready to handle new
>> devices. Some of the internal structures has been reorganized in order to
>> keep consistent view (like removing per_cpu pd pointers). To track usage
>> of the Energy Model structures, they are protected with kref.
>
> Why not add the energy model structure in the struct device directly?
Do you mean this structure?
https://elixir.bootlin.com/linux/latest/source/include/linux/device.h#L537
and to put something like:
struct device {
...
struct dev_pm_domain *pm_domain;
#ifdef CONFIG_ENERGY_MODEL
struct em_perf_domain *em_pd;
#endif
...
};
>
> For instance for the em_cpu_get() function, the cpu id allows to retrieve the
> cpu device and then from there, the energy model instead of browsing another
> list. The em_device life cycle will be tied to the struct device.
That would be perfect.
>
> Then when the struct device and the em_device are connected, add the debugfs
> with a struct device list for those which are energy aware, so you end up with
> a structure:
>
> struct em_device {
> struct device *dev;
> struct list_head em_dev_list;
> };
>
> (a global single dentry for debugfs to do a recursive delete is enough).
>
> Locks when inspecting and add/removal called from the struct device release
> function. So no need of an extra refcounting.
>
> Does it make sense?
>
Indeed it looks much cleaner/simpler.
I will try to address this idea and get rid of refcounting.
This should be doable in this patch (4/10). In the v7 I will keep your
ACKs for other patches that you have already commented.
Thank you for your suggestions and review.
Regards,
Lukasz
WARNING: multiple messages have this Message-ID (diff)
From: Lukasz Luba <lukasz.luba@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: nm@ti.com, juri.lelli@redhat.com, peterz@infradead.org,
viresh.kumar@linaro.org, liviu.dudau@arm.com,
dri-devel@lists.freedesktop.org, bjorn.andersson@linaro.org,
bsegall@google.com, alyssa.rosenzweig@collabora.com,
festevam@gmail.com, mka@chromium.org, robh@kernel.org,
amit.kucheria@verdurent.com, lorenzo.pieralisi@arm.com,
vincent.guittot@linaro.org, khilman@kernel.org,
agross@kernel.org, b.zolnierkie@samsung.com,
steven.price@arm.com, cw00.choi@samsung.com, mingo@redhat.com,
linux-imx@nxp.com, rui.zhang@intel.com, mgorman@suse.de,
orjan.eide@arm.com, daniel@ffwll.ch, linux-pm@vger.kernel.org,
linux-arm-msm@vger.kernel.org, s.hauer@pengutronix.de,
rostedt@goodmis.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-omap@vger.kernel.org,
Dietmar.Eggemann@arm.com, linux-arm-kernel@lists.infradead.org,
airlied@linux.ie, tomeu.vizoso@collabora.com, qperret@google.com,
sboyd@kernel.org, rdunlap@infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
sudeep.holla@arm.com, patrick.bellasi@matbug.net,
shawnguo@kernel.org
Subject: Re: [PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model
Date: Thu, 23 Apr 2020 17:57:45 +0100 [thread overview]
Message-ID: <ff1c8cc5-f64d-6156-7d30-97b8426c6f99@arm.com> (raw)
In-Reply-To: <20200423151250.GB65632@linaro.org>
On 4/23/20 4:12 PM, Daniel Lezcano wrote:
> On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
>> Add support for other devices that CPUs. The registration function
>> does not require a valid cpumask pointer and is ready to handle new
>> devices. Some of the internal structures has been reorganized in order to
>> keep consistent view (like removing per_cpu pd pointers). To track usage
>> of the Energy Model structures, they are protected with kref.
>
> Why not add the energy model structure in the struct device directly?
Do you mean this structure?
https://elixir.bootlin.com/linux/latest/source/include/linux/device.h#L537
and to put something like:
struct device {
...
struct dev_pm_domain *pm_domain;
#ifdef CONFIG_ENERGY_MODEL
struct em_perf_domain *em_pd;
#endif
...
};
>
> For instance for the em_cpu_get() function, the cpu id allows to retrieve the
> cpu device and then from there, the energy model instead of browsing another
> list. The em_device life cycle will be tied to the struct device.
That would be perfect.
>
> Then when the struct device and the em_device are connected, add the debugfs
> with a struct device list for those which are energy aware, so you end up with
> a structure:
>
> struct em_device {
> struct device *dev;
> struct list_head em_dev_list;
> };
>
> (a global single dentry for debugfs to do a recursive delete is enough).
>
> Locks when inspecting and add/removal called from the struct device release
> function. So no need of an extra refcounting.
>
> Does it make sense?
>
Indeed it looks much cleaner/simpler.
I will try to address this idea and get rid of refcounting.
This should be doable in this patch (4/10). In the v7 I will keep your
ACKs for other patches that you have already commented.
Thank you for your suggestions and review.
Regards,
Lukasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Lukasz Luba <lukasz.luba@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: nm@ti.com, juri.lelli@redhat.com, peterz@infradead.org,
viresh.kumar@linaro.org, liviu.dudau@arm.com,
dri-devel@lists.freedesktop.org, bjorn.andersson@linaro.org,
bsegall@google.com, alyssa.rosenzweig@collabora.com,
festevam@gmail.com, mka@chromium.org, robh@kernel.org,
amit.kucheria@verdurent.com, lorenzo.pieralisi@arm.com,
khilman@kernel.org, agross@kernel.org, b.zolnierkie@samsung.com,
steven.price@arm.com, cw00.choi@samsung.com, mingo@redhat.com,
linux-imx@nxp.com, rui.zhang@intel.com, mgorman@suse.de,
orjan.eide@arm.com, daniel@ffwll.ch, linux-pm@vger.kernel.org,
linux-arm-msm@vger.kernel.org, s.hauer@pengutronix.de,
rostedt@goodmis.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-omap@vger.kernel.org,
Dietmar.Eggemann@arm.com, linux-arm-kernel@lists.infradead.org,
airlied@linux.ie, tomeu.vizoso@collabora.com, qperret@google.com,
sboyd@kernel.org, rdunlap@infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
sudeep.holla@arm.com, patrick.bellasi@matbug.net,
shawnguo@kernel.org
Subject: Re: [PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model
Date: Thu, 23 Apr 2020 17:57:45 +0100 [thread overview]
Message-ID: <ff1c8cc5-f64d-6156-7d30-97b8426c6f99@arm.com> (raw)
In-Reply-To: <20200423151250.GB65632@linaro.org>
On 4/23/20 4:12 PM, Daniel Lezcano wrote:
> On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
>> Add support for other devices that CPUs. The registration function
>> does not require a valid cpumask pointer and is ready to handle new
>> devices. Some of the internal structures has been reorganized in order to
>> keep consistent view (like removing per_cpu pd pointers). To track usage
>> of the Energy Model structures, they are protected with kref.
>
> Why not add the energy model structure in the struct device directly?
Do you mean this structure?
https://elixir.bootlin.com/linux/latest/source/include/linux/device.h#L537
and to put something like:
struct device {
...
struct dev_pm_domain *pm_domain;
#ifdef CONFIG_ENERGY_MODEL
struct em_perf_domain *em_pd;
#endif
...
};
>
> For instance for the em_cpu_get() function, the cpu id allows to retrieve the
> cpu device and then from there, the energy model instead of browsing another
> list. The em_device life cycle will be tied to the struct device.
That would be perfect.
>
> Then when the struct device and the em_device are connected, add the debugfs
> with a struct device list for those which are energy aware, so you end up with
> a structure:
>
> struct em_device {
> struct device *dev;
> struct list_head em_dev_list;
> };
>
> (a global single dentry for debugfs to do a recursive delete is enough).
>
> Locks when inspecting and add/removal called from the struct device release
> function. So no need of an extra refcounting.
>
> Does it make sense?
>
Indeed it looks much cleaner/simpler.
I will try to address this idea and get rid of refcounting.
This should be doable in this patch (4/10). In the v7 I will keep your
ACKs for other patches that you have already commented.
Thank you for your suggestions and review.
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Lukasz Luba <lukasz.luba@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: nm@ti.com, juri.lelli@redhat.com, peterz@infradead.org,
viresh.kumar@linaro.org, liviu.dudau@arm.com,
dri-devel@lists.freedesktop.org, bjorn.andersson@linaro.org,
bsegall@google.com, alyssa.rosenzweig@collabora.com,
mka@chromium.org, amit.kucheria@verdurent.com,
lorenzo.pieralisi@arm.com, vincent.guittot@linaro.org,
khilman@kernel.org, agross@kernel.org, b.zolnierkie@samsung.com,
steven.price@arm.com, cw00.choi@samsung.com, mingo@redhat.com,
linux-imx@nxp.com, rui.zhang@intel.com, mgorman@suse.de,
orjan.eide@arm.com, linux-pm@vger.kernel.org,
linux-arm-msm@vger.kernel.org, s.hauer@pengutronix.de,
rostedt@goodmis.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-omap@vger.kernel.org,
Dietmar.Eggemann@arm.com, linux-arm-kernel@lists.infradead.org,
airlied@linux.ie, tomeu.vizoso@collabora.com, qperret@google.com,
sboyd@kernel.org, rdunlap@infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
sudeep.holla@arm.com, patrick.bellasi@matbug.net,
shawnguo@kernel.org
Subject: Re: [PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model
Date: Thu, 23 Apr 2020 17:57:45 +0100 [thread overview]
Message-ID: <ff1c8cc5-f64d-6156-7d30-97b8426c6f99@arm.com> (raw)
In-Reply-To: <20200423151250.GB65632@linaro.org>
On 4/23/20 4:12 PM, Daniel Lezcano wrote:
> On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
>> Add support for other devices that CPUs. The registration function
>> does not require a valid cpumask pointer and is ready to handle new
>> devices. Some of the internal structures has been reorganized in order to
>> keep consistent view (like removing per_cpu pd pointers). To track usage
>> of the Energy Model structures, they are protected with kref.
>
> Why not add the energy model structure in the struct device directly?
Do you mean this structure?
https://elixir.bootlin.com/linux/latest/source/include/linux/device.h#L537
and to put something like:
struct device {
...
struct dev_pm_domain *pm_domain;
#ifdef CONFIG_ENERGY_MODEL
struct em_perf_domain *em_pd;
#endif
...
};
>
> For instance for the em_cpu_get() function, the cpu id allows to retrieve the
> cpu device and then from there, the energy model instead of browsing another
> list. The em_device life cycle will be tied to the struct device.
That would be perfect.
>
> Then when the struct device and the em_device are connected, add the debugfs
> with a struct device list for those which are energy aware, so you end up with
> a structure:
>
> struct em_device {
> struct device *dev;
> struct list_head em_dev_list;
> };
>
> (a global single dentry for debugfs to do a recursive delete is enough).
>
> Locks when inspecting and add/removal called from the struct device release
> function. So no need of an extra refcounting.
>
> Does it make sense?
>
Indeed it looks much cleaner/simpler.
I will try to address this idea and get rid of refcounting.
This should be doable in this patch (4/10). In the v7 I will keep your
ACKs for other patches that you have already commented.
Thank you for your suggestions and review.
Regards,
Lukasz
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-23 16:58 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 8:42 [PATCH v6 00/10] Add support for devices in the Energy Model Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` [PATCH v6 01/10] PM / EM: change naming convention from 'capacity' to 'performance' Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 9:55 ` Daniel Lezcano
2020-04-23 9:55 ` Daniel Lezcano
2020-04-23 9:55 ` Daniel Lezcano
2020-04-23 9:55 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 02/10] PM / EM: introduce em_dev_register_perf_domain function Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 10:46 ` Daniel Lezcano
2020-04-23 10:46 ` Daniel Lezcano
2020-04-23 10:46 ` Daniel Lezcano
2020-04-23 10:46 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 03/10] PM / EM: update callback structure and add device pointer Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 13:22 ` Daniel Lezcano
2020-04-23 13:22 ` Daniel Lezcano
2020-04-23 13:22 ` Daniel Lezcano
2020-04-23 13:22 ` Daniel Lezcano
2020-04-23 15:28 ` Lukasz Luba
2020-04-23 15:28 ` Lukasz Luba
2020-04-23 15:28 ` Lukasz Luba
2020-04-23 15:28 ` Lukasz Luba
2020-04-10 8:42 ` [PATCH v6 04/10] PM / EM: add support for other devices than CPUs in Energy Model Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 11:12 ` Luis Gerhorst
2020-04-10 11:12 ` Luis Gerhorst
2020-04-10 11:12 ` Luis Gerhorst
2020-04-10 11:12 ` Luis Gerhorst
2020-04-10 11:34 ` Lukasz Luba
2020-04-10 11:34 ` Lukasz Luba
2020-04-10 11:34 ` Lukasz Luba
2020-04-10 11:34 ` Lukasz Luba
2020-04-10 14:35 ` kbuild test robot
2020-04-10 14:35 ` kbuild test robot
2020-04-10 14:35 ` kbuild test robot
2020-04-10 14:35 ` kbuild test robot
2020-04-23 15:12 ` Daniel Lezcano
2020-04-23 15:12 ` Daniel Lezcano
2020-04-23 15:12 ` Daniel Lezcano
2020-04-23 15:12 ` Daniel Lezcano
2020-04-23 16:57 ` Lukasz Luba [this message]
2020-04-23 16:57 ` Lukasz Luba
2020-04-23 16:57 ` Lukasz Luba
2020-04-23 16:57 ` Lukasz Luba
2020-04-23 17:15 ` Daniel Lezcano
2020-04-23 17:15 ` Daniel Lezcano
2020-04-23 17:15 ` Daniel Lezcano
2020-04-23 17:15 ` Daniel Lezcano
2020-04-23 17:19 ` Lukasz Luba
2020-04-23 17:19 ` Lukasz Luba
2020-04-23 17:19 ` Lukasz Luba
2020-04-23 17:19 ` Lukasz Luba
2020-04-10 8:42 ` [PATCH v6 05/10] PM / EM: remove em_register_perf_domain Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 15:14 ` Daniel Lezcano
2020-04-23 15:14 ` Daniel Lezcano
2020-04-23 15:14 ` Daniel Lezcano
2020-04-23 15:14 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 06/10] PM / EM: change name of em_pd_energy to em_cpu_energy Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 15:28 ` Daniel Lezcano
2020-04-23 15:28 ` Daniel Lezcano
2020-04-23 15:28 ` Daniel Lezcano
2020-04-23 15:28 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 07/10] Documentation: power: update Energy Model description Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 16:07 ` Daniel Lezcano
2020-04-23 16:07 ` Daniel Lezcano
2020-04-23 16:07 ` Daniel Lezcano
2020-04-23 16:07 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 08/10] OPP: refactor dev_pm_opp_of_register_em() and update related drivers Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 16:47 ` Daniel Lezcano
2020-04-23 16:47 ` Daniel Lezcano
2020-04-23 16:47 ` Daniel Lezcano
2020-04-23 16:47 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 09/10] thermal: devfreq_cooling: Refactor code and switch to use Energy Model Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-23 17:57 ` Daniel Lezcano
2020-04-23 17:57 ` Daniel Lezcano
2020-04-23 17:57 ` Daniel Lezcano
2020-04-23 17:57 ` Daniel Lezcano
2020-04-24 10:02 ` Lukasz Luba
2020-04-24 10:02 ` Lukasz Luba
2020-04-24 10:02 ` Lukasz Luba
2020-04-24 10:02 ` Lukasz Luba
2020-04-24 10:43 ` Daniel Lezcano
2020-04-24 10:43 ` Daniel Lezcano
2020-04-24 10:43 ` Daniel Lezcano
2020-04-24 10:43 ` Daniel Lezcano
2020-04-10 8:42 ` [PATCH v6 10/10] drm/panfrost: Register devfreq cooling and attempt to add " Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
2020-04-10 8:42 ` Lukasz Luba
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=ff1c8cc5-f64d-6156-7d30-97b8426c6f99@arm.com \
--to=lukasz.luba@arm.com \
--cc=Dietmar.Eggemann@arm.com \
--cc=agross@kernel.org \
--cc=airlied@linux.ie \
--cc=alyssa.rosenzweig@collabora.com \
--cc=amit.kucheria@verdurent.com \
--cc=b.zolnierkie@samsung.com \
--cc=bjorn.andersson@linaro.org \
--cc=bsegall@google.com \
--cc=cw00.choi@samsung.com \
--cc=daniel.lezcano@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kernel@pengutronix.de \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mka@chromium.org \
--cc=nm@ti.com \
--cc=orjan.eide@arm.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=s.hauer@pengutronix.de \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.org \
--cc=steven.price@arm.com \
--cc=sudeep.holla@arm.com \
--cc=tomeu.vizoso@collabora.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.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.