How to enable LDOs in Android bootloader (LK)

Hi everyone,

I’m studying AOSP’s bootloader (LK) with Dragonboard 410c (branch LA.BR.1.2.7-01010-8x16) and I want to enable LDO15 & LDO16 in LK.

My problem is that I just can read the LDO16_EN_CTL register of PMIC (address 0x00014E46, refers to “PM8916 Hardware Register Description” document) by using pm8x41_reg_read() function or REG_READ() macro. But when I try to write new value to this register, the boot process hangs at the call of pm8x41_reg_write(0x00014E46, 0x80) or REG_WRITE(0x00014E46, 0x80) in LK and I have to reflash the on-board eMMC :frowning: (although there’s many calls to REG_WRITE() macro in /lk/dev/pmic/pm8x41/pm8x41.c).

Please help me to solve this problem.

Hi @vutuda,

You are the adventurer. :slight_smile:
We also have only the information about PMIC described in the bellow documentation.

PM8916 Hardware Register Description

The linux kernel might have more info one the LDO15 & LDO16.

Hi Mr. Akira Tsukamoto,

Thanks for your info.
But I still wonder why Android stock image does not enable the 1V8 power supply (on Low Speed Expansion connector) or other LDOs in Little Kernel (bootloader) by default.

Anyway, I’ll try to find another ways :slight_smile:

Best regards


I just happened to stumble on this thread. Did you find out a way to modify the LDO configuration already in the lk? I would assume you need to configure the other registers as well on that LDO that you are enabling. But it’s still a fragile system and turning on stuff in the wrong order will just not work.


Hi Vutuda, Nicklas,
did you already made some progress regarding this topic?
I would also be highly interested in leraning how to enable PMICs from lk?

Many thanks in advance,

Hi Nicklas, dieter,

I’m sorry, I cannot find any solutions to enable the default-OFF LDOs (eg. LDO15 or LDO16) in LK.
I think this caused by proprietary binaries from Qualcomm. Maybe, by default, they didn’t expose permissions to user to enable the PMIC’s LDO in LK.

Best regards.

Hi Dieter,

Per the permission model in the Qualcomm platforms you are likely not allowed to work the regulator directly with the PMIC, instead you must make your requests to the resource power manager (RPM), which is controlling most of the regulators provided by the PMIC.

To do this you have to issue RPM requests over SMD.

Looking at the specific LK tag I see that 8916 does not do any such operations currently (and doesn’t even initialize SMD). It does however do this for 8994, so we have all the code for doing this.

So, based on msm8994 as reference, you would need to:

  • define SMD_IRQ for 8916 - seems to be 168
  • define APCS_ALIAS0_IPC_INTERRUPT as 0x0b011008
  • make sure to call rpm_smd_init() from your target_init()
  • similar to target/msm8994/regulator.c call rpm_send_data() on something like this
static uint32_t ldo15[] = {
    KEY_MICRO_VOLT, 4, some_voltage,

rpm_send_data(ldo15, sizeof(ldo15) - 2, RPM_REQUEST_TYPE);

This request is for LDO 15 on the primary (the A in ldoA) PMIC. The packets are of [key, length, value] format, so we’re asking to change the value of “enable” and “micro_volt”, each takes 4 bytes of parameters and the values are “enable” and “some_voltage” (e.g. 1800000) respectively.

Unfortunately I now see what the difference between 8916 and 8994 is in terms of SMD. LK will leave the RPM SMD channel in a state where the Linux kernel won’t trigger the initialization of regulator, so you can use this to implement your LK feature but I need to figure out how to fix the kernel to live with this.


Hi Bjorn,
given the fact we would habe setup everyhting according to what you described above.
Please can you check what needs to be fixed inside the kernel?
As far as I understood my customer the state-machine jumps on “CLOSING” of remote_status when running the uinit sequence (as with the 8909). After that linux ignores this channel and the regulators can not longer be adressed.

Would be great to have your valuable feedback,

Dieter, Vutuda,

This came up again and I wrote up two patches that I’m currently testing. Please have a look if this is still relevant. If nothing comes up I intend to include these in v4.16 (and if you find it useful I can backport them to our v4.14 release branch)


Hi Bjorn,
thank you for that information!
If you would aks me, v4.14 would be great because this is LTS kernel, correct?


Right, v4.14 is what will be the base for our releases during 2018. But the patch will enter mainline in v4.16.