[PATCH v6 0/9] AXP803 PMIC support for Pine64

[PATCH v6 0/9] AXP803 PMIC support for Pine64

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).

This patchset adds support for it and enabled it in Pine64 device tree.

Some parts of this patchset is already applied, including basical AXP803
MFD code and A64 RSB device node.

Thus this patchset is now still two parts, but a bit different to older
revisions:

- Part1: from PATCH 1/9 to PATCH 4/9, which focus on enabling AXP803 in the
  device tree: the R_INTC interrupt controller (for the NMI line, which is
  connected to AXP803 on Pine64), and finally the basical AXP803 node.
- Part2: from PATCH 5/9 to PATCH 9/9, which are enabling the regulator
  function of the AXP803 PMIC. Finally Wi-Fi function is added
  as a usage of regulators function.

PATCH 1 adds device tree binding of A64 R_INTC.

PATCH 2 really adds support for A64 R_INTC in NMI driver.

PATCH 3 adds R_INTC node in A64 device tree.

PATCH 4 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.

PATCH 5 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)

PATCH 6 enables the AXP803 regulator cell in MFD driver.

PATCH 7 adds a DTSI file for AXP803, like other older AXP PMICs.

PATCH 8 enables AXP803 regulators in Pine64 device tree.

PATCH 9 enables Wi-Fi for Pine64.

Icenowy Zheng (9):
  irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
  irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
  arm64: allwinner: a64: add NMI (R_INTC) controller on A64
  arm64: allwinner: a64: add AXP803 node to Pine64 device tree
  regulator: axp20x-regulator: add support for AXP803
  mfd: axp20x: add axp20x-regulator cell for AXP803
  arm64: allwinner: a64: add DTSI file for AXP803 PMIC
  arm64: allwinner: a64: enable AXP803 regulators for Pine64
  arm64: allwinner: a64: enable Wi-Fi for Pine64

 .../interrupt-controller/allwinner,sunxi-nmi.txt   |   7 +-
 arch/arm64/boot/dts/allwinner/axp803.dtsi          | 150 ++++++++++++++++++++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |   8 ++
 drivers/irqchip/irq-sunxi-nmi.c                    |  13 ++
 drivers/mfd/axp20x.c                               |   3 +-
 drivers/regulator/axp20x-regulator.c               | 153 ++++++++++++++++++---
 include/linux/mfd/axp20x.h                         |  37 +++++
 8 files changed, 482 insertions(+), 25 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

-- 
2.12.2

[PATCH v6 0/9] AXP803 PMIC support for Pine64

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).

This patchset adds support for it and enabled it in Pine64 device tree.

Some parts of this patchset is already applied, including basical AXP803
MFD code and A64 RSB device node.

Thus this patchset is now still two parts, but a bit different to older
revisions:

- Part1: from PATCH 1/9 to PATCH 4/9, which focus on enabling AXP803 in the
  device tree: the R_INTC interrupt controller (for the NMI line, which is
  connected to AXP803 on Pine64), and finally the basical AXP803 node.
- Part2: from PATCH 5/9 to PATCH 9/9, which are enabling the regulator
  function of the AXP803 PMIC. Finally Wi-Fi function is added
  as a usage of regulators function.

PATCH 1 adds device tree binding of A64 R_INTC.

PATCH 2 really adds support for A64 R_INTC in NMI driver.

PATCH 3 adds R_INTC node in A64 device tree.

PATCH 4 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.

PATCH 5 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)

PATCH 6 enables the AXP803 regulator cell in MFD driver.

PATCH 7 adds a DTSI file for AXP803, like other older AXP PMICs.

PATCH 8 enables AXP803 regulators in Pine64 device tree.

PATCH 9 enables Wi-Fi for Pine64.

Icenowy Zheng (9):
  irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
  irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
  arm64: allwinner: a64: add NMI (R_INTC) controller on A64
  arm64: allwinner: a64: add AXP803 node to Pine64 device tree
  regulator: axp20x-regulator: add support for AXP803
  mfd: axp20x: add axp20x-regulator cell for AXP803
  arm64: allwinner: a64: add DTSI file for AXP803 PMIC
  arm64: allwinner: a64: enable AXP803 regulators for Pine64
  arm64: allwinner: a64: enable Wi-Fi for Pine64

 .../interrupt-controller/allwinner,sunxi-nmi.txt   |   7 +-
 arch/arm64/boot/dts/allwinner/axp803.dtsi          | 150 ++++++++++++++++++++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |   8 ++
 drivers/irqchip/irq-sunxi-nmi.c                    |  13 ++
 drivers/mfd/axp20x.c                               |   3 +-
 drivers/regulator/axp20x-regulator.c               | 153 ++++++++++++++++++---
 include/linux/mfd/axp20x.h                         |  37 +++++
 8 files changed, 482 insertions(+), 25 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

-- 
2.12.2

[PATCH v6 0/9] AXP803 PMIC support for Pine64

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).

This patchset adds support for it and enabled it in Pine64 device tree.

Some parts of this patchset is already applied, including basical AXP803
MFD code and A64 RSB device node.

Thus this patchset is now still two parts, but a bit different to older
revisions:

- Part1: from PATCH 1/9 to PATCH 4/9, which focus on enabling AXP803 in the
  device tree: the R_INTC interrupt controller (for the NMI line, which is
  connected to AXP803 on Pine64), and finally the basical AXP803 node.
- Part2: from PATCH 5/9 to PATCH 9/9, which are enabling the regulator
  function of the AXP803 PMIC. Finally Wi-Fi function is added
  as a usage of regulators function.

PATCH 1 adds device tree binding of A64 R_INTC.

PATCH 2 really adds support for A64 R_INTC in NMI driver.

PATCH 3 adds R_INTC node in A64 device tree.

PATCH 4 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.

PATCH 5 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)

PATCH 6 enables the AXP803 regulator cell in MFD driver.

PATCH 7 adds a DTSI file for AXP803, like other older AXP PMICs.

PATCH 8 enables AXP803 regulators in Pine64 device tree.

PATCH 9 enables Wi-Fi for Pine64.

Icenowy Zheng (9):
  irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
  irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
  arm64: allwinner: a64: add NMI (R_INTC) controller on A64
  arm64: allwinner: a64: add AXP803 node to Pine64 device tree
  regulator: axp20x-regulator: add support for AXP803
  mfd: axp20x: add axp20x-regulator cell for AXP803
  arm64: allwinner: a64: add DTSI file for AXP803 PMIC
  arm64: allwinner: a64: enable AXP803 regulators for Pine64
  arm64: allwinner: a64: enable Wi-Fi for Pine64

 .../interrupt-controller/allwinner,sunxi-nmi.txt   |   7 +-
 arch/arm64/boot/dts/allwinner/axp803.dtsi          | 150 ++++++++++++++++++++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |   8 ++
 drivers/irqchip/irq-sunxi-nmi.c                    |  13 ++
 drivers/mfd/axp20x.c                               |   3 +-
 drivers/regulator/axp20x-regulator.c               | 153 ++++++++++++++++++---
 include/linux/mfd/axp20x.h                         |  37 +++++
 8 files changed, 482 insertions(+), 25 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

-- 
2.12.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Icenowy Zheng]

The A31 NMI driver seems to be using wrong base address.

As we're going to convert to use a correct NMI base address (and
correctly name it to R_INTC as the datasheet suggests), add a new
compatible string for the "correct" R_INTC, which we will use for A64
SoC.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v6:
- Added Rob's ACK.

 .../bindings/interrupt-controller/allwinner,sunxi-nmi.txt          | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
index 81cd3692405e..fea0c6a6211f 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
@@ -3,8 +3,11 @@ Allwinner Sunxi NMI Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
-  "allwinner,sun6i-a31-sc-nmi" or "allwinner,sun9i-a80-nmi"
+- compatible : should be one of:
+	"allwinner,sun6i-a31-sc-nmi"
+	"allwinner,sun7i-a20-sc-nmi"
+	"allwinner,sun9i-a80-nmi"
+	"allwinner,sun50i-a64-r-intc"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
-- 
2.12.2

[PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Icenowy Zheng]

The A31 NMI driver seems to be using wrong base address.

As we're going to convert to use a correct NMI base address (and
correctly name it to R_INTC as the datasheet suggests), add a new
compatible string for the "correct" R_INTC, which we will use for A64
SoC.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v6:
- Added Rob's ACK.

 .../bindings/interrupt-controller/allwinner,sunxi-nmi.txt          | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
index 81cd3692405e..fea0c6a6211f 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
@@ -3,8 +3,11 @@ Allwinner Sunxi NMI Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
-  "allwinner,sun6i-a31-sc-nmi" or "allwinner,sun9i-a80-nmi"
+- compatible : should be one of:
+	"allwinner,sun6i-a31-sc-nmi"
+	"allwinner,sun7i-a20-sc-nmi"
+	"allwinner,sun9i-a80-nmi"
+	"allwinner,sun50i-a64-r-intc"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
-- 
2.12.2

[PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Icenowy Zheng]

The A31 NMI driver seems to be using wrong base address.

As we're going to convert to use a correct NMI base address (and
correctly name it to R_INTC as the datasheet suggests), add a new
compatible string for the "correct" R_INTC, which we will use for A64
SoC.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v6:
- Added Rob's ACK.

 .../bindings/interrupt-controller/allwinner,sunxi-nmi.txt          | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
index 81cd3692405e..fea0c6a6211f 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
@@ -3,8 +3,11 @@ Allwinner Sunxi NMI Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
-  "allwinner,sun6i-a31-sc-nmi" or "allwinner,sun9i-a80-nmi"
+- compatible : should be one of:
+	"allwinner,sun6i-a31-sc-nmi"
+	"allwinner,sun7i-a20-sc-nmi"
+	"allwinner,sun9i-a80-nmi"
+	"allwinner,sun50i-a64-r-intc"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
-- 
2.12.2

Re: [linux-sunxi] [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The A31 NMI driver seems to be using wrong base address.
>
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Rob Herring <robh@kernel.org>

The subject prefix might need a bit of work, but otherwise

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

[linux-sunxi] [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The A31 NMI driver seems to be using wrong base address.
>
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Rob Herring <robh@kernel.org>

The subject prefix might need a bit of work, but otherwise

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Re: [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> The A31 NMI driver seems to be using wrong base address.
>
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

The subject prefix might need a bit of work, but otherwise

Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Re: [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Thu, May 18, 2017 at 03:16:45PM +0800, Icenowy Zheng wrote:
> The A31 NMI driver seems to be using wrong base address.
> 
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Rob Herring <robh@kernel.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Maxime Ripard]

On Thu, May 18, 2017 at 03:16:45PM +0800, Icenowy Zheng wrote:
> The A31 NMI driver seems to be using wrong base address.
> 
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Rob Herring <robh@kernel.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170518/abd1cbe1/attachment-0001.sig>

Re: [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On Thu, May 18, 2017 at 03:16:45PM +0800, Icenowy Zheng wrote:
> The A31 NMI driver seems to be using wrong base address.
> 
> As we're going to convert to use a correct NMI base address (and
> correctly name it to R_INTC as the datasheet suggests), add a new
> compatible string for the "correct" R_INTC, which we will use for A64
> SoC.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

Add support for the newly imported compatible for the A64 R_INTC in
irq-sunxi-nmi driver.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v5:
- Fix A64 R_INTC compatible.

 drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 668730c5cb66..5559c1d593bf 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
 	.enable	= 0x04,
 };
 
+static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
+	.ctrl	= 0x0c,
+	.pend	= 0x10,
+	.enable	= 0x40,
+};
+
 static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
 				      u32 val)
 {
@@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
 	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
 }
 IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
+
+static int __init sun50i_nmi_irq_init(struct device_node *node,
+				     struct device_node *parent)
+{
+	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
+}
+IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc", sun50i_nmi_irq_init);
-- 
2.12.2

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

Add support for the newly imported compatible for the A64 R_INTC in
irq-sunxi-nmi driver.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v5:
- Fix A64 R_INTC compatible.

 drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 668730c5cb66..5559c1d593bf 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
 	.enable	= 0x04,
 };
 
+static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
+	.ctrl	= 0x0c,
+	.pend	= 0x10,
+	.enable	= 0x40,
+};
+
 static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
 				      u32 val)
 {
@@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
 	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
 }
 IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
+
+static int __init sun50i_nmi_irq_init(struct device_node *node,
+				     struct device_node *parent)
+{
+	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
+}
+IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc", sun50i_nmi_irq_init);
-- 
2.12.2

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

Add support for the newly imported compatible for the A64 R_INTC in
irq-sunxi-nmi driver.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
Changes in v5:
- Fix A64 R_INTC compatible.

 drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 668730c5cb66..5559c1d593bf 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
 	.enable	= 0x04,
 };
 
+static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
+	.ctrl	= 0x0c,
+	.pend	= 0x10,
+	.enable	= 0x40,
+};
+
 static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
 				      u32 val)
 {
@@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
 	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
 }
 IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
+
+static int __init sun50i_nmi_irq_init(struct device_node *node,
+				     struct device_node *parent)
+{
+	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
+}
+IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc", sun50i_nmi_irq_init);
-- 
2.12.2

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote:
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Maxime Ripard]

On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote:
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170518/f3d84963/attachment-0001.sig>

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote:
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>

Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:52 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote:
>> Add support for the newly imported compatible for the A64 R_INTC in
>> irq-sunxi-nmi driver.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:52 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote:
>> Add support for the newly imported compatible for the A64 R_INTC in
>> irq-sunxi-nmi driver.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:52 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote:
>> Add support for the newly imported compatible for the A64 R_INTC in
>> irq-sunxi-nmi driver.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>
> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 18/05/17 08:16, Icenowy Zheng wrote:
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v5:
> - Fix A64 R_INTC compatible.
> 
>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
> index 668730c5cb66..5559c1d593bf 100644
> --- a/drivers/irqchip/irq-sunxi-nmi.c
> +++ b/drivers/irqchip/irq-sunxi-nmi.c
> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
>  	.enable	= 0x04,
>  };
>  
> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
> +	.ctrl	= 0x0c,
> +	.pend	= 0x10,
> +	.enable	= 0x40,
> +};
> +

Magic values? Even if no #define is provided, a pointer to the
corresponding documentation would be appreciated (assuming documentation
exists).

>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
>  				      u32 val)
>  {
> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
>  	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>  }
>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
> +
> +static int __init sun50i_nmi_irq_init(struct device_node *node,
> +				     struct device_node *parent)
> +{
> +	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
> +}
> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc", sun50i_nmi_irq_init);
> 

Apart from the above:

Acked-by: Marc Zyngier <marc.zyngier@arm.com>

Let me know how you want this to be merged.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 18/05/17 08:16, Icenowy Zheng wrote:
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v5:
> - Fix A64 R_INTC compatible.
> 
>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
> index 668730c5cb66..5559c1d593bf 100644
> --- a/drivers/irqchip/irq-sunxi-nmi.c
> +++ b/drivers/irqchip/irq-sunxi-nmi.c
> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
>  	.enable	= 0x04,
>  };
>  
> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
> +	.ctrl	= 0x0c,
> +	.pend	= 0x10,
> +	.enable	= 0x40,
> +};
> +

Magic values? Even if no #define is provided, a pointer to the
corresponding documentation would be appreciated (assuming documentation
exists).

>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
>  				      u32 val)
>  {
> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
>  	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>  }
>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
> +
> +static int __init sun50i_nmi_irq_init(struct device_node *node,
> +				     struct device_node *parent)
> +{
> +	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
> +}
> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc", sun50i_nmi_irq_init);
> 

Apart from the above:

Acked-by: Marc Zyngier <marc.zyngier@arm.com>

Let me know how you want this to be merged.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 18/05/17 08:16, Icenowy Zheng wrote:
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v5:
> - Fix A64 R_INTC compatible.
> 
>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
> index 668730c5cb66..5559c1d593bf 100644
> --- a/drivers/irqchip/irq-sunxi-nmi.c
> +++ b/drivers/irqchip/irq-sunxi-nmi.c
> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
>  	.enable	= 0x04,
>  };
>  
> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
> +	.ctrl	= 0x0c,
> +	.pend	= 0x10,
> +	.enable	= 0x40,
> +};
> +

Magic values? Even if no #define is provided, a pointer to the
corresponding documentation would be appreciated (assuming documentation
exists).

>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
>  				      u32 val)
>  {
> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
>  	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>  }
>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
> +
> +static int __init sun50i_nmi_irq_init(struct device_node *node,
> +				     struct device_node *parent)
> +{
> +	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
> +}
> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc", sun50i_nmi_irq_init);
> 

Apart from the above:

Acked-by: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>

Let me know how you want this to be merged.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier@arm.com> 写到:
>On 18/05/17 08:16, Icenowy Zheng wrote:
>> Add support for the newly imported compatible for the A64 R_INTC in
>> irq-sunxi-nmi driver.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v5:
>> - Fix A64 R_INTC compatible.
>> 
>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>b/drivers/irqchip/irq-sunxi-nmi.c
>> index 668730c5cb66..5559c1d593bf 100644
>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>= {
>>  	.enable	= 0x04,
>>  };
>>  
>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>> +	.ctrl	= 0x0c,
>> +	.pend	= 0x10,
>> +	.enable	= 0x40,
>> +};
>> +
>
>Magic values? Even if no #define is provided, a pointer to the
>corresponding documentation would be appreciated (assuming
>documentation
>exists).

No documents is available for A64 R_INTC.

>
>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>u32 off,
>>  				      u32 val)
>>  {
>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>device_node *node,
>>  	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>  }
>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>sun9i_nmi_irq_init);
>> +
>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>> +				     struct device_node *parent)
>> +{
>> +	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>> +}
>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>sun50i_nmi_irq_init);
>> 
>
>Apart from the above:
>
>Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
>Let me know how you want this to be merged.

I think it can just go via IRQ subsystem.

>
>Thanks,
>
>	M.

[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

? 2017?5?22? GMT+08:00 ??5:39:22, Marc Zyngier <marc.zyngier@arm.com> ??:
>On 18/05/17 08:16, Icenowy Zheng wrote:
>> Add support for the newly imported compatible for the A64 R_INTC in
>> irq-sunxi-nmi driver.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v5:
>> - Fix A64 R_INTC compatible.
>> 
>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>b/drivers/irqchip/irq-sunxi-nmi.c
>> index 668730c5cb66..5559c1d593bf 100644
>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>= {
>>  	.enable	= 0x04,
>>  };
>>  
>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>> +	.ctrl	= 0x0c,
>> +	.pend	= 0x10,
>> +	.enable	= 0x40,
>> +};
>> +
>
>Magic values? Even if no #define is provided, a pointer to the
>corresponding documentation would be appreciated (assuming
>documentation
>exists).

No documents is available for A64 R_INTC.

>
>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>u32 off,
>>  				      u32 val)
>>  {
>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>device_node *node,
>>  	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>  }
>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>sun9i_nmi_irq_init);
>> +
>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>> +				     struct device_node *parent)
>> +{
>> +	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>> +}
>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>sun50i_nmi_irq_init);
>> 
>
>Apart from the above:
>
>Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
>Let me know how you want this to be merged.

I think it can just go via IRQ subsystem.

>
>Thanks,
>
>	M.

Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>On 18/05/17 08:16, Icenowy Zheng wrote:
>> Add support for the newly imported compatible for the A64 R_INTC in
>> irq-sunxi-nmi driver.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> Changes in v5:
>> - Fix A64 R_INTC compatible.
>> 
>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>b/drivers/irqchip/irq-sunxi-nmi.c
>> index 668730c5cb66..5559c1d593bf 100644
>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>= {
>>  	.enable	= 0x04,
>>  };
>>  
>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>> +	.ctrl	= 0x0c,
>> +	.pend	= 0x10,
>> +	.enable	= 0x40,
>> +};
>> +
>
>Magic values? Even if no #define is provided, a pointer to the
>corresponding documentation would be appreciated (assuming
>documentation
>exists).

No documents is available for A64 R_INTC.

>
>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>u32 off,
>>  				      u32 val)
>>  {
>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>device_node *node,
>>  	return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>  }
>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>sun9i_nmi_irq_init);
>> +
>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>> +				     struct device_node *parent)
>> +{
>> +	return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>> +}
>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>sun50i_nmi_irq_init);
>> 
>
>Apart from the above:
>
>Acked-by: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
>
>Let me know how you want this to be merged.

I think it can just go via IRQ subsystem.

>
>Thanks,
>
>	M.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier@arm.com> 写到:
>>On 18/05/17 08:16, Icenowy Zheng wrote:
>>> Add support for the newly imported compatible for the A64 R_INTC in
>>> irq-sunxi-nmi driver.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> Changes in v5:
>>> - Fix A64 R_INTC compatible.
>>>
>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>  1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>b/drivers/irqchip/irq-sunxi-nmi.c
>>> index 668730c5cb66..5559c1d593bf 100644
>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>= {
>>>      .enable = 0x04,
>>>  };
>>>
>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>> +    .ctrl   = 0x0c,
>>> +    .pend   = 0x10,
>>> +    .enable = 0x40,
>>> +};
>>> +
>>
>>Magic values? Even if no #define is provided, a pointer to the
>>corresponding documentation would be appreciated (assuming
>>documentation
>>exists).
>
> No documents is available for A64 R_INTC.

No code either. In Allwinner's BSP, the interrupts for the PMICs go
through the (closed source) OpenRISC firmware, so there's no driver
for it in the kernel.

The registers line up with the old interrupt controller from the A10,
but it seems only the NMI interrupt is wired up.

ChenYu

>>
>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>u32 off,
>>>                                    u32 val)
>>>  {
>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>device_node *node,
>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>  }
>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>sun9i_nmi_irq_init);
>>> +
>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>> +                                 struct device_node *parent)
>>> +{
>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>> +}
>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>sun50i_nmi_irq_init);
>>>
>>
>>Apart from the above:
>>
>>Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>>Let me know how you want this to be merged.
>
> I think it can just go via IRQ subsystem.
>
>>
>>Thanks,
>>
>>       M.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> ? 2017?5?22? GMT+08:00 ??5:39:22, Marc Zyngier <marc.zyngier@arm.com> ??:
>>On 18/05/17 08:16, Icenowy Zheng wrote:
>>> Add support for the newly imported compatible for the A64 R_INTC in
>>> irq-sunxi-nmi driver.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> Changes in v5:
>>> - Fix A64 R_INTC compatible.
>>>
>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>  1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>b/drivers/irqchip/irq-sunxi-nmi.c
>>> index 668730c5cb66..5559c1d593bf 100644
>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>= {
>>>      .enable = 0x04,
>>>  };
>>>
>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>> +    .ctrl   = 0x0c,
>>> +    .pend   = 0x10,
>>> +    .enable = 0x40,
>>> +};
>>> +
>>
>>Magic values? Even if no #define is provided, a pointer to the
>>corresponding documentation would be appreciated (assuming
>>documentation
>>exists).
>
> No documents is available for A64 R_INTC.

No code either. In Allwinner's BSP, the interrupts for the PMICs go
through the (closed source) OpenRISC firmware, so there's no driver
for it in the kernel.

The registers line up with the old interrupt controller from the A10,
but it seems only the NMI interrupt is wired up.

ChenYu

>>
>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>u32 off,
>>>                                    u32 val)
>>>  {
>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>device_node *node,
>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>  }
>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>sun9i_nmi_irq_init);
>>> +
>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>> +                                 struct device_node *parent)
>>> +{
>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>> +}
>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>sun50i_nmi_irq_init);
>>>
>>
>>Apart from the above:
>>
>>Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>>Let me know how you want this to be merged.
>
> I think it can just go via IRQ subsystem.
>
>>
>>Thanks,
>>
>>       M.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>>On 18/05/17 08:16, Icenowy Zheng wrote:
>>> Add support for the newly imported compatible for the A64 R_INTC in
>>> irq-sunxi-nmi driver.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>> Changes in v5:
>>> - Fix A64 R_INTC compatible.
>>>
>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>  1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>b/drivers/irqchip/irq-sunxi-nmi.c
>>> index 668730c5cb66..5559c1d593bf 100644
>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>= {
>>>      .enable = 0x04,
>>>  };
>>>
>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>> +    .ctrl   = 0x0c,
>>> +    .pend   = 0x10,
>>> +    .enable = 0x40,
>>> +};
>>> +
>>
>>Magic values? Even if no #define is provided, a pointer to the
>>corresponding documentation would be appreciated (assuming
>>documentation
>>exists).
>
> No documents is available for A64 R_INTC.

