All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>, cw00.choi@samsung.com
Cc: "Roger Lu" <roger.lu@mediatek.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Enric Balletbo Serra" <eballetbo@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Nicolas Boichat" <drinkcat@google.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Fan Chen" <fan.chen@mediatek.com>,
	"Charles Yang" <Charles.Yang@mediatek.com>,
	"Angus Lin" <Angus.Lin@mediatek.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Nishanth Menon" <nm@ti.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group@mediatek.com,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Jia-wei Chang" <jia-wei.chang@mediatek.com>,
	"Rex-BC Chen (陳柏辰)" <rex-bc.chen@mediatek.com>
Subject: Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
Date: Thu, 19 May 2022 11:25:07 -0700	[thread overview]
Message-ID: <7hmtfdbcsc.fsf@baylibre.com> (raw)
In-Reply-To: <CAGXv+5GT=3m=pVPwUOWR42BR=emCpBXvvoAiRV7YKt2kEKWdAQ@mail.gmail.com>

Chen-Yu Tsai <wenst@chromium.org> writes:

> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>
>> Kevin Hilman <khilman@kernel.org> writes:
>>
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >
>> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>
>> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>
>> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>
>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>
>> >>> Change since v24:
>> >>> - Rebase to Linux 5.18-rc6
>> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>
>> >>> Test in below environment:
>> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>> HW: mt8183-Krane
>> >>>
>> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>> >>
>> >> I've updated my branch to include all the latest versions of the relevant
>> >> patch series:
>> >>
>> >> - anx7625 DPI bus type series v2 (so the display works)
>> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >> maintainer)
>> >> - MTK SVS driver series v25
>> >> - devfreq: cpu based scaling support to passive governor series v5
>> >> - MTK CCI devfreq series v4
>> >> - MT8183 cpufreq series v7
>> >> - Additional WIP patches for panfrost MTK devfreq
>> >
>> > Thanks for preparing an integration branch Chen-Yu.
>> >
>> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> > regulator[1], and the defconfig you posted in a previous rev of this
>> > series, but the CCI driver still causes a fault on boot[2] on my
>> > platform.
>> >
>> > I mentioned in earlier reviews that I think there's potentially a race
>> > between CCI and SVS loading since they are co-dependent.  My hunch is
>> > that this is still not being handled properly.
>>
>> Ah, actually it's crashing when I try to boot the platform with
>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> unstable upstream with the 2nd cluster enabled.)
>>
>> The CCI driver should be a bit more robust about detecting
>> available/online CPUs
>
> This all seems to be handled in the devfreq passive governor.

Well, that's the initial crash.  But the SVS driver will also go through
its svs_mt8183_banks[] array (including both big & little clusters) and
try to init SVS, so presumably that will have some problems also if only
one cluster is enabled.

> And presumably we'd like to have CCI devfreq running even if just one
> core was booted.

Yes, I assume so also.

> Added Chanwoo for more ideas.

OK, thanks.

Kevin

_______________________________________________
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: Kevin Hilman <khilman@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>, cw00.choi@samsung.com
Cc: "Roger Lu" <roger.lu@mediatek.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Enric Balletbo Serra" <eballetbo@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Nicolas Boichat" <drinkcat@google.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Fan Chen" <fan.chen@mediatek.com>,
	"Charles Yang" <Charles.Yang@mediatek.com>,
	"Angus Lin" <Angus.Lin@mediatek.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Nishanth Menon" <nm@ti.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group@mediatek.com,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Jia-wei Chang" <jia-wei.chang@mediatek.com>,
	"Rex-BC Chen (陳柏辰)" <rex-bc.chen@mediatek.com>
Subject: Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
Date: Thu, 19 May 2022 11:25:07 -0700	[thread overview]
Message-ID: <7hmtfdbcsc.fsf@baylibre.com> (raw)
In-Reply-To: <CAGXv+5GT=3m=pVPwUOWR42BR=emCpBXvvoAiRV7YKt2kEKWdAQ@mail.gmail.com>

Chen-Yu Tsai <wenst@chromium.org> writes:

> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>
>> Kevin Hilman <khilman@kernel.org> writes:
>>
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >
>> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>
>> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>
>> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>
>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>
>> >>> Change since v24:
>> >>> - Rebase to Linux 5.18-rc6
>> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>
>> >>> Test in below environment:
>> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>> HW: mt8183-Krane
>> >>>
>> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>> >>
>> >> I've updated my branch to include all the latest versions of the relevant
>> >> patch series:
>> >>
>> >> - anx7625 DPI bus type series v2 (so the display works)
>> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >> maintainer)
>> >> - MTK SVS driver series v25
>> >> - devfreq: cpu based scaling support to passive governor series v5
>> >> - MTK CCI devfreq series v4
>> >> - MT8183 cpufreq series v7
>> >> - Additional WIP patches for panfrost MTK devfreq
>> >
>> > Thanks for preparing an integration branch Chen-Yu.
>> >
>> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> > regulator[1], and the defconfig you posted in a previous rev of this
>> > series, but the CCI driver still causes a fault on boot[2] on my
>> > platform.
>> >
>> > I mentioned in earlier reviews that I think there's potentially a race
>> > between CCI and SVS loading since they are co-dependent.  My hunch is
>> > that this is still not being handled properly.
>>
>> Ah, actually it's crashing when I try to boot the platform with
>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> unstable upstream with the 2nd cluster enabled.)
>>
>> The CCI driver should be a bit more robust about detecting
>> available/online CPUs
>
> This all seems to be handled in the devfreq passive governor.

Well, that's the initial crash.  But the SVS driver will also go through
its svs_mt8183_banks[] array (including both big & little clusters) and
try to init SVS, so presumably that will have some problems also if only
one cluster is enabled.

> And presumably we'd like to have CCI devfreq running even if just one
> core was booted.

Yes, I assume so also.

> Added Chanwoo for more ideas.

OK, thanks.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Chen-Yu Tsai <wenst@chromium.org>, cw00.choi@samsung.com
Cc: "Roger Lu" <roger.lu@mediatek.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Enric Balletbo Serra" <eballetbo@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Nicolas Boichat" <drinkcat@google.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Fan Chen" <fan.chen@mediatek.com>,
	"Charles Yang" <Charles.Yang@mediatek.com>,
	"Angus Lin" <Angus.Lin@mediatek.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Nishanth Menon" <nm@ti.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group@mediatek.com,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Jia-wei Chang" <jia-wei.chang@mediatek.com>,
	"Rex-BC Chen (陳柏辰)" <rex-bc.chen@mediatek.com>
