Linux 6.8 rebase: WB8 thermal & cpufreq patches - #225
Merged
Conversation
The Allwinner H616 SoC contains a mysterious bit at register offset 0x0 in the SRAM control block. If bit 16 is set (the reset value), the temperature readings of the THS are way off, leading to reports about 200C, at normal ambient temperatures. Clearing this bits brings the reported values down to the expected values. The BSP code clears this bit in firmware (U-Boot), and has an explicit comment about this, but offers no real explanation. Experiments in U-Boot show that register 0x0 has no effect on the SRAM C visibility: all tested bit settings still allow full read and write access by the CPU to the whole of SRAM C. Only bit 24 of the register at offset 0x4 makes all of SRAM C inaccessible by the CPU. So modelling the THS switch functionality as an SRAM region would not reflect reality. Since we should not rely on firmware settings, allow other code (the THS driver) to access this register, by exporting it through the already existing regmap. This mimics what we already do for the LDO control and the EMAC register. To avoid concurrent accesses to the same register at the same time, by the SRAM switch code and the regmap code, use the same lock to protect the access. The regmap subsystem allows to use an existing lock, so we just need to hook in there. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240219153639.179814-2-andre.przywara@arm.com
This controller is similar to the H6, but covers four sensors and uses slightly different calibration methods. Also the H616 requires to poke a bit in the SYS_CFG register range for correct operation, so add a phandle property to point there. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240219153639.179814-3-andre.przywara@arm.com
So far we were ORing in some "unknown" value into the THS control register on the Allwinner H6. This part of the register is not explained in the H6 manual, but the H616 manual details those bits, and on closer inspection the THS IP blocks in both SoCs seem very close: - The BSP code for both SoCs writes the same values into THS_CTRL. - The reset values of at least the first three registers are the same. Replace the "unknown" value with its proper meaning: "acquire time", most probably the sample part of the sample & hold circuit of the ADC, according to its explanation in the H616 manual. No functional change, just a macro rename and adjustment. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240219153639.179814-4-andre.przywara@arm.com
The H616 SoC resembles the H6 thermal sensor controller, with a few changes like four sensors. Extend sun50i_h6_ths_calibrate() function to support calibration of these sensors. Co-developed-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240219153639.179814-5-andre.przywara@arm.com
The Allwinner H616 SoC needs to clear a bit in one register in the SRAM controller, to report reasonable temperature values. On reset, bit 16 in register 0x3000000 is set, which leads to the driver reporting temperatures around 200C. Clearing this bit brings the values down to the expected range. The BSP code does a one-time write in U-Boot, with a comment just mentioning the effect on the THS, but offering no further explanation. To not rely on firmware to set things up for us, add code that queries the SRAM controller device via a DT phandle link, then clear just this single bit. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240219153639.179814-6-andre.przywara@arm.com
Add support for the thermal sensor found in H616 SoCs, is the same as the H6 thermal sensor controller, but with four sensors. Also the registers readings are wrong, unless a bit in the first SYS_CFG register cleared, so set exercise the SRAM regmap to take care of that. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240219153639.179814-7-andre.przywara@arm.com
Currently the sun8i thermal driver will fail to probe if any of the thermal zones it is registering fails to register with the thermal core. Since we currently do not define any trip points for the GPU thermal zones on at least A64 or H5 this means that we have no thermal support on these platforms: [ 1.698703] thermal_sys: Failed to find 'trips' node [ 1.698707] thermal_sys: Failed to find trip points for thermal-sensor id=1 even though the main CPU thermal zone on both SoCs is fully configured. This does not seem ideal, while we may not be able to use all the zones it seems better to have those zones which are usable be operational. Instead just carry on registering zones if we get any non-deferral error, allowing use of those zones which are usable. This means that we also need to update the interrupt handler to not attempt to notify the core for events on zones which we have not registered, I didn't see an ability to mask individual interrupts and I would expect that interrupts would still be indicated in the ISR even if they were masked. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240123-thermal-sun8i-registration-v3-1-3e5771b1bbdd@kernel.org
Copied from: https://patchwork.kernel.org/project/linux-pm/patch/20240209144221.3602382-8-andre.przywara@arm.com/ May be already present in newer kernels so feel free to throw this away.
The "SoC ID revision" as provided via the SMCCC SOCID interface can be valuable information for drivers, when certain functionality depends on a die revision, for instance. One example is the sun50i-cpufreq-nvmem driver, which needs this information to determine the speed bin of the SoC. Export the arm_smccc_get_soc_id_revision() function so that it can be called by any driver. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
The AllWinner H616 SoC will use the (extended) H6 OPP driver, so add them to the cpufreq-dt blocklist, to not create the device twice. This also affects the closely related sibling SoCs H618 and H700. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Compared to the existing Allwinner H6 OPP scheme, the H616 uses a similar NVMEM based mechanism to determine the silicon revision, which is required to select the right frequency / voltage pair for the OPPs. However it limits the maximum frequency for some speed bins, also seems to not support all frequencies in all speed bins, which requires us to introduce the opp-supported-hw property. Add this property to the list of allowed properties, also drop the requirement for the revision specific opp-microvolt properties, since they might not be needed if using opp-supported-hw. Also use to opportunity to adjust some wording, and drop a sentence referring to the Linux driver and the OPP subsystem. Shorten the existing example and add another example, showcasing the opp-supported-hw property. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
Make converting the speed bin value into a speed grade generic and determined by a platform specific callback. Also change the prototypes involved to encode the speed bin directly in the return value. This allows to extend the driver more easily to support more SoCs. Signed-off-by: Brandon Cheo Fusi <fusibrandon13@gmail.com> [Andre: merge output into return value] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The opp_supported_hw DT property allows the DT to specify a mask of chip revisions that a certain OPP is eligible for. This allows for easy limiting of maximum frequencies, for instance. Add support for that in the sun50i-cpufreq-nvmem driver. We support both the existing opp-microvolt suffix properties as well as the opp-supported-hw property, the generic code figures out which is needed automatically. However if none of the DT OPP nodes contain an opp-supported-hw property, the core code will ignore all OPPs and the driver will fail probing. So check the DT's eligibility first before using that feature. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The Allwinner H616/H618 SoCs have different OPP tables per SoC version and die revision. The SoC version is stored in NVMEM, as before, though encoded differently. The die revision is in a different register, in the SRAM controller. Firmware already exports that value in a standardised way, through the SMCCC SoCID mechanism. We need both values, as some chips have the same SoC version, but they don't support the same frequencies and they get differentiated by the die revision. Add the new compatible string and tie the new translation function to it. This mechanism not only covers the original H616 SoC, but also its very close sibling SoCs H618 and H700, so add them to the list as well. Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Add an Operating Performance Points table for the CPU cores to enable Dynamic Voltage & Frequency Scaling (DVFS) on the H616. The values were taken from the BSP sources. There is a separate OPP set seen on some H700 devices, but they didn't really work out in testing, so they are not included for now. Also add the needed cpu_speed_grade nvmem cell and the cooling cells properties, to enable passive cooling. Signed-off-by: Martin Botka <martin.botka@somainline.org> [Andre: rework to minimise opp-microvolt properties] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
H616 core can be clocked at 288 MHz on CPU_PLL without adjusting PLL frequency divider which the kernel doesn't support at the moment. Running at 288 MHz compared to 488 MHz saves some 0.1W of power.
webconn
force-pushed
the
feature/SOFT-3594-wb8-kernel-thermal-cpufreq
branch
from
July 29, 2024 15:15
6fdaf48 to
37569a9
Compare
evgeny-boger
requested changes
Aug 4, 2024
evgeny-boger
left a comment
Member
There was a problem hiding this comment.
вроде оно уже в апстрим заехало. А это же не оттуда коммиты ещё, а из рассылки?
Contributor
Author
|
я просто твои коммиты перетащил, не смотрел, откуда именно они взялись |
evgeny-boger
approved these changes
Aug 8, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Десятый PR из серии, в которой мы проведём ревью всех изменений в ядро 6.8 для Wiren Board 8.
Здесь собраны все патчи вокруг кода из апстрима (не включены правки в наши dts, будут собраны отдельным PR).
Скорее всего, после проверки #208 надо будет добавить сюда ещё коммит.