No code either. In Allwinner's BSP, the interrupts for the PMICs go
through the (closed source) OpenRISC firmware, so there's no driver
for it in the kernel.

The registers line up with the old interrupt controller from the A10,
but it seems only the NMI interrupt is wired up.

ChenYu

>>
>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>u32 off,
>>>                                    u32 val)
>>>  {
>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>device_node *node,
>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>  }
>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>sun9i_nmi_irq_init);
>>> +
>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>> +                                 struct device_node *parent)
>>> +{
>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>> +}
>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>sun50i_nmi_irq_init);
>>>
>>
>>Apart from the above:
>>
>>Acked-by: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
>>
>>Let me know how you want this to be merged.
>
> I think it can just go via IRQ subsystem.
>
>>
>>Thanks,
>>
>>       M.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

Hi Marc,

On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>
>>
>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier@arm.com> 写到:
>>>On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support for the newly imported compatible for the A64 R_INTC in
>>>> irq-sunxi-nmi driver.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> Changes in v5:
>>>> - Fix A64 R_INTC compatible.
>>>>
>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>  1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>b/drivers/irqchip/irq-sunxi-nmi.c
>>>> index 668730c5cb66..5559c1d593bf 100644
>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>>= {
>>>>      .enable = 0x04,
>>>>  };
>>>>
>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>> +    .ctrl   = 0x0c,
>>>> +    .pend   = 0x10,
>>>> +    .enable = 0x40,
>>>> +};
>>>> +
>>>
>>>Magic values? Even if no #define is provided, a pointer to the
>>>corresponding documentation would be appreciated (assuming
>>>documentation
>>>exists).
>>
>> No documents is available for A64 R_INTC.
>
> No code either. In Allwinner's BSP, the interrupts for the PMICs go
> through the (closed source) OpenRISC firmware, so there's no driver
> for it in the kernel.
>
> The registers line up with the old interrupt controller from the A10,
> but it seems only the NMI interrupt is wired up.

Is this OK? Or do you want Icenowy to respin a version with defines?

>>>
>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>>u32 off,
>>>>                                    u32 val)
>>>>  {
>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>device_node *node,
>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>  }
>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>sun9i_nmi_irq_init);
>>>> +
>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>> +                                 struct device_node *parent)
>>>> +{
>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>> +}
>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>sun50i_nmi_irq_init);
>>>>
>>>
>>>Apart from the above:
>>>
>>>Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>>Let me know how you want this to be merged.

This, and the previous dt bindings patch, can be merged through whatever
tree irqchip drivers are merged through. Is that Jason's irqchip tree?

We're mostly waiting on this before merging the remaining device tree
changes.


Thanks
ChenYu

>>
>> I think it can just go via IRQ subsystem.
>>
>>>
>>>Thanks,
>>>
>>>       M.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

Hi Marc,

On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>
>>
>> ? 2017?5?22? GMT+08:00 ??5:39:22, Marc Zyngier <marc.zyngier@arm.com> ??:
>>>On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support for the newly imported compatible for the A64 R_INTC in
>>>> irq-sunxi-nmi driver.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> Changes in v5:
>>>> - Fix A64 R_INTC compatible.
>>>>
>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>  1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>b/drivers/irqchip/irq-sunxi-nmi.c
>>>> index 668730c5cb66..5559c1d593bf 100644
>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>>= {
>>>>      .enable = 0x04,
>>>>  };
>>>>
>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>> +    .ctrl   = 0x0c,
>>>> +    .pend   = 0x10,
>>>> +    .enable = 0x40,
>>>> +};
>>>> +
>>>
>>>Magic values? Even if no #define is provided, a pointer to the
>>>corresponding documentation would be appreciated (assuming
>>>documentation
>>>exists).
>>
>> No documents is available for A64 R_INTC.
>
> No code either. In Allwinner's BSP, the interrupts for the PMICs go
> through the (closed source) OpenRISC firmware, so there's no driver
> for it in the kernel.
>
> The registers line up with the old interrupt controller from the A10,
> but it seems only the NMI interrupt is wired up.

Is this OK? Or do you want Icenowy to respin a version with defines?

>>>
>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>>u32 off,
>>>>                                    u32 val)
>>>>  {
>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>device_node *node,
>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>  }
>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>sun9i_nmi_irq_init);
>>>> +
>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>> +                                 struct device_node *parent)
>>>> +{
>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>> +}
>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>sun50i_nmi_irq_init);
>>>>
>>>
>>>Apart from the above:
>>>
>>>Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>>Let me know how you want this to be merged.

This, and the previous dt bindings patch, can be merged through whatever
tree irqchip drivers are merged through. Is that Jason's irqchip tree?

We're mostly waiting on this before merging the remaining device tree
changes.


Thanks
ChenYu

>>
>> I think it can just go via IRQ subsystem.
>>
>>>
>>>Thanks,
>>>
>>>       M.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Chen-Yu Tsai]

Hi Marc,

On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>>
>>
>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>>>On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support for the newly imported compatible for the A64 R_INTC in
>>>> irq-sunxi-nmi driver.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>> ---
>>>> Changes in v5:
>>>> - Fix A64 R_INTC compatible.
>>>>
>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>  1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>b/drivers/irqchip/irq-sunxi-nmi.c
>>>> index 668730c5cb66..5559c1d593bf 100644
>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>>= {
>>>>      .enable = 0x04,
>>>>  };
>>>>
>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>> +    .ctrl   = 0x0c,
>>>> +    .pend   = 0x10,
>>>> +    .enable = 0x40,
>>>> +};
>>>> +
>>>
>>>Magic values? Even if no #define is provided, a pointer to the
>>>corresponding documentation would be appreciated (assuming
>>>documentation
>>>exists).
>>
>> No documents is available for A64 R_INTC.
>
> No code either. In Allwinner's BSP, the interrupts for the PMICs go
> through the (closed source) OpenRISC firmware, so there's no driver
> for it in the kernel.
>
> The registers line up with the old interrupt controller from the A10,
> but it seems only the NMI interrupt is wired up.

Is this OK? Or do you want Icenowy to respin a version with defines?

>>>
>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>>u32 off,
>>>>                                    u32 val)
>>>>  {
>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>device_node *node,
>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>  }
>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>sun9i_nmi_irq_init);
>>>> +
>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>> +                                 struct device_node *parent)
>>>> +{
>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>> +}
>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>sun50i_nmi_irq_init);
>>>>
>>>
>>>Apart from the above:
>>>
>>>Acked-by: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
>>>
>>>Let me know how you want this to be merged.

This, and the previous dt bindings patch, can be merged through whatever
tree irqchip drivers are merged through. Is that Jason's irqchip tree?

We're mostly waiting on this before merging the remaining device tree
changes.


Thanks
ChenYu

>>
>> I think it can just go via IRQ subsystem.
>>
>>>
>>>Thanks,
>>>
>>>       M.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 05/06/17 06:57, Chen-Yu Tsai wrote:
> Hi Marc,
> 
> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>>
>>>
>>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier <marc.zyngier@arm.com> 写到:
>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>> Add support for the newly imported compatible for the A64 R_INTC in
>>>>> irq-sunxi-nmi driver.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>> ---
>>>>> Changes in v5:
>>>>> - Fix A64 R_INTC compatible.
>>>>>
>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>  1 file changed, 13 insertions(+)
>>>>>
>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>>> = {
>>>>>      .enable = 0x04,
>>>>>  };
>>>>>
>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>> +    .ctrl   = 0x0c,
>>>>> +    .pend   = 0x10,
>>>>> +    .enable = 0x40,
>>>>> +};
>>>>> +
>>>>
>>>> Magic values? Even if no #define is provided, a pointer to the
>>>> corresponding documentation would be appreciated (assuming
>>>> documentation
>>>> exists).
>>>
>>> No documents is available for A64 R_INTC.
>>
>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>> through the (closed source) OpenRISC firmware, so there's no driver
>> for it in the kernel.
>>
>> The registers line up with the old interrupt controller from the A10,
>> but it seems only the NMI interrupt is wired up.
> 
> Is this OK? Or do you want Icenowy to respin a version with defines?

Ideally, I'd like to see some #defines, but given that the rest of the
file is already littered with hard-coded constants, you might as well do
the whole thing in a subsequent patch that I would merge with these two
patches.

>>>>
>>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>>> u32 off,
>>>>>                                    u32 val)
>>>>>  {
>>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>> device_node *node,
>>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>>  }
>>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>> sun9i_nmi_irq_init);
>>>>> +
>>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>>> +                                 struct device_node *parent)
>>>>> +{
>>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>>> +}
>>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>> sun50i_nmi_irq_init);
>>>>>
>>>>
>>>> Apart from the above:
>>>>
>>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> Let me know how you want this to be merged.
> 
> This, and the previous dt bindings patch, can be merged through whatever
> tree irqchip drivers are merged through. Is that Jason's irqchip tree?

I'll probably start pushing a branch with all the irqchip patches I've
collected at some point this week, for Thomas to take into 4.13.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 05/06/17 06:57, Chen-Yu Tsai wrote:
> Hi Marc,
> 
> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>>
>>>
>>> ? 2017?5?22? GMT+08:00 ??5:39:22, Marc Zyngier <marc.zyngier@arm.com> ??:
>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>> Add support for the newly imported compatible for the A64 R_INTC in
>>>>> irq-sunxi-nmi driver.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>> ---
>>>>> Changes in v5:
>>>>> - Fix A64 R_INTC compatible.
>>>>>
>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>  1 file changed, 13 insertions(+)
>>>>>
>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs
>>>> = {
>>>>>      .enable = 0x04,
>>>>>  };
>>>>>
>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>> +    .ctrl   = 0x0c,
>>>>> +    .pend   = 0x10,
>>>>> +    .enable = 0x40,
>>>>> +};
>>>>> +
>>>>
>>>> Magic values? Even if no #define is provided, a pointer to the
>>>> corresponding documentation would be appreciated (assuming
>>>> documentation
>>>> exists).
>>>
>>> No documents is available for A64 R_INTC.
>>
>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>> through the (closed source) OpenRISC firmware, so there's no driver
>> for it in the kernel.
>>
>> The registers line up with the old interrupt controller from the A10,
>> but it seems only the NMI interrupt is wired up.
> 
> Is this OK? Or do you want Icenowy to respin a version with defines?

Ideally, I'd like to see some #defines, but given that the rest of the
file is already littered with hard-coded constants, you might as well do
the whole thing in a subsequent patch that I would merge with these two
patches.

>>>>
>>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc,
>>>> u32 off,
>>>>>                                    u32 val)
>>>>>  {
>>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>> device_node *node,
>>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>>  }
>>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>> sun9i_nmi_irq_init);
>>>>> +
>>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>>> +                                 struct device_node *parent)
>>>>> +{
>>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>>> +}
>>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>> sun50i_nmi_irq_init);
>>>>>
>>>>
>>>> Apart from the above:
>>>>
>>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> Let me know how you want this to be merged.
> 
> This, and the previous dt bindings patch, can be merged through whatever
> tree irqchip drivers are merged through. Is that Jason's irqchip tree?

I'll probably start pushing a branch with all the irqchip patches I've
collected at some point this week, for Thomas to take into 4.13.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

于 2017年6月5日 GMT+08:00 下午3:53:50, Marc Zyngier <marc.zyngier@arm.com> 写到:
>On 05/06/17 06:57, Chen-Yu Tsai wrote:
>> Hi Marc,
>> 
>> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>>
>>>>
>>>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier
><marc.zyngier@arm.com> 写到:
>>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>>> Add support for the newly imported compatible for the A64 R_INTC
>in
>>>>>> irq-sunxi-nmi driver.
>>>>>>
>>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>>> ---
>>>>>> Changes in v5:
>>>>>> - Fix A64 R_INTC compatible.
>>>>>>
>>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>>  1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs
>sun9i_reg_offs
>>>>> = {
>>>>>>      .enable = 0x04,
>>>>>>  };
>>>>>>
>>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>>> +    .ctrl   = 0x0c,
>>>>>> +    .pend   = 0x10,
>>>>>> +    .enable = 0x40,
>>>>>> +};
>>>>>> +
>>>>>
>>>>> Magic values? Even if no #define is provided, a pointer to the
>>>>> corresponding documentation would be appreciated (assuming
>>>>> documentation
>>>>> exists).
>>>>
>>>> No documents is available for A64 R_INTC.
>>>
>>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>>> through the (closed source) OpenRISC firmware, so there's no driver
>>> for it in the kernel.
>>>
>>> The registers line up with the old interrupt controller from the
>A10,
>>> but it seems only the NMI interrupt is wired up.
>> 
>> Is this OK? Or do you want Icenowy to respin a version with defines?
>
>Ideally, I'd like to see some #defines, but given that the rest of the
>file is already littered with hard-coded constants, you might as well
>do
>the whole thing in a subsequent patch that I would merge with these two
>patches.

Personally I think the values are self-explained (the variable
name) and used only once in this structure.

Making defines doesn't make the code more clear.

>
>>>>>
>>>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic
>*gc,
>>>>> u32 off,
>>>>>>                                    u32 val)
>>>>>>  {
>>>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>>> device_node *node,
>>>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>>>  }
>>>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>>> sun9i_nmi_irq_init);
>>>>>> +
>>>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>>>> +                                 struct device_node *parent)
>>>>>> +{
>>>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>>>> +}
>>>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>>> sun50i_nmi_irq_init);
>>>>>>
>>>>>
>>>>> Apart from the above:
>>>>>
>>>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>>
>>>>> Let me know how you want this to be merged.
>> 
>> This, and the previous dt bindings patch, can be merged through
>whatever
>> tree irqchip drivers are merged through. Is that Jason's irqchip
>tree?
>
>I'll probably start pushing a branch with all the irqchip patches I've
>collected at some point this week, for Thomas to take into 4.13.
>
>Thanks,
>
>	M.
>-- 
>Jazz is not dead. It just smells funny...
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

? 2017?6?5? GMT+08:00 ??3:53:50, Marc Zyngier <marc.zyngier@arm.com> ??:
>On 05/06/17 06:57, Chen-Yu Tsai wrote:
>> Hi Marc,
>> 
>> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>>
>>>>
>>>> ? 2017?5?22? GMT+08:00 ??5:39:22, Marc Zyngier
><marc.zyngier@arm.com> ??:
>>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>>> Add support for the newly imported compatible for the A64 R_INTC
>in
>>>>>> irq-sunxi-nmi driver.
>>>>>>
>>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>>> ---
>>>>>> Changes in v5:
>>>>>> - Fix A64 R_INTC compatible.
>>>>>>
>>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>>  1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs
>sun9i_reg_offs
>>>>> = {
>>>>>>      .enable = 0x04,
>>>>>>  };
>>>>>>
>>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>>> +    .ctrl   = 0x0c,
>>>>>> +    .pend   = 0x10,
>>>>>> +    .enable = 0x40,
>>>>>> +};
>>>>>> +
>>>>>
>>>>> Magic values? Even if no #define is provided, a pointer to the
>>>>> corresponding documentation would be appreciated (assuming
>>>>> documentation
>>>>> exists).
>>>>
>>>> No documents is available for A64 R_INTC.
>>>
>>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>>> through the (closed source) OpenRISC firmware, so there's no driver
>>> for it in the kernel.
>>>
>>> The registers line up with the old interrupt controller from the
>A10,
>>> but it seems only the NMI interrupt is wired up.
>> 
>> Is this OK? Or do you want Icenowy to respin a version with defines?
>
>Ideally, I'd like to see some #defines, but given that the rest of the
>file is already littered with hard-coded constants, you might as well
>do
>the whole thing in a subsequent patch that I would merge with these two
>patches.

Personally I think the values are self-explained (the variable
name) and used only once in this structure.

Making defines doesn't make the code more clear.

>
>>>>>
>>>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic
>*gc,
>>>>> u32 off,
>>>>>>                                    u32 val)
>>>>>>  {
>>>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>>> device_node *node,
>>>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>>>  }
>>>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>>> sun9i_nmi_irq_init);
>>>>>> +
>>>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>>>> +                                 struct device_node *parent)
>>>>>> +{
>>>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>>>> +}
>>>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>>> sun50i_nmi_irq_init);
>>>>>>
>>>>>
>>>>> Apart from the above:
>>>>>
>>>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>>
>>>>> Let me know how you want this to be merged.
>> 
>> This, and the previous dt bindings patch, can be merged through
>whatever
>> tree irqchip drivers are merged through. Is that Jason's irqchip
>tree?
>
>I'll probably start pushing a branch with all the irqchip patches I've
>collected at some point this week, for Thomas to take into 4.13.
>
>Thanks,
>
>	M.
>-- 
>Jazz is not dead. It just smells funny...
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Icenowy Zheng]

于 2017年6月5日 GMT+08:00 下午3:53:50, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>On 05/06/17 06:57, Chen-Yu Tsai wrote:
>> Hi Marc,
>> 
>> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>wrote:
>>>>
>>>>
>>>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier
><marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>>> Add support for the newly imported compatible for the A64 R_INTC
>in
>>>>>> irq-sunxi-nmi driver.
>>>>>>
>>>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>>>> ---
>>>>>> Changes in v5:
>>>>>> - Fix A64 R_INTC compatible.
>>>>>>
>>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>>  1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs
>sun9i_reg_offs
>>>>> = {
>>>>>>      .enable = 0x04,
>>>>>>  };
>>>>>>
>>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>>> +    .ctrl   = 0x0c,
>>>>>> +    .pend   = 0x10,
>>>>>> +    .enable = 0x40,
>>>>>> +};
>>>>>> +
>>>>>
>>>>> Magic values? Even if no #define is provided, a pointer to the
>>>>> corresponding documentation would be appreciated (assuming
>>>>> documentation
>>>>> exists).
>>>>
>>>> No documents is available for A64 R_INTC.
>>>
>>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>>> through the (closed source) OpenRISC firmware, so there's no driver
>>> for it in the kernel.
>>>
>>> The registers line up with the old interrupt controller from the
>A10,
>>> but it seems only the NMI interrupt is wired up.
>> 
>> Is this OK? Or do you want Icenowy to respin a version with defines?
>
>Ideally, I'd like to see some #defines, but given that the rest of the
>file is already littered with hard-coded constants, you might as well
>do
>the whole thing in a subsequent patch that I would merge with these two
>patches.

Personally I think the values are self-explained (the variable
name) and used only once in this structure.

Making defines doesn't make the code more clear.

>
>>>>>
>>>>>>  static inline void sunxi_sc_nmi_write(struct irq_chip_generic
>*gc,
>>>>> u32 off,
>>>>>>                                    u32 val)
>>>>>>  {
>>>>>> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
>>>>> device_node *node,
>>>>>>      return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
>>>>>>  }
>>>>>>  IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
>>>>> sun9i_nmi_irq_init);
>>>>>> +
>>>>>> +static int __init sun50i_nmi_irq_init(struct device_node *node,
>>>>>> +                                 struct device_node *parent)
>>>>>> +{
>>>>>> +    return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
>>>>>> +}
>>>>>> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
>>>>> sun50i_nmi_irq_init);
>>>>>>
>>>>>
>>>>> Apart from the above:
>>>>>
>>>>> Acked-by: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
>>>>>
>>>>> Let me know how you want this to be merged.
>> 
>> This, and the previous dt bindings patch, can be merged through
>whatever
>> tree irqchip drivers are merged through. Is that Jason's irqchip
>tree?
>
>I'll probably start pushing a branch with all the irqchip patches I've
>collected at some point this week, for Thomas to take into 4.13.
>
>Thanks,
>
>	M.
>-- 
>Jazz is not dead. It just smells funny...
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 05/06/17 08:56, Icenowy Zheng wrote:
> 
> 
> 于 2017年6月5日 GMT+08:00 下午3:53:50, Marc Zyngier <marc.zyngier@arm.com> 写到:
>> On 05/06/17 06:57, Chen-Yu Tsai wrote:
>>> Hi Marc,
>>>
>>> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io>
>> wrote:
>>>>>
>>>>>
>>>>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier
>> <marc.zyngier@arm.com> 写到:
>>>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>>>> Add support for the newly imported compatible for the A64 R_INTC
>> in
>>>>>>> irq-sunxi-nmi driver.
>>>>>>>
>>>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>>>> ---
>>>>>>> Changes in v5:
>>>>>>> - Fix A64 R_INTC compatible.
>>>>>>>
>>>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>>>  1 file changed, 13 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs
>> sun9i_reg_offs
>>>>>> = {
>>>>>>>      .enable = 0x04,
>>>>>>>  };
>>>>>>>
>>>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>>>> +    .ctrl   = 0x0c,
>>>>>>> +    .pend   = 0x10,
>>>>>>> +    .enable = 0x40,
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> Magic values? Even if no #define is provided, a pointer to the
>>>>>> corresponding documentation would be appreciated (assuming
>>>>>> documentation
>>>>>> exists).
>>>>>
>>>>> No documents is available for A64 R_INTC.
>>>>
>>>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>>>> through the (closed source) OpenRISC firmware, so there's no driver
>>>> for it in the kernel.
>>>>
>>>> The registers line up with the old interrupt controller from the
>> A10,
>>>> but it seems only the NMI interrupt is wired up.
>>>
>>> Is this OK? Or do you want Icenowy to respin a version with defines?
>>
>> Ideally, I'd like to see some #defines, but given that the rest of the
>> file is already littered with hard-coded constants, you might as well
>> do
>> the whole thing in a subsequent patch that I would merge with these two
>> patches.
> 
> Personally I think the values are self-explained (the variable
> name) and used only once in this structure.
> 
> Making defines doesn't make the code more clear.

That's where you're severely misguided. There is plenty of places in the
kernel where constants are used exactly once, and yet they have a
#define. And the reason for this is consistency. We don't deal with raw
values, we deal with named constants.

For you, this code is probably "write-only". Once it works, you'll never
go back to it. On the other hand, I get to maintain it and apply tree
wide changes as necessary. So if the code looks better *to me*, then
that's the way.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 05/06/17 08:56, Icenowy Zheng wrote:
> 
> 
> ? 2017?6?5? GMT+08:00 ??3:53:50, Marc Zyngier <marc.zyngier@arm.com> ??:
>> On 05/06/17 06:57, Chen-Yu Tsai wrote:
>>> Hi Marc,
>>>
>>> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy@aosc.io>
>> wrote:
>>>>>
>>>>>
>>>>> ? 2017?5?22? GMT+08:00 ??5:39:22, Marc Zyngier
>> <marc.zyngier@arm.com> ??:
>>>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>>>> Add support for the newly imported compatible for the A64 R_INTC
>> in
>>>>>>> irq-sunxi-nmi driver.
>>>>>>>
>>>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>>>> ---
>>>>>>> Changes in v5:
>>>>>>> - Fix A64 R_INTC compatible.
>>>>>>>
>>>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>>>  1 file changed, 13 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs
>> sun9i_reg_offs
>>>>>> = {
>>>>>>>      .enable = 0x04,
>>>>>>>  };
>>>>>>>
>>>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>>>> +    .ctrl   = 0x0c,
>>>>>>> +    .pend   = 0x10,
>>>>>>> +    .enable = 0x40,
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> Magic values? Even if no #define is provided, a pointer to the
>>>>>> corresponding documentation would be appreciated (assuming
>>>>>> documentation
>>>>>> exists).
>>>>>
>>>>> No documents is available for A64 R_INTC.
>>>>
>>>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>>>> through the (closed source) OpenRISC firmware, so there's no driver
>>>> for it in the kernel.
>>>>
>>>> The registers line up with the old interrupt controller from the
>> A10,
>>>> but it seems only the NMI interrupt is wired up.
>>>
>>> Is this OK? Or do you want Icenowy to respin a version with defines?
>>
>> Ideally, I'd like to see some #defines, but given that the rest of the
>> file is already littered with hard-coded constants, you might as well
>> do
>> the whole thing in a subsequent patch that I would merge with these two
>> patches.
> 
> Personally I think the values are self-explained (the variable
> name) and used only once in this structure.
> 
> Making defines doesn't make the code more clear.

