| Message ID | 20180528090003.GA8778@localhost.localdomain |
|---|---|
| Headers | show |
| Series | mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver | expand |
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?
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.
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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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