kernel/linux.git/drivers/acpi/pmic, branch v6.6.133

ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()

2024-10-04T14:28:49+00:00

[ Upstream commit 07442c46abad1d50ac82af5e0f9c5de2732c4592 ] In tps68470_pmic_opregion_probe() pointer 'dev' is compared to NULL which is useless. Fix this issue by removing unneeded check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e13452ac3790 ("ACPI / PMIC: Add TI PMIC TPS68470 operation region driver") Suggested-by: Andy Shevchenko Signed-off-by: Aleksandr Mishin Reviewed-by: Sakari Ailus Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20240730225339.13165-1-amishin@t-argos.ru [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: PMIC: Add comments with DSDT power opregion field names

2023-01-30T15:47:13+00:00

The DSDTs of CHT devices using the Dollar Cove TI PMIC, all use LDO1 - LDO14 names for the DSDT power opregion field names. Add comments with these fields to make it easier to see which PMIC registers are being set by ACPI code using these. Note that LDO4 is missing and the mapped registers jump from 0x43 to 0x45 to match. This matches with how the fields are declared in the DSDT where LDO4 is skipped too. Note there is no hole in the field addresses, LDO4 is simply just not defined on either side. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

ACPI: PMIC: Add pmic_i2c_address to BYT Crystal Cove support

2022-12-30T17:46:55+00:00

Add a pmic_i2c_address entry to intel_pmic_bytcrc.c, so that intel_soc_pmic_exec_mipi_pmic_seq_element() can be used on devices with a Bay Trail Crystal Cove PMIC OpRegion driver. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

ACPI: PMIC: xpower: Fix _TMP ACPI errors

2021-12-08T14:34:57+00:00

On some devices with a X-Powers AXP288 PMIC the LPAT tables in the ACPI node for the AXP288 PMIC for some reason only describe a small temperature range, e.g. 27° - 37° Celcius (assuming the entries are in millidegrees). When the tablet is idle in a room at 21° degrees this is causing values outside the LPAT table to be read, causing e.g. the following 2 errors to get spammed to the logs every 4 seconds! : [ 7512.791316] ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20210930/evregion-281) [ 7512.791611] ACPI Error: Aborting method \_SB.SXP1._TMP due to previous error (AE_ERROR) (20210930/psparse-529) Fix this by clamping the raw value to the LPAT table range before passing it to acpi_lpat_raw_to_temp(). Note clamping has been chosen rather then extrapolating because it is unknown how other parts of the ACPI tables will respond to temperature values outside of the LPAT range. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

ACPI: PMIC: allow drivers to provide a custom lpat_raw_to_temp() function

2021-12-08T14:34:57+00:00

The LPAT tables used in the DSDT for some PMICs require special handling, allow the PMIC OpRegion drivers to provide an alternative implementation by adding a lpat_raw_to_temp function pointer to struct pmic_table; and initialize this to the default acpi_lpat_raw_to_temp function for all PMICs. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

ACPI: PMIC: constify all struct intel_pmic_opregion_data declarations

2021-12-08T14:34:57+00:00

The struct intel_pmic_opregion_data declarations never change, constify them all. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses

2021-11-03T18:28:32+00:00

The handling of PMIC register reads through writing 0 to address 4 of the OpRegion is wrong. Instead of returning the read value through the value64, which is a no-op for function == ACPI_WRITE calls, store the value and then on a subsequent function == ACPI_READ with address == 3 (the address for the value field of the OpRegion) return the stored value. This has been tested on a Xiaomi Mi Pad 2 and makes the ACPI battery dev there mostly functional (unfortunately there are still other issues). Here are the SET() / GET() functions of the PMIC ACPI device, which use this OpRegion, which clearly show the new behavior to be correct: OperationRegion (REGS, 0x8F, Zero, 0x50) Field (REGS, ByteAcc, NoLock, Preserve) { CLNT, 8, SA, 8, OFF, 8, VAL, 8, RWM, 8 } Method (GET, 3, Serialized) { If ((AVBE == One)) { CLNT = Arg0 SA = Arg1 OFF = Arg2 RWM = Zero If ((AVBG == One)) { GPRW = Zero } } Return (VAL) /* \_SB_.PCI0.I2C7.PMI5.VAL_ */ } Method (SET, 4, Serialized) { If ((AVBE == One)) { CLNT = Arg0 SA = Arg1 OFF = Arg2 VAL = Arg3 RWM = One If ((AVBG == One)) { GPRW = One } } } Fixes: 0afa877a5650 ("ACPI / PMIC: intel: add REGS operation region support") Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: XPower: optimize MIPI PMIQ sequence I2C-bus accesses

2021-07-16T17:05:59+00:00

The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus and while the kernel holds the semaphore the CPU and GPU power-states must not be changed otherwise the system will freeze. This is a complex process, which is quite expensive. This is all done by iosf_mbi_block_punit_i2c_access(). To ensure that no unguarded I2C-bus accesses happen, iosf_mbi_block_punit_i2c_access() gets called by the I2C-bus-driver for every I2C transfer. Because this is so expensive it is allowed to call iosf_mbi_block_punit_i2c_access() in a nested fashion, so that higher-level code which does multiple I2C-transfers can call it once for a group of transfers, turning the calls done by the I2C-bus-driver into no-ops. The default exec_mipi_pmic_seq_element implementation from drivers/acpi/pmic/intel_pmic.c does a regmap_update_bits() call and the involved registers are typically marked as volatile in the regmap, so this leads to 2 I2C-bus accesses. Add a XPower AXP288 specific implementation of exec_mipi_pmic_seq_element which calls iosf_mbi_block_punit_i2c_access() calls before the regmap_update_bits() call to avoid having to do the whole expensive acquire P-Unit semaphore dance twice. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: XPower: optimize I2C-bus accesses

2021-07-16T17:05:59+00:00

The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus and while the kernel holds the semaphore the CPU and GPU power-states must not be changed otherwise the system will freeze. This is a complex process, which is quite expensive. This is all done by iosf_mbi_block_punit_i2c_access(). To ensure that no unguarded I2C-bus accesses happen, iosf_mbi_block_punit_i2c_access() gets called by the I2C-bus-driver for every I2C transfer. Because this is so expensive it is allowed to call iosf_mbi_block_punit_i2c_access() in a nested fashion, so that higher-level code which does multiple I2C-transfers can call it once for a group of transfers, turning the calls done by the I2C-bus-driver into no-ops. Add iosf_mbi_block_punit_i2c_access() calls around groups of register accesses, so that the P-Unit semaphore only needs to be taken once for each group of register accesses. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

mfd: tps68470: Remove tps68470 MFD driver

2021-06-17T11:12:18+00:00

This driver only covered one scenario in which ACPI devices with _HID INT3472 are found, and its functionality has been taken over by the intel-skl-int3472 module, so remove it. Acked-by: Andy Shevchenko Acked-by: Lee Jones Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Scally Link: https://lore.kernel.org/r/20210603224007.120560-7-djrscally@gmail.com Signed-off-by: Hans de Goede