That's where you're severely misguided. There is plenty of places in the
kernel where constants are used exactly once, and yet they have a
#define. And the reason for this is consistency. We don't deal with raw
values, we deal with named constants.

For you, this code is probably "write-only". Once it works, you'll never
go back to it. On the other hand, I get to maintain it and apply tree
wide changes as necessary. So if the code looks better *to me*, then
that's the way.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

[Marc Zyngier]

On 05/06/17 08:56, Icenowy Zheng wrote:
> 
> 
> 于 2017年6月5日 GMT+08:00 下午3:53:50, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>> On 05/06/17 06:57, Chen-Yu Tsai wrote:
>>> Hi Marc,
>>>
>>> On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>>>> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> wrote:
>>>>>
>>>>>
>>>>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier
>> <marc.zyngier-5wv7dgnIgG8@public.gmane.org> 写到:
>>>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>>>> Add support for the newly imported compatible for the A64 R_INTC
>> in
>>>>>>> irq-sunxi-nmi driver.
>>>>>>>
>>>>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>>>>> ---
>>>>>>> Changes in v5:
>>>>>>> - Fix A64 R_INTC compatible.
>>>>>>>
>>>>>>>  drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
>>>>>>>  1 file changed, 13 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>> b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> index 668730c5cb66..5559c1d593bf 100644
>>>>>>> --- a/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>>>>>>> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs
>> sun9i_reg_offs
>>>>>> = {
>>>>>>>      .enable = 0x04,
>>>>>>>  };
>>>>>>>
>>>>>>> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
>>>>>>> +    .ctrl   = 0x0c,
>>>>>>> +    .pend   = 0x10,
>>>>>>> +    .enable = 0x40,
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> Magic values? Even if no #define is provided, a pointer to the
>>>>>> corresponding documentation would be appreciated (assuming
>>>>>> documentation
>>>>>> exists).
>>>>>
>>>>> No documents is available for A64 R_INTC.
>>>>
>>>> No code either. In Allwinner's BSP, the interrupts for the PMICs go
>>>> through the (closed source) OpenRISC firmware, so there's no driver
>>>> for it in the kernel.
>>>>
>>>> The registers line up with the old interrupt controller from the
>> A10,
>>>> but it seems only the NMI interrupt is wired up.
>>>
>>> Is this OK? Or do you want Icenowy to respin a version with defines?
>>
>> Ideally, I'd like to see some #defines, but given that the rest of the
>> file is already littered with hard-coded constants, you might as well
>> do
>> the whole thing in a subsequent patch that I would merge with these two
>> patches.
> 
> Personally I think the values are self-explained (the variable
> name) and used only once in this structure.
> 
> Making defines doesn't make the code more clear.

That's where you're severely misguided. There is plenty of places in the
kernel where constants are used exactly once, and yet they have a
#define. And the reason for this is consistency. We don't deal with raw
values, we deal with named constants.

For you, this code is probably "write-only". Once it works, you'll never
go back to it. On the other hand, I get to maintain it and apply tree
wide changes as necessary. So if the code looks better *to me*, then
that's the way.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64

[Icenowy Zheng]

Allwinner A64 SoC features a R_INTC controller, which controls the NMI
line, and this interrupt line is usually connected to the AXP PMIC.

Add support for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v4:
- Changes it to use R_INTC binding and change node label to r_intc.
- Fixed MMIO region.
- Dropped Chen-Yu's ACK due to big change.
Changes in v2:
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..45c7c3145248 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -445,6 +445,14 @@
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		r_intc: interrupt-controller@1f00c00 {
+			compatible = "allwinner,sun50i-a64-r-intc";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			reg = <0x01f00c00 0x400>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		r_ccu: clock@1f01400 {
 			compatible = "allwinner,sun50i-a64-r-ccu";
 			reg = <0x01f01400 0x100>;
-- 
2.12.2

[PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64

[Icenowy Zheng]

Allwinner A64 SoC features a R_INTC controller, which controls the NMI
line, and this interrupt line is usually connected to the AXP PMIC.

Add support for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v4:
- Changes it to use R_INTC binding and change node label to r_intc.
- Fixed MMIO region.
- Dropped Chen-Yu's ACK due to big change.
Changes in v2:
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..45c7c3145248 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -445,6 +445,14 @@
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		r_intc: interrupt-controller at 1f00c00 {
+			compatible = "allwinner,sun50i-a64-r-intc";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			reg = <0x01f00c00 0x400>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		r_ccu: clock at 1f01400 {
 			compatible = "allwinner,sun50i-a64-r-ccu";
 			reg = <0x01f01400 0x100>;
-- 
2.12.2

[PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64

[Icenowy Zheng]

Allwinner A64 SoC features a R_INTC controller, which controls the NMI
line, and this interrupt line is usually connected to the AXP PMIC.

Add support for it.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
Changes in v4:
- Changes it to use R_INTC binding and change node label to r_intc.
- Fixed MMIO region.
- Dropped Chen-Yu's ACK due to big change.
Changes in v2:
- Added Chen-Yu's ACK.

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..45c7c3145248 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -445,6 +445,14 @@
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		r_intc: interrupt-controller@1f00c00 {
+			compatible = "allwinner,sun50i-a64-r-intc";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			reg = <0x01f00c00 0x400>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		r_ccu: clock@1f01400 {
 			compatible = "allwinner,sun50i-a64-r-ccu";
 			reg = <0x01f01400 0x100>;
-- 
2.12.2

Re: [linux-sunxi] [PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Allwinner A64 SoC features a R_INTC controller, which controls the NMI
> line, and this interrupt line is usually connected to the AXP PMIC.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

[linux-sunxi] [PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Allwinner A64 SoC features a R_INTC controller, which controls the NMI
> line, and this interrupt line is usually connected to the AXP PMIC.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Re: [linux-sunxi] [PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> Allwinner A64 SoC features a R_INTC controller, which controls the NMI
> line, and this interrupt line is usually connected to the AXP PMIC.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>

Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.

Add its device node.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v6:
- Rebase on next-20170517.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..36001884ed33 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -107,6 +107,17 @@
 	status = "okay";
 };
 
+&r_rsb {
+	status = "okay";
+
+	axp803: pmic@3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
 	pinctrl-names = "default";
-- 
2.12.2

[PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.

Add its device node.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v6:
- Rebase on next-20170517.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..36001884ed33 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -107,6 +107,17 @@
 	status = "okay";
 };
 
+&r_rsb {
+	status = "okay";
+
+	axp803: pmic at 3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
 	pinctrl-names = "default";
-- 
2.12.2

[PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Icenowy Zheng]

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.

Add its device node.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
Changes in v6:
- Rebase on next-20170517.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..36001884ed33 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -107,6 +107,17 @@
 	status = "okay";
 };
 
+&r_rsb {
+	status = "okay";
+
+	axp803: pmic@3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
 	pinctrl-names = "default";
-- 
2.12.2

Re: [linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
>
> Add its device node.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

[linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
>
> Add its device node.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Re: [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
>
> Add its device node.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>

Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Re: [linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 10:28 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
>>
>> Add its device node.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Applied for 4.14.

[linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 10:28 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
>>
>> Add its device node.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Applied for 4.14.

Re: [linux-sunxi] [PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 10:28 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
>>
>> Add its device node.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>
> Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Applied for 4.14.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 5/9] regulator: axp20x-regulator: add support for AXP803

[Icenowy Zheng]

AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.

Add support for them.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v4:
- Fixed somewhere which mention AXP806 before 803.
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.

 drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
 include/linux/mfd/axp20x.h           |  37 +++++++++
 2 files changed, 168 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..e2608fe770b9 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc axp22x_drivevbus_regulator = {
 	.ops		= &axp20x_ops_sw,
 };
 
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0x0, 0x46, 10000),
+	REGULATOR_LINEAR_RANGE(1220000, 0x47, 0x4b, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+	REGULATOR_LINEAR_RANGE(800000, 0x0, 0x20, 10000),
+	REGULATOR_LINEAR_RANGE(1140000, 0x21, 0x44, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
+	REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+	AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+		 AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+	AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+			76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(1)),
+	AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+			76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(2)),
+	AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+			76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(3)),
+	AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+			68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(4)),
+	AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+			72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(5)),
+	/* secondary switchable output of DCDC1 */
+	AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+		    BIT(7)),
+	AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+	AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+	AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+	AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+	AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+			32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+			BIT(4)),
+	AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+	AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+	AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+	AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+	AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+	AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+		 AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+	AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+		 AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+	AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
+};
+
 static const struct regulator_linear_range axp806_dcdca_ranges[] = {
 	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
 	REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
@@ -254,11 +330,6 @@ static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
 	REGULATOR_LINEAR_RANGE(1600000, 0x2e, 0x3f, 100000),
 };
 
-static const struct regulator_linear_range axp806_cldo2_ranges[] = {
-	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
-	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
-};
-
 static const struct regulator_desc axp806_regulators[] = {
 	AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
 			72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
@@ -289,7 +360,7 @@ static const struct regulator_desc axp806_regulators[] = {
 		 AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
 	AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
 		 AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
-	AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+	AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp803_dldo2_ranges,
 			32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
 			BIT(5)),
 	AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
@@ -326,7 +397,7 @@ static const struct regulator_desc axp809_regulators[] = {
 		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
 	AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
 		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
-	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,
+	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp803_dldo2_ranges,
 			32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
 			BIT(3)),
 	AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
@@ -369,14 +440,21 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		def = 1500;
 		step = 75;
 		break;
-	case AXP806_ID:
+	case AXP803_ID:
 		/*
-		 * AXP806 DCDC work frequency setting has the same range and
+		 * AXP803 DCDC work frequency setting has the same range and
 		 * step as AXP22X, but at a different register.
 		 * Fall through to the check below.
 		 * (See include/linux/mfd/axp20x.h)
 		 */
-		reg = AXP806_DCDC_FREQ_CTRL;
+		reg = AXP803_DCDC_FREQ_CTRL;
+	case AXP806_ID:
+		/*
+		 * AXP806 also have DCDC work frequency setting register at a
+		 * different position.
+		 */
+		if (axp20x->variant == AXP806_ID)
+			reg = AXP806_DCDC_FREQ_CTRL;
 	case AXP221_ID:
 	case AXP223_ID:
 	case AXP809_ID:
@@ -475,6 +553,14 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 		workmode <<= id - AXP22X_DCDC1;
 		break;
 
+	case AXP803_ID:
+		if (id < AXP803_DCDC1 || id > AXP803_DCDC6)
+			return -EINVAL;
+
+		mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP803_DCDC1);
+		workmode <<= id - AXP803_DCDC1;
+		break;
+
 	default:
 		/* should not happen */
 		WARN_ON(1);
@@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
 {
 	u32 reg = 0;
 
-	/* Only AXP806 has poly-phase outputs */
-	if (axp20x->variant != AXP806_ID)
-		return false;
+	/*
+	 * Currently in our supported AXP variants, only AXP803 and AXP806
+	 * have polyphase regulators.
+	 */
+	switch (axp20x->variant) {
+	case AXP803_ID:
+		regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, &reg);
+
+		switch (id) {
+		case AXP803_DCDC3:
+			return !!(reg & BIT(6));
+		case AXP803_DCDC6:
+			return !!(reg & BIT(7));
+		}
+		break;
 
-	regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, &reg);
+	case AXP806_ID:
+		regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, &reg);
+
+		switch (id) {
+		case AXP806_DCDCB:
+			return (((reg & GENMASK(7, 6)) == BIT(6)) ||
+				((reg & GENMASK(7, 6)) == BIT(7)));
+		case AXP806_DCDCC:
+			return ((reg & GENMASK(7, 6)) == BIT(7));
+		case AXP806_DCDCE:
+			return !!(reg & BIT(5));
+		}
+		break;
 
-	switch (id) {
-	case AXP806_DCDCB:
-		return (((reg & GENMASK(7, 6)) == BIT(6)) ||
-			((reg & GENMASK(7, 6)) == BIT(7)));
-	case AXP806_DCDCC:
-		return ((reg & GENMASK(7, 6)) == BIT(7));
-	case AXP806_DCDCE:
-		return !!(reg & BIT(5));
+	default:
+		return false;
 	}
 
 	return false;
@@ -540,6 +644,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
 						  "x-powers,drive-vbus-en");
 		break;
+	case AXP803_ID:
+		regulators = axp803_regulators;
+		nregulators = AXP803_REG_ID_MAX;
+		break;
 	case AXP806_ID:
 		regulators = axp806_regulators;
 		nregulators = AXP806_REG_ID_MAX;
@@ -579,6 +687,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		 * name.
 		 */
 		if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+		    (regulators == axp803_regulators && i == AXP803_DC1SW) ||
 		    (regulators == axp809_regulators && i == AXP809_DC1SW)) {
 			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
 						GFP_KERNEL);
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index cde56cfe8446..965b027e31b3 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -119,6 +119,17 @@ enum axp20x_variants {
 #define AXP806_BUS_ADDR_EXT		0xfe
 #define AXP806_REG_ADDR_EXT		0xff
 
+#define AXP803_POLYPHASE_CTRL		0x14
+#define AXP803_FLDO1_V_OUT		0x1c
+#define AXP803_FLDO2_V_OUT		0x1d
+#define AXP803_DCDC1_V_OUT		0x20
+#define AXP803_DCDC2_V_OUT		0x21
+#define AXP803_DCDC3_V_OUT		0x22
+#define AXP803_DCDC4_V_OUT		0x23
+#define AXP803_DCDC5_V_OUT		0x24
+#define AXP803_DCDC6_V_OUT		0x25
+#define AXP803_DCDC_FREQ_CTRL		0x3b
+
 /* Interrupt */
 #define AXP152_IRQ1_EN			0x40
 #define AXP152_IRQ2_EN			0x41
@@ -350,6 +361,32 @@ enum {
 	AXP809_REG_ID_MAX,
 };
 
+enum {
+	AXP803_DCDC1 = 0,
+	AXP803_DCDC2,
+	AXP803_DCDC3,
+	AXP803_DCDC4,
+	AXP803_DCDC5,
+	AXP803_DCDC6,
+	AXP803_DC1SW,
+	AXP803_ALDO1,
+	AXP803_ALDO2,
+	AXP803_ALDO3,
+	AXP803_DLDO1,
+	AXP803_DLDO2,
+	AXP803_DLDO3,
+	AXP803_DLDO4,
+	AXP803_ELDO1,
+	AXP803_ELDO2,
+	AXP803_ELDO3,
+	AXP803_FLDO1,
+	AXP803_FLDO2,
+	AXP803_RTC_LDO,
+	AXP803_LDO_IO0,
+	AXP803_LDO_IO1,
+	AXP803_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
 	AXP152_IRQ_LDO0IN_CONNECT = 1,
-- 
2.12.2

[PATCH v6 5/9] regulator: axp20x-regulator: add support for AXP803

[Icenowy Zheng]

AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.

Add support for them.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v4:
- Fixed somewhere which mention AXP806 before 803.
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.

 drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
 include/linux/mfd/axp20x.h           |  37 +++++++++
 2 files changed, 168 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..e2608fe770b9 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc axp22x_drivevbus_regulator = {
 	.ops		= &axp20x_ops_sw,
 };
 
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0x0, 0x46, 10000),
+	REGULATOR_LINEAR_RANGE(1220000, 0x47, 0x4b, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+	REGULATOR_LINEAR_RANGE(800000, 0x0, 0x20, 10000),
+	REGULATOR_LINEAR_RANGE(1140000, 0x21, 0x44, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
+	REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+	AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+		 AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+	AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+			76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(1)),
+	AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+			76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(2)),
+	AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+			76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(3)),
+	AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+			68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(4)),
+	AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+			72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(5)),
+	/* secondary switchable output of DCDC1 */
+	AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+		    BIT(7)),
+	AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+	AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+	AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+	AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+	AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+			32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+			BIT(4)),
+	AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+	AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+	AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+	AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+	AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+	AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+		 AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+	AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+		 AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+	AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
+};
+
 static const struct regulator_linear_range axp806_dcdca_ranges[] = {
 	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
 	REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
@@ -254,11 +330,6 @@ static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
 	REGULATOR_LINEAR_RANGE(1600000, 0x2e, 0x3f, 100000),
 };
 
-static const struct regulator_linear_range axp806_cldo2_ranges[] = {
-	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
-	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
-};
-
 static const struct regulator_desc axp806_regulators[] = {
 	AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
 			72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
@@ -289,7 +360,7 @@ static const struct regulator_desc axp806_regulators[] = {
 		 AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
 	AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
 		 AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
-	AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+	AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp803_dldo2_ranges,
 			32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
 			BIT(5)),
 	AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
@@ -326,7 +397,7 @@ static const struct regulator_desc axp809_regulators[] = {
 		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
 	AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
 		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
-	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,
+	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp803_dldo2_ranges,
 			32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
 			BIT(3)),
 	AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
@@ -369,14 +440,21 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		def = 1500;
 		step = 75;
 		break;
-	case AXP806_ID:
+	case AXP803_ID:
 		/*
-		 * AXP806 DCDC work frequency setting has the same range and
+		 * AXP803 DCDC work frequency setting has the same range and
 		 * step as AXP22X, but at a different register.
 		 * Fall through to the check below.
 		 * (See include/linux/mfd/axp20x.h)
 		 */
-		reg = AXP806_DCDC_FREQ_CTRL;
+		reg = AXP803_DCDC_FREQ_CTRL;
+	case AXP806_ID:
+		/*
+		 * AXP806 also have DCDC work frequency setting register at a
+		 * different position.
+		 */
+		if (axp20x->variant == AXP806_ID)
+			reg = AXP806_DCDC_FREQ_CTRL;
 	case AXP221_ID:
 	case AXP223_ID:
 	case AXP809_ID:
@@ -475,6 +553,14 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 		workmode <<= id - AXP22X_DCDC1;
 		break;
 
+	case AXP803_ID:
+		if (id < AXP803_DCDC1 || id > AXP803_DCDC6)
+			return -EINVAL;
+
+		mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP803_DCDC1);
+		workmode <<= id - AXP803_DCDC1;
+		break;
+
 	default:
 		/* should not happen */
 		WARN_ON(1);
@@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
 {
 	u32 reg = 0;
 
-	/* Only AXP806 has poly-phase outputs */
-	if (axp20x->variant != AXP806_ID)
-		return false;
+	/*
+	 * Currently in our supported AXP variants, only AXP803 and AXP806
+	 * have polyphase regulators.
+	 */
+	switch (axp20x->variant) {
+	case AXP803_ID:
+		regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, &reg);
+
+		switch (id) {
+		case AXP803_DCDC3:
+			return !!(reg & BIT(6));
+		case AXP803_DCDC6:
+			return !!(reg & BIT(7));
+		}
+		break;
 
-	regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, &reg);
+	case AXP806_ID:
+		regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, &reg);
+
+		switch (id) {
+		case AXP806_DCDCB:
+			return (((reg & GENMASK(7, 6)) == BIT(6)) ||
+				((reg & GENMASK(7, 6)) == BIT(7)));
+		case AXP806_DCDCC:
+			return ((reg & GENMASK(7, 6)) == BIT(7));
+		case AXP806_DCDCE:
+			return !!(reg & BIT(5));
+		}
+		break;
 
-	switch (id) {
-	case AXP806_DCDCB:
-		return (((reg & GENMASK(7, 6)) == BIT(6)) ||
-			((reg & GENMASK(7, 6)) == BIT(7)));
-	case AXP806_DCDCC:
-		return ((reg & GENMASK(7, 6)) == BIT(7));
-	case AXP806_DCDCE:
-		return !!(reg & BIT(5));
+	default:
+		return false;
 	}
 
 	return false;
@@ -540,6 +644,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
 						  "x-powers,drive-vbus-en");
 		break;
+	case AXP803_ID:
+		regulators = axp803_regulators;
+		nregulators = AXP803_REG_ID_MAX;
+		break;
 	case AXP806_ID:
 		regulators = axp806_regulators;
 		nregulators = AXP806_REG_ID_MAX;
@@ -579,6 +687,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		 * name.
 		 */
 		if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+		    (regulators == axp803_regulators && i == AXP803_DC1SW) ||
 		    (regulators == axp809_regulators && i == AXP809_DC1SW)) {
 			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
 						GFP_KERNEL);
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index cde56cfe8446..965b027e31b3 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -119,6 +119,17 @@ enum axp20x_variants {
 #define AXP806_BUS_ADDR_EXT		0xfe
 #define AXP806_REG_ADDR_EXT		0xff
 
+#define AXP803_POLYPHASE_CTRL		0x14
+#define AXP803_FLDO1_V_OUT		0x1c
+#define AXP803_FLDO2_V_OUT		0x1d
+#define AXP803_DCDC1_V_OUT		0x20
+#define AXP803_DCDC2_V_OUT		0x21
+#define AXP803_DCDC3_V_OUT		0x22
+#define AXP803_DCDC4_V_OUT		0x23
+#define AXP803_DCDC5_V_OUT		0x24
+#define AXP803_DCDC6_V_OUT		0x25
+#define AXP803_DCDC_FREQ_CTRL		0x3b
+
 /* Interrupt */
 #define AXP152_IRQ1_EN			0x40
 #define AXP152_IRQ2_EN			0x41
@@ -350,6 +361,32 @@ enum {
 	AXP809_REG_ID_MAX,
 };
 
+enum {
+	AXP803_DCDC1 = 0,
+	AXP803_DCDC2,
+	AXP803_DCDC3,
+	AXP803_DCDC4,
+	AXP803_DCDC5,
+	AXP803_DCDC6,
+	AXP803_DC1SW,
+	AXP803_ALDO1,
+	AXP803_ALDO2,
+	AXP803_ALDO3,
+	AXP803_DLDO1,
+	AXP803_DLDO2,
+	AXP803_DLDO3,
+	AXP803_DLDO4,
+	AXP803_ELDO1,
+	AXP803_ELDO2,
+	AXP803_ELDO3,
+	AXP803_FLDO1,
+	AXP803_FLDO2,
+	AXP803_RTC_LDO,
+	AXP803_LDO_IO0,
+	AXP803_LDO_IO1,
+	AXP803_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
 	AXP152_IRQ_LDO0IN_CONNECT = 1,
-- 
2.12.2

[PATCH v6 5/9] regulator: axp20x-regulator: add support for AXP803

[Icenowy Zheng]

AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.

Add support for them.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Changes in v4:
- Fixed somewhere which mention AXP806 before 803.
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.

 drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
 include/linux/mfd/axp20x.h           |  37 +++++++++
 2 files changed, 168 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..e2608fe770b9 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc axp22x_drivevbus_regulator = {
 	.ops		= &axp20x_ops_sw,
 };
 
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0x0, 0x46, 10000),
+	REGULATOR_LINEAR_RANGE(1220000, 0x47, 0x4b, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+	REGULATOR_LINEAR_RANGE(800000, 0x0, 0x20, 10000),
+	REGULATOR_LINEAR_RANGE(1140000, 0x21, 0x44, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
+	REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+	AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+		 AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+	AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+			76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(1)),
+	AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+			76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(2)),
+	AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+			76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(3)),
+	AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+			68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(4)),
+	AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+			72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+			BIT(5)),
+	/* secondary switchable output of DCDC1 */
+	AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+		    BIT(7)),
+	AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+	AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+	AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+	AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+	AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+			32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+			BIT(4)),
+	AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+	AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+	AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+	AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+	AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+		 AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+	AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+		 AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+	AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+		 AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+	AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
+};
+
 static const struct regulator_linear_range axp806_dcdca_ranges[] = {
 	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
 	REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
@@ -254,11 +330,6 @@ static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
 	REGULATOR_LINEAR_RANGE(1600000, 0x2e, 0x3f, 100000),
 };
 
