From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com> To: Balsam CHIHI <bchihi@baylibre.com> Cc: Chen-Yu Tsai <wenst@chromium.org>, 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: Wed, 26 Apr 2023 19:20:25 -0400 [thread overview] Message-ID: <28e50e45-53cf-4a34-a81c-10f1faab2d4e@notapiano> (raw) In-Reply-To: <CAGuA+oo0w8n9zEKdd1UfYx+F08wK4CcUGqRbBi4C-xNYp+vtDA@mail.gmail.com> On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > <nfraprado@collabora.com> wrote: > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI 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 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. > > > > > > Hi Balsam, > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > sensors. The controller calibration isn't currently handled in this driver (and > > > downstream it also isn't used, since a current value is read from the controller > > > instead), so we can just ignore those. > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > are still tripping excessively. The readings seem normal though. Specifically, > > it's bits 16 and 17 that are tripping. > > > > Hi Chen-Yu, > > Thank you for testing! > > As the readings are normal that proves that calibration data offsets > are correct. > would you like that I send the v2 of series to add mt8192 support? > Then we could deal with the interrupts later in a separate fix, > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > Does Nícolas also have tripping interrupts? > On my side, I've got no interrupts tripping on mt8195. > > Any other suggestions (a question for everyone)? Hi, sorry for the delay. Indeed the interrupts are constantly tripping on mt8192 here as well. I do not see the same bits as Chen-Yu mentioned however, I see LVTS_MONINTSTS = 0x08070000 which corresponds to Hot threshold on sense point 3 high to normal offset on sense point 2 high offset on sense point 2 low offset on sense point 2 and it's the same on all controllers and domains here, which is weird. I noticed we have offset interrupts enabled even though we don't configure the values for those, but even after disabling them and clearing the status register, the interrupts keep triggering and the status is the same, so for some reason LVTS_MONINT doesn't seem to be honored. I also tried using the filtered mode instead of immediate for the sensors, and that together with disabling the extra interrupts, got me a zeroed LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor LVTS_MONINTSTS updated) when the temperature goes over the configured one in LVTS_HTHRE. I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same LVTS_MONINTSTS = 0x08070000 even though the interrupts aren't being triggered, but in fact I don't see them triggering over the threshold either, so I suspect the irq number might be incorrectly described in the DT there. Do either of you have it working correctly on mt8195? Anyway, I'll keep digging and reply here when I find a solution. Thanks, Nícolas
WARNING: multiple messages have this Message-ID (diff)
From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com> To: Balsam CHIHI <bchihi@baylibre.com> Cc: Chen-Yu Tsai <wenst@chromium.org>, 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: Wed, 26 Apr 2023 19:20:25 -0400 [thread overview] Message-ID: <28e50e45-53cf-4a34-a81c-10f1faab2d4e@notapiano> (raw) In-Reply-To: <CAGuA+oo0w8n9zEKdd1UfYx+F08wK4CcUGqRbBi4C-xNYp+vtDA@mail.gmail.com> On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > <nfraprado@collabora.com> wrote: > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI 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 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. > > > > > > Hi Balsam, > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > sensors. The controller calibration isn't currently handled in this driver (and > > > downstream it also isn't used, since a current value is read from the controller > > > instead), so we can just ignore those. > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > are still tripping excessively. The readings seem normal though. Specifically, > > it's bits 16 and 17 that are tripping. > > > > Hi Chen-Yu, > > Thank you for testing! > > As the readings are normal that proves that calibration data offsets > are correct. > would you like that I send the v2 of series to add mt8192 support? > Then we could deal with the interrupts later in a separate fix, > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > Does Nícolas also have tripping interrupts? > On my side, I've got no interrupts tripping on mt8195. > > Any other suggestions (a question for everyone)? Hi, sorry for the delay. Indeed the interrupts are constantly tripping on mt8192 here as well. I do not see the same bits as Chen-Yu mentioned however, I see LVTS_MONINTSTS = 0x08070000 which corresponds to Hot threshold on sense point 3 high to normal offset on sense point 2 high offset on sense point 2 low offset on sense point 2 and it's the same on all controllers and domains here, which is weird. I noticed we have offset interrupts enabled even though we don't configure the values for those, but even after disabling them and clearing the status register, the interrupts keep triggering and the status is the same, so for some reason LVTS_MONINT doesn't seem to be honored. I also tried using the filtered mode instead of immediate for the sensors, and that together with disabling the extra interrupts, got me a zeroed LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor LVTS_MONINTSTS updated) when the temperature goes over the configured one in LVTS_HTHRE. I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same LVTS_MONINTSTS = 0x08070000 even though the interrupts aren't being triggered, but in fact I don't see them triggering over the threshold either, so I suspect the irq number might be incorrectly described in the DT there. Do either of you have it working correctly on mt8195? Anyway, I'll keep digging and reply here when I find a solution. Thanks, Nícolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-26 23:20 UTC|newest] Thread overview: 46+ 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 ` bchihi 2023-03-07 16:34 ` [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition " bchihi 2023-03-07 16:34 ` bchihi 2023-03-08 9:20 ` AngeloGioacchino Del Regno 2023-03-08 9:20 ` AngeloGioacchino Del Regno 2023-03-09 16:17 ` Krzysztof Kozlowski 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-07 16:34 ` bchihi 2023-03-08 9:23 ` AngeloGioacchino Del Regno 2023-03-08 9:23 ` AngeloGioacchino Del Regno 2023-03-08 15:59 ` Balsam CHIHI 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 ` bchihi 2023-03-07 16:34 ` [PATCH 4/4] arm64: dts: mediatek: mt8192: Add temperature mitigation threshold bchihi 2023-03-07 16:34 ` bchihi 2023-03-09 5:04 ` [PATCH 0/4] Add LVTS support for mt8192 Chen-Yu Tsai 2023-03-09 5:04 ` Chen-Yu Tsai 2023-03-09 10:47 ` Balsam CHIHI 2023-03-09 10:47 ` Balsam CHIHI 2023-03-22 12:48 ` Balsam CHIHI 2023-03-22 12:48 ` Balsam CHIHI 2023-03-25 4:33 ` Chen-Yu Tsai 2023-03-25 4:33 ` Chen-Yu Tsai 2023-03-28 0:20 ` Balsam CHIHI 2023-03-28 0:20 ` Balsam CHIHI 2023-03-28 3:12 ` Chen-Yu Tsai 2023-03-28 3:12 ` Chen-Yu Tsai 2023-03-29 8:05 ` Balsam CHIHI 2023-03-29 8:05 ` Balsam CHIHI 2023-04-24 22:21 ` Nícolas F. R. A. Prado 2023-04-24 22:21 ` Nícolas F. R. A. Prado 2023-04-25 8:36 ` Balsam CHIHI 2023-04-25 8:36 ` Balsam CHIHI 2023-04-25 9:59 ` Chen-Yu Tsai 2023-04-25 9:59 ` Chen-Yu Tsai 2023-04-25 11:28 ` Balsam CHIHI 2023-04-25 11:28 ` Balsam CHIHI 2023-04-26 23:20 ` Nícolas F. R. A. Prado [this message] 2023-04-26 23:20 ` Nícolas F. R. A. Prado 2023-04-27 14:08 ` Balsam CHIHI 2023-04-27 14:08 ` Balsam CHIHI 2023-04-28 20:00 ` Nícolas F. R. A. Prado 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=28e50e45-53cf-4a34-a81c-10f1faab2d4e@notapiano \ --to=nfraprado@collabora.com \ --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=wenst@chromium.org \ --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: linkBe 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.