Strange PMIC behaviour with rohm bd71847 on Ka-Ro tx8m-1610 (imx8mm)

Strange PMIC behaviour with rohm bd71847 on Ka-Ro tx8m-1610 (imx8mm)

[Maud Spierings]

I have been having some issues running mainline Linux on this specific 
COM. Specifically with the shutdown/reboot behaviour seemingly being 
inverted.

I have now figured out how to make shutdown actually behave like 
shutdown. It seems like something is setting BD718XX_REG_TRANS_COND1 
(0x20) to 0xcf. The only bit of code I can find that touches this 
register is this:
drivers/regulator/bd718x7-regulator.c bd718xx_probe():
use_snvs = of_property_read_bool(pdev->dev.parent->of_node,
                      "rohm,reset-snvs-powered");

/*
  * Change the next stage from poweroff to be READY instead of SNVS
  * for all reset types because OTP loading at READY will clear SEL
  * bit allowing HW defaults for power rails to be used
  */
if (!use_snvs) {
         err = regmap_update_bits(regmap, BD718XX_REG_TRANS_COND1,
                      BD718XX_ON_REQ_POWEROFF_MASK |
                      BD718XX_SWRESET_POWEROFF_MASK |
                      BD718XX_WDOG_POWEROFF_MASK |
                      BD718XX_KEY_L_POWEROFF_MASK,
                      BD718XX_POWOFF_TO_RDY);
         if (err)
                 return dev_err_probe(&pdev->dev, err,
                          "Failed to change reset target\n");

         dev_dbg(&pdev->dev, "Changed all resets from SVNS to READY\n");

}

Even with rohm,reset-snvs-powered set I still end up with 0xcf. I've had 
to add the inverse in an else block to get the desired outcome.

else {
         err = regmap_update_bits(regmap, BD718XX_REG_TRANS_COND1,
                      BD718XX_ON_REQ_POWEROFF_MASK |
                      BD718XX_SWRESET_POWEROFF_MASK |
                      BD718XX_WDOG_POWEROFF_MASK |
                      BD718XX_KEY_L_POWEROFF_MASK,
                      BD718XX_POWOFF_TO_SNVS);
         if (err)
                 return dev_err_probe(&pdev->dev, err,
                          "Failed to change reset target\n");

         dev_dbg(&pdev->dev, "Changed all resets from READY to SNVS\n");
}

In uboot I get:

i2c md 0x4b 0x20.1 0x1
0020: c0    .

So something in the kernel is touching this register when it shouldn't.

I am curious if anyone else with this pmic can confirm this.

I used `i2cget -f -y 0 0x4b 0x20` to get the current value.

As a reference my tree is at [1] I'm using the gocontroll_defconfig that 
is present in there and imx8mm-tx8m-1610-moduline-iv-306-d.dtb.
This dts does not have that property set yet, only have that in my local 
tree.

reboot is still shutting down instead of rebooting but I feel like it is 
going to be a similar story.

Kind regards,
Maud

[1]: https://github.com/GOcontroll/linux/tree/gocontroll-6.12.45

Re: Strange PMIC behaviour with rohm bd71847 on Ka-Ro tx8m-1610 (imx8mm)

[Matti Vaittinen]

On 09/09/2025 18:16, Maud Spierings wrote:
> I have been having some issues running mainline Linux on this specific 
> COM. Specifically with the shutdown/reboot behaviour seemingly being 
> inverted.
> 
> I have now figured out how to make shutdown actually behave like 
> shutdown. It seems like something is setting BD718XX_REG_TRANS_COND1 
> (0x20) to 0xcf. The only bit of code I can find that touches this 
> register is this:
> drivers/regulator/bd718x7-regulator.c bd718xx_probe():
> use_snvs = of_property_read_bool(pdev->dev.parent->of_node,
>                       "rohm,reset-snvs-powered");

AFAICS, this is the only place in kernel touching the TRANS_COND.