-static const struct regulator_linear_range axp806_cldo2_ranges[] = {
-	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
-	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
-};
-
 static const struct regulator_desc axp806_regulators[] = {
 	AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
 			72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
@@ -289,7 +360,7 @@ static const struct regulator_desc axp806_regulators[] = {
 		 AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
 	AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
 		 AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
-	AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+	AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp803_dldo2_ranges,
 			32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
 			BIT(5)),
 	AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
@@ -326,7 +397,7 @@ static const struct regulator_desc axp809_regulators[] = {
 		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
 	AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
 		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
-	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,
+	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp803_dldo2_ranges,
 			32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
 			BIT(3)),
 	AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
@@ -369,14 +440,21 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		def = 1500;
 		step = 75;
 		break;
-	case AXP806_ID:
+	case AXP803_ID:
 		/*
-		 * AXP806 DCDC work frequency setting has the same range and
+		 * AXP803 DCDC work frequency setting has the same range and
 		 * step as AXP22X, but at a different register.
 		 * Fall through to the check below.
 		 * (See include/linux/mfd/axp20x.h)
 		 */
-		reg = AXP806_DCDC_FREQ_CTRL;
+		reg = AXP803_DCDC_FREQ_CTRL;
+	case AXP806_ID:
+		/*
+		 * AXP806 also have DCDC work frequency setting register at a
+		 * different position.
+		 */
+		if (axp20x->variant == AXP806_ID)
+			reg = AXP806_DCDC_FREQ_CTRL;
 	case AXP221_ID:
 	case AXP223_ID:
 	case AXP809_ID:
@@ -475,6 +553,14 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 		workmode <<= id - AXP22X_DCDC1;
 		break;
 
+	case AXP803_ID:
+		if (id < AXP803_DCDC1 || id > AXP803_DCDC6)
+			return -EINVAL;
+
+		mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP803_DCDC1);
+		workmode <<= id - AXP803_DCDC1;
+		break;
+
 	default:
 		/* should not happen */
 		WARN_ON(1);
@@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
 {
 	u32 reg = 0;
 
-	/* Only AXP806 has poly-phase outputs */
-	if (axp20x->variant != AXP806_ID)
-		return false;
+	/*
+	 * Currently in our supported AXP variants, only AXP803 and AXP806
+	 * have polyphase regulators.
+	 */
+	switch (axp20x->variant) {
+	case AXP803_ID:
+		regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, &reg);
+
+		switch (id) {
+		case AXP803_DCDC3:
+			return !!(reg & BIT(6));
+		case AXP803_DCDC6:
+			return !!(reg & BIT(7));
+		}
+		break;
 
-	regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, &reg);
+	case AXP806_ID:
+		regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, &reg);
+
+		switch (id) {
+		case AXP806_DCDCB:
+			return (((reg & GENMASK(7, 6)) == BIT(6)) ||
+				((reg & GENMASK(7, 6)) == BIT(7)));
+		case AXP806_DCDCC:
+			return ((reg & GENMASK(7, 6)) == BIT(7));
+		case AXP806_DCDCE:
+			return !!(reg & BIT(5));
+		}
+		break;
 
-	switch (id) {
-	case AXP806_DCDCB:
-		return (((reg & GENMASK(7, 6)) == BIT(6)) ||
-			((reg & GENMASK(7, 6)) == BIT(7)));
-	case AXP806_DCDCC:
-		return ((reg & GENMASK(7, 6)) == BIT(7));
-	case AXP806_DCDCE:
-		return !!(reg & BIT(5));
+	default:
+		return false;
 	}
 
 	return false;
@@ -540,6 +644,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
 						  "x-powers,drive-vbus-en");
 		break;
+	case AXP803_ID:
+		regulators = axp803_regulators;
+		nregulators = AXP803_REG_ID_MAX;
+		break;
 	case AXP806_ID:
 		regulators = axp806_regulators;
 		nregulators = AXP806_REG_ID_MAX;
@@ -579,6 +687,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		 * name.
 		 */
 		if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+		    (regulators == axp803_regulators && i == AXP803_DC1SW) ||
 		    (regulators == axp809_regulators && i == AXP809_DC1SW)) {
 			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
 						GFP_KERNEL);
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index cde56cfe8446..965b027e31b3 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -119,6 +119,17 @@ enum axp20x_variants {
 #define AXP806_BUS_ADDR_EXT		0xfe
 #define AXP806_REG_ADDR_EXT		0xff
 
+#define AXP803_POLYPHASE_CTRL		0x14
+#define AXP803_FLDO1_V_OUT		0x1c
+#define AXP803_FLDO2_V_OUT		0x1d
+#define AXP803_DCDC1_V_OUT		0x20
+#define AXP803_DCDC2_V_OUT		0x21
+#define AXP803_DCDC3_V_OUT		0x22
+#define AXP803_DCDC4_V_OUT		0x23
+#define AXP803_DCDC5_V_OUT		0x24
+#define AXP803_DCDC6_V_OUT		0x25
+#define AXP803_DCDC_FREQ_CTRL		0x3b
+
 /* Interrupt */
 #define AXP152_IRQ1_EN			0x40
 #define AXP152_IRQ2_EN			0x41
@@ -350,6 +361,32 @@ enum {
 	AXP809_REG_ID_MAX,
 };
 
+enum {
+	AXP803_DCDC1 = 0,
+	AXP803_DCDC2,
+	AXP803_DCDC3,
+	AXP803_DCDC4,
+	AXP803_DCDC5,
+	AXP803_DCDC6,
+	AXP803_DC1SW,
+	AXP803_ALDO1,
+	AXP803_ALDO2,
+	AXP803_ALDO3,
+	AXP803_DLDO1,
+	AXP803_DLDO2,
+	AXP803_DLDO3,
+	AXP803_DLDO4,
+	AXP803_ELDO1,
+	AXP803_ELDO2,
+	AXP803_ELDO3,
+	AXP803_FLDO1,
+	AXP803_FLDO2,
+	AXP803_RTC_LDO,
+	AXP803_LDO_IO0,
+	AXP803_LDO_IO1,
+	AXP803_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
 	AXP152_IRQ_LDO0IN_CONNECT = 1,
-- 
2.12.2

[PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803

[Icenowy Zheng]

As axp20x-regulator now supports AXP803, add a cell for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v5:
- Removed wrong snippet.
Changes in v4:
- Added a trailing comma for new cell, for easier further cell addition.
Changes in v3:
- Make the new cell one-liner.

 drivers/mfd/axp20x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..917b6ddc4f15 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
 		.name			= "axp20x-pek",
 		.num_resources		= ARRAY_SIZE(axp803_pek_resources),
 		.resources		= axp803_pek_resources,
-	}
+	},
+	{	.name			= "axp20x-regulator" },
 };
 
 static struct mfd_cell axp806_cells[] = {
-- 
2.12.2

[PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803

[Icenowy Zheng]

As axp20x-regulator now supports AXP803, add a cell for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v5:
- Removed wrong snippet.
Changes in v4:
- Added a trailing comma for new cell, for easier further cell addition.
Changes in v3:
- Make the new cell one-liner.

 drivers/mfd/axp20x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..917b6ddc4f15 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
 		.name			= "axp20x-pek",
 		.num_resources		= ARRAY_SIZE(axp803_pek_resources),
 		.resources		= axp803_pek_resources,
-	}
+	},
+	{	.name			= "axp20x-regulator" },
 };
 
 static struct mfd_cell axp806_cells[] = {
-- 
2.12.2

[PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803

[Icenowy Zheng]

As axp20x-regulator now supports AXP803, add a cell for it.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Changes in v5:
- Removed wrong snippet.
Changes in v4:
- Added a trailing comma for new cell, for easier further cell addition.
Changes in v3:
- Make the new cell one-liner.

 drivers/mfd/axp20x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..917b6ddc4f15 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
 		.name			= "axp20x-pek",
 		.num_resources		= ARRAY_SIZE(axp803_pek_resources),
 		.resources		= axp803_pek_resources,
-	}
+	},
+	{	.name			= "axp20x-regulator" },
 };
 
 static struct mfd_cell axp806_cells[] = {
-- 
2.12.2

Re: [PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803

[Lee Jones]

On Thu, 18 May 2017, Icenowy Zheng wrote:

> As axp20x-regulator now supports AXP803, add a cell for it.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Changes in v5:
> - Removed wrong snippet.
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
> 
>  drivers/mfd/axp20x.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 1dc6235778eb..917b6ddc4f15 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
>  		.name			= "axp20x-pek",
>  		.num_resources		= ARRAY_SIZE(axp803_pek_resources),
>  		.resources		= axp803_pek_resources,
> -	}
> +	},
> +	{	.name			= "axp20x-regulator" },
>  };
>  
>  static struct mfd_cell axp806_cells[] = {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803

[Lee Jones]

On Thu, 18 May 2017, Icenowy Zheng wrote:

> As axp20x-regulator now supports AXP803, add a cell for it.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Changes in v5:
> - Removed wrong snippet.
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
> 
>  drivers/mfd/axp20x.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 1dc6235778eb..917b6ddc4f15 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
>  		.name			= "axp20x-pek",
>  		.num_resources		= ARRAY_SIZE(axp803_pek_resources),
>  		.resources		= axp803_pek_resources,
> -	}
> +	},
> +	{	.name			= "axp20x-regulator" },
>  };
>  
>  static struct mfd_cell axp806_cells[] = {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803

[Lee Jones]

On Thu, 18 May 2017, Icenowy Zheng wrote:

> As axp20x-regulator now supports AXP803, add a cell for it.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Changes in v5:
> - Removed wrong snippet.
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
> 
>  drivers/mfd/axp20x.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 1dc6235778eb..917b6ddc4f15 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
>  		.name			= "axp20x-pek",
>  		.num_resources		= ARRAY_SIZE(axp803_pek_resources),
>  		.resources		= axp803_pek_resources,
> -	}
> +	},
> +	{	.name			= "axp20x-regulator" },
>  };
>  
>  static struct mfd_cell axp806_cells[] = {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Icenowy Zheng]

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Mark Brown <broonie@kernel.org>
---
Changes in v5:
- Added Mark Brown's ACK.
Changes in v4:
- Re-sorted the nodes.

 arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index 000000000000..ff8af52743ff
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+&axp803 {
+	interrupt-controller;
+	#interrupt-cells = <1>;
+
+	regulators {
+		/* Default work frequency for buck regulators */
+		x-powers,dcdc-freq = <3000>;
+
+		reg_aldo1: aldo1 {
+			regulator-name = "aldo1";
+		};
+
+		reg_aldo2: aldo2 {
+			regulator-name = "aldo2";
+		};
+
+		reg_aldo3: aldo3 {
+			regulator-name = "aldo3";
+		};
+
+		reg_dc1sw: dc1sw {
+			regulator-name = "dc1sw";
+		};
+
+		reg_dcdc1: dcdc1 {
+			regulator-name = "dcdc1";
+		};
+
+		reg_dcdc2: dcdc2 {
+			regulator-name = "dcdc2";
+		};
+
+		reg_dcdc3: dcdc3 {
+			regulator-name = "dcdc3";
+		};
+
+		reg_dcdc4: dcdc4 {
+			regulator-name = "dcdc4";
+		};
+
+		reg_dcdc5: dcdc5 {
+			regulator-name = "dcdc5";
+		};
+
+		reg_dcdc6: dcdc6 {
+			regulator-name = "dcdc6";
+		};
+
+		reg_dldo1: dldo1 {
+			regulator-name = "dldo1";
+		};
+
+		reg_dldo2: dldo2 {
+			regulator-name = "dldo2";
+		};
+
+		reg_dldo3: dldo3 {
+			regulator-name = "dldo3";
+		};
+
+		reg_dldo4: dldo4 {
+			regulator-name = "dldo4";
+		};
+
+		reg_eldo1: eldo1 {
+			regulator-name = "eldo1";
+		};
+
+		reg_eldo2: eldo2 {
+			regulator-name = "eldo2";
+		};
+
+		reg_eldo3: eldo3 {
+			regulator-name = "eldo3";
+		};
+
+		reg_fldo1: fldo1 {
+			regulator-name = "fldo1";
+		};
+
+		reg_fldo2: fldo2 {
+			regulator-name = "fldo2";
+		};
+
+		reg_ldo_io0: ldo-io0 {
+			regulator-name = "ldo-io0";
+			status = "disabled";
+		};
+
+		reg_ldo_io1: ldo-io1 {
+			regulator-name = "ldo-io1";
+			status = "disabled";
+		};
+
+		reg_rtc_ldo: rtc-ldo {
+			/* RTC_LDO is a fixed, always-on regulator */
+			regulator-always-on;
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-name = "rtc-ldo";
+		};
+	};
+};
-- 
2.12.2

[PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Icenowy Zheng]

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Mark Brown <broonie@kernel.org>
---
Changes in v5:
- Added Mark Brown's ACK.
Changes in v4:
- Re-sorted the nodes.

 arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index 000000000000..ff8af52743ff
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+&axp803 {
+	interrupt-controller;
+	#interrupt-cells = <1>;
+
+	regulators {
+		/* Default work frequency for buck regulators */
+		x-powers,dcdc-freq = <3000>;
+
+		reg_aldo1: aldo1 {
+			regulator-name = "aldo1";
+		};
+
+		reg_aldo2: aldo2 {
+			regulator-name = "aldo2";
+		};
+
+		reg_aldo3: aldo3 {
+			regulator-name = "aldo3";
+		};
+
+		reg_dc1sw: dc1sw {
+			regulator-name = "dc1sw";
+		};
+
+		reg_dcdc1: dcdc1 {
+			regulator-name = "dcdc1";
+		};
+
+		reg_dcdc2: dcdc2 {
+			regulator-name = "dcdc2";
+		};
+
+		reg_dcdc3: dcdc3 {
+			regulator-name = "dcdc3";
+		};
+
+		reg_dcdc4: dcdc4 {
+			regulator-name = "dcdc4";
+		};
+
+		reg_dcdc5: dcdc5 {
+			regulator-name = "dcdc5";
+		};
+
+		reg_dcdc6: dcdc6 {
+			regulator-name = "dcdc6";
+		};
+
+		reg_dldo1: dldo1 {
+			regulator-name = "dldo1";
+		};
+
+		reg_dldo2: dldo2 {
+			regulator-name = "dldo2";
+		};
+
+		reg_dldo3: dldo3 {
+			regulator-name = "dldo3";
+		};
+
+		reg_dldo4: dldo4 {
+			regulator-name = "dldo4";
+		};
+
+		reg_eldo1: eldo1 {
+			regulator-name = "eldo1";
+		};
+
+		reg_eldo2: eldo2 {
+			regulator-name = "eldo2";
+		};
+
+		reg_eldo3: eldo3 {
+			regulator-name = "eldo3";
+		};
+
+		reg_fldo1: fldo1 {
+			regulator-name = "fldo1";
+		};
+
+		reg_fldo2: fldo2 {
+			regulator-name = "fldo2";
+		};
+
+		reg_ldo_io0: ldo-io0 {
+			regulator-name = "ldo-io0";
+			status = "disabled";
+		};
+
+		reg_ldo_io1: ldo-io1 {
+			regulator-name = "ldo-io1";
+			status = "disabled";
+		};
+
+		reg_rtc_ldo: rtc-ldo {
+			/* RTC_LDO is a fixed, always-on regulator */
+			regulator-always-on;
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-name = "rtc-ldo";
+		};
+	};
+};
-- 
2.12.2

[PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Icenowy Zheng]

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v5:
- Added Mark Brown's ACK.
Changes in v4:
- Re-sorted the nodes.

 arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index 000000000000..ff8af52743ff
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+&axp803 {
+	interrupt-controller;
+	#interrupt-cells = <1>;
+
+	regulators {
+		/* Default work frequency for buck regulators */
+		x-powers,dcdc-freq = <3000>;
+
+		reg_aldo1: aldo1 {
+			regulator-name = "aldo1";
+		};
+
+		reg_aldo2: aldo2 {
+			regulator-name = "aldo2";
+		};
+
+		reg_aldo3: aldo3 {
+			regulator-name = "aldo3";
+		};
+
+		reg_dc1sw: dc1sw {
+			regulator-name = "dc1sw";
+		};
+
+		reg_dcdc1: dcdc1 {
+			regulator-name = "dcdc1";
+		};
+
+		reg_dcdc2: dcdc2 {
+			regulator-name = "dcdc2";
+		};
+
+		reg_dcdc3: dcdc3 {
+			regulator-name = "dcdc3";
+		};
+
+		reg_dcdc4: dcdc4 {
+			regulator-name = "dcdc4";
+		};
+
+		reg_dcdc5: dcdc5 {
+			regulator-name = "dcdc5";
+		};
+
+		reg_dcdc6: dcdc6 {
+			regulator-name = "dcdc6";
+		};
+
+		reg_dldo1: dldo1 {
+			regulator-name = "dldo1";
+		};
+
+		reg_dldo2: dldo2 {
+			regulator-name = "dldo2";
+		};
+
+		reg_dldo3: dldo3 {
+			regulator-name = "dldo3";
+		};
+
+		reg_dldo4: dldo4 {
+			regulator-name = "dldo4";
+		};
+
+		reg_eldo1: eldo1 {
+			regulator-name = "eldo1";
+		};
+
+		reg_eldo2: eldo2 {
+			regulator-name = "eldo2";
+		};
+
+		reg_eldo3: eldo3 {
+			regulator-name = "eldo3";
+		};
+
+		reg_fldo1: fldo1 {
+			regulator-name = "fldo1";
+		};
+
+		reg_fldo2: fldo2 {
+			regulator-name = "fldo2";
+		};
+
+		reg_ldo_io0: ldo-io0 {
+			regulator-name = "ldo-io0";
+			status = "disabled";
+		};
+
+		reg_ldo_io1: ldo-io1 {
+			regulator-name = "ldo-io1";
+			status = "disabled";
+		};
+
+		reg_rtc_ldo: rtc-ldo {
+			/* RTC_LDO is a fixed, always-on regulator */
+			regulator-always-on;
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-name = "rtc-ldo";
+		};
+	};
+};
-- 
2.12.2

Re: [linux-sunxi] [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
> like the old DTSI files for AXP20x/22x, for the common parts of the
> PMIC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Mark Brown <broonie@kernel.org>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

[linux-sunxi] [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
> like the old DTSI files for AXP20x/22x, for the common parts of the
> PMIC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Mark Brown <broonie@kernel.org>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Re: [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Chen-Yu Tsai]

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
> like the old DTSI files for AXP20x/22x, for the common parts of the
> PMIC.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Re: [linux-sunxi] [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 10:29 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
>> like the old DTSI files for AXP20x/22x, for the common parts of the
>> PMIC.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Acked-by: Mark Brown <broonie@kernel.org>
>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Applied for 4.14.

[linux-sunxi] [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 10:29 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
>> like the old DTSI files for AXP20x/22x, for the common parts of the
>> PMIC.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Acked-by: Mark Brown <broonie@kernel.org>
>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>

Applied for 4.14.

Re: [PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 10:29 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
>> like the old DTSI files for AXP20x/22x, for the common parts of the
>> PMIC.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Applied for 4.14.

[PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v6:
- Rebased on next-20170517.

 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 36001884ed33..40921bacb39c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -118,6 +118,115 @@
 	};
 };
 
+#include "axp803.dtsi"
+
+&reg_aldo1 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-csi";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <2700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc1sw {
+	regulator-name = "vcc-phy";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-hdmi";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-mipi";
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "avdd-csi";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "cpvdd";
+};
+
+&reg_eldo3 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vdd-1v8-csi";
+};
+
+&reg_fldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-1v2-hsic";
+};
+
+&reg_fldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
 	pinctrl-names = "default";
-- 
2.12.2

[PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v6:
- Rebased on next-20170517.

 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 36001884ed33..40921bacb39c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -118,6 +118,115 @@
 	};
 };
 
+#include "axp803.dtsi"
+
+&reg_aldo1 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-csi";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <2700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc1sw {
+	regulator-name = "vcc-phy";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-hdmi";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-mipi";
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "avdd-csi";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "cpvdd";
+};
+
+&reg_eldo3 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vdd-1v8-csi";
+};
+
+&reg_fldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-1v2-hsic";
+};
+
+&reg_fldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
 	pinctrl-names = "default";
-- 
2.12.2

[PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
Changes in v6:
- Rebased on next-20170517.

 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 36001884ed33..40921bacb39c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -118,6 +118,115 @@
 	};
 };
 
+#include "axp803.dtsi"
+
+&reg_aldo1 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-csi";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <2700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc1sw {
+	regulator-name = "vcc-phy";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-hdmi";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-mipi";
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "avdd-csi";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "cpvdd";
+};
+
+&reg_eldo3 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vdd-1v8-csi";
+};
+
+&reg_fldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-1v2-hsic";
+};
+
+&reg_fldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
+};
+
 /* On Exp and Euler connectors */
 &uart0 {
 	pinctrl-names = "default";
-- 
2.12.2

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

Hi,

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v6:
> - Rebased on next-20170517.
>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>         };
>  };
>
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +       regulator-min-microvolt = <2800000>;
> +       regulator-max-microvolt = <2800000>;
> +       regulator-name = "vcc-csi";

"csi-afvdd-dovdd"

This regulator provides power for the camera module's Auto Focus, if available,
and Digital i/O parts of the sensor module. Hence the names of the rails.

> +};
> +
> +&reg_aldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <2700000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +       regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1000000>;
> +       regulator-max-microvolt = <1300000>;
> +       regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1500000>;
> +       regulator-max-microvolt = <1500000>;
> +       regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-hdmi";
> +};

This should probably be "vcc-hdmi-dsi".

> +
> +&reg_dldo2 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-mipi";
> +};

On the MIPI-LCD page of the schematics, it says this is connected to
VDD18, so it should be 1.8V.

> +
> +&reg_dldo3 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "avdd-csi";
> +};

2.8V for this one.

ChenYu

> +
> +&reg_dldo4 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +       regulator-min-microvolt = <1200000>;
> +       regulator-max-microvolt = <1200000>;
> +       regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +       regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>         pinctrl-names = "default";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v6:
> - Rebased on next-20170517.
>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>         };
>  };
>
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +       regulator-min-microvolt = <2800000>;
> +       regulator-max-microvolt = <2800000>;
> +       regulator-name = "vcc-csi";
> +};
> +
> +&reg_aldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <2700000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +       regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1000000>;
> +       regulator-max-microvolt = <1300000>;
> +       regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1500000>;
> +       regulator-max-microvolt = <1500000>;
> +       regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-hdmi";
> +};
> +
> +&reg_dldo2 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-mipi";
> +};
> +
> +&reg_dldo3 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +       regulator-min-microvolt = <1200000>;
> +       regulator-max-microvolt = <1200000>;
> +       regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +       regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>         pinctrl-names = "default";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

Hi,

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v6:
> - Rebased on next-20170517.
>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>         };
>  };
>
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +       regulator-min-microvolt = <2800000>;
> +       regulator-max-microvolt = <2800000>;
> +       regulator-name = "vcc-csi";

"csi-afvdd-dovdd"

This regulator provides power for the camera module's Auto Focus, if available,
and Digital i/O parts of the sensor module. Hence the names of the rails.

> +};
> +
> +&reg_aldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <2700000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +       regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1000000>;
> +       regulator-max-microvolt = <1300000>;
> +       regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1500000>;
> +       regulator-max-microvolt = <1500000>;
> +       regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-hdmi";
> +};

This should probably be "vcc-hdmi-dsi".

> +
> +&reg_dldo2 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-mipi";
> +};

On the MIPI-LCD page of the schematics, it says this is connected to
VDD18, so it should be 1.8V.

