[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXv+5EZPWohGN5CaEiqVrM4MyAar3cPEUhHtGY_9wTJSJNVFQ@mail.gmail.com>
Date: Sat, 25 Mar 2023 12:33:23 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: Balsam CHIHI <bchihi@...libre.com>
Cc: daniel.lezcano@...aro.org, angelogioacchino.delregno@...labora.com,
rafael@...nel.org, amitk@...nel.org, rui.zhang@...el.com,
matthias.bgg@...il.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, rdunlap@...radead.org,
ye.xingchen@....com.cn, p.zabel@...gutronix.de,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org,
khilman@...libre.com, james.lo@...iatek.com,
rex-bc.chen@...iatek.com
Subject: Re: [PATCH 0/4] Add LVTS support for mt8192
On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@...libre.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
Powered by blists - more mailing lists