> /*
>   * Change the next stage from poweroff to be READY instead of SNVS
>   * for all reset types because OTP loading at READY will clear SEL
>   * bit allowing HW defaults for power rails to be used
>   */
> if (!use_snvs) {
>          err = regmap_update_bits(regmap, BD718XX_REG_TRANS_COND1,
>                       BD718XX_ON_REQ_POWEROFF_MASK |
>                       BD718XX_SWRESET_POWEROFF_MASK |
>                       BD718XX_WDOG_POWEROFF_MASK |
>                       BD718XX_KEY_L_POWEROFF_MASK,
>                       BD718XX_POWOFF_TO_RDY);
>          if (err)
>                  return dev_err_probe(&pdev->dev, err,
>                           "Failed to change reset target\n");
> 
>          dev_dbg(&pdev->dev, "Changed all resets from SVNS to READY\n");
> 
> }
> 
> Even with rohm,reset-snvs-powered set I still end up with 0xcf.

Yes. The driver is not - due to historical reasons :) - configuring the 
reset target to SNVS. This should be done by boot SW if SNVS is intended 
to be used. Then the "rohm,reset-snvs-powered" can be used to prevent 
the driver from overwriting the config, and to prevent the driver from 
taking the control of the boot-critical power-outputs. (This is because, 
when SNVS is used, the SW-controlled power-outputs will not get 
automatically enabled after reset - which may "brick" the device).

Some more discussion can be seen in this thread here:
https://lore.kernel.org/all/87bjs3auj9.fsf@geanix.com/

> I've had 
> to add the inverse in an else block to get the desired outcome.
> 
> else {
>          err = regmap_update_bits(regmap, BD718XX_REG_TRANS_COND1,
>                       BD718XX_ON_REQ_POWEROFF_MASK |
>                       BD718XX_SWRESET_POWEROFF_MASK |
>                       BD718XX_WDOG_POWEROFF_MASK |
>                       BD718XX_KEY_L_POWEROFF_MASK,
>                       BD718XX_POWOFF_TO_SNVS);
>          if (err)
>                  return dev_err_probe(&pdev->dev, err,
>                           "Failed to change reset target\n");
> 
>          dev_dbg(&pdev->dev, "Changed all resets from READY to SNVS\n");
> }

This would've originally been "The Right Thing To Do(tm)". Introducing 
it now in upstream would be risky - as discussed in the thread I linked 
above.

> 
> In uboot I get:
> 
> i2c md 0x4b 0x20.1 0x1
> 0020: c0    .
> 
> So something in the kernel is touching this register when it shouldn't.

1. Do you have the "rohm,reset-snvs-powered" set?
2. Can you read and print the TRANS_COND1 at the bd718x7 MFD driver's 
probe (before it instantiates the regulator driver or other sub devices?)
3. Please also read and print the register content in the else branch 
you added, before writing the TRANS_COND1.

(As I wrote above, AFAIR there should be no other places (in kernel) 
where the TRANS_COND1 is written. Are you sure this is not done by boot?)

Yours,
	-- Matti

Re: Strange PMIC behaviour with rohm bd71847 on Ka-Ro tx8m-1610 (imx8mm)

[Maud Spierings]

Hello Matti,