> +
> +&reg_dldo3 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "avdd-csi";
> +};

2.8V for this one.

ChenYu

> +
> +&reg_dldo4 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +       regulator-min-microvolt = <1200000>;
> +       regulator-max-microvolt = <1200000>;
> +       regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +       regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>         pinctrl-names = "default";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v6:
> - Rebased on next-20170517.
>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>         };
>  };
>
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +       regulator-min-microvolt = <2800000>;
> +       regulator-max-microvolt = <2800000>;
> +       regulator-name = "vcc-csi";
> +};
> +
> +&reg_aldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <2700000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +       regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1000000>;
> +       regulator-max-microvolt = <1300000>;
> +       regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1500000>;
> +       regulator-max-microvolt = <1500000>;
> +       regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-hdmi";
> +};
> +
> +&reg_dldo2 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-mipi";
> +};
> +
> +&reg_dldo3 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +       regulator-min-microvolt = <1200000>;
> +       regulator-max-microvolt = <1200000>;
> +       regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +       regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>         pinctrl-names = "default";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

Hi,

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v6:
> - Rebased on next-20170517.
>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>         };
>  };
>
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +       regulator-min-microvolt = <2800000>;
> +       regulator-max-microvolt = <2800000>;
> +       regulator-name = "vcc-csi";

"csi-afvdd-dovdd"

This regulator provides power for the camera module's Auto Focus, if available,
and Digital i/O parts of the sensor module. Hence the names of the rails.

> +};
> +
> +&reg_aldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <2700000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +       regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1000000>;
> +       regulator-max-microvolt = <1300000>;
> +       regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1500000>;
> +       regulator-max-microvolt = <1500000>;
> +       regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-hdmi";
> +};

This should probably be "vcc-hdmi-dsi".

> +
> +&reg_dldo2 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-mipi";
> +};

On the MIPI-LCD page of the schematics, it says this is connected to
VDD18, so it should be 1.8V.

> +
> +&reg_dldo3 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "avdd-csi";
> +};

2.8V for this one.

ChenYu

> +
> +&reg_dldo4 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +       regulator-min-microvolt = <1200000>;
> +       regulator-max-microvolt = <1200000>;
> +       regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +       regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>         pinctrl-names = "default";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v6:
> - Rebased on next-20170517.
>
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>         };
>  };
>
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +       regulator-min-microvolt = <2800000>;
> +       regulator-max-microvolt = <2800000>;
> +       regulator-name = "vcc-csi";
> +};
> +
> +&reg_aldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <2700000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +       regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1000000>;
> +       regulator-max-microvolt = <1300000>;
> +       regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1500000>;
> +       regulator-max-microvolt = <1500000>;
> +       regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-hdmi";
> +};
> +
> +&reg_dldo2 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-mipi";
> +};
> +
> +&reg_dldo3 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +       regulator-min-microvolt = <3300000>;
> +       regulator-max-microvolt = <3300000>;
> +       regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +       regulator-min-microvolt = <1800000>;
> +       regulator-max-microvolt = <1800000>;
> +       regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +       regulator-min-microvolt = <1200000>;
> +       regulator-max-microvolt = <1200000>;
> +       regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +       regulator-always-on;
> +       regulator-min-microvolt = <1100000>;
> +       regulator-max-microvolt = <1100000>;
> +       regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +       regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>         pinctrl-names = "default";
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 上午10:54:21, Chen-Yu Tsai <wens@csie.org> 写到:
>Hi,
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>>
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>         };
>>  };
>>
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +       regulator-min-microvolt = <2800000>;
>> +       regulator-max-microvolt = <2800000>;
>> +       regulator-name = "vcc-csi";
>
>"csi-afvdd-dovdd"
>
>This regulator provides power for the camera module's Auto Focus, if
>available,
>and Digital i/O parts of the sensor module. Hence the names of the
>rails.
>
>> +};
>> +
>> +&reg_aldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <2700000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +       regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1000000>;
>> +       regulator-max-microvolt = <1300000>;
>> +       regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1500000>;
>> +       regulator-max-microvolt = <1500000>;
>> +       regulator-name = "vcc-dram";
>> +};
>> +
>> +&reg_dcdc6 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-hdmi";
>> +};
>
>This should probably be "vcc-hdmi-dsi".

oh yes...

>
>> +
>> +&reg_dldo2 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-mipi";
>> +};
>
>On the MIPI-LCD page of the schematics, it says this is connected to
>VDD18, so it should be 1.8V.

Rename it to "vcc-dsi-1v8"?

>
>> +
>> +&reg_dldo3 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "avdd-csi";
>> +};
>
>2.8V for this one.
>

Thanks!

>ChenYu
>
>> +
>> +&reg_dldo4 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +       regulator-min-microvolt = <1200000>;
>> +       regulator-max-microvolt = <1200000>;
>> +       regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +       regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>         pinctrl-names = "default";
>> --
>> 2.12.2
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>>
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>         };
>>  };
>>
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +       regulator-min-microvolt = <2800000>;
>> +       regulator-max-microvolt = <2800000>;
>> +       regulator-name = "vcc-csi";
>> +};
>> +
>> +&reg_aldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <2700000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +       regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1000000>;
>> +       regulator-max-microvolt = <1300000>;
>> +       regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1500000>;
>> +       regulator-max-microvolt = <1500000>;
>> +       regulator-name = "vcc-dram";
>> +};
>> +
>> +&reg_dcdc6 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-hdmi";
>> +};
>> +
>> +&reg_dldo2 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-mipi";
>> +};
>> +
>> +&reg_dldo3 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "avdd-csi";
>> +};
>> +
>> +&reg_dldo4 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +       regulator-min-microvolt = <1200000>;
>> +       regulator-max-microvolt = <1200000>;
>> +       regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +       regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>         pinctrl-names = "default";
>> --
>> 2.12.2
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

? 2017?5?19? GMT+08:00 ??10:54:21, Chen-Yu Tsai <wens@csie.org> ??:
>Hi,
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>>
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>         };
>>  };
>>
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +       regulator-min-microvolt = <2800000>;
>> +       regulator-max-microvolt = <2800000>;
>> +       regulator-name = "vcc-csi";
>
>"csi-afvdd-dovdd"
>
>This regulator provides power for the camera module's Auto Focus, if
>available,
>and Digital i/O parts of the sensor module. Hence the names of the
>rails.
>
>> +};
>> +
>> +&reg_aldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <2700000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +       regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1000000>;
>> +       regulator-max-microvolt = <1300000>;
>> +       regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1500000>;
>> +       regulator-max-microvolt = <1500000>;
>> +       regulator-name = "vcc-dram";
>> +};
>> +
>> +&reg_dcdc6 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-hdmi";
>> +};
>
>This should probably be "vcc-hdmi-dsi".

oh yes...

>
>> +
>> +&reg_dldo2 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-mipi";
>> +};
>
>On the MIPI-LCD page of the schematics, it says this is connected to
>VDD18, so it should be 1.8V.

Rename it to "vcc-dsi-1v8"?

>
>> +
>> +&reg_dldo3 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "avdd-csi";
>> +};
>
>2.8V for this one.
>

Thanks!

>ChenYu
>
>> +
>> +&reg_dldo4 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +       regulator-min-microvolt = <1200000>;
>> +       regulator-max-microvolt = <1200000>;
>> +       regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +       regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>         pinctrl-names = "default";
>> --
>> 2.12.2
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>>
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>         };
>>  };
>>
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +       regulator-min-microvolt = <2800000>;
>> +       regulator-max-microvolt = <2800000>;
>> +       regulator-name = "vcc-csi";
>> +};
>> +
>> +&reg_aldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <2700000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +       regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1000000>;
>> +       regulator-max-microvolt = <1300000>;
>> +       regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1500000>;
>> +       regulator-max-microvolt = <1500000>;
>> +       regulator-name = "vcc-dram";
>> +};
>> +
>> +&reg_dcdc6 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-hdmi";
>> +};
>> +
>> +&reg_dldo2 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-mipi";
>> +};
>> +
>> +&reg_dldo3 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "avdd-csi";
>> +};
>> +
>> +&reg_dldo4 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +       regulator-min-microvolt = <1200000>;
>> +       regulator-max-microvolt = <1200000>;
>> +       regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +       regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>         pinctrl-names = "default";
>> --
>> 2.12.2
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 上午10:54:21, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>Hi,
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>>
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>         };
>>  };
>>
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +       regulator-min-microvolt = <2800000>;
>> +       regulator-max-microvolt = <2800000>;
>> +       regulator-name = "vcc-csi";
>
>"csi-afvdd-dovdd"
>
>This regulator provides power for the camera module's Auto Focus, if
>available,
>and Digital i/O parts of the sensor module. Hence the names of the
>rails.
>
>> +};
>> +
>> +&reg_aldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <2700000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +       regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1000000>;
>> +       regulator-max-microvolt = <1300000>;
>> +       regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1500000>;
>> +       regulator-max-microvolt = <1500000>;
>> +       regulator-name = "vcc-dram";
>> +};
>> +
>> +&reg_dcdc6 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-hdmi";
>> +};
>
>This should probably be "vcc-hdmi-dsi".

oh yes...

>
>> +
>> +&reg_dldo2 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-mipi";
>> +};
>
>On the MIPI-LCD page of the schematics, it says this is connected to
>VDD18, so it should be 1.8V.

Rename it to "vcc-dsi-1v8"?

>
>> +
>> +&reg_dldo3 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "avdd-csi";
>> +};
>
>2.8V for this one.
>

Thanks!

>ChenYu
>
>> +
>> +&reg_dldo4 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +       regulator-min-microvolt = <1200000>;
>> +       regulator-max-microvolt = <1200000>;
>> +       regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +       regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>         pinctrl-names = "default";
>> --
>> 2.12.2
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit https://groups.google.com/d/optout.
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>>
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>         };
>>  };
>>
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +       regulator-min-microvolt = <2800000>;
>> +       regulator-max-microvolt = <2800000>;
>> +       regulator-name = "vcc-csi";
>> +};
>> +
>> +&reg_aldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <2700000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +       regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1000000>;
>> +       regulator-max-microvolt = <1300000>;
>> +       regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1500000>;
>> +       regulator-max-microvolt = <1500000>;
>> +       regulator-name = "vcc-dram";
>> +};
>> +
>> +&reg_dcdc6 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-hdmi";
>> +};
>> +
>> +&reg_dldo2 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-mipi";
>> +};
>> +
>> +&reg_dldo3 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "avdd-csi";
>> +};
>> +
>> +&reg_dldo4 {
>> +       regulator-min-microvolt = <3300000>;
>> +       regulator-max-microvolt = <3300000>;
>> +       regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +       regulator-min-microvolt = <1800000>;
>> +       regulator-max-microvolt = <1800000>;
>> +       regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +       regulator-min-microvolt = <1200000>;
>> +       regulator-max-microvolt = <1200000>;
>> +       regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +       regulator-always-on;
>> +       regulator-min-microvolt = <1100000>;
>> +       regulator-max-microvolt = <1100000>;
>> +       regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +       regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>         pinctrl-names = "default";
>> --
>> 2.12.2
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 11:00 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年5月19日 GMT+08:00 上午10:54:21, Chen-Yu Tsai <wens@csie.org> 写到:
>>Hi,
>>
>>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>to
>>> enable many future functionalities, e.g. Wi-Fi.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> Changes in v6:
>>> - Rebased on next-20170517.
>>>
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>+++++++++++++++++++++
>>>  1 file changed, 109 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> index 36001884ed33..40921bacb39c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> @@ -118,6 +118,115 @@
>>>         };
>>>  };
>>>
>>> +#include "axp803.dtsi"
>>> +
>>> +&reg_aldo1 {
>>> +       regulator-min-microvolt = <2800000>;
>>> +       regulator-max-microvolt = <2800000>;
>>> +       regulator-name = "vcc-csi";
>>
>>"csi-afvdd-dovdd"
>>
>>This regulator provides power for the camera module's Auto Focus, if
>>available,
>>and Digital i/O parts of the sensor module. Hence the names of the
>>rails.
>>
>>> +};
>>> +
>>> +&reg_aldo2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-pl";
>>> +};
>>> +
>>> +&reg_aldo3 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <2700000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-pll-avcc";
>>> +};
>>> +
>>> +&reg_dc1sw {
>>> +       regulator-name = "vcc-phy";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-3v3";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1000000>;
>>> +       regulator-max-microvolt = <1300000>;
>>> +       regulator-name = "vdd-cpux";
>>> +};
>>> +
>>> +/* DCDC3 is polyphased with DCDC2 */
>>> +
>>> +&reg_dcdc5 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1500000>;
>>> +       regulator-max-microvolt = <1500000>;
>>> +       regulator-name = "vcc-dram";
>>> +};
>>> +
>>> +&reg_dcdc6 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1100000>;
>>> +       regulator-max-microvolt = <1100000>;
>>> +       regulator-name = "vdd-sys";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-hdmi";
>>> +};
>>
>>This should probably be "vcc-hdmi-dsi".
>
> oh yes...
>
>>
>>> +
>>> +&reg_dldo2 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-mipi";
>>> +};
>>
>>On the MIPI-LCD page of the schematics, it says this is connected to
>>VDD18, so it should be 1.8V.
>
> Rename it to "vcc-dsi-1v8"?

The name is OK. I'm just worried about the voltage. We don't want
users frying their display panel. They probably cost more than the
board itself.

For most of these SBCs, they are designed to work with the panels
they provide. Could you reach out to TL Lim and ask about the voltage
used? Or maybe dig it out of the FEX files?

Thanks
ChenYu

>>
>>> +
>>> +&reg_dldo3 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "avdd-csi";
>>> +};
>>
>>2.8V for this one.
>>
>
> Thanks!
>
>>ChenYu
>>
>>> +
>>> +&reg_dldo4 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +&reg_eldo1 {
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <1800000>;
>>> +       regulator-name = "cpvdd";
>>> +};
>>> +
>>> +&reg_eldo3 {
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <1800000>;
>>> +       regulator-name = "vdd-1v8-csi";
>>> +};
>>> +
>>> +&reg_fldo1 {
>>> +       regulator-min-microvolt = <1200000>;
>>> +       regulator-max-microvolt = <1200000>;
>>> +       regulator-name = "vcc-1v2-hsic";
>>> +};
>>> +
>>> +&reg_fldo2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1100000>;
>>> +       regulator-max-microvolt = <1100000>;
>>> +       regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_rtc_ldo {
>>> +       regulator-name = "vcc-rtc";
>>> +};
>>> +
>>>  /* On Exp and Euler connectors */
>>>  &uart0 {
>>>         pinctrl-names = "default";
>>> --
>>> 2.12.2
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>send an email to linux-sunxi+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 11:00 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> ? 2017?5?19? GMT+08:00 ??10:54:21, Chen-Yu Tsai <wens@csie.org> ??:
>>Hi,
>>
>>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>to
>>> enable many future functionalities, e.g. Wi-Fi.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> Changes in v6:
>>> - Rebased on next-20170517.
>>>
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>+++++++++++++++++++++
>>>  1 file changed, 109 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> index 36001884ed33..40921bacb39c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> @@ -118,6 +118,115 @@
>>>         };
>>>  };
>>>
>>> +#include "axp803.dtsi"
>>> +
>>> +&reg_aldo1 {
>>> +       regulator-min-microvolt = <2800000>;
>>> +       regulator-max-microvolt = <2800000>;
>>> +       regulator-name = "vcc-csi";
>>
>>"csi-afvdd-dovdd"
>>
>>This regulator provides power for the camera module's Auto Focus, if
>>available,
>>and Digital i/O parts of the sensor module. Hence the names of the
>>rails.
>>
>>> +};
>>> +
>>> +&reg_aldo2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-pl";
>>> +};
>>> +
>>> +&reg_aldo3 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <2700000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-pll-avcc";
>>> +};
>>> +
>>> +&reg_dc1sw {
>>> +       regulator-name = "vcc-phy";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-3v3";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1000000>;
>>> +       regulator-max-microvolt = <1300000>;
>>> +       regulator-name = "vdd-cpux";
>>> +};
>>> +
>>> +/* DCDC3 is polyphased with DCDC2 */
>>> +
>>> +&reg_dcdc5 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1500000>;
>>> +       regulator-max-microvolt = <1500000>;
>>> +       regulator-name = "vcc-dram";
>>> +};
>>> +
>>> +&reg_dcdc6 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1100000>;
>>> +       regulator-max-microvolt = <1100000>;
>>> +       regulator-name = "vdd-sys";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-hdmi";
>>> +};
>>
>>This should probably be "vcc-hdmi-dsi".
>
> oh yes...
>
>>
>>> +
>>> +&reg_dldo2 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-mipi";
>>> +};
>>
>>On the MIPI-LCD page of the schematics, it says this is connected to
>>VDD18, so it should be 1.8V.
>
> Rename it to "vcc-dsi-1v8"?

The name is OK. I'm just worried about the voltage. We don't want
users frying their display panel. They probably cost more than the
board itself.

For most of these SBCs, they are designed to work with the panels
they provide. Could you reach out to TL Lim and ask about the voltage
used? Or maybe dig it out of the FEX files?

Thanks
ChenYu

>>
>>> +
>>> +&reg_dldo3 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "avdd-csi";
>>> +};
>>
>>2.8V for this one.
>>
>
> Thanks!
>
>>ChenYu
>>
>>> +
>>> +&reg_dldo4 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +&reg_eldo1 {
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <1800000>;
>>> +       regulator-name = "cpvdd";
>>> +};
>>> +
>>> +&reg_eldo3 {
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <1800000>;
>>> +       regulator-name = "vdd-1v8-csi";
>>> +};
>>> +
>>> +&reg_fldo1 {
>>> +       regulator-min-microvolt = <1200000>;
>>> +       regulator-max-microvolt = <1200000>;
>>> +       regulator-name = "vcc-1v2-hsic";
>>> +};
>>> +
>>> +&reg_fldo2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1100000>;
>>> +       regulator-max-microvolt = <1100000>;
>>> +       regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_rtc_ldo {
>>> +       regulator-name = "vcc-rtc";
>>> +};
>>> +
>>>  /* On Exp and Euler connectors */
>>>  &uart0 {
>>>         pinctrl-names = "default";
>>> --
>>> 2.12.2
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 11:00 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 于 2017年5月19日 GMT+08:00 上午10:54:21, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>Hi,
>>
>>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>to
>>> enable many future functionalities, e.g. Wi-Fi.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>> Changes in v6:
>>> - Rebased on next-20170517.
>>>
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>+++++++++++++++++++++
>>>  1 file changed, 109 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> index 36001884ed33..40921bacb39c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> @@ -118,6 +118,115 @@
>>>         };
>>>  };
>>>
>>> +#include "axp803.dtsi"
>>> +
>>> +&reg_aldo1 {
>>> +       regulator-min-microvolt = <2800000>;
>>> +       regulator-max-microvolt = <2800000>;
>>> +       regulator-name = "vcc-csi";
>>
>>"csi-afvdd-dovdd"
>>
>>This regulator provides power for the camera module's Auto Focus, if
>>available,
>>and Digital i/O parts of the sensor module. Hence the names of the
>>rails.
>>
>>> +};
>>> +
>>> +&reg_aldo2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-pl";
>>> +};
>>> +
>>> +&reg_aldo3 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <2700000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-pll-avcc";
>>> +};
>>> +
>>> +&reg_dc1sw {
>>> +       regulator-name = "vcc-phy";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-3v3";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1000000>;
>>> +       regulator-max-microvolt = <1300000>;
>>> +       regulator-name = "vdd-cpux";
>>> +};
>>> +
>>> +/* DCDC3 is polyphased with DCDC2 */
>>> +
>>> +&reg_dcdc5 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1500000>;
>>> +       regulator-max-microvolt = <1500000>;
>>> +       regulator-name = "vcc-dram";
>>> +};
>>> +
>>> +&reg_dcdc6 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1100000>;
>>> +       regulator-max-microvolt = <1100000>;
>>> +       regulator-name = "vdd-sys";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-hdmi";
>>> +};
>>
>>This should probably be "vcc-hdmi-dsi".
>
> oh yes...
>
>>
>>> +
>>> +&reg_dldo2 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-mipi";
>>> +};
>>
>>On the MIPI-LCD page of the schematics, it says this is connected to
>>VDD18, so it should be 1.8V.
>
> Rename it to "vcc-dsi-1v8"?

The name is OK. I'm just worried about the voltage. We don't want
users frying their display panel. They probably cost more than the
board itself.

For most of these SBCs, they are designed to work with the panels
they provide. Could you reach out to TL Lim and ask about the voltage
used? Or maybe dig it out of the FEX files?

Thanks
ChenYu

>>
>>> +
>>> +&reg_dldo3 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "avdd-csi";
>>> +};
>>
>>2.8V for this one.
>>
>
> Thanks!
>
>>ChenYu
>>
>>> +
>>> +&reg_dldo4 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +&reg_eldo1 {
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <1800000>;
>>> +       regulator-name = "cpvdd";
>>> +};
>>> +
>>> +&reg_eldo3 {
>>> +       regulator-min-microvolt = <1800000>;
>>> +       regulator-max-microvolt = <1800000>;
>>> +       regulator-name = "vdd-1v8-csi";
>>> +};
>>> +
>>> +&reg_fldo1 {
>>> +       regulator-min-microvolt = <1200000>;
>>> +       regulator-max-microvolt = <1200000>;
>>> +       regulator-name = "vcc-1v2-hsic";
>>> +};
>>> +
>>> +&reg_fldo2 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1100000>;
>>> +       regulator-max-microvolt = <1100000>;
>>> +       regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_rtc_ldo {
>>> +       regulator-name = "vcc-rtc";
>>> +};
>>> +
>>>  /* On Exp and Euler connectors */
>>>  &uart0 {
>>>         pinctrl-names = "default";
>>> --
>>> 2.12.2
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 上午11:10:36, Chen-Yu Tsai <wens@csie.org> 写到:
>On Fri, May 19, 2017 at 11:00 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>
>>
>> 于 2017年5月19日 GMT+08:00 上午10:54:21, Chen-Yu Tsai <wens@csie.org> 写到:
>>>Hi,
>>>
>>>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in
>order
>>>to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>>+++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>         };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +       regulator-min-microvolt = <2800000>;
>>>> +       regulator-max-microvolt = <2800000>;
>>>> +       regulator-name = "vcc-csi";
>>>
>>>"csi-afvdd-dovdd"
>>>
>>>This regulator provides power for the camera module's Auto Focus, if
>>>available,
>>>and Digital i/O parts of the sensor module. Hence the names of the
>>>rails.
>>>
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <2700000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-pll-avcc";
>>>> +};
>>>> +
>>>> +&reg_dc1sw {
>>>> +       regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1000000>;
>>>> +       regulator-max-microvolt = <1300000>;
>>>> +       regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1500000>;
>>>> +       regulator-max-microvolt = <1500000>;
>>>> +       regulator-name = "vcc-dram";
>>>> +};
>>>> +
>>>> +&reg_dcdc6 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1100000>;
>>>> +       regulator-max-microvolt = <1100000>;
>>>> +       regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-hdmi";
>>>> +};
>>>
>>>This should probably be "vcc-hdmi-dsi".
>>
>> oh yes...
>>
>>>
>>>> +
>>>> +&reg_dldo2 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-mipi";
>>>> +};
>>>
>>>On the MIPI-LCD page of the schematics, it says this is connected to
>>>VDD18, so it should be 1.8V.
>>
>> Rename it to "vcc-dsi-1v8"?
>
>The name is OK. I'm just worried about the voltage. We don't want
>users frying their display panel. They probably cost more than the
>board itself.

As we renamed dldo1 to vcc-hdmi-dsi, the name may lead to confusion...

So I suppose to rename it.

