[PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[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:

- 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

Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Lee Jones]

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

Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Matti Vaittinen]

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

Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Lee Jones]

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

Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Stephen Boyd]

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 =3D) Just one slight pro=
blem.
> > 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
> > 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.

Re: [PATCH v2 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver

[Matti Vaittinen]

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