On 9/10/25 08:25, Matti Vaittinen wrote:
> On 09/09/2025 18:16, Maud Spierings wrote:
>> I have been having some issues running mainline Linux on this specific 
>> COM. Specifically with the shutdown/reboot behaviour seemingly being 
>> inverted.
>>
>> I have now figured out how to make shutdown actually behave like 
>> shutdown. It seems like something is setting BD718XX_REG_TRANS_COND1 
>> (0x20) to 0xcf. The only bit of code I can find that touches this 
>> register is this:
>> drivers/regulator/bd718x7-regulator.c bd718xx_probe():
>> use_snvs = of_property_read_bool(pdev->dev.parent->of_node,
>>                       "rohm,reset-snvs-powered");
> 
> AFAICS, this is the only place in kernel touching the TRANS_COND.
> 
>> /*
>>   * Change the next stage from poweroff to be READY instead of SNVS
>>   * for all reset types because OTP loading at READY will clear SEL
>>   * bit allowing HW defaults for power rails to be used
>>   */
>> if (!use_snvs) {
>>          err = regmap_update_bits(regmap, BD718XX_REG_TRANS_COND1,
>>                       BD718XX_ON_REQ_POWEROFF_MASK |
>>                       BD718XX_SWRESET_POWEROFF_MASK |
>>                       BD718XX_WDOG_POWEROFF_MASK |
>>                       BD718XX_KEY_L_POWEROFF_MASK,
>>                       BD718XX_POWOFF_TO_RDY);
>>          if (err)
>>                  return dev_err_probe(&pdev->dev, err,
>>                           "Failed to change reset target\n");
>>
>>          dev_dbg(&pdev->dev, "Changed all resets from SVNS to READY\n");
>>
>> }
>>
>> Even with rohm,reset-snvs-powered set I still end up with 0xcf.
> 
> Yes. The driver is not - due to historical reasons :) - configuring the 
> reset target to SNVS. This should be done by boot SW if SNVS is intended 
> to be used. Then the "rohm,reset-snvs-powered" can be used to prevent 
> the driver from overwriting the config, and to prevent the driver from 
> taking the control of the boot-critical power-outputs. (This is because, 
> when SNVS is used, the SW-controlled power-outputs will not get 
> automatically enabled after reset - which may "brick" the device).
> 
> Some more discussion can be seen in this thread here:
> https://lore.kernel.org/all/87bjs3auj9.fsf@geanix.com/
> 
>> I've had to add the inverse in an else block to get the desired outcome.
>>
>> else {
>>          err = regmap_update_bits(regmap, BD718XX_REG_TRANS_COND1,
>>                       BD718XX_ON_REQ_POWEROFF_MASK |
>>                       BD718XX_SWRESET_POWEROFF_MASK |
>>                       BD718XX_WDOG_POWEROFF_MASK |
>>                       BD718XX_KEY_L_POWEROFF_MASK,
>>                       BD718XX_POWOFF_TO_SNVS);
>>          if (err)
>>                  return dev_err_probe(&pdev->dev, err,
>>                           "Failed to change reset target\n");
>>
>>          dev_dbg(&pdev->dev, "Changed all resets from READY to SNVS\n");
>> }
> 
> This would've originally been "The Right Thing To Do(tm)". Introducing 
> it now in upstream would be risky - as discussed in the thread I linked 
> above.
> 
>>
>> In uboot I get:
>>
>> i2c md 0x4b 0x20.1 0x1
>> 0020: c0    .
>>
>> So something in the kernel is touching this register when it shouldn't.
> 
> 1. Do you have the "rohm,reset-snvs-powered" set?
> 2. Can you read and print the TRANS_COND1 at the bd718x7 MFD driver's 
> probe (before it instantiates the regulator driver or other sub devices?)
> 3. Please also read and print the register content in the else branch 
> you added, before writing the TRANS_COND1.
> 
> (As I wrote above, AFAIR there should be no other places (in kernel) 
> where the TRANS_COND1 is written. Are you sure this is not done by boot?)

Okay I don't know what happened here, it seems to be fine now? I even 
checked the loaded dtb in sysfs to check that the property was there, 
and it was. Now it just seems to behave correctly? I really have no 
explanation for what happened there but what is happening now seems way 
more reasonable and how it actually should be.

Could be that due to the wonky shutdown reboot behaviour the register 
values in the PMIC were saved in the registers from before I added the 
property. Because u-boot does not touch this register at all. Given that 
it doesn't actively write something with this property set.

I'm very sorry for wasting your time because it seems to be fine now. 
Now onto fixing the reboot behaviour.

Again very sorry, a day of patience would've resolved this issue on its 
own it seems. And many thanks for the help.

Kind regards,
Maud

Re: Strange PMIC behaviour with rohm bd71847 on Ka-Ro tx8m-1610 (imx8mm)

[Matti Vaittinen]

On 10/09/2025 11:49, Maud Spierings wrote:
> Hello Matti,
> 
> On 9/10/25 08:25, Matti Vaittinen wrote:
>> On 09/09/2025 18:16, Maud Spierings wrote:

> Again very sorry, a day of patience would've resolved this issue on its 
> own it seems. And many thanks for the help.

No problem! Glad it works for you now.

Yours,
	-- Matti