[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGb2v64O3w6AGH4V-r6D_Zni-pCW2g7BTTceb4CoeAdowR2KNw@mail.gmail.com>
Date: Tue, 29 Jun 2021 10:19:32 +0800
From: Chen-Yu Tsai <wens@...e.org>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Lee Jones <lee.jones@...aro.org>, linux-acpi@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Clamshell <clamfly@....com>
Subject: Re: [PATCH] mfd: axp20x: Update AXP288 volatile ranges
Hi,
On Sat, Jun 26, 2021 at 9:29 PM Hans de Goede <hdegoede@...hat.com> wrote:
>
> On Cherry Trail devices with an AXP288 PMIC the external SD-card slot
> used the AXP's DLDO2 as card-voltage and either DLDO3 or GPIO1LDO
> (GPIO1 pin in low noise LDO mode) as signal-voltage.
>
> These regulators are turned on/off and in case of the signal-voltage
> also have their output-voltage changed by the _PS0 and _PS3 power-
> management ACPI methods on the MMC-controllers ACPI fwnode as well as
> by the _DSM ACPI method for changing the signal voltage.
>
> The AML code implementing these methods is directly accessing the
> PMIC through ACPI I2C OpRegion accesses, instead of using the special
> PMIC OpRegion handled by drivers/acpi/pmic/intel_pmic_xpower.c .
>
> This means that the contents of the involved PMIC registers can change
> without the change being made through the regmap interface, so regmap
> should not cache the contents of these registers.
>
> Mark the LDO power on/off, the LDO voltage control and the GPIO1 control
> register as volatile, to avoid regmap caching their contents.
>
> Specifically this fixes an issue on some models where the i915 driver
> toggles another LDO using the same on/off register on/off through
> MIPI sequences (through intel_soc_pmic_exec_mipi_pmic_seq_element())
> which then writes back a cached on/off register-value where the
> card-voltage is off causing the external sdcard slot to stop working
> when the screen goes blank, or comes back on again.
>
> Note the AXP288 PMIC is only used on Bay- and Cherry-Trail platforms,
> so even though this is an ACPI specific problem there is no need to
> make the new volatile ranges conditional since these platforms always
> use ACPI.
>
> Fixes: dc91c3b6fe66 ("mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatile")
Maybe you want
Fixes: cd53216625a0 ("mfd: axp20x: Fix axp288 volatile ranges")
and then list the other one as a prerequisite? Or just list both tags.
Should we CC stable on this? I don't know the exact use case for these
devices. Are people running distro LTS kernels on them?
> Reported-and-tested-by: Clamshell <clamfly@....com>
> Signed-off-by: Hans de Goede <hdegoede@...hat.com>
> ---
> drivers/mfd/axp20x.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 3eae04e24ac8..db6a21465594 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -125,12 +125,13 @@ static const struct regmap_range axp288_writeable_ranges[] = {
>
> static const struct regmap_range axp288_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP288_POWER_REASON),
> + regmap_reg_range(AXP22X_PWR_OUT_CTRL1, AXP22X_ALDO3_V_OUT),
This region also covers the voltage and on/off controls for the buck
regulators. Maybe include that in your commit message if that was the
intent, or skip over them if not?
Thanks
ChenYu
> regmap_reg_range(AXP288_BC_GLOBAL, AXP288_BC_GLOBAL),
> regmap_reg_range(AXP288_BC_DET_STAT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_CHRG_BAK_CTRL, AXP20X_CHRG_BAK_CTRL),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IPSOUT_V_HIGH_L),
> regmap_reg_range(AXP20X_TIMER_CTRL, AXP20X_TIMER_CTRL),
> - regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> + regmap_reg_range(AXP20X_GPIO1_CTRL, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP288_RT_BATT_V_H, AXP288_RT_BATT_V_L),
> regmap_reg_range(AXP20X_FG_RES, AXP288_FG_CC_CAP_REG),
> };
> --
> 2.31.1
>
Powered by blists - more mailing lists