Subject: Re: [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS
Date: Thu, 19 May 2022 11:25:07 -0700	[thread overview]
Message-ID: <7hmtfdbcsc.fsf@baylibre.com> (raw)
In-Reply-To: <CAGXv+5GT=3m=pVPwUOWR42BR=emCpBXvvoAiRV7YKt2kEKWdAQ@mail.gmail.com>

Chen-Yu Tsai <wenst@chromium.org> writes:

> n Wed, May 18, 2022 at 8:03 AM Kevin Hilman <khilman@kernel.org> wrote:
>>
>> Kevin Hilman <khilman@kernel.org> writes:
>>
>> > Chen-Yu Tsai <wenst@chromium.org> writes:
>> >
>> >> On Mon, May 16, 2022 at 8:43 AM Roger Lu <roger.lu@mediatek.com> wrote:
>> >>>
>> >>> The Smart Voltage Scaling(SVS) engine is a piece of hardware
>> >>> which calculates suitable SVS bank voltages to OPP voltage table.
>> >>> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
>> >>> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>> >>>
>> >>> 1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
>> >>> 2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
>> >>> After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
>> >>>
>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=25cb20a212a1f989385dfe23230817e69c62bee5
>> >>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git/commit/?h=opp/linux-next&id=b325ce39785b1408040d90365a6ab1aa36e94f87
>> >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.16-next/dts64&id=a8168cebf1bca1b5269e8a7eb2626fb76814d6e2
>> >>>
>> >>> Change since v24:
>> >>> - Rebase to Linux 5.18-rc6
>> >>> - Show specific fail log in svs_platform_probe() to help catch which step fails quickly
>> >>> - Remove struct svs_bank member "pd_dev" because all subsys device's power domain has been merged into one node like above [3]
>> >>>
>> >>> Test in below environment:
>> >>> SW: Integration Tree [4] + Thermal patch [5] + SVS v25 (this patchset)
>> >>> HW: mt8183-Krane
>> >>>
>> >>> [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
>> >>
>> >> I've updated my branch to include all the latest versions of the relevant
>> >> patch series:
>> >>
>> >> - anx7625 DPI bus type series v2 (so the display works)
>> >> - MT8183 thermal series v9 (this seems to have been overlooked by the
>> >> maintainer)
>> >> - MTK SVS driver series v25
>> >> - devfreq: cpu based scaling support to passive governor series v5
>> >> - MTK CCI devfreq series v4
>> >> - MT8183 cpufreq series v7
>> >> - Additional WIP patches for panfrost MTK devfreq
>> >
>> > Thanks for preparing an integration branch Chen-Yu.
>> >
>> > I'm testing this on mt8183-pumpkin with one patch to add the CCI
>> > regulator[1], and the defconfig you posted in a previous rev of this
>> > series, but the CCI driver still causes a fault on boot[2] on my
>> > platform.
>> >
>> > I mentioned in earlier reviews that I think there's potentially a race
>> > between CCI and SVS loading since they are co-dependent.  My hunch is
>> > that this is still not being handled properly.
>>
>> Ah, actually it's crashing when I try to boot the platform with
>> `maxcpus=4` on the cmdline (which I have to do because mt8183-pumpkin is
>> unstable upstream with the 2nd cluster enabled.)
>>
>> The CCI driver should be a bit more robust about detecting
>> available/online CPUs
>
> This all seems to be handled in the devfreq passive governor.

Well, that's the initial crash.  But the SVS driver will also go through
its svs_mt8183_banks[] array (including both big & little clusters) and
try to init SVS, so presumably that will have some problems also if only
one cluster is enabled.

> And presumably we'd like to have CCI devfreq running even if just one
> core was booted.

Yes, I assume so also.

> Added Chanwoo for more ideas.

OK, thanks.

Kevin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-19 18:25 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-16  0:43 [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS Roger Lu
2022-05-16  0:43 ` Roger Lu
2022-05-16  0:43 ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 2/7] arm64: dts: mt8183: add svs device information Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 3/7] soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 4/7] soc: mediatek: SVS: add monitor mode Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 5/7] soc: mediatek: SVS: add debug commands Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 6/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43 ` [PATCH v25 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-16  0:43   ` Roger Lu
2022-05-17 10:04 ` [PATCH v25 0/7] soc: mediatek: SVS: introduce MTK SVS Chen-Yu Tsai
2022-05-17 10:04   ` Chen-Yu Tsai
2022-05-17 10:04   ` Chen-Yu Tsai
2022-05-17 22:59   ` Kevin Hilman
2022-05-17 22:59     ` Kevin Hilman
2022-05-17 22:59     ` Kevin Hilman
2022-05-18  0:03     ` Kevin Hilman
2022-05-18  0:03       ` Kevin Hilman
2022-05-18  0:03       ` Kevin Hilman
2022-05-18  4:17       ` Chen-Yu Tsai
2022-05-18  4:17         ` Chen-Yu Tsai
2022-05-18  4:17         ` Chen-Yu Tsai
2022-05-19 18:25         ` Kevin Hilman [this message]
2022-05-19 18:25           ` Kevin Hilman
2022-05-19 18:25           ` Kevin Hilman
2022-05-20  1:54           ` Chanwoo Choi
2022-05-20  1:54             ` Chanwoo Choi
2022-05-20  1:54             ` Chanwoo Choi
2022-05-20  2:42             ` Chen-Yu Tsai
2022-05-20  2:42               ` Chen-Yu Tsai
2022-05-20  2:42               ` Chen-Yu Tsai
2022-05-20  3:12               ` Chanwoo Choi
2022-05-20  3:12                 ` Chanwoo Choi
2022-05-20  3:12                 ` Chanwoo Choi
2022-05-20 10:20               ` Chanwoo Choi
2022-05-20 10:20                 ` Chanwoo Choi
2022-05-20 10:20                 ` Chanwoo Choi
2022-05-24  6:17                 ` Chen-Yu Tsai
2022-05-24  6:17                   ` Chen-Yu Tsai
2022-05-24  6:17                   ` Chen-Yu Tsai
2022-05-25 22:07                   ` Kevin Hilman
2022-05-25 22:07                     ` Kevin Hilman
2022-05-25 22:07                     ` Kevin Hilman
2022-05-31  5:55                     ` Chanwoo Choi
2022-05-31  5:55                       ` Chanwoo Choi
2022-05-31  5:55                       ` Chanwoo Choi
2022-05-18  2:57 ` Rex-BC Chen
2022-05-18  2:57   ` Rex-BC Chen
2022-05-18  2:57   ` Rex-BC Chen
2022-06-06 10:05 ` Chen-Yu Tsai
2022-06-06 10:05   ` Chen-Yu Tsai
2022-06-06 10:05   ` Chen-Yu Tsai
2022-06-08  9:33 ` Kevin Hilman
2022-06-08  9:33   ` Kevin Hilman
2022-06-08  9:33   ` Kevin Hilman
2022-06-17  8:53 ` Matthias Brugger
2022-06-17  8:53   ` Matthias Brugger

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=7hmtfdbcsc.fsf@baylibre.com \
    --to=khilman@kernel.org \
    --cc=Angus.Lin@mediatek.com \
    --cc=Charles.Yang@mediatek.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@google.com \
    --cc=eballetbo@gmail.com \
    --cc=fan.chen@mediatek.com \
    --cc=jia-wei.chang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=nm@ti.com \
    --cc=p.zabel@pengutronix.de \
    --cc=rex-bc.chen@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=roger.lu@mediatek.com \
    --cc=sboyd@kernel.org \
    --cc=wenst@chromium.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.