linux.git/drivers/acpi/pmic, branch v5.16

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

ACPI: scan: Extend acpi_walk_dep_device_list()

2021-06-07T14:45:05+00:00

The acpi_walk_dep_device_list() function is not as generic as its
name implies, serving only to decrement the dependency count for each
dependent device of the input.

Extend it to accept a callback which can be applied to all the
dependencies in acpi_dep_list.

Replace all existing calls to the function with calls to a wrapper,
passing a callback that applies the same dependency reduction.

Reviewed-by: Andy Shevchenko 
Acked-by: Maximilian Luz   # for platform/surface parts
Signed-off-by: Daniel Scally 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki

ACPI: fix various typos in comments

2021-03-19T16:45:49+00:00

Fix trivial ACPI driver comment typos.

s/notifcations/notifications/
s/Ajust/Adjust/
s/preform/perform/
s/atrributes/attributes/
s/Souce/Source/
s/Evalutes/Evaluates/
s/Evalutes/Evaluates/
s/specifiy/specify/
s/promixity/proximity/
s/presuambly/presumably/
s/Evalute/Evaluate/
s/specificed/specified/
s/rountine/routine/
s/previosuly/previously/

Change comment referencing pcc_send_cmd to send_pcc_cmd.

Signed-off-by: Tom Saeger 
Reviewed-by: Randy Dunlap 
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: Move TPS68470 OpRegion driver to drivers/acpi/pmic/

2020-09-15T17:40:59+00:00

It is revealed now that TPS68470 OpRegion driver has been added
in slightly different scope. Let's move it to the drivers/acpi/pmic/
folder for sake of the unification.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: Split out Kconfig and Makefile specific for ACPI PMIC

2020-09-15T17:40:59+00:00

It's a bit better to maintain and allows to avoid mistakes in the future
with PMIC OpRegion drivers, if we split out Kconfig and Makefile
for ACPI PMIC to its own folder.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: Add i2c address for thermal control

2020-05-18T10:57:24+00:00

On Asus T101HA, we keep receiving those error messages:

	i915 0000:00:02.0: [drm] *ERROR* mipi_exec_pmic failed, error: -95
	intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented
	intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x5e reg-addr 0x4b value 0x59 mask 0xff

Because the opregion is missing the I2C address.

Suggested-by: Hans de Goede 
Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Hans de Goede 
Reviewed-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: Add Cherry Trail Crystal Cove PMIC OpRegion driver

2019-10-25T09:43:08+00:00

We have no docs for the CHT Crystal Cove PMIC. The Asus Zenfone-2 kernel
code has 2 Crystal Cove regulator drivers, one calls the PMIC a "Crystal
Cove Plus" PMIC and talks about Cherry Trail, so presuambly that one
could be used to get register info for the regulators if we need to
implement regulator support in the future.

For now the sole purpose of this driver is to make
intel_soc_pmic_exec_mipi_pmic_seq_element work on devices with a
CHT Crystal Cove PMIC.

Specifically this fixes the following MIPI PMIC sequence related errors
on e.g. an Asus T100HA:

[  178.211801] intel_soc_pmic_exec_mipi_pmic_seq_element: No PMIC registered
[  178.211897] [drm:intel_dsi_dcs_init_backlight_funcs [i915]] *ERROR* mipi_exec_pmic failed, error: -6

Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki