| Message ID | 20180802103425.3053-1-o.rempel@pengutronix.de |
|---|---|
| Headers | show |
| Series | provide power off support for iMX6 with external PMIC | expand |
On Thu, Aug 02, 2018 at 12:34:22PM +0200, Oleksij Rempel wrote: > Export pm_power_off_prepare. It is needed to implement power off on > Freescale/NXP iMX6 based boards with external power management > integrated circuit (PMIC). I thought we'd got an ack for this from Raphael on a previous version or am I mistaken?
On 02.08.2018 12:44, Mark Brown wrote: > On Thu, Aug 02, 2018 at 12:34:22PM +0200, Oleksij Rempel wrote: >> Export pm_power_off_prepare. It is needed to implement power off on >> Freescale/NXP iMX6 based boards with external power management >> integrated circuit (PMIC). > > I thought we'd got an ack for this from Raphael on a previous version or > am I mistaken? > No, we got an: "Anyway, I have no particular problems with exporting pm_power_off_prepare via EXPORT_SYMBOL_GPL()." Should i see it as ACK?
On Thu, Aug 02, 2018 at 12:47:27PM +0200, Oleksij Rempel wrote: > On 02.08.2018 12:44, Mark Brown wrote: > > I thought we'd got an ack for this from Raphael on a previous version or > > am I mistaken? > No, we got an: > "Anyway, I have no particular problems with exporting > pm_power_off_prepare via EXPORT_SYMBOL_GPL()." > Should i see it as ACK? It's probably good enough.
On Thu, Aug 02, 2018 at 12:35:52PM +0100, Mark Brown wrote: > On Thu, Aug 02, 2018 at 12:47:27PM +0200, Oleksij Rempel wrote: > > On 02.08.2018 12:44, Mark Brown wrote: > > > > I thought we'd got an ack for this from Raphael on a previous version or > > > am I mistaken? > > > No, we got an: > > "Anyway, I have no particular problems with exporting > > pm_power_off_prepare via EXPORT_SYMBOL_GPL()." > > > Should i see it as ACK? Mark, Can you ACK on those two regulator patches, so that I can queue this series up on IMX tree? Shawn
On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > Can you ACK on those two regulator patches, so that I can queue this > series up on IMX tree? I was expecting to get a pull request with the precursor patches in it - the regulator driver seems to get a moderate amount of development so there's a reasonable risk of conflicts.
Hi Mark, On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > > > Can you ACK on those two regulator patches, so that I can queue this > > series up on IMX tree? > > I was expecting to get a pull request with the precursor patches in it - > the regulator driver seems to get a moderate amount of development so > there's a reasonable risk of conflicts. Are there any thing I can or should do?
On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > > > Can you ACK on those two regulator patches, so that I can queue this > > series up on IMX tree? > > I was expecting to get a pull request with the precursor patches in it - > the regulator driver seems to get a moderate amount of development so > there's a reasonable risk of conflicts. What about you create a stable topic branch for regulator patches and I pull it into IMX tree? Shawn
On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote: > On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > > I was expecting to get a pull request with the precursor patches in it - > > the regulator driver seems to get a moderate amount of development so > > there's a reasonable risk of conflicts. > What about you create a stable topic branch for regulator patches and I > pull it into IMX tree? Sure, I can send a pull request back but the first two patches in the series are ARM ones - are you OK with me just applying them and sending them in the pull request or do you want to apply them first?
On Mon, Sep 10, 2018 at 04:19:26PM +0100, Mark Brown wrote: > On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote: > > On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > > > > I was expecting to get a pull request with the precursor patches in it - > > > the regulator driver seems to get a moderate amount of development so > > > there's a reasonable risk of conflicts. > > > What about you create a stable topic branch for regulator patches and I > > pull it into IMX tree? > > Sure, I can send a pull request back but the first two patches in the > series are ARM ones - are you OK with me just applying them and sending > them in the pull request or do you want to apply them first? I just took another look at the series. It seems that there is no build-time dependency between regulator and platform patches. So I think we can handle the series like: - You apply patch #3, #4 and #5 on regulator tree; - I apply the reset on IMX tree. There shouldn't be any build or run time regression on either tree, and the feature that the series adds will be available when both trees get merged together on -next or Linus tree. @Oleksij Is my understanding above correct? Shawn
Hi Shawn, On 11.09.2018 03:53, Shawn Guo wrote: > On Mon, Sep 10, 2018 at 04:19:26PM +0100, Mark Brown wrote: >> On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote: >>> On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: >> >>>> I was expecting to get a pull request with the precursor patches in it - >>>> the regulator driver seems to get a moderate amount of development so >>>> there's a reasonable risk of conflicts. >> >>> What about you create a stable topic branch for regulator patches and I >>> pull it into IMX tree? >> >> Sure, I can send a pull request back but the first two patches in the >> series are ARM ones - are you OK with me just applying them and sending >> them in the pull request or do you want to apply them first? > > I just took another look at the series. It seems that there is no > build-time dependency between regulator and platform patches. So I > think we can handle the series like: > > - You apply patch #3, #4 and #5 on regulator tree; > - I apply the reset on IMX tree. > > There shouldn't be any build or run time regression on either tree, and > the feature that the series adds will be available when both trees get > merged together on -next or Linus tree. > > @Oleksij Is my understanding above correct? Yes.
On Tue, Sep 11, 2018 at 09:53:21AM +0800, Shawn Guo wrote: > There shouldn't be any build or run time regression on either tree, and > the feature that the series adds will be available when both trees get > merged together on -next or Linus tree. The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/pfuze100-poweroff for you to fetch changes up to c29daffa322ad36978cbce487f8ebcd9c3c3f7c0: regulator: pfuze100-regulator: provide pm_power_off_prepare handler (2018-09-11 16:15:57 +0100) ---------------------------------------------------------------- regulator: pfuze100: Power off support The pfuze100 has some innovative and creative power off support which requires some cross tree work to handle; this tag is the regualtor bits of that work. ---------------------------------------------------------------- Oleksij Rempel (3): kernel/reboot.c: export pm_power_off_prepare regulator: pfuze100: add fsl,pmic-stby-poweroff property regulator: pfuze100-regulator: provide pm_power_off_prepare handler .../devicetree/bindings/regulator/pfuze100.txt | 5 ++ drivers/regulator/pfuze100-regulator.c | 91 ++++++++++++++++++++++ kernel/reboot.c | 1 + 3 files changed, 97 insertions(+)
On Thu, Aug 02, 2018 at 12:34:21PM +0200, Oleksij Rempel wrote: > One of the Freescale recommended sequences for power off with external > PMIC is the following: > ... > 3. SoC is programming PMIC for power off when standby is asserted. > 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies. > > See: > http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf > page 5083 > > This patch implements step 4. of this sequence. > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Applied, thanks.
On Thu, Aug 02, 2018 at 12:34:25PM +0200, Oleksij Rempel wrote: > This board, as well as some other boards with i.MX6 and a PMIC, uses a > "PMIC_STBY_REQ" line to notify the PMIC about a state change. > The PMIC is programmed for a specific state change before triggering the > line. > In this case, PMIC_STBY_REQ can be used for stand by, sleep > and power off modes. > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Applied, thanks.
2018.08.02 v9: - remove include <linux/kallsyms.h> - rebase against current regulator/for-next branch and test it. - as result of previous discussions: - there is no need to remove "syscon-poweroff" node, it is by default disabled. - supported PFUZE version is tested by pfuze_power_off_prepare_init() - advantages or disadvantages of using this power off method should be described in NXP SoC or PMIC documentation, not in change log or devicetree. 2018.07.26: v8 is a rebase against kernel v4.18-rc6. No other changes are made. Added: linux-imx@nxp.com and yibin.gong@nxp.com to the CC. 2018.05.17: update patches to version v7 This patch series is providing power off support for Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). As a first step the PMIC is configured to turn off the system if the standby pin is asserted. On second step we assert the standby pin. For this reason we need to use pm_power_off_prepare. Usage of stnadby pin for power off is described in official iMX6 documentation. 2018.03.05: As this patch set touches multiple subsystems I think it would make sense for Shawn Guo to take the all patch set. The only part which didn't receive an ACK is regulator stuff. So I would hope that Mark Brown can ACK it. Kind regards, Oleksij Rempel 2017.12.06: Adding Linus. Probably there is no maintainer for this patch set. No changes are made, tested on v4.15-rc1. 2017.10.27: Last version of this patch set was send at 20 Jun 2017, this is a rebase against kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments, please point me. changes: v7: - use EXPORT_SYMBOL_GPL(pm_power_off_prepare) instead of EXPORT_SYMBOL - call imx6q_suspend_finish() directly without cpu_suspend() v6: - rename imx6_pm_poweroff to imx6_pm_stby_poweroff - fix "MPIC_STBY_REQ" typo in the comment. v5: - remove useless includes from pm-imx6.c patch - add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property" patch v4: - update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..." patch - add Acked-by to "ARM: imx6q: provide documentation for new ..." patch v3: - set pm_power_off_prepare = NULL on .remove. - documentation and spelling fixes. - use %pf instead of lookup_symbol_name. Oleksij Rempel (6): ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set kernel/reboot.c: export pm_power_off_prepare regulator: pfuze100: add fsl,pmic-stby-poweroff property regulator: pfuze100-regulator: provide pm_power_off_prepare handler ARM: dts: imx6: RIoTboard provide standby on power off option .../devicetree/bindings/clock/imx6q-clock.txt | 8 ++ .../bindings/regulator/pfuze100.txt | 5 + arch/arm/boot/dts/imx6dl-riotboard.dts | 5 + arch/arm/mach-imx/pm-imx6.c | 25 +++++ drivers/regulator/pfuze100-regulator.c | 91 +++++++++++++++++++ kernel/reboot.c | 1 + 6 files changed, 135 insertions(+)