>
>For most of these SBCs, they are designed to work with the panels
>they provide. Could you reach out to TL Lim and ask about the voltage
>used? Or maybe dig it out of the FEX files?
>
>Thanks
>ChenYu
>
>>>
>>>> +
>>>> +&reg_dldo3 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "avdd-csi";
>>>> +};
>>>
>>>2.8V for this one.
>>>
>>
>> Thanks!
>>
>>>ChenYu
>>>
>>>> +
>>>> +&reg_dldo4 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <1800000>;
>>>> +       regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <1800000>;
>>>> +       regulator-name = "vdd-1v8-csi";
>>>> +};
>>>> +
>>>> +&reg_fldo1 {
>>>> +       regulator-min-microvolt = <1200000>;
>>>> +       regulator-max-microvolt = <1200000>;
>>>> +       regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1100000>;
>>>> +       regulator-max-microvolt = <1100000>;
>>>> +       regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +       regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>         pinctrl-names = "default";
>>>> --
>>>> 2.12.2
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>Groups "linux-sunxi" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>send an email to linux-sunxi+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

? 2017?5?19? GMT+08:00 ??11:10:36, Chen-Yu Tsai <wens@csie.org> ??:
>On Fri, May 19, 2017 at 11:00 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>
>>
>> ? 2017?5?19? GMT+08:00 ??10:54:21, Chen-Yu Tsai <wens@csie.org> ??:
>>>Hi,
>>>
>>>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in
>order
>>>to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>>+++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>         };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +       regulator-min-microvolt = <2800000>;
>>>> +       regulator-max-microvolt = <2800000>;
>>>> +       regulator-name = "vcc-csi";
>>>
>>>"csi-afvdd-dovdd"
>>>
>>>This regulator provides power for the camera module's Auto Focus, if
>>>available,
>>>and Digital i/O parts of the sensor module. Hence the names of the
>>>rails.
>>>
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <2700000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-pll-avcc";
>>>> +};
>>>> +
>>>> +&reg_dc1sw {
>>>> +       regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1000000>;
>>>> +       regulator-max-microvolt = <1300000>;
>>>> +       regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1500000>;
>>>> +       regulator-max-microvolt = <1500000>;
>>>> +       regulator-name = "vcc-dram";
>>>> +};
>>>> +
>>>> +&reg_dcdc6 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1100000>;
>>>> +       regulator-max-microvolt = <1100000>;
>>>> +       regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-hdmi";
>>>> +};
>>>
>>>This should probably be "vcc-hdmi-dsi".
>>
>> oh yes...
>>
>>>
>>>> +
>>>> +&reg_dldo2 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-mipi";
>>>> +};
>>>
>>>On the MIPI-LCD page of the schematics, it says this is connected to
>>>VDD18, so it should be 1.8V.
>>
>> Rename it to "vcc-dsi-1v8"?
>
>The name is OK. I'm just worried about the voltage. We don't want
>users frying their display panel. They probably cost more than the
>board itself.

As we renamed dldo1 to vcc-hdmi-dsi, the name may lead to confusion...

So I suppose to rename it.

>
>For most of these SBCs, they are designed to work with the panels
>they provide. Could you reach out to TL Lim and ask about the voltage
>used? Or maybe dig it out of the FEX files?
>
>Thanks
>ChenYu
>
>>>
>>>> +
>>>> +&reg_dldo3 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "avdd-csi";
>>>> +};
>>>
>>>2.8V for this one.
>>>
>>
>> Thanks!
>>
>>>ChenYu
>>>
>>>> +
>>>> +&reg_dldo4 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <1800000>;
>>>> +       regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <1800000>;
>>>> +       regulator-name = "vdd-1v8-csi";
>>>> +};
>>>> +
>>>> +&reg_fldo1 {
>>>> +       regulator-min-microvolt = <1200000>;
>>>> +       regulator-max-microvolt = <1200000>;
>>>> +       regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1100000>;
>>>> +       regulator-max-microvolt = <1100000>;
>>>> +       regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +       regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>         pinctrl-names = "default";
>>>> --
>>>> 2.12.2
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>Groups "linux-sunxi" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 上午11:10:36, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>On Fri, May 19, 2017 at 11:00 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>wrote:
>>
>>
>> 于 2017年5月19日 GMT+08:00 上午10:54:21, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>>Hi,
>>>
>>>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in
>order
>>>to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>>+++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>         };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +       regulator-min-microvolt = <2800000>;
>>>> +       regulator-max-microvolt = <2800000>;
>>>> +       regulator-name = "vcc-csi";
>>>
>>>"csi-afvdd-dovdd"
>>>
>>>This regulator provides power for the camera module's Auto Focus, if
>>>available,
>>>and Digital i/O parts of the sensor module. Hence the names of the
>>>rails.
>>>
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <2700000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-pll-avcc";
>>>> +};
>>>> +
>>>> +&reg_dc1sw {
>>>> +       regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1000000>;
>>>> +       regulator-max-microvolt = <1300000>;
>>>> +       regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1500000>;
>>>> +       regulator-max-microvolt = <1500000>;
>>>> +       regulator-name = "vcc-dram";
>>>> +};
>>>> +
>>>> +&reg_dcdc6 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1100000>;
>>>> +       regulator-max-microvolt = <1100000>;
>>>> +       regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-hdmi";
>>>> +};
>>>
>>>This should probably be "vcc-hdmi-dsi".
>>
>> oh yes...
>>
>>>
>>>> +
>>>> +&reg_dldo2 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-mipi";
>>>> +};
>>>
>>>On the MIPI-LCD page of the schematics, it says this is connected to
>>>VDD18, so it should be 1.8V.
>>
>> Rename it to "vcc-dsi-1v8"?
>
>The name is OK. I'm just worried about the voltage. We don't want
>users frying their display panel. They probably cost more than the
>board itself.

As we renamed dldo1 to vcc-hdmi-dsi, the name may lead to confusion...

So I suppose to rename it.

>
>For most of these SBCs, they are designed to work with the panels
>they provide. Could you reach out to TL Lim and ask about the voltage
>used? Or maybe dig it out of the FEX files?
>
>Thanks
>ChenYu
>
>>>
>>>> +
>>>> +&reg_dldo3 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "avdd-csi";
>>>> +};
>>>
>>>2.8V for this one.
>>>
>>
>> Thanks!
>>
>>>ChenYu
>>>
>>>> +
>>>> +&reg_dldo4 {
>>>> +       regulator-min-microvolt = <3300000>;
>>>> +       regulator-max-microvolt = <3300000>;
>>>> +       regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <1800000>;
>>>> +       regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +       regulator-min-microvolt = <1800000>;
>>>> +       regulator-max-microvolt = <1800000>;
>>>> +       regulator-name = "vdd-1v8-csi";
>>>> +};
>>>> +
>>>> +&reg_fldo1 {
>>>> +       regulator-min-microvolt = <1200000>;
>>>> +       regulator-max-microvolt = <1200000>;
>>>> +       regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +       regulator-always-on;
>>>> +       regulator-min-microvolt = <1100000>;
>>>> +       regulator-max-microvolt = <1100000>;
>>>> +       regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +       regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>         pinctrl-names = "default";
>>>> --
>>>> 2.12.2
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>Groups "linux-sunxi" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Andre Przywara]

Hi,

On 18/05/17 08:16, Icenowy Zheng wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v6:
> - Rebased on next-20170517.
> 
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>  	};
>  };
>  
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +	regulator-name = "vcc-csi";
> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <2700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +	regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1000000>;
> +	regulator-max-microvolt = <1300000>;
> +	regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1500000>;
> +	regulator-max-microvolt = <1500000>;
> +	regulator-name = "vcc-dram";
> +};

I think I mentioned this before, but the Pine64 has DDR3L DRAM, which is
specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
The reset value is even (wrongly?) configured to 1.24V.

So is there any reason you set the voltage to 1.5V? Is that what the BSP
does? Or did you see any problems with 1.36V?

Cheers,
Andre.

> +&reg_dcdc6 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-hdmi";
> +};
> +
> +&reg_dldo2 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-mipi";
> +};
> +
> +&reg_dldo3 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +	regulator-min-microvolt = <1200000>;
> +	regulator-max-microvolt = <1200000>;
> +	regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +	regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>  	pinctrl-names = "default";
> 

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Andre Przywara]

Hi,

On 18/05/17 08:16, Icenowy Zheng wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v6:
> - Rebased on next-20170517.
> 
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>  	};
>  };
>  
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +	regulator-name = "vcc-csi";
> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <2700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +	regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1000000>;
> +	regulator-max-microvolt = <1300000>;
> +	regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1500000>;
> +	regulator-max-microvolt = <1500000>;
> +	regulator-name = "vcc-dram";
> +};

I think I mentioned this before, but the Pine64 has DDR3L DRAM, which is
specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
The reset value is even (wrongly?) configured to 1.24V.

So is there any reason you set the voltage to 1.5V? Is that what the BSP
does? Or did you see any problems with 1.36V?

Cheers,
Andre.

> +&reg_dcdc6 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-hdmi";
> +};
> +
> +&reg_dldo2 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-mipi";
> +};
> +
> +&reg_dldo3 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +	regulator-min-microvolt = <1200000>;
> +	regulator-max-microvolt = <1200000>;
> +	regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +	regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>  	pinctrl-names = "default";
> 

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Andre Przywara]

Hi,

On 18/05/17 08:16, Icenowy Zheng wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v6:
> - Rebased on next-20170517.
> 
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>  1 file changed, 109 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 36001884ed33..40921bacb39c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -118,6 +118,115 @@
>  	};
>  };
>  
> +#include "axp803.dtsi"
> +
> +&reg_aldo1 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +	regulator-name = "vcc-csi";
> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <2700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dc1sw {
> +	regulator-name = "vcc-phy";
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1000000>;
> +	regulator-max-microvolt = <1300000>;
> +	regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1500000>;
> +	regulator-max-microvolt = <1500000>;
> +	regulator-name = "vcc-dram";
> +};

I think I mentioned this before, but the Pine64 has DDR3L DRAM, which is
specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
The reset value is even (wrongly?) configured to 1.24V.

So is there any reason you set the voltage to 1.5V? Is that what the BSP
does? Or did you see any problems with 1.36V?

Cheers,
Andre.

> +&reg_dcdc6 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_dldo1 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-hdmi";
> +};
> +
> +&reg_dldo2 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-mipi";
> +};
> +
> +&reg_dldo3 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-wifi";
> +};
> +
> +&reg_eldo1 {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "cpvdd";
> +};
> +
> +&reg_eldo3 {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "vdd-1v8-csi";
> +};
> +
> +&reg_fldo1 {
> +	regulator-min-microvolt = <1200000>;
> +	regulator-max-microvolt = <1200000>;
> +	regulator-name = "vcc-1v2-hsic";
> +};
> +
> +&reg_fldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-cpus";
> +};
> +
> +&reg_rtc_ldo {
> +	regulator-name = "vcc-rtc";
> +};
> +
>  /* On Exp and Euler connectors */
>  &uart0 {
>  	pinctrl-names = "default";
> 

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara@arm.com> 写到:
>Hi,
>
>On 18/05/17 08:16, Icenowy Zheng wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>> 
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>  	};
>>  };
>>  
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +	regulator-min-microvolt = <2800000>;
>> +	regulator-max-microvolt = <2800000>;
>> +	regulator-name = "vcc-csi";
>> +};
>> +
>> +&reg_aldo2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <2700000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +	regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1000000>;
>> +	regulator-max-microvolt = <1300000>;
>> +	regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1500000>;
>> +	regulator-max-microvolt = <1500000>;
>> +	regulator-name = "vcc-dram";
>> +};
>
>I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>is
>specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>The reset value is even (wrongly?) configured to 1.24V.
>
>So is there any reason you set the voltage to 1.5V? Is that what the
>BSP
>does? Or did you see any problems with 1.36V?

I just set it based on the schematics.

And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)

>
>Cheers,
>Andre.
>
>> +&reg_dcdc6 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1100000>;
>> +	regulator-max-microvolt = <1100000>;
>> +	regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-hdmi";
>> +};
>> +
>> +&reg_dldo2 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-mipi";
>> +};
>> +
>> +&reg_dldo3 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "avdd-csi";
>> +};
>> +
>> +&reg_dldo4 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <1800000>;
>> +	regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <1800000>;
>> +	regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +	regulator-min-microvolt = <1200000>;
>> +	regulator-max-microvolt = <1200000>;
>> +	regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1100000>;
>> +	regulator-max-microvolt = <1100000>;
>> +	regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +	regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>  	pinctrl-names = "default";
>> 

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

? 2017?5?19? GMT+08:00 ??4:27:21, Andre Przywara <andre.przywara@arm.com> ??:
>Hi,
>
>On 18/05/17 08:16, Icenowy Zheng wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>> 
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>  	};
>>  };
>>  
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +	regulator-min-microvolt = <2800000>;
>> +	regulator-max-microvolt = <2800000>;
>> +	regulator-name = "vcc-csi";
>> +};
>> +
>> +&reg_aldo2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <2700000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +	regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1000000>;
>> +	regulator-max-microvolt = <1300000>;
>> +	regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1500000>;
>> +	regulator-max-microvolt = <1500000>;
>> +	regulator-name = "vcc-dram";
>> +};
>
>I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>is
>specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>The reset value is even (wrongly?) configured to 1.24V.
>
>So is there any reason you set the voltage to 1.5V? Is that what the
>BSP
>does? Or did you see any problems with 1.36V?

I just set it based on the schematics.

And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)

>
>Cheers,
>Andre.
>
>> +&reg_dcdc6 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1100000>;
>> +	regulator-max-microvolt = <1100000>;
>> +	regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-hdmi";
>> +};
>> +
>> +&reg_dldo2 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-mipi";
>> +};
>> +
>> +&reg_dldo3 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "avdd-csi";
>> +};
>> +
>> +&reg_dldo4 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <1800000>;
>> +	regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <1800000>;
>> +	regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +	regulator-min-microvolt = <1200000>;
>> +	regulator-max-microvolt = <1200000>;
>> +	regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1100000>;
>> +	regulator-max-microvolt = <1100000>;
>> +	regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +	regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>  	pinctrl-names = "default";
>> 

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>Hi,
>
>On 18/05/17 08:16, Icenowy Zheng wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>> 
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> Changes in v6:
>> - Rebased on next-20170517.
>> 
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>>  1 file changed, 109 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 36001884ed33..40921bacb39c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -118,6 +118,115 @@
>>  	};
>>  };
>>  
>> +#include "axp803.dtsi"
>> +
>> +&reg_aldo1 {
>> +	regulator-min-microvolt = <2800000>;
>> +	regulator-max-microvolt = <2800000>;
>> +	regulator-name = "vcc-csi";
>> +};
>> +
>> +&reg_aldo2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pl";
>> +};
>> +
>> +&reg_aldo3 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <2700000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +&reg_dc1sw {
>> +	regulator-name = "vcc-phy";
>> +};
>> +
>> +&reg_dcdc1 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-3v3";
>> +};
>> +
>> +&reg_dcdc2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1000000>;
>> +	regulator-max-microvolt = <1300000>;
>> +	regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +&reg_dcdc5 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1500000>;
>> +	regulator-max-microvolt = <1500000>;
>> +	regulator-name = "vcc-dram";
>> +};
>
>I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>is
>specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>The reset value is even (wrongly?) configured to 1.24V.
>
>So is there any reason you set the voltage to 1.5V? Is that what the
>BSP
>does? Or did you see any problems with 1.36V?

I just set it based on the schematics.

And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)

>
>Cheers,
>Andre.
>
>> +&reg_dcdc6 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1100000>;
>> +	regulator-max-microvolt = <1100000>;
>> +	regulator-name = "vdd-sys";
>> +};
>> +
>> +&reg_dldo1 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-hdmi";
>> +};
>> +
>> +&reg_dldo2 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-mipi";
>> +};
>> +
>> +&reg_dldo3 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "avdd-csi";
>> +};
>> +
>> +&reg_dldo4 {
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-wifi";
>> +};
>> +
>> +&reg_eldo1 {
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <1800000>;
>> +	regulator-name = "cpvdd";
>> +};
>> +
>> +&reg_eldo3 {
>> +	regulator-min-microvolt = <1800000>;
>> +	regulator-max-microvolt = <1800000>;
>> +	regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +&reg_fldo1 {
>> +	regulator-min-microvolt = <1200000>;
>> +	regulator-max-microvolt = <1200000>;
>> +	regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +&reg_fldo2 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <1100000>;
>> +	regulator-max-microvolt = <1100000>;
>> +	regulator-name = "vdd-cpus";
>> +};
>> +
>> +&reg_rtc_ldo {
>> +	regulator-name = "vcc-rtc";
>> +};
>> +
>>  /* On Exp and Euler connectors */
>>  &uart0 {
>>  	pinctrl-names = "default";
>> 

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Andre Przywara]

Hi,

On 19/05/17 09:29, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara@arm.com> 写到:
>> Hi,
>>
>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>> to
>>> enable many future functionalities, e.g. Wi-Fi.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> Changes in v6:
>>> - Rebased on next-20170517.
>>>
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>> +++++++++++++++++++++
>>>  1 file changed, 109 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> index 36001884ed33..40921bacb39c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> @@ -118,6 +118,115 @@
>>>  	};
>>>  };
>>>  
>>> +#include "axp803.dtsi"
>>> +
>>> +&reg_aldo1 {
>>> +	regulator-min-microvolt = <2800000>;
>>> +	regulator-max-microvolt = <2800000>;
>>> +	regulator-name = "vcc-csi";
>>> +};
>>> +
>>> +&reg_aldo2 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-pl";
>>> +};
>>> +
>>> +&reg_aldo3 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <2700000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-pll-avcc";
>>> +};

The schematic puts this at a fixed 3.0V, so why the range here? Are we
expected to tune the voltage of the PLLs?

>>> +
>>> +&reg_dc1sw {
>>> +	regulator-name = "vcc-phy";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-3v3";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1000000>;
>>> +	regulator-max-microvolt = <1300000>;
>>> +	regulator-name = "vdd-cpux";
>>> +};
>>> +
>>> +/* DCDC3 is polyphased with DCDC2 */
>>> +
>>> +&reg_dcdc5 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1500000>;
>>> +	regulator-max-microvolt = <1500000>;
>>> +	regulator-name = "vcc-dram";
>>> +};
>>
>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>> is
>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>> The reset value is even (wrongly?) configured to 1.24V.
>>
>> So is there any reason you set the voltage to 1.5V? Is that what the
>> BSP
>> does? Or did you see any problems with 1.36V?
> 
> I just set it based on the schematics.

I wouldn't trust the schematics too much. They are rather generic, see
the Ethernet page, for instance, showing *different* PHYs, not just the
ones used.
For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
the name under the chip is just describing the package.

> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)

Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
more is well within the tolerance ;-)

>>> +&reg_dcdc6 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1100000>;
>>> +	regulator-max-microvolt = <1100000>;
>>> +	regulator-name = "vdd-sys";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-hdmi";
>>> +};
>>> +
>>> +&reg_dldo2 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-mipi";
>>> +};
>>> +
>>> +&reg_dldo3 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "avdd-csi";
>>> +};

If you stick to the schematic, this should be 2.8V.

>>> +
>>> +&reg_dldo4 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +&reg_eldo1 {
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <1800000>;
>>> +	regulator-name = "cpvdd";
>>> +};
>>> +
>>> +&reg_eldo3 {
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <1800000>;
>>> +	regulator-name = "vdd-1v8-csi";
>>> +};

The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

>>> +
>>> +&reg_fldo1 {
>>> +	regulator-min-microvolt = <1200000>;
>>> +	regulator-max-microvolt = <1200000>;
>>> +	regulator-name = "vcc-1v2-hsic";
>>> +};
>>> +
>>> +&reg_fldo2 {
>>> +	regulator-always-on;

Why do we need to turn this on? Upstream firmware does not use the
arisc, so it can stay off.
Also in general I think Linux should not tinker with the management
processor at all.

Cheers,
Andre.

>>> +	regulator-min-microvolt = <1100000>;
>>> +	regulator-max-microvolt = <1100000>;
>>> +	regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_rtc_ldo {
>>> +	regulator-name = "vcc-rtc";
>>> +};
>>> +
>>>  /* On Exp and Euler connectors */
>>>  &uart0 {
>>>  	pinctrl-names = "default";
>>>

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Andre Przywara]

Hi,

On 19/05/17 09:29, Icenowy Zheng wrote:
> 
> 
> ? 2017?5?19? GMT+08:00 ??4:27:21, Andre Przywara <andre.przywara@arm.com> ??:
>> Hi,
>>
>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>> to
>>> enable many future functionalities, e.g. Wi-Fi.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> Changes in v6:
>>> - Rebased on next-20170517.
>>>
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>> +++++++++++++++++++++
>>>  1 file changed, 109 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> index 36001884ed33..40921bacb39c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> @@ -118,6 +118,115 @@
>>>  	};
>>>  };
>>>  
>>> +#include "axp803.dtsi"
>>> +
>>> +&reg_aldo1 {
>>> +	regulator-min-microvolt = <2800000>;
>>> +	regulator-max-microvolt = <2800000>;
>>> +	regulator-name = "vcc-csi";
>>> +};
>>> +
>>> +&reg_aldo2 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-pl";
>>> +};
>>> +
>>> +&reg_aldo3 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <2700000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-pll-avcc";
>>> +};

The schematic puts this at a fixed 3.0V, so why the range here? Are we
expected to tune the voltage of the PLLs?

>>> +
>>> +&reg_dc1sw {
>>> +	regulator-name = "vcc-phy";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-3v3";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1000000>;
>>> +	regulator-max-microvolt = <1300000>;
>>> +	regulator-name = "vdd-cpux";
>>> +};
>>> +
>>> +/* DCDC3 is polyphased with DCDC2 */
>>> +
>>> +&reg_dcdc5 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1500000>;
>>> +	regulator-max-microvolt = <1500000>;
>>> +	regulator-name = "vcc-dram";
>>> +};
>>
>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>> is
>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>> The reset value is even (wrongly?) configured to 1.24V.
>>
>> So is there any reason you set the voltage to 1.5V? Is that what the
>> BSP
>> does? Or did you see any problems with 1.36V?
> 
> I just set it based on the schematics.

I wouldn't trust the schematics too much. They are rather generic, see
the Ethernet page, for instance, showing *different* PHYs, not just the
ones used.
For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
the name under the chip is just describing the package.

> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)

Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
more is well within the tolerance ;-)

>>> +&reg_dcdc6 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1100000>;
>>> +	regulator-max-microvolt = <1100000>;
>>> +	regulator-name = "vdd-sys";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-hdmi";
>>> +};
>>> +
>>> +&reg_dldo2 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-mipi";
>>> +};
>>> +
>>> +&reg_dldo3 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "avdd-csi";
>>> +};

If you stick to the schematic, this should be 2.8V.

>>> +
>>> +&reg_dldo4 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +&reg_eldo1 {
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <1800000>;
>>> +	regulator-name = "cpvdd";
>>> +};
>>> +
>>> +&reg_eldo3 {
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <1800000>;
>>> +	regulator-name = "vdd-1v8-csi";
>>> +};

The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

