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
--
2.14.3
On Mon, 28 May 2018, Matti Vaittinen wrote:
> 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.
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?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hello,
On Tue, May 29, 2018 at 08:39:58AM +0100, Lee Jones wrote:
> On Mon, 28 May 2018, Matti Vaittinen wrote:
>
> > 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
On Tue, 29 May 2018, Matti Vaittinen wrote:
> Hello,
>
> On Tue, May 29, 2018 at 08:39:58AM +0100, Lee Jones wrote:
> > On Mon, 28 May 2018, Matti Vaittinen wrote:
> >
> > > 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.
You don't need to do this manually.
Just use `git send-email` with the correct arguments.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Quoting Lee Jones (2018-05-30 04:16:49)
> On Tue, 29 May 2018, Matti Vaittinen wrote:
>
> > Hello,
> >
> > On Tue, May 29, 2018 at 08:39:58AM +0100, Lee Jones wrote:
> > > On Mon, 28 May 2018, Matti Vaittinen wrote:
> > >
> > > > 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.
>
> You don't need to do this manually.
>
> Just use `git send-email` with 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.
On Wed, May 30, 2018 at 08:23:47AM -0700, Stephen Boyd wrote:
> Quoting Lee Jones (2018-05-30 04:16:49)
> > On Tue, 29 May 2018, Matti Vaittinen wrote:
> >
> > > Hello,
> > >
> > > On Tue, May 29, 2018 at 08:39:58AM +0100, Lee Jones wrote:
> > > > On Mon, 28 May 2018, Matti Vaittinen wrote:
> > > >
> > > > > 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.
> >
> > You don't need to do this manually.
> >
> > Just use `git send-email` with 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