Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230307163413.143334-1-bchihi@baylibre.com> <CAGXv+5E0wUJYUVD3wx3-=uES612ARQmUE0rxgAruFHxpZCBjzA@mail.gmail.com>
 <CAGuA+ooi7Kx05gagLzXAN3upDiSqDUNOM_djYdGftw6ogVx5gw@mail.gmail.com>
 <CAGuA+oqDPPYFJef_8=YrOpHQNVJ3xgm_zXS6fq_HG2Jy_6t-Zg@mail.gmail.com> <CAGXv+5EZPWohGN5CaEiqVrM4MyAar3cPEUhHtGY_9wTJSJNVFQ@mail.gmail.com>
In-Reply-To: <CAGXv+5EZPWohGN5CaEiqVrM4MyAar3cPEUhHtGY_9wTJSJNVFQ@mail.gmail.com>
From:   Balsam CHIHI <bchihi@baylibre.com>
Date:   Tue, 28 Mar 2023 02:20:24 +0200
Message-ID: <CAGuA+oqF4jFMyEo09VDmCf-_7g0ua3XDKDAJ+t3Gat14pDM9NA@mail.gmail.com>
Subject: Re: [PATCH 0/4] Add LVTS support for mt8192
To:     Chen-Yu Tsai <wenst@chromium.org>
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, Mar 25, 2023 at 5:33=E2=80=AFAM Chen-Yu Tsai <wenst@chromium.org> w=
rote:
>
> On Wed, Mar 22, 2023 at 8:48=E2=80=AFPM 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[] =3D {
> >                 {
> > -               .cal_offset =3D { 0x25, 0x28 },
> > +               .cal_offset =3D { 0x04, 0x04 },
> >                 .lvts_sensor =3D {
> >                         { .dt_id =3D MT8192_AP_VPU0 },
> >                         { .dt_id =3D MT8192_AP_VPU1 }
> > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data
> > mt8192_lvts_ap_data_ctrl[] =3D {
> >                 .hw_tshut_temp =3D LVTS_HW_SHUTDOWN_MT8192,
> >         },
> >         {
> > -               .cal_offset =3D { 0x2e, 0x31 },
> > +               .cal_offset =3D { 0x04, 0x04 },
> >                 .lvts_sensor =3D {
> >                         { .dt_id =3D MT8192_AP_GPU0 },
> >                         { .dt_id =3D MT8192_AP_GPU1 }
> > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data
> > mt8192_lvts_ap_data_ctrl[] =3D {
> >                 .hw_tshut_temp =3D LVTS_HW_SHUTDOWN_MT8192,
> >         },
> >         {
> > -               .cal_offset =3D { 0x37, 0x3a },
> > +               .cal_offset =3D { 0x04, 0x04 },
> >                 .lvts_sensor =3D {
> >                         { .dt_id =3D MT8192_AP_INFRA },
> >                         { .dt_id =3D MT8192_AP_CAM },
> > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data
> > mt8192_lvts_ap_data_ctrl[] =3D {
> >                 .hw_tshut_temp =3D LVTS_HW_SHUTDOWN_MT8192,
> >         },
> >         {
> > -               .cal_offset =3D { 0x40, 0x43, 0x46 },
> > +               .cal_offset =3D { 0x04, 0x04, 0x04 },
> >                 .lvts_sensor =3D {
> >                         { .dt_id =3D MT8192_AP_MD0 },
> >                         { .dt_id =3D 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 ChromeO=
S'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 store=
d
> in lower 24 bits of each 32-bit word, and the highest 8 bits are then use=
d
> 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 mt=
8195.
So, the mt8192's support will be delayed for now, to allow further debuggin=
g.

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?

Best regards,
Balsam