From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE7A8C76196 for ; Sat, 25 Mar 2023 04:33:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231861AbjCYEdk (ORCPT ); Sat, 25 Mar 2023 00:33:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231417AbjCYEdi (ORCPT ); Sat, 25 Mar 2023 00:33:38 -0400 Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C6971715 for ; Fri, 24 Mar 2023 21:33:35 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id 89so2836817uao.0 for ; Fri, 24 Mar 2023 21:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1679718814; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+FwD1qe1aEhxGQwbkfsAcs59fzQAp+267YsErGDwRDQ=; b=iOFPi2EpJxYYxobOHGqjcpDoFg3I0Cf9cCiHsWV6gSJJ/2aZpe6HW9DB/PQLkXxGzN qj2kCyi+v1dUPETrWiILCcrZHHflu9iCIqKBzkAHRMM9GRgZ/m/uLOtcWmX4mAJDumVZ UNpPB7YoMkihR/Bvc44JXgVgX8VjDhAwXtAfY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679718814; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+FwD1qe1aEhxGQwbkfsAcs59fzQAp+267YsErGDwRDQ=; b=byGKr7wyxDF021U0jJfmo7idEqz2CRpbB8CdZXMZwQoBAu68Gab77jXJgzQuySZ2lJ v/Tnu8GoJ56yUJFsZed80sUM7pRQWfDIwIw+dcgNZnYaz438Nq6cVZU2FzNaS0FojOaz jz75mIbS7TMD8hjROtySnf56jBNjXkcnQeATr/eg+1glJhHHaQD0g5mYaoNuSRM69peZ Q2IacaE/yhS5x1oFwgAZ5fWcbp4gS2aWk5daEUAMm3n+DEVhwrz1w/jI/uGu1r9T/4k8 zPzTsPOq93UeDxRddgJJpBOB1Wr6GPkFmBov/Ggxx9ulDxIZF+PnneYTFmNVeqwqXv9e uuvw== X-Gm-Message-State: AO0yUKXdPTAkYSIufaas1Kvu1wxrFu0HlpfvQgv4Slu2Q5l+biWpORyA Up43Lnh1InINpKwY0coYt79DriaeekxHVRSzG1XOtQ== X-Google-Smtp-Source: AK7set8snxwLMBw9XRJSwzZ8WvoC9Kq12OK3/hxUxctwmRuEURtsmj8QD8ZysLyTsXXDQnMndDgdvCTkYeUbBR3rXP4= X-Received: by 2002:a05:6122:7c9:b0:401:7625:e9e3 with SMTP id l9-20020a05612207c900b004017625e9e3mr7173590vkr.1.1679718814257; Fri, 24 Mar 2023 21:33:34 -0700 (PDT) MIME-Version: 1.0 References: <20230307163413.143334-1-bchihi@baylibre.com> In-Reply-To: From: Chen-Yu Tsai Date: Sat, 25 Mar 2023 12:33:23 +0800 Message-ID: Subject: Re: [PATCH 0/4] Add LVTS support for mt8192 To: Balsam CHIHI 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 List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Wed, Mar 22, 2023 at 8:48=E2=80=AFPM Balsam CHIHI = 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 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