>>> +
>>> +&reg_fldo1 {
>>> +	regulator-min-microvolt = <1200000>;
>>> +	regulator-max-microvolt = <1200000>;
>>> +	regulator-name = "vcc-1v2-hsic";
>>> +};
>>> +
>>> +&reg_fldo2 {
>>> +	regulator-always-on;

Why do we need to turn this on? Upstream firmware does not use the
arisc, so it can stay off.
Also in general I think Linux should not tinker with the management
processor at all.

Cheers,
Andre.

>>> +	regulator-min-microvolt = <1100000>;
>>> +	regulator-max-microvolt = <1100000>;
>>> +	regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_rtc_ldo {
>>> +	regulator-name = "vcc-rtc";
>>> +};
>>> +
>>>  /* On Exp and Euler connectors */
>>>  &uart0 {
>>>  	pinctrl-names = "default";
>>>

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Andre Przywara]

Hi,

On 19/05/17 09:29, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>> Hi,
>>
>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>> to
>>> enable many future functionalities, e.g. Wi-Fi.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>> Changes in v6:
>>> - Rebased on next-20170517.
>>>
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>> +++++++++++++++++++++
>>>  1 file changed, 109 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> index 36001884ed33..40921bacb39c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> @@ -118,6 +118,115 @@
>>>  	};
>>>  };
>>>  
>>> +#include "axp803.dtsi"
>>> +
>>> +&reg_aldo1 {
>>> +	regulator-min-microvolt = <2800000>;
>>> +	regulator-max-microvolt = <2800000>;
>>> +	regulator-name = "vcc-csi";
>>> +};
>>> +
>>> +&reg_aldo2 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-pl";
>>> +};
>>> +
>>> +&reg_aldo3 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <2700000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-pll-avcc";
>>> +};

The schematic puts this at a fixed 3.0V, so why the range here? Are we
expected to tune the voltage of the PLLs?

>>> +
>>> +&reg_dc1sw {
>>> +	regulator-name = "vcc-phy";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-3v3";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1000000>;
>>> +	regulator-max-microvolt = <1300000>;
>>> +	regulator-name = "vdd-cpux";
>>> +};
>>> +
>>> +/* DCDC3 is polyphased with DCDC2 */
>>> +
>>> +&reg_dcdc5 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1500000>;
>>> +	regulator-max-microvolt = <1500000>;
>>> +	regulator-name = "vcc-dram";
>>> +};
>>
>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>> is
>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>> The reset value is even (wrongly?) configured to 1.24V.
>>
>> So is there any reason you set the voltage to 1.5V? Is that what the
>> BSP
>> does? Or did you see any problems with 1.36V?
> 
> I just set it based on the schematics.

I wouldn't trust the schematics too much. They are rather generic, see
the Ethernet page, for instance, showing *different* PHYs, not just the
ones used.
For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
the name under the chip is just describing the package.

> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)

Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
more is well within the tolerance ;-)

>>> +&reg_dcdc6 {
>>> +	regulator-always-on;
>>> +	regulator-min-microvolt = <1100000>;
>>> +	regulator-max-microvolt = <1100000>;
>>> +	regulator-name = "vdd-sys";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-hdmi";
>>> +};
>>> +
>>> +&reg_dldo2 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-mipi";
>>> +};
>>> +
>>> +&reg_dldo3 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "avdd-csi";
>>> +};

If you stick to the schematic, this should be 2.8V.

>>> +
>>> +&reg_dldo4 {
>>> +	regulator-min-microvolt = <3300000>;
>>> +	regulator-max-microvolt = <3300000>;
>>> +	regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +&reg_eldo1 {
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <1800000>;
>>> +	regulator-name = "cpvdd";
>>> +};
>>> +
>>> +&reg_eldo3 {
>>> +	regulator-min-microvolt = <1800000>;
>>> +	regulator-max-microvolt = <1800000>;
>>> +	regulator-name = "vdd-1v8-csi";
>>> +};

The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

>>> +
>>> +&reg_fldo1 {
>>> +	regulator-min-microvolt = <1200000>;
>>> +	regulator-max-microvolt = <1200000>;
>>> +	regulator-name = "vcc-1v2-hsic";
>>> +};
>>> +
>>> +&reg_fldo2 {
>>> +	regulator-always-on;

Why do we need to turn this on? Upstream firmware does not use the
arisc, so it can stay off.
Also in general I think Linux should not tinker with the management
processor at all.

Cheers,
Andre.

>>> +	regulator-min-microvolt = <1100000>;
>>> +	regulator-max-microvolt = <1100000>;
>>> +	regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_rtc_ldo {
>>> +	regulator-name = "vcc-rtc";
>>> +};
>>> +
>>>  /* On Exp and Euler connectors */
>>>  &uart0 {
>>>  	pinctrl-names = "default";
>>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 4:55 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 19/05/17 09:29, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara@arm.com> 写到:
>>> Hi,
>>>
>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>> to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>> +++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>     };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +   regulator-min-microvolt = <2800000>;
>>>> +   regulator-max-microvolt = <2800000>;
>>>> +   regulator-name = "vcc-csi";
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <2700000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pll-avcc";
>>>> +};
>
> The schematic puts this at a fixed 3.0V, so why the range here? Are we
> expected to tune the voltage of the PLLs?

Normally these would describe the operating limits. We did this
in the past for most boards. I'm fine with fixing it to 3.0V
though.

>
>>>> +
>>>> +&reg_dc1sw {
>>>> +   regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1000000>;
>>>> +   regulator-max-microvolt = <1300000>;
>>>> +   regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1500000>;
>>>> +   regulator-max-microvolt = <1500000>;
>>>> +   regulator-name = "vcc-dram";
>>>> +};
>>>
>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>>> is
>>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>>> The reset value is even (wrongly?) configured to 1.24V.
>>>
>>> So is there any reason you set the voltage to 1.5V? Is that what the
>>> BSP
>>> does? Or did you see any problems with 1.36V?
>>
>> I just set it based on the schematics.
>
> I wouldn't trust the schematics too much. They are rather generic, see
> the Ethernet page, for instance, showing *different* PHYs, not just the
> ones used.
> For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
> the name under the chip is just describing the package.
>
>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)
>
> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
> more is well within the tolerance ;-)
>
>>>> +&reg_dcdc6 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-hdmi";
>>>> +};
>>>> +
>>>> +&reg_dldo2 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-mipi";
>>>> +};
>>>> +
>>>> +&reg_dldo3 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "avdd-csi";
>>>> +};
>
> If you stick to the schematic, this should be 2.8V.

Agreed. But...

>>>> +
>>>> +&reg_dldo4 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "vdd-1v8-csi";
>>>> +};
>
> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

This and avdd-csi really depends on the camera module used.
Maybe this should be left to an overlay.

>
>>>> +
>>>> +&reg_fldo1 {
>>>> +   regulator-min-microvolt = <1200000>;
>>>> +   regulator-max-microvolt = <1200000>;
>>>> +   regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +   regulator-always-on;
>
> Why do we need to turn this on? Upstream firmware does not use the
> arisc, so it can stay off.
> Also in general I think Linux should not tinker with the management
> processor at all.

I'm not sure, but I think at least one SoC had failed to work without
this powered on. If that is the case with the A64, then please leave
a comment saying so. Otherwise let it stay off.

ChenYu

> Cheers,
> Andre.
>
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +   regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>     pinctrl-names = "default";
>>>>

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 4:55 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 19/05/17 09:29, Icenowy Zheng wrote:
>>
>>
>> ? 2017?5?19? GMT+08:00 ??4:27:21, Andre Przywara <andre.przywara@arm.com> ??:
>>> Hi,
>>>
>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>> to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>> +++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>     };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +   regulator-min-microvolt = <2800000>;
>>>> +   regulator-max-microvolt = <2800000>;
>>>> +   regulator-name = "vcc-csi";
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <2700000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pll-avcc";
>>>> +};
>
> The schematic puts this at a fixed 3.0V, so why the range here? Are we
> expected to tune the voltage of the PLLs?

Normally these would describe the operating limits. We did this
in the past for most boards. I'm fine with fixing it to 3.0V
though.

>
>>>> +
>>>> +&reg_dc1sw {
>>>> +   regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1000000>;
>>>> +   regulator-max-microvolt = <1300000>;
>>>> +   regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1500000>;
>>>> +   regulator-max-microvolt = <1500000>;
>>>> +   regulator-name = "vcc-dram";
>>>> +};
>>>
>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>>> is
>>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>>> The reset value is even (wrongly?) configured to 1.24V.
>>>
>>> So is there any reason you set the voltage to 1.5V? Is that what the
>>> BSP
>>> does? Or did you see any problems with 1.36V?
>>
>> I just set it based on the schematics.
>
> I wouldn't trust the schematics too much. They are rather generic, see
> the Ethernet page, for instance, showing *different* PHYs, not just the
> ones used.
> For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
> the name under the chip is just describing the package.
>
>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)
>
> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
> more is well within the tolerance ;-)
>
>>>> +&reg_dcdc6 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-hdmi";
>>>> +};
>>>> +
>>>> +&reg_dldo2 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-mipi";
>>>> +};
>>>> +
>>>> +&reg_dldo3 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "avdd-csi";
>>>> +};
>
> If you stick to the schematic, this should be 2.8V.

Agreed. But...

>>>> +
>>>> +&reg_dldo4 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "vdd-1v8-csi";
>>>> +};
>
> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

This and avdd-csi really depends on the camera module used.
Maybe this should be left to an overlay.

>
>>>> +
>>>> +&reg_fldo1 {
>>>> +   regulator-min-microvolt = <1200000>;
>>>> +   regulator-max-microvolt = <1200000>;
>>>> +   regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +   regulator-always-on;
>
> Why do we need to turn this on? Upstream firmware does not use the
> arisc, so it can stay off.
> Also in general I think Linux should not tinker with the management
> processor at all.

I'm not sure, but I think at least one SoC had failed to work without
this powered on. If that is the case with the A64, then please leave
a comment saying so. Otherwise let it stay off.

ChenYu

> Cheers,
> Andre.
>
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +   regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>     pinctrl-names = "default";
>>>>

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Chen-Yu Tsai]

On Fri, May 19, 2017 at 4:55 PM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi,
>
> On 19/05/17 09:29, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>> Hi,
>>>
>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>> to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>> +++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>     };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +   regulator-min-microvolt = <2800000>;
>>>> +   regulator-max-microvolt = <2800000>;
>>>> +   regulator-name = "vcc-csi";
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <2700000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pll-avcc";
>>>> +};
>
> The schematic puts this at a fixed 3.0V, so why the range here? Are we
> expected to tune the voltage of the PLLs?

Normally these would describe the operating limits. We did this
in the past for most boards. I'm fine with fixing it to 3.0V
though.

>
>>>> +
>>>> +&reg_dc1sw {
>>>> +   regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1000000>;
>>>> +   regulator-max-microvolt = <1300000>;
>>>> +   regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1500000>;
>>>> +   regulator-max-microvolt = <1500000>;
>>>> +   regulator-name = "vcc-dram";
>>>> +};
>>>
>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>>> is
>>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>>> The reset value is even (wrongly?) configured to 1.24V.
>>>
>>> So is there any reason you set the voltage to 1.5V? Is that what the
>>> BSP
>>> does? Or did you see any problems with 1.36V?
>>
>> I just set it based on the schematics.
>
> I wouldn't trust the schematics too much. They are rather generic, see
> the Ethernet page, for instance, showing *different* PHYs, not just the
> ones used.
> For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
> the name under the chip is just describing the package.
>
>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)
>
> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
> more is well within the tolerance ;-)
>
>>>> +&reg_dcdc6 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-hdmi";
>>>> +};
>>>> +
>>>> +&reg_dldo2 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-mipi";
>>>> +};
>>>> +
>>>> +&reg_dldo3 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "avdd-csi";
>>>> +};
>
> If you stick to the schematic, this should be 2.8V.

Agreed. But...

>>>> +
>>>> +&reg_dldo4 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "vdd-1v8-csi";
>>>> +};
>
> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

This and avdd-csi really depends on the camera module used.
Maybe this should be left to an overlay.

>
>>>> +
>>>> +&reg_fldo1 {
>>>> +   regulator-min-microvolt = <1200000>;
>>>> +   regulator-max-microvolt = <1200000>;
>>>> +   regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +   regulator-always-on;
>
> Why do we need to turn this on? Upstream firmware does not use the
> arisc, so it can stay off.
> Also in general I think Linux should not tinker with the management
> processor at all.

I'm not sure, but I think at least one SoC had failed to work without
this powered on. If that is the case with the A64, then please leave
a comment saying so. Otherwise let it stay off.

ChenYu

> Cheers,
> Andre.
>
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +   regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>     pinctrl-names = "default";
>>>>

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年7月18日 GMT+08:00 上午10:58:52, Chen-Yu Tsai <wens@csie.org> 写到:
>On Fri, May 19, 2017 at 4:55 PM, Andre Przywara
><andre.przywara@arm.com> wrote:
>> Hi,
>>
>> On 19/05/17 09:29, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara
><andre.przywara@arm.com> 写到:
>>>> Hi,
>>>>
>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>> Add support of AXP803 regulators in the Pine64 device tree, in
>order
>>>> to
>>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>> ---
>>>>> Changes in v6:
>>>>> - Rebased on next-20170517.
>>>>>
>>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>>> +++++++++++++++++++++
>>>>>  1 file changed, 109 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> index 36001884ed33..40921bacb39c 100644
>>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> @@ -118,6 +118,115 @@
>>>>>     };
>>>>>  };
>>>>>
>>>>> +#include "axp803.dtsi"
>>>>> +
>>>>> +&reg_aldo1 {
>>>>> +   regulator-min-microvolt = <2800000>;
>>>>> +   regulator-max-microvolt = <2800000>;
>>>>> +   regulator-name = "vcc-csi";
>>>>> +};
>>>>> +
>>>>> +&reg_aldo2 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-pl";
>>>>> +};
>>>>> +
>>>>> +&reg_aldo3 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <2700000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-pll-avcc";
>>>>> +};
>>
>> The schematic puts this at a fixed 3.0V, so why the range here? Are
>we
>> expected to tune the voltage of the PLLs?
>
>Normally these would describe the operating limits. We did this
>in the past for most boards. I'm fine with fixing it to 3.0V
>though.
>
>>
>>>>> +
>>>>> +&reg_dc1sw {
>>>>> +   regulator-name = "vcc-phy";
>>>>> +};
>>>>> +
>>>>> +&reg_dcdc1 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-3v3";
>>>>> +};
>>>>> +
>>>>> +&reg_dcdc2 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1000000>;
>>>>> +   regulator-max-microvolt = <1300000>;
>>>>> +   regulator-name = "vdd-cpux";
>>>>> +};
>>>>> +
>>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>>> +
>>>>> +&reg_dcdc5 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1500000>;
>>>>> +   regulator-max-microvolt = <1500000>;
>>>>> +   regulator-name = "vcc-dram";
>>>>> +};
>>>>
>>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM,
>which
>>>> is
>>>> specified to run at 1.35V (1.36V with the 20mV granularity of the
>AXP).
>>>> The reset value is even (wrongly?) configured to 1.24V.
>>>>
>>>> So is there any reason you set the voltage to 1.5V? Is that what
>the
>>>> BSP
>>>> does? Or did you see any problems with 1.36V?
>>>
>>> I just set it based on the schematics.
>>
>> I wouldn't trust the schematics too much. They are rather generic,
>see
>> the Ethernet page, for instance, showing *different* PHYs, not just
>the
>> ones used.
>> For the DRAM the Pine64 schematic does not even tell the DRAM chip
>used,
>> the name under the chip is just describing the package.
>>
>>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem
>whether to use 1.34v or 1.36v ;-)
>>
>> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
>> more is well within the tolerance ;-)
>>
>>>>> +&reg_dcdc6 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1100000>;
>>>>> +   regulator-max-microvolt = <1100000>;
>>>>> +   regulator-name = "vdd-sys";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo1 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-hdmi";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo2 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-mipi";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo3 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "avdd-csi";
>>>>> +};
>>
>> If you stick to the schematic, this should be 2.8V.
>
>Agreed. But...
>
>>>>> +
>>>>> +&reg_dldo4 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-wifi";
>>>>> +};
>>>>> +
>>>>> +&reg_eldo1 {
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <1800000>;
>>>>> +   regulator-name = "cpvdd";
>>>>> +};
>>>>> +
>>>>> +&reg_eldo3 {
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <1800000>;
>>>>> +   regulator-name = "vdd-1v8-csi";
>>>>> +};
>>
>> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?
>
>This and avdd-csi really depends on the camera module used.
>Maybe this should be left to an overlay.

Agree.

>
>>
>>>>> +
>>>>> +&reg_fldo1 {
>>>>> +   regulator-min-microvolt = <1200000>;
>>>>> +   regulator-max-microvolt = <1200000>;
>>>>> +   regulator-name = "vcc-1v2-hsic";
>>>>> +};
>>>>> +
>>>>> +&reg_fldo2 {
>>>>> +   regulator-always-on;
>>
>> Why do we need to turn this on? Upstream firmware does not use the
>> arisc, so it can stay off.
>> Also in general I think Linux should not tinker with the management
>> processor at all.
>
>I'm not sure, but I think at least one SoC had failed to work without
>this powered on. If that is the case with the A64, then please leave
>a comment saying so. Otherwise let it stay off.

Yes it failed to work, and this seems to be common among SoCs
with CPUs power domain.

>
>ChenYu
>
>> Cheers,
>> Andre.
>>
>>>>> +   regulator-min-microvolt = <1100000>;
>>>>> +   regulator-max-microvolt = <1100000>;
>>>>> +   regulator-name = "vdd-cpus";
>>>>> +};
>>>>> +
>>>>> +&reg_rtc_ldo {
>>>>> +   regulator-name = "vcc-rtc";
>>>>> +};
>>>>> +
>>>>>  /* On Exp and Euler connectors */
>>>>>  &uart0 {
>>>>>     pinctrl-names = "default";
>>>>>

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

? 2017?7?18? GMT+08:00 ??10:58:52, Chen-Yu Tsai <wens@csie.org> ??:
>On Fri, May 19, 2017 at 4:55 PM, Andre Przywara
><andre.przywara@arm.com> wrote:
>> Hi,
>>
>> On 19/05/17 09:29, Icenowy Zheng wrote:
>>>
>>>
>>> ? 2017?5?19? GMT+08:00 ??4:27:21, Andre Przywara
><andre.przywara@arm.com> ??:
>>>> Hi,
>>>>
>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>> Add support of AXP803 regulators in the Pine64 device tree, in
>order
>>>> to
>>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>> ---
>>>>> Changes in v6:
>>>>> - Rebased on next-20170517.
>>>>>
>>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>>> +++++++++++++++++++++
>>>>>  1 file changed, 109 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> index 36001884ed33..40921bacb39c 100644
>>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> @@ -118,6 +118,115 @@
>>>>>     };
>>>>>  };
>>>>>
>>>>> +#include "axp803.dtsi"
>>>>> +
>>>>> +&reg_aldo1 {
>>>>> +   regulator-min-microvolt = <2800000>;
>>>>> +   regulator-max-microvolt = <2800000>;
>>>>> +   regulator-name = "vcc-csi";
>>>>> +};
>>>>> +
>>>>> +&reg_aldo2 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-pl";
>>>>> +};
>>>>> +
>>>>> +&reg_aldo3 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <2700000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-pll-avcc";
>>>>> +};
>>
>> The schematic puts this at a fixed 3.0V, so why the range here? Are
>we
>> expected to tune the voltage of the PLLs?
>
>Normally these would describe the operating limits. We did this
>in the past for most boards. I'm fine with fixing it to 3.0V
>though.
>
>>
>>>>> +
>>>>> +&reg_dc1sw {
>>>>> +   regulator-name = "vcc-phy";
>>>>> +};
>>>>> +
>>>>> +&reg_dcdc1 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-3v3";
>>>>> +};
>>>>> +
>>>>> +&reg_dcdc2 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1000000>;
>>>>> +   regulator-max-microvolt = <1300000>;
>>>>> +   regulator-name = "vdd-cpux";
>>>>> +};
>>>>> +
>>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>>> +
>>>>> +&reg_dcdc5 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1500000>;
>>>>> +   regulator-max-microvolt = <1500000>;
>>>>> +   regulator-name = "vcc-dram";
>>>>> +};
>>>>
>>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM,
>which
>>>> is
>>>> specified to run at 1.35V (1.36V with the 20mV granularity of the
>AXP).
>>>> The reset value is even (wrongly?) configured to 1.24V.
>>>>
>>>> So is there any reason you set the voltage to 1.5V? Is that what
>the
>>>> BSP
>>>> does? Or did you see any problems with 1.36V?
>>>
>>> I just set it based on the schematics.
>>
>> I wouldn't trust the schematics too much. They are rather generic,
>see
>> the Ethernet page, for instance, showing *different* PHYs, not just
>the
>> ones used.
>> For the DRAM the Pine64 schematic does not even tell the DRAM chip
>used,
>> the name under the chip is just describing the package.
>>
>>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem
>whether to use 1.34v or 1.36v ;-)
>>
>> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
>> more is well within the tolerance ;-)
>>
>>>>> +&reg_dcdc6 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1100000>;
>>>>> +   regulator-max-microvolt = <1100000>;
>>>>> +   regulator-name = "vdd-sys";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo1 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-hdmi";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo2 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-mipi";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo3 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "avdd-csi";
>>>>> +};
>>
>> If you stick to the schematic, this should be 2.8V.
>
>Agreed. But...
>
>>>>> +
>>>>> +&reg_dldo4 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-wifi";
>>>>> +};
>>>>> +
>>>>> +&reg_eldo1 {
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <1800000>;
>>>>> +   regulator-name = "cpvdd";
>>>>> +};
>>>>> +
>>>>> +&reg_eldo3 {
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <1800000>;
>>>>> +   regulator-name = "vdd-1v8-csi";
>>>>> +};
>>
>> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?
>
>This and avdd-csi really depends on the camera module used.
>Maybe this should be left to an overlay.

Agree.

>
>>
>>>>> +
>>>>> +&reg_fldo1 {
>>>>> +   regulator-min-microvolt = <1200000>;
>>>>> +   regulator-max-microvolt = <1200000>;
>>>>> +   regulator-name = "vcc-1v2-hsic";
>>>>> +};
>>>>> +
>>>>> +&reg_fldo2 {
>>>>> +   regulator-always-on;
>>
>> Why do we need to turn this on? Upstream firmware does not use the
>> arisc, so it can stay off.
>> Also in general I think Linux should not tinker with the management
>> processor at all.
>
>I'm not sure, but I think at least one SoC had failed to work without
>this powered on. If that is the case with the A64, then please leave
>a comment saying so. Otherwise let it stay off.

Yes it failed to work, and this seems to be common among SoCs
with CPUs power domain.

>
>ChenYu
>
>> Cheers,
>> Andre.
>>
>>>>> +   regulator-min-microvolt = <1100000>;
>>>>> +   regulator-max-microvolt = <1100000>;
>>>>> +   regulator-name = "vdd-cpus";
>>>>> +};
>>>>> +
>>>>> +&reg_rtc_ldo {
>>>>> +   regulator-name = "vcc-rtc";
>>>>> +};
>>>>> +
>>>>>  /* On Exp and Euler connectors */
>>>>>  &uart0 {
>>>>>     pinctrl-names = "default";
>>>>>

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Icenowy Zheng]

