linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wenst@chromium.org>
To: Balsam CHIHI <bchihi@baylibre.com>
Cc: daniel.lezcano@linaro.org,
	angelogioacchino.delregno@collabora.com, rafael@kernel.org,
	amitk@kernel.org, rui.zhang@intel.com, matthias.bgg@gmail.com,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	rdunlap@infradead.org, ye.xingchen@zte.com.cn,
	p.zabel@pengutronix.de, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org,
	khilman@baylibre.com, james.lo@mediatek.com,
	rex-bc.chen@mediatek.com
Subject: Re: [PATCH 0/4] Add LVTS support for mt8192
Date: Tue, 28 Mar 2023 11:12:43 +0800	[thread overview]
Message-ID: <CAGXv+5GGO76H9Z-X=3nhtmSyp7uhuUF4DE0T527M5z+SBX482Q@mail.gmail.com> (raw)
In-Reply-To: <CAGuA+oqF4jFMyEo09VDmCf-_7g0ua3XDKDAJ+t3Gat14pDM9NA@mail.gmail.com>

On Tue, Mar 28, 2023 at 8:21 AM Balsam CHIHI <bchihi@baylibre.com> wrote:
>
> On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote:
> > >
> > > Hi Chen-Yu,
> > >
> > > I suspect the bug comes from incorrect calibration data offsets for AP
> > > Domain because you confirm that MCU Domain probe runs without issues.
> > > Is it possible to test something for us to confirm this theory (i
> > > don't have an mt8192 board on hand now), when you have the time of
> > > course?
> > > We would like to test AP Domain's calibration data offsets with a
> > > working one, for example :
> > >
> > >  static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = {
> > >                 {
> > > -               .cal_offset = { 0x25, 0x28 },
> > > +               .cal_offset = { 0x04, 0x04 },
> > >                 .lvts_sensor = {
> > >                         { .dt_id = MT8192_AP_VPU0 },
> > >                         { .dt_id = MT8192_AP_VPU1 }
> > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data
> > > mt8192_lvts_ap_data_ctrl[] = {
> > >                 .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192,
> > >         },
> > >         {
> > > -               .cal_offset = { 0x2e, 0x31 },
> > > +               .cal_offset = { 0x04, 0x04 },
> > >                 .lvts_sensor = {
> > >                         { .dt_id = MT8192_AP_GPU0 },
> > >                         { .dt_id = MT8192_AP_GPU1 }
> > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data
> > > mt8192_lvts_ap_data_ctrl[] = {
> > >                 .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192,
> > >         },
> > >         {
> > > -               .cal_offset = { 0x37, 0x3a },
> > > +               .cal_offset = { 0x04, 0x04 },
> > >                 .lvts_sensor = {
> > >                         { .dt_id = MT8192_AP_INFRA },
> > >                         { .dt_id = MT8192_AP_CAM },
> > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data
> > > mt8192_lvts_ap_data_ctrl[] = {
> > >                 .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192,
> > >         },
> > >         {
> > > -               .cal_offset = { 0x40, 0x43, 0x46 },
> > > +               .cal_offset = { 0x04, 0x04, 0x04 },
> > >                 .lvts_sensor = {
> > >                         { .dt_id = MT8192_AP_MD0 },
> > >                         { .dt_id = MT8192_AP_MD1 },
> > >
> > > This example is tested and works for mt8195,
> > > (all sensors use the same calibration data offset for testing purposes).
> > >
> > > Thank you in advance for your help.
> >
> > The MCU ones are still tripping though. If I change all of them to 0x04,
> > then nothing trips. There's also a bug in the interrupt handling code
> > that needs to be dealt with.
> >
> > AFAICT the calibration data is stored differently. If you look at ChromeOS's
> > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192,
> > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to:
> > MT8195 has all data sequentially stored, while MT8192 has most data stored
> > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used
> > to pack data for the remaining sensors.
> >
> > Regards
> > ChenYu
>
> Hi Chen-Yu Tsai,
>
> Thank you very much for helping me testing this suggestion.
>
> Indeed, calibration data is stored differently in the mt8192 compared to mt8195.
> So, the mt8192's support will be delayed for now, to allow further debugging.
>
> In the mean time, we will only continue to upstream the remaining
> mt8195's source code, so it will get full LVTS support.
> A new series will be submitted soon.
>
> Would you please point me out to the bug in interrupt handling code?

I just sent out two patches and CC-ed you on them. They are here just in case:

https://lore.kernel.org/linux-pm/20230328031037.1361048-1-wenst@chromium.org/
https://lore.kernel.org/linux-pm/20230328031017.1360976-1-wenst@chromium.org/

ChenYu

  reply	other threads:[~2023-03-28  3:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 16:34 [PATCH 0/4] Add LVTS support for mt8192 bchihi
2023-03-07 16:34 ` [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition " bchihi
2023-03-08  9:20   ` AngeloGioacchino Del Regno
2023-03-09 16:17   ` Krzysztof Kozlowski
2023-03-07 16:34 ` [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support bchihi
2023-03-08  9:23   ` AngeloGioacchino Del Regno
2023-03-08 15:59     ` Balsam CHIHI
2023-03-07 16:34 ` [PATCH 3/4] arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes bchihi
2023-03-07 16:34 ` [PATCH 4/4] arm64: dts: mediatek: mt8192: Add temperature mitigation threshold bchihi
2023-03-09  5:04 ` [PATCH 0/4] Add LVTS support for mt8192 Chen-Yu Tsai
2023-03-09 10:47   ` Balsam CHIHI
2023-03-22 12:48     ` Balsam CHIHI
2023-03-25  4:33       ` Chen-Yu Tsai
2023-03-28  0:20         ` Balsam CHIHI
2023-03-28  3:12           ` Chen-Yu Tsai [this message]
2023-03-29  8:05             ` Balsam CHIHI
2023-04-24 22:21           ` Nícolas F. R. A. Prado
2023-04-25  8:36             ` Balsam CHIHI
2023-04-25  9:59             ` Chen-Yu Tsai
2023-04-25 11:28               ` Balsam CHIHI
2023-04-26 23:20                 ` Nícolas F. R. A. Prado
2023-04-27 14:08                   ` Balsam CHIHI
2023-04-28 20:00                     ` Nícolas F. R. A. Prado

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='CAGXv+5GGO76H9Z-X=3nhtmSyp7uhuUF4DE0T527M5z+SBX482Q@mail.gmail.com' \
    --to=wenst@chromium.org \
    --cc=amitk@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bchihi@baylibre.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=james.lo@mediatek.com \
    --cc=khilman@baylibre.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --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=matthias.bgg@gmail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rex-bc.chen@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=ye.xingchen@zte.com.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).