[v7,0/6] Support ROHM BD9576MUF and BD9573MUF PMICs

Message

Vaittinen, Matti Jan. 22, 2021, 2:30 p.m. UTC

Initial support for ROHM BD9576MUF and BD9573MUF PMICs.

These PMICs are primarily intended to be used to power the R-Car family
processors. BD9576MUF includes some additional safety features the
BD9573MUF does not have. This initial version of drivers provides
temperature, over voltage and under voltage warnings is IRQ information
is passed via DT.

This patch series includes MFD and watchdog drivers. Regulator part was
already applied but this series brings the over-/undervoltage and
temperature error notifications which consumer drivers can utilize.

WDG supports
- Enabling and pinging the watchdog
- configuring watchog timeout / window from device-tree

BD9576MUF and BD9573MUF are designed to keep the IRQ line low for whole
duration of error condition. Yet the IRQ must be acked before line is
pulled low. This means that handling the IRQ as edge triggered IRQ
will introduce the classic race of new IRQ occurring while one is
handled. (New status bit being set just after status was read but before
it was acked. That will cause the new IRQ to not be acked which leaves the
IRQ line low. With edge triggered IRQs this means that no more edges will
be seen.) In order to prevent the processor from staying in IRQ handling
loop we only handle the main status register with regmap IRQ
irq-controller (main status bits can be masked) but leave the sub-status
bits (some of which can't be masked) to be handled by the IRQ handlers.
When regulator driver handler is run, it will 'increase the depth' of IRQ
disabling (causing main status bit to stay masked when handler exits)
and arms a 1sec delayed_work to do unmasking. I am open to suggestions as
how to handle this more elegantly. Please note that the BD9573 does not
offer 'warning' interrupts and will only generate IRQ when it is
entering into emergency state and shutting down the power from the SOC.

This far the IRQ logic has only received a limited amount of testing. I
managed to get the OVD/UVD condition by probing break-out board
manually. This however usually did  lead the PMIC to go to emergency
state so there may be corner cases not covered by my tests. Basic IRQ
limiting seems to be working though.

Please note that not all of the boards are expected to be utilizing the
warning IRQs. Thus populating the IRQ information from DT is optional.

Changelog v7:
  - Added interrupt handling
  - Added notifications and error_flag getter to regulators

Changelog v6:
  - Fixed watchdog timeout

Changelog v5:
  - rebased on top of v5.10-rc2
  - few styling fixes in MFD as suggested by Lee

Changelog v4:
  - rebased on top of 5.10-rc1
  - Fix typo (repeated word maximum) from the DT binding doc

Changelog v3:
  - use only one binding to specify watchdog time-out window.

Changelog v2:
  - dropped already applied regulator part
  - dt_bindings: Fix case for regulator-names in the example
  - watchdod: unify probe error check and revise includes

---


Matti Vaittinen (6):
  dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs
  mfd: Support ROHM BD9576MUF and BD9573MUF
  mfd: bd9576: Add IRQ support
  wdt: Support wdt on ROHM BD9576MUF and BD9573MUF
  MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers
  regulator: bd9576: Support error reporting

 .../bindings/mfd/rohm,bd9576-pmic.yaml        | 123 ++++
 MAINTAINERS                                   |   4 +
 drivers/mfd/Kconfig                           |  11 +
 drivers/mfd/Makefile                          |   1 +
 drivers/mfd/rohm-bd9576.c                     | 186 ++++++
 drivers/regulator/bd9576-regulator.c          | 534 ++++++++++++++----
 drivers/watchdog/Kconfig                      |  13 +
 drivers/watchdog/Makefile                     |   1 +
 drivers/watchdog/bd9576_wdt.c                 | 291 ++++++++++
 include/linux/mfd/rohm-bd957x.h               | 121 ++++
 include/linux/mfd/rohm-generic.h              |   2 +
 11 files changed, 1165 insertions(+), 122 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
 create mode 100644 drivers/mfd/rohm-bd9576.c
 create mode 100644 drivers/watchdog/bd9576_wdt.c
 create mode 100644 include/linux/mfd/rohm-bd957x.h


base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837

Comments

Vaittinen, Matti Feb. 9, 2021, 2:19 p.m. UTC | #1

Hello Lee, Mark All,

On Fri, 2021-01-22 at 16:30 +0200, Matti Vaittinen wrote:
> Initial support for ROHM BD9576MUF and BD9573MUF PMICs.
> 
> These PMICs are primarily intended to be used to power the R-Car
> family
> processors. BD9576MUF includes some additional safety features the
> BD9573MUF does not have. This initial version of drivers provides
> temperature, over voltage and under voltage warnings is IRQ
> information
> is passed via DT.
> 
> This patch series includes MFD and watchdog drivers. Regulator part
> was
> already applied but this series brings the over-/undervoltage and
> temperature error notifications which consumer drivers can utilize.

I had some discussion with Mark and Angelo about creating a helper for
handling this kind of regulator notification IRQs.
(For anyone interested: the discussion can be seen here:
https://lore.kernel.org/lkml/[e-mail]/
)

I've now drafted RFCv1 for that support (not sent it yet). The RFC
converts the BD9576 regulator driver to use the new helper and adds
some new definitions to MFD headers.

What would be the most convenient way of handling this? Should I merge
this series in the RFC and make it just one big series? Or should I
keep these as two separated series? If I keep these as separate series,
should I then omit all the MFD patches from RFC series - and add
potential MFD changes (like OVD/UVD configuration registers) in this
series (which makes bd9576 regulators not compiling) - or should the
MFD parts be included in both series - in which case we need to somehow
stay on track what parts of MFD is reviewed.

Simplest for me would be if we could get the oldest patches 1,2,4 and 5
from this series in-tree (only MFD is not acked) - but I guess it won't
happen at this point of the development cycle - and bring in the IRQ
(patch 3) and regulator notifications (patch 6) using the RFC series.

How do you see it? Should I meld this in the RFC or keep two separate
series - in which case, how should I handle the MFD changes brought by
the RFC series?

Best Regards
	Matti Vaittinen