mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
v2 cover mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
Patch series adding support for ROHM BD71837 PMIC.
BD71837 is a programmable Power Management IC for powering single-core, dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for low BOM cost and compact solution footprint. It integrates 8 buck regulators and 7 LDO’s to provide all the power rails required by the SoC and the commonly used peripherals.
The driver aims to not limit the usage of PMIC. Thus the buck and LDO naming is generic and not tied to any specific purposes. However there is following limitations which make it mostly suitable for use cases where the processor where PMIC driver is running is powered by the PMIC:
- The PMIC is not re-initialized if it resets. PMIC may reset as a result of voltage monitoring (over/under voltage) or due to reset request. Driver is only initializing PMIC at probe. This is not problem as long as processor controlling PMIC is powered by PMIC.
- The PMIC internal state machine is ignored by driver. Driver assumes the PMIC is wired so that it is always in "run" state when controlled by the driver.
Changelog v2
Based on feedback from Mark Brown
- Squashed code and buildfile changes to same patch
- Fixed some styling issues
- Changed SPDX comments to CPP style
- Error out if voltage is changed when regulator is enabled instead of Disabling the regulator for duration of change
- Use devm_regulator_register
- Remove compatible usage from regulators - use parent dev for config
- Add a note about using regulator-boot-on for BUCK6 and 7
- fixed warnings from kbuild test robot
patch 1:
MFD driver and definitions bringing interrupt support and enabling clk and regulator subsystems.
Patches 2, 3 and 4:
device tree binding documents.
Patch 5:
clock subsystem and support for gated clock.
Patch 6:
regulator driver supporting 8 bucks and 7 LDOs.
This patch series is based on for-mfd-next
---
Matti Vaittinen (6):
mfd: bd71837: mfd driver for ROHM BD71837 PMIC
mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
regulator: bd71837: Devicetree bindings for BD71837 regulators
clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
clk: bd71837: Add driver for BD71837 PMIC clock
regulator: bd71837: BD71837 PMIC regulator driver
.../bindings/clock/rohm,bd71837-clock.txt | 37 ++ .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 52 ++ .../bindings/regulator/rohm,bd71837-regulator.txt | 126 ++++ drivers/clk/Kconfig | 9 + drivers/clk/Makefile | 1 + drivers/clk/clk-bd71837.c | 154 +++++ drivers/mfd/Kconfig | 13 + drivers/mfd/Makefile | 1 + drivers/mfd/bd71837.c | 238 ++++++++ drivers/regulator/Kconfig | 11 + drivers/regulator/Makefile | 1 + drivers/regulator/bd71837-regulator.c | 678 +++++++++++++++++++++ include/linux/mfd/bd71837.h | 316 ++++++++++ 13 files changed, 1637 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt create mode 100644 drivers/clk/clk-bd71837.c create mode 100644 drivers/mfd/bd71837.c create mode 100644 drivers/regulator/bd71837-regulator.c create mode 100644 include/linux/mfd/bd71837.h
Signature · 1 line
2.14.3
Quoted 13 lines · Matti Vaittinen
Patch series adding support for ROHM BD71837 PMIC.
BD71837 is a programmable Power Management IC for powering single-core, dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for low BOM cost and compact solution footprint. It integrates 8 buck regulators and 7 LDO’s to provide all the power rails required by the SoC and the commonly used peripherals.
The driver aims to not limit the usage of PMIC. Thus the buck and LDO naming is generic and not tied to any specific purposes. However there is following limitations which make it mostly suitable for use cases where the processor where PMIC driver is running is powered by the PMIC:
Quoted 8 lines
- The PMIC is not re-initialized if it resets. PMIC may reset as a result of voltage monitoring (over/under voltage) or due to reset request. Driver is only initializing PMIC at probe. This is not problem as long as processor controlling PMIC is powered by PMIC.
- The PMIC internal state machine is ignored by driver. Driver assumes the PMIC is wired so that it is always in "run" state when controlled by the driver.
FYI, this patch-set is going to be difficult to manage since it was not sent 'threaded'. As people start replying to different patches, they are going to scatter-bomb throughout all of the recipient's inboxes.
If/when you send a subsequent version, could you please ensure you send the set threaded so the patches keep in relation to one another as they are reviewed?
Signature · 4 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Hello,
Quoted 9 lines · Lee Jones
Quoted 1 line · Matti Vaittinen
Patch series adding support for ROHM BD71837 PMIC.
FYI, this patch-set is going to be difficult to manage since it was not sent 'threaded'.
If/when you send a subsequent version, could you please ensure you send the set threaded so the patches keep in relation to one another as they are reviewed?
Thanks for the guidance. I have not sent so many patches to community so I am grateful also from all the practical tips =) Just one slight problem. I have only seen emails being threaded when one is replying to an email. So how should I send my patches in same thread? Just send first one and then send subsequent patches as replies?
I just killed some unused definitions and one unused variable from the code so I am about to send new version. I'll try doing that as a threaded series and resend all the patches as v3.
Br,
Matti Vaittinen
Quoted 19 lines · Matti Vaittinen
Hello,
Quoted 9 lines · Lee Jones
Quoted 1 line · Matti Vaittinen
Patch series adding support for ROHM BD71837 PMIC.
FYI, this patch-set is going to be difficult to manage since it was not sent 'threaded'.
If/when you send a subsequent version, could you please ensure you send the set threaded so the patches keep in relation to one another as they are reviewed?
Thanks for the guidance. I have not sent so many patches to community so I am grateful also from all the practical tips =) Just one slight problem. I have only seen emails being threaded when one is replying to an email. So how should I send my patches in same thread? Just send first one and then send subsequent patches as replies?
Quoted 3 lines
I just killed some unused definitions and one unused variable from the code so I am about to send new version. I'll try doing that as a threaded series and resend all the patches as v3.
You don't need to do this manually.
Just use git send-email with the correct arguments.
Signature · 4 lines
Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Stephen Boyd
maintainerQuoting Lee Jones (2018-05-30 04:16:49)
Quoted 22 lines · Matti Vaittinen
=
Quoted 19 lines
Hello,
=Quoted 11 lines · Lee Jones
On Mon, 28 May 2018, Matti Vaittinen wrote:
=Quoted 1 line
Patch series adding support for ROHM BD71837 PMIC.
FYI, this patch-set is going to be difficult to manage since it was not sent 'threaded'.
=If/when you send a subsequent version, could you please ensure you send the set threaded so the patches keep in relation to one another as they are reviewed?
=
Thanks for the guidance. I have not sent so many patches to community so I am grateful also from all the practical tips =3D) Just one slight pro=
blem.
Quoted 7 lines
Quoted 7 lines
I have only seen emails being threaded when one is replying to an email. So how should I send my patches in same thread? Just send first one and then send subsequent patches as replies?
=I just killed some unused definitions and one unused variable from the code so I am about to send new version. I'll try doing that as a thread=
ed
Quoted 8 lines
Quoted 1 line
series and resend all the patches as v3.
=
You don't need to do this manually.
=Just use
git send-emailwith the correct arguments. =
I usually send with 'git send-email *.patch' so that git can do the threading for me. Looks like these patches were sent with Mutt though, so perhaps 'git format-patch | git imap-send' was used without the --thread option on format-patch.
Quoted 28 lines · Stephen Boyd
Quoting Lee Jones (2018-05-30 04:16:49)
Quoted 27 lines · Matti Vaittinen
Quoted 20 lines
Hello,
Quoted 9 lines · Lee Jones
Quoted 1 line · Matti Vaittinen
Patch series adding support for ROHM BD71837 PMIC.
FYI, this patch-set is going to be difficult to manage since it was not sent 'threaded'.
If/when you send a subsequent version, could you please ensure you send the set threaded so the patches keep in relation to one another as they are reviewed?
Thanks for the guidance. I have not sent so many patches to community so I am grateful also from all the practical tips =) Just one slight problem. I have only seen emails being threaded when one is replying to an email. So how should I send my patches in same thread? Just send first one and then send subsequent patches as replies?
Quoted 3 lines
I just killed some unused definitions and one unused variable from the code so I am about to send new version. I'll try doing that as a threaded series and resend all the patches as v3.
You don't need to do this manually.
Quoted 7 lines
Quoted 2 lines
Just use
git send-emailwith the correct arguments.I usually send with 'git send-email *.patch' so that git can do the threading for me. Looks like these patches were sent with Mutt though, so perhaps 'git format-patch | git imap-send' was used without the --thread option on format-patch.
Yep. I used git format-patch without the --thread and mutt -H for sending. Learned the --thread after Lee pointed out the threading and used it for further series. Thanks for the help!
Br,
Matti Vaittinen