于 2017年7月18日 GMT+08:00 上午10:58:52, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>On Fri, May 19, 2017 at 4:55 PM, Andre Przywara
><andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
>> Hi,
>>
>> On 19/05/17 09:29, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara
><andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>> Hi,
>>>>
>>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>>> Add support of AXP803 regulators in the Pine64 device tree, in
>order
>>>> to
>>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>>> ---
>>>>> Changes in v6:
>>>>> - Rebased on next-20170517.
>>>>>
>>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>>> +++++++++++++++++++++
>>>>>  1 file changed, 109 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> index 36001884ed33..40921bacb39c 100644
>>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>>> @@ -118,6 +118,115 @@
>>>>>     };
>>>>>  };
>>>>>
>>>>> +#include "axp803.dtsi"
>>>>> +
>>>>> +&reg_aldo1 {
>>>>> +   regulator-min-microvolt = <2800000>;
>>>>> +   regulator-max-microvolt = <2800000>;
>>>>> +   regulator-name = "vcc-csi";
>>>>> +};
>>>>> +
>>>>> +&reg_aldo2 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-pl";
>>>>> +};
>>>>> +
>>>>> +&reg_aldo3 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <2700000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-pll-avcc";
>>>>> +};
>>
>> The schematic puts this at a fixed 3.0V, so why the range here? Are
>we
>> expected to tune the voltage of the PLLs?
>
>Normally these would describe the operating limits. We did this
>in the past for most boards. I'm fine with fixing it to 3.0V
>though.
>
>>
>>>>> +
>>>>> +&reg_dc1sw {
>>>>> +   regulator-name = "vcc-phy";
>>>>> +};
>>>>> +
>>>>> +&reg_dcdc1 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-3v3";
>>>>> +};
>>>>> +
>>>>> +&reg_dcdc2 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1000000>;
>>>>> +   regulator-max-microvolt = <1300000>;
>>>>> +   regulator-name = "vdd-cpux";
>>>>> +};
>>>>> +
>>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>>> +
>>>>> +&reg_dcdc5 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1500000>;
>>>>> +   regulator-max-microvolt = <1500000>;
>>>>> +   regulator-name = "vcc-dram";
>>>>> +};
>>>>
>>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM,
>which
>>>> is
>>>> specified to run at 1.35V (1.36V with the 20mV granularity of the
>AXP).
>>>> The reset value is even (wrongly?) configured to 1.24V.
>>>>
>>>> So is there any reason you set the voltage to 1.5V? Is that what
>the
>>>> BSP
>>>> does? Or did you see any problems with 1.36V?
>>>
>>> I just set it based on the schematics.
>>
>> I wouldn't trust the schematics too much. They are rather generic,
>see
>> the Ethernet page, for instance, showing *different* PHYs, not just
>the
>> ones used.
>> For the DRAM the Pine64 schematic does not even tell the DRAM chip
>used,
>> the name under the chip is just describing the package.
>>
>>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem
>whether to use 1.34v or 1.36v ;-)
>>
>> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
>> more is well within the tolerance ;-)
>>
>>>>> +&reg_dcdc6 {
>>>>> +   regulator-always-on;
>>>>> +   regulator-min-microvolt = <1100000>;
>>>>> +   regulator-max-microvolt = <1100000>;
>>>>> +   regulator-name = "vdd-sys";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo1 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-hdmi";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo2 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-mipi";
>>>>> +};
>>>>> +
>>>>> +&reg_dldo3 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "avdd-csi";
>>>>> +};
>>
>> If you stick to the schematic, this should be 2.8V.
>
>Agreed. But...
>
>>>>> +
>>>>> +&reg_dldo4 {
>>>>> +   regulator-min-microvolt = <3300000>;
>>>>> +   regulator-max-microvolt = <3300000>;
>>>>> +   regulator-name = "vcc-wifi";
>>>>> +};
>>>>> +
>>>>> +&reg_eldo1 {
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <1800000>;
>>>>> +   regulator-name = "cpvdd";
>>>>> +};
>>>>> +
>>>>> +&reg_eldo3 {
>>>>> +   regulator-min-microvolt = <1800000>;
>>>>> +   regulator-max-microvolt = <1800000>;
>>>>> +   regulator-name = "vdd-1v8-csi";
>>>>> +};
>>
>> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?
>
>This and avdd-csi really depends on the camera module used.
>Maybe this should be left to an overlay.

Agree.

>
>>
>>>>> +
>>>>> +&reg_fldo1 {
>>>>> +   regulator-min-microvolt = <1200000>;
>>>>> +   regulator-max-microvolt = <1200000>;
>>>>> +   regulator-name = "vcc-1v2-hsic";
>>>>> +};
>>>>> +
>>>>> +&reg_fldo2 {
>>>>> +   regulator-always-on;
>>
>> Why do we need to turn this on? Upstream firmware does not use the
>> arisc, so it can stay off.
>> Also in general I think Linux should not tinker with the management
>> processor at all.
>
>I'm not sure, but I think at least one SoC had failed to work without
>this powered on. If that is the case with the A64, then please leave
>a comment saying so. Otherwise let it stay off.

Yes it failed to work, and this seems to be common among SoCs
with CPUs power domain.

>
>ChenYu
>
>> Cheers,
>> Andre.
>>
>>>>> +   regulator-min-microvolt = <1100000>;
>>>>> +   regulator-max-microvolt = <1100000>;
>>>>> +   regulator-name = "vdd-cpus";
>>>>> +};
>>>>> +
>>>>> +&reg_rtc_ldo {
>>>>> +   regulator-name = "vcc-rtc";
>>>>> +};
>>>>> +
>>>>>  /* On Exp and Euler connectors */
>>>>>  &uart0 {
>>>>>     pinctrl-names = "default";
>>>>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

On Fri, May 19, 2017 at 04:29:01PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara@arm.com> 写到:
> >Hi,
> >
> >On 18/05/17 08:16, Icenowy Zheng wrote:
> >> Add support of AXP803 regulators in the Pine64 device tree, in order
> >to
> >> enable many future functionalities, e.g. Wi-Fi.
> >> 
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> ---
> >> Changes in v6:
> >> - Rebased on next-20170517.
> >> 
> >>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
> >+++++++++++++++++++++
> >>  1 file changed, 109 insertions(+)
> >> 
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> index 36001884ed33..40921bacb39c 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> @@ -118,6 +118,115 @@
> >>  	};
> >>  };
> >>  
> >> +#include "axp803.dtsi"
> >> +
> >> +&reg_aldo1 {
> >> +	regulator-min-microvolt = <2800000>;
> >> +	regulator-max-microvolt = <2800000>;
> >> +	regulator-name = "vcc-csi";
> >> +};
> >> +
> >> +&reg_aldo2 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1800000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-pl";
> >> +};
> >> +
> >> +&reg_aldo3 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <2700000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-pll-avcc";
> >> +};
> >> +
> >> +&reg_dc1sw {
> >> +	regulator-name = "vcc-phy";
> >> +};
> >> +
> >> +&reg_dcdc1 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <3300000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-3v3";
> >> +};
> >> +
> >> +&reg_dcdc2 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1000000>;
> >> +	regulator-max-microvolt = <1300000>;
> >> +	regulator-name = "vdd-cpux";
> >> +};
> >> +
> >> +/* DCDC3 is polyphased with DCDC2 */
> >> +
> >> +&reg_dcdc5 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1500000>;
> >> +	regulator-max-microvolt = <1500000>;
> >> +	regulator-name = "vcc-dram";
> >> +};
> >
> >I think I mentioned this before, but the Pine64 has DDR3L DRAM,
> >which is specified to run at 1.35V (1.36V with the 20mV granularity
> >of the AXP).  The reset value is even (wrongly?) configured to
> >1.24V.
> >
> >So is there any reason you set the voltage to 1.5V? Is that what
> >the BSP does? Or did you see any problems with 1.36V?
> 
> I just set it based on the schematics.
> 
> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem
> whether to use 1.34v or 1.36v ;-)

1.36V seems safer.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Maxime Ripard]

On Fri, May 19, 2017 at 04:29:01PM +0800, Icenowy Zheng wrote:
> 
> 
> ? 2017?5?19? GMT+08:00 ??4:27:21, Andre Przywara <andre.przywara@arm.com> ??:
> >Hi,
> >
> >On 18/05/17 08:16, Icenowy Zheng wrote:
> >> Add support of AXP803 regulators in the Pine64 device tree, in order
> >to
> >> enable many future functionalities, e.g. Wi-Fi.
> >> 
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> ---
> >> Changes in v6:
> >> - Rebased on next-20170517.
> >> 
> >>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
> >+++++++++++++++++++++
> >>  1 file changed, 109 insertions(+)
> >> 
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> index 36001884ed33..40921bacb39c 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> @@ -118,6 +118,115 @@
> >>  	};
> >>  };
> >>  
> >> +#include "axp803.dtsi"
> >> +
> >> +&reg_aldo1 {
> >> +	regulator-min-microvolt = <2800000>;
> >> +	regulator-max-microvolt = <2800000>;
> >> +	regulator-name = "vcc-csi";
> >> +};
> >> +
> >> +&reg_aldo2 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1800000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-pl";
> >> +};
> >> +
> >> +&reg_aldo3 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <2700000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-pll-avcc";
> >> +};
> >> +
> >> +&reg_dc1sw {
> >> +	regulator-name = "vcc-phy";
> >> +};
> >> +
> >> +&reg_dcdc1 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <3300000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-3v3";
> >> +};
> >> +
> >> +&reg_dcdc2 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1000000>;
> >> +	regulator-max-microvolt = <1300000>;
> >> +	regulator-name = "vdd-cpux";
> >> +};
> >> +
> >> +/* DCDC3 is polyphased with DCDC2 */
> >> +
> >> +&reg_dcdc5 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1500000>;
> >> +	regulator-max-microvolt = <1500000>;
> >> +	regulator-name = "vcc-dram";
> >> +};
> >
> >I think I mentioned this before, but the Pine64 has DDR3L DRAM,
> >which is specified to run at 1.35V (1.36V with the 20mV granularity
> >of the AXP).  The reset value is even (wrongly?) configured to
> >1.24V.
> >
> >So is there any reason you set the voltage to 1.5V? Is that what
> >the BSP does? Or did you see any problems with 1.36V?
> 
> I just set it based on the schematics.
> 
> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem
> whether to use 1.34v or 1.36v ;-)

1.36V seems safer.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170519/23b2a80b/attachment.sig>

Re: [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]

On Fri, May 19, 2017 at 04:29:01PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >Hi,
> >
> >On 18/05/17 08:16, Icenowy Zheng wrote:
> >> Add support of AXP803 regulators in the Pine64 device tree, in order
> >to
> >> enable many future functionalities, e.g. Wi-Fi.
> >> 
> >> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> >> ---
> >> Changes in v6:
> >> - Rebased on next-20170517.
> >> 
> >>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
> >+++++++++++++++++++++
> >>  1 file changed, 109 insertions(+)
> >> 
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> index 36001884ed33..40921bacb39c 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> @@ -118,6 +118,115 @@
> >>  	};
> >>  };
> >>  
> >> +#include "axp803.dtsi"
> >> +
> >> +&reg_aldo1 {
> >> +	regulator-min-microvolt = <2800000>;
> >> +	regulator-max-microvolt = <2800000>;
> >> +	regulator-name = "vcc-csi";
> >> +};
> >> +
> >> +&reg_aldo2 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1800000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-pl";
> >> +};
> >> +
> >> +&reg_aldo3 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <2700000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-pll-avcc";
> >> +};
> >> +
> >> +&reg_dc1sw {
> >> +	regulator-name = "vcc-phy";
> >> +};
> >> +
> >> +&reg_dcdc1 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <3300000>;
> >> +	regulator-max-microvolt = <3300000>;
> >> +	regulator-name = "vcc-3v3";
> >> +};
> >> +
> >> +&reg_dcdc2 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1000000>;
> >> +	regulator-max-microvolt = <1300000>;
> >> +	regulator-name = "vdd-cpux";
> >> +};
> >> +
> >> +/* DCDC3 is polyphased with DCDC2 */
> >> +
> >> +&reg_dcdc5 {
> >> +	regulator-always-on;
> >> +	regulator-min-microvolt = <1500000>;
> >> +	regulator-max-microvolt = <1500000>;
> >> +	regulator-name = "vcc-dram";
> >> +};
> >
> >I think I mentioned this before, but the Pine64 has DDR3L DRAM,
> >which is specified to run at 1.35V (1.36V with the 20mV granularity
> >of the AXP).  The reset value is even (wrongly?) configured to
> >1.24V.
> >
> >So is there any reason you set the voltage to 1.5V? Is that what
> >the BSP does? Or did you see any problems with 1.36V?
> 
> I just set it based on the schematics.
> 
> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem
> whether to use 1.34v or 1.36v ;-)

1.36V seems safer.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).

Add device node for it.

Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 40921bacb39c..6e43e2c07025 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -68,6 +68,11 @@
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
 	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+	};
 };
 
 &ehci0 {
@@ -99,6 +104,17 @@
 	status = "okay";
 };
 
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dldo4>;
+	vqmmc-supply = <&reg_eldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	non-removable;
+	bus-width = <4>;
+	status = "okay";
+};
+
 &ohci0 {
 	status = "okay";
 };
-- 
2.12.2

[PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).

Add device node for it.

Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 40921bacb39c..6e43e2c07025 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -68,6 +68,11 @@
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
 	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+	};
 };
 
 &ehci0 {
@@ -99,6 +104,17 @@
 	status = "okay";
 };
 
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dldo4>;
+	vqmmc-supply = <&reg_eldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	non-removable;
+	bus-width = <4>;
+	status = "okay";
+};
+
 &ohci0 {
 	status = "okay";
 };
-- 
2.12.2

[PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).

Add device node for it.

Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 40921bacb39c..6e43e2c07025 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -68,6 +68,11 @@
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
 	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+	};
 };
 
 &ehci0 {
@@ -99,6 +104,17 @@
 	status = "okay";
 };
 
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dldo4>;
+	vqmmc-supply = <&reg_eldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	non-removable;
+	bus-width = <4>;
+	status = "okay";
+};
+
 &ohci0 {
 	status = "okay";
 };
-- 
2.12.2

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Chen-Yu Tsai]

Hi,

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
> one provides I/O voltage).
>
> Add device node for it.
>
> Although the Wi-Fi module is an external module which should be inserted
> to a header, according to my personal talk with TL Lim, he does not want
> this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
> other GPIO headers).

The patch looks OK, but given the module is removable, I think it should be
an overlay. The overlay would enable WiFi + Bluetooth, and all the
peripherals needed to connect them.

That way, if the module is not installed, we avoid confusing the user with
unused peripherals, and avoid having live voltage on an unoccupied header.

ChenYu

[linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Chen-Yu Tsai]

Hi,

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
> one provides I/O voltage).
>
> Add device node for it.
>
> Although the Wi-Fi module is an external module which should be inserted
> to a header, according to my personal talk with TL Lim, he does not want
> this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
> other GPIO headers).

The patch looks OK, but given the module is removable, I think it should be
an overlay. The overlay would enable WiFi + Bluetooth, and all the
peripherals needed to connect them.

That way, if the module is not installed, we avoid confusing the user with
unused peripherals, and avoid having live voltage on an unoccupied header.

ChenYu

Re: [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Chen-Yu Tsai]

Hi,

On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
> one provides I/O voltage).
>
> Add device node for it.
>
> Although the Wi-Fi module is an external module which should be inserted
> to a header, according to my personal talk with TL Lim, he does not want
> this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
> other GPIO headers).

The patch looks OK, but given the module is removable, I think it should be
an overlay. The overlay would enable WiFi + Bluetooth, and all the
peripherals needed to connect them.

That way, if the module is not installed, we avoid confusing the user with
unused peripherals, and avoid having live voltage on an unoccupied header.

ChenYu

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 上午11:01:39, Chen-Yu Tsai <wens@csie.org> 写到:
>Hi,
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
>> one provides I/O voltage).
>>
>> Add device node for it.
>>
>> Although the Wi-Fi module is an external module which should be
>inserted
>> to a header, according to my personal talk with TL Lim, he does not
>want
>> this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm
>as
>> other GPIO headers).
>
>The patch looks OK, but given the module is removable, I think it
>should be
>an overlay. The overlay would enable WiFi + Bluetooth, and all the
>peripherals needed to connect them.
>
>That way, if the module is not installed, we avoid confusing the user
>with
>unused peripherals, and avoid having live voltage on an unoccupied
>header.

But as this header have specific usage, we will also confuse user
if it's not enabled as its target usage.

>
>ChenYu

[linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

? 2017?5?19? GMT+08:00 ??11:01:39, Chen-Yu Tsai <wens@csie.org> ??:
>Hi,
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
>> one provides I/O voltage).
>>
>> Add device node for it.
>>
>> Although the Wi-Fi module is an external module which should be
>inserted
>> to a header, according to my personal talk with TL Lim, he does not
>want
>> this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm
>as
>> other GPIO headers).
>
>The patch looks OK, but given the module is removable, I think it
>should be
>an overlay. The overlay would enable WiFi + Bluetooth, and all the
>peripherals needed to connect them.
>
>That way, if the module is not installed, we avoid confusing the user
>with
>unused peripherals, and avoid having live voltage on an unoccupied
>header.

But as this header have specific usage, we will also confuse user
if it's not enabled as its target usage.

>
>ChenYu

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Icenowy Zheng]

于 2017年5月19日 GMT+08:00 上午11:01:39, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>Hi,
>
>On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
>> one provides I/O voltage).
>>
>> Add device node for it.
>>
>> Although the Wi-Fi module is an external module which should be
>inserted
>> to a header, according to my personal talk with TL Lim, he does not
>want
>> this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm
>as
>> other GPIO headers).
>
>The patch looks OK, but given the module is removable, I think it
>should be
>an overlay. The overlay would enable WiFi + Bluetooth, and all the
>peripherals needed to connect them.
>
>That way, if the module is not installed, we avoid confusing the user
>with
>unused peripherals, and avoid having live voltage on an unoccupied
>header.

But as this header have specific usage, we will also confuse user
if it's not enabled as its target usage.

>
>ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> >The patch looks OK, but given the module is removable, I think it
> >should be
> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> >peripherals needed to connect them.
> >
> >That way, if the module is not installed, we avoid confusing the user
> >with
> >unused peripherals, and avoid having live voltage on an unoccupied
> >header.
> 
> But as this header have specific usage, we will also confuse user
> if it's not enabled as its target usage.

Yet you would enable unused resources.

This was already pointed out here:
https://patchwork.kernel.org/patch/9670235/

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> >The patch looks OK, but given the module is removable, I think it
> >should be
> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> >peripherals needed to connect them.
> >
> >That way, if the module is not installed, we avoid confusing the user
> >with
> >unused peripherals, and avoid having live voltage on an unoccupied
> >header.
> 
> But as this header have specific usage, we will also confuse user
> if it's not enabled as its target usage.

Yet you would enable unused resources.

This was already pointed out here:
https://patchwork.kernel.org/patch/9670235/

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170519/259493c5/attachment.sig>

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> >The patch looks OK, but given the module is removable, I think it
> >should be
> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> >peripherals needed to connect them.
> >
> >That way, if the module is not installed, we avoid confusing the user
> >with
> >unused peripherals, and avoid having live voltage on an unoccupied
> >header.
> 
> But as this header have specific usage, we will also confuse user
> if it's not enabled as its target usage.

Yet you would enable unused resources.

This was already pointed out here:
https://patchwork.kernel.org/patch/9670235/

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[icenowy]

在 2017-05-19 15:19，Maxime Ripard 写道：
> On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
>> >The patch looks OK, but given the module is removable, I think it
>> >should be
>> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
>> >peripherals needed to connect them.
>> >
>> >That way, if the module is not installed, we avoid confusing the user
>> >with
>> >unused peripherals, and avoid having live voltage on an unoccupied
>> >header.
>> 
>> But as this header have specific usage, we will also confuse user
>> if it's not enabled as its target usage.
> 
> Yet you would enable unused resources.
> 
> This was already pointed out here:
> https://patchwork.kernel.org/patch/9670235/

I think, before we have an official repository of device tree
overlays (either directly in torvalds/linux or maintained by
linux-sunxi), we shouldn't rely on device tree overlay
functionality.

> 
> Maxime
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[icenowy at aosc.io]

? 2017-05-19 15:19?Maxime Ripard ???
> On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
>> >The patch looks OK, but given the module is removable, I think it
>> >should be
>> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
>> >peripherals needed to connect them.
>> >
>> >That way, if the module is not installed, we avoid confusing the user
>> >with
>> >unused peripherals, and avoid having live voltage on an unoccupied
>> >header.
>> 
>> But as this header have specific usage, we will also confuse user
>> if it's not enabled as its target usage.
> 
> Yet you would enable unused resources.
> 
> This was already pointed out here:
> https://patchwork.kernel.org/patch/9670235/

I think, before we have an official repository of device tree
overlays (either directly in torvalds/linux or maintained by
linux-sunxi), we shouldn't rely on device tree overlay
functionality.

> 
> Maxime
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[icenowy-h8G6r0blFSE]

在 2017-05-19 15:19，Maxime Ripard 写道：
> On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
>> >The patch looks OK, but given the module is removable, I think it
>> >should be
>> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
>> >peripherals needed to connect them.
>> >
>> >That way, if the module is not installed, we avoid confusing the user
>> >with
>> >unused peripherals, and avoid having live voltage on an unoccupied
>> >header.
>> 
>> But as this header have specific usage, we will also confuse user
>> if it's not enabled as its target usage.
> 
> Yet you would enable unused resources.
> 
> This was already pointed out here:
> https://patchwork.kernel.org/patch/9670235/

I think, before we have an official repository of device tree
overlays (either directly in torvalds/linux or maintained by
linux-sunxi), we shouldn't rely on device tree overlay
functionality.

> 
> Maxime
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

On Fri, May 19, 2017 at 03:22:28PM +0800, icenowy@aosc.io wrote:
> 在 2017-05-19 15:19，Maxime Ripard 写道：
> > On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> > > >The patch looks OK, but given the module is removable, I think it
> > > >should be
> > > >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> > > >peripherals needed to connect them.
> > > >
> > > >That way, if the module is not installed, we avoid confusing the user
> > > >with
> > > >unused peripherals, and avoid having live voltage on an unoccupied
> > > >header.
> > > 
> > > But as this header have specific usage, we will also confuse user
> > > if it's not enabled as its target usage.
> > 
> > Yet you would enable unused resources.
> > 
> > This was already pointed out here:
> > https://patchwork.kernel.org/patch/9670235/
> 
> I think, before we have an official repository of device tree
> overlays (either directly in torvalds/linux or maintained by
> linux-sunxi), we shouldn't rely on device tree overlay
> functionality.

This is a board specific overlay, and having some upstream repository
with all the possible combinations of SoC / daughter board is just not
realistic.

This should be shipped by the board vendors. RPi does that, the
beaglebone does that, the CHIP does that, surely, if it works for
them, it should work for you.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

On Fri, May 19, 2017 at 03:22:28PM +0800, icenowy at aosc.io wrote:
> ? 2017-05-19 15:19?Maxime Ripard ???
> > On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> > > >The patch looks OK, but given the module is removable, I think it
> > > >should be
> > > >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> > > >peripherals needed to connect them.
> > > >
> > > >That way, if the module is not installed, we avoid confusing the user
> > > >with
> > > >unused peripherals, and avoid having live voltage on an unoccupied
> > > >header.
> > > 
> > > But as this header have specific usage, we will also confuse user
> > > if it's not enabled as its target usage.
> > 
> > Yet you would enable unused resources.
> > 
> > This was already pointed out here:
> > https://patchwork.kernel.org/patch/9670235/
> 
> I think, before we have an official repository of device tree
> overlays (either directly in torvalds/linux or maintained by
> linux-sunxi), we shouldn't rely on device tree overlay
> functionality.

This is a board specific overlay, and having some upstream repository
with all the possible combinations of SoC / daughter board is just not
realistic.

This should be shipped by the board vendors. RPi does that, the
beaglebone does that, the CHIP does that, surely, if it works for
them, it should work for you.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170523/9d24abc0/attachment.sig>

Re: [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

On Fri, May 19, 2017 at 03:22:28PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote:
> 在 2017-05-19 15:19，Maxime Ripard 写道：
> > On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> > > >The patch looks OK, but given the module is removable, I think it
> > > >should be
> > > >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> > > >peripherals needed to connect them.
> > > >
> > > >That way, if the module is not installed, we avoid confusing the user
> > > >with
> > > >unused peripherals, and avoid having live voltage on an unoccupied
> > > >header.
> > > 
> > > But as this header have specific usage, we will also confuse user
> > > if it's not enabled as its target usage.
> > 
> > Yet you would enable unused resources.
> > 
> > This was already pointed out here:
> > https://patchwork.kernel.org/patch/9670235/
> 
> I think, before we have an official repository of device tree
> overlays (either directly in torvalds/linux or maintained by
> linux-sunxi), we shouldn't rely on device tree overlay
> functionality.

This is a board specific overlay, and having some upstream repository
with all the possible combinations of SoC / daughter board is just not
realistic.

This should be shipped by the board vendors. RPi does that, the
beaglebone does that, the CHIP does that, surely, if it works for
them, it should work for you.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]