* Re: [PATCH v4 7/7] ARM64: dts: marvell: armada37xx: add pinctrl definition
From: Gregory CLEMENT @ 2017-04-26 10:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-gpio, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, Linus Walleij, Rob Herring, devicetree,
linux-kernel, Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding,
Hua Jing, Neta Zur Hershkovits
In-Reply-To: <7b07bd69cd506effa716c41f8ec3dda7a7c6c563.1491405475.git-series.gregory.clement@free-electrons.com>
Hi,
On mer., avril 05 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Start to populate the device tree of the Armada 37xx with the pincontrol
> configuration used on the board providing a dts.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +++++-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 31 +++++++++++++++++++-
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> index 86602c907a61..e749c5727490 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> @@ -63,6 +63,8 @@
> };
>
> &i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins>;
> status = "okay";
> };
>
> @@ -73,6 +75,8 @@
>
> &spi0 {
> status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_quad_pins>;
>
> m25p80@0 {
> compatible = "jedec,spi-nor";
> @@ -103,6 +107,8 @@
>
> /* Exported on the micro USB connector CON32 through an FTDI */
> &uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins>;
> status = "okay";
> };
>
> @@ -128,6 +134,8 @@
> };
>
> ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> phy-mode = "rgmii-id";
> phy = <&phy0>;
> status = "okay";
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index c02b13479458..2ac25f54d01d 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -186,6 +186,31 @@
> clock-output-names = "xtal";
> #clock-cells = <0>;
> };
> +
> + spi_quad_pins: spi-quad-pins {
> + groups = "spi_quad";
> + function = "spi";
> + };
> +
> + i2c1_pins: i2c1-pins {
> + groups = "i2c1";
> + function = "i2c";
> + };
> +
> + i2c2_pins: i2c2-pins {
> + groups = "i2c2";
> + function = "i2c";
> + };
> +
> + uart1_pins: uart1-pins {
> + groups = "uart1";
> + function = "uart";
> + };
> +
> + uart2_pins: uart2-pins {
> + groups = "uart2";
> + function = "uart";
> + };
> };
>
> pinctrl_sb: pinctrl-sb@18800 {
> @@ -203,6 +228,12 @@
> <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> + rgmii_pins: mii-pins {
> + groups = "rgmii";
> + function = "mii";
> + };
> +
> };
>
> eth0: ethernet@30000 {
> --
> git-series 0.9.1
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property
From: Viresh Kumar @ 2017-04-26 10:57 UTC (permalink / raw)
To: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, sudeep.holla-5wv7dgnIgG8,
Viresh Kumar, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1493203884.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Power-domains need to express their active states in DT and the devices
within the power-domain need to express their dependency on those active
states. The power-domains can use the OPP tables without any
modifications to the bindings.
Add a new property "power-domain-opp", which will contain phandle to the
OPP node of the parent power domain. This is required for devices which
have dependency on the configured active state of the power domain for
their working.
For some platforms the actual frequency and voltages of the power
domains are managed by the firmware and are so hidden from the high
level operating system. The "opp-hz" property is relaxed a bit to
contain indexes instead of actual frequency values to support such
platforms.
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 74 ++++++++++++++++++++++++++-
1 file changed, 73 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 63725498bd20..6e30cae2a936 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -77,7 +77,10 @@ This defines voltage-current-frequency combinations along with other related
properties.
Required properties:
-- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer.
+- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. In some
+ cases the exact frequency in Hz may be hidden from the OS by the firmware and
+ this field may contain values that represent the frequency in a firmware
+ dependent way, for example an index of an array in the firmware.
Optional properties:
- opp-microvolt: voltage in micro Volts.
@@ -154,6 +157,13 @@ properties.
- status: Marks the node enabled/disabled.
+- power-domain-opp: Phandle to the OPP node of the parent power-domain. The
+ parent power-domain should be configured to the OPP whose node is pointed by
+ the phandle, in order to configure the device for the OPP node that contains
+ this property. The order in which the device and power domain should be
+ configured is implementation defined. The OPP table of a device can set this
+ property only if the device node contains "power-domains" property.
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
@@ -528,3 +538,65 @@ Example 5: opp-supported-hw
};
};
};
+
+Example 7: Power domains with their own OPP tables:
+(example: For 1GHz device require domain state 1 and for 1.1 & 1.2 GHz device require state 2)
+
+/ {
+ domain_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ /*
+ * NOTE: Actual frequency is managed by firmware and is hidden
+ * from HLOS, so we simply use index in the opp-hz field to
+ * select the OPP.
+ */
+ domain_opp_1: opp-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain_opp_2: opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <1075000 1000000 1085000>;
+ };
+ };
+
+ foo_domain: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <0>;
+ operating-points-v2 = <&domain_opp_table>;
+ }
+
+ cpu0_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ power-domain-opp = <&domain_opp_1>;
+ };
+ opp-1100000000 {
+ opp-hz = /bits/ 64 <1100000000>;
+ power-domain-opp = <&domain_opp_2>;
+ };
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ power-domain-opp = <&domain_opp_2>;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ clocks = <&clk_controller 0>;
+ clock-names = "cpu";
+ operating-points-v2 = <&cpu0_opp_table>;
+ power-domains = <&foo_domain>;
+ };
+ };
+};
--
2.12.0.432.g71c3a4f4ba37
--
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
^ permalink raw reply related
* [PATCH V6 2/9] PM / Domains: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-26 10:57 UTC (permalink / raw)
To: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
Stephen Boyd, Nishanth Menon, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
lina.iyer-QSEj5FYQhm4dnm+yROfE0A, rnayak-sgV2jX0FEOL9JmXXK+q4OQ,
sudeep.holla-5wv7dgnIgG8, Viresh Kumar,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1493203884.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Update the power-domain bindings to allow "operating-points-v2" to be
present within the power-domain's provider node.
Also allow consumer devices that don't use OPP tables, to specify the
parent power-domain's OPP node in their "power-domain-opp" property.
Also note that the "operating-points-v2" property is extended to support
an array for the power domain providers.
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/power/power_domain.txt | 106 +++++++++++++++++++++
1 file changed, 106 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 14bd9e945ff6..730af0afc09a 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -40,6 +40,10 @@ phandle arguments (so called PM domain specifiers) of length specified by the
domain's idle states. In the absence of this property, the domain would be
considered as capable of being powered-on or powered-off.
+- operating-points-v2 : Phandles to the OPP tables for a power domain provider.
+ If the provider provides a single power domain, then this shall contain a
+ single phandle. Refer to ../opp/opp.txt for more information.
+
Example:
power: power-controller@12340000 {
@@ -120,4 +124,106 @@ The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
+Optional properties:
+- power-domain-opp: Phandle to the OPP node of the parent power-domain. The
+ parent power-domain should be configured to the OPP whose node is pointed by
+ the phandle, in order to use the device that contains this property.
+
+
+Example:
+- Device with parent power domain with two active states represented by OPP
+ table.
+
+ domain_opp_table: opp_table {
+ compatible = "operating-points-v2";
+
+ /*
+ * NOTE: Actual frequency is managed by firmware and is hidden
+ * from HLOS, so we simply use index in the opp-hz field to
+ * select the OPP.
+ */
+ domain_opp_1: opp-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain_opp_2: opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <1075000 1000000 1085000>;
+ };
+ };
+
+
+ parent: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <0>;
+ operating-points-v2 = <&domain_opp_table>;
+ };
+
+ leaky-device@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&parent>;
+ power-domain-opp = <&domain_opp_2>;
+ };
+
+- OPP table for domain provider that provides two domains.
+
+ domain0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ /*
+ * NOTE: Actual frequency is managed by firmware and is hidden
+ * from HLOS, so we simply use index in the opp-hz field to
+ * select the OPP.
+ */
+ domain0_opp_1: opp-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain0_opp_2: opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <1075000 1000000 1085000>;
+ };
+ };
+
+ domain1_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+
+ /*
+ * NOTE: Actual frequency is managed by firmware and is hidden
+ * from HLOS, so we simply use index in the opp-hz field to
+ * select the OPP.
+ */
+ domain1_opp_1: opp-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain1_opp_2: opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <1075000 1000000 1085000>;
+ };
+ };
+
+ parent: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
+ };
+
+ leaky-device0@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&parent 0>;
+ power-domain-opp = <&domain0_opp_2>;
+ };
+
+ leaky-device1@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&parent 1>;
+ power-domain-opp = <&domain1_opp_2>;
+ };
+
[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
--
2.12.0.432.g71c3a4f4ba37
--
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
^ permalink raw reply related
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-26 12:03 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <87zif38qu2.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Apr 26, 2017 at 11:23 AM, Gregory CLEMENT
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On lun., avril 24 2017, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> + spin_lock_irqsave(&info->irq_lock, flags);
>>> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
>>> + /* Manage only the interrupt that was enabled */
>>> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
>>> + spin_unlock_irqrestore(&info->irq_lock, flags);
>>> + while (status) {
>>> + u32 hwirq = ffs(status) - 1;
>>> + u32 virq = irq_find_mapping(d, hwirq +
>>> + i * GPIO_PER_REG);
>>> +
>>> + generic_handle_irq(virq);
>>> + status &= ~BIT(hwirq);
>>> + }
>>
>> You hae a problem here is a new IRQ appears while you are inside
>> of this loop. You need to re-read the status register for each iteration
>> (and &= with the IRQ_EN I guess).
>
> If a new IRQ appears during the loop, then the irq handler will be
> called again because the cause of this new IRQ won't have been acked
> yet. So I think we're fine here.
That *might* be true. It is true if the CPU gets a level IRQ from the
GPIO controller. But hardware dealing with edge IRQs can be very
quirky here, and just send a pulse on the line to the CPU if the
CPU-bound IRQ is also just edge triggered. And then that
pulse would potentially be missed while dealing with the current
IRQ in this handler. (And exactly this happened to us on other
hardware.)
But anyway: why let the irq handler be called again if you can avoid it?
You would avoid a double context switch by just checking it again
in the loop before exiting the handler. And that can be really nice
for latency-sensitive stuff.
Yours,
Linus Walleij
--
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
^ permalink raw reply
* Re: [PATCH v4 2/9] pinctrl: Renesas RZ/A1 pin and gpio controller
From: Geert Uytterhoeven @ 2017-04-26 12:21 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Linus Walleij, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1491401247-7030-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Wed, Apr 5, 2017 at 4:07 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Add combined gpio and pin controller driver for Renesas RZ/A1
> r7s72100 SoC.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-rza1.c
> +/*
> + * Keep this up-to-date with pinconf-generic.h: it performs packing of
> + * pin conf flags and argument during pinconf_generic_parse_dt_config();
> + * we simply discard pinconf argument here
> + */
> +#define PIN_CONF_UNPACK(pinconf) ((pinconf) & 0xffUL)
Perhaps this should be moved to pinconf-generic.h, to make sure it stays
up-to-date?
> +static inline int rza1_get_bit(struct rza1_port *port, unsigned int reg,
I'd use "unsigned int" as the return type.
It doesn't matter much as register values are 16-bit, but people might copy
from this driver when writing their own.
> + unsigned int bit)
> +{
> + void __iomem *mem = RZA1_ADDR(port->base, reg, port->id);
> +
> + return ioread16(mem) & BIT(bit);
> +}
> +static inline int rza1_pin_get_direction(struct rza1_port *port,
> + unsigned int pin)
> +{
> + unsigned long irqflags;
> + int input;
> +
> + spin_lock_irqsave(&port->lock, irqflags);
> + input = rza1_get_bit(port, RZA1_PM_REG, pin);
> + spin_unlock_irqrestore(&port->lock, irqflags);
> +
> + return input;
return !!input;
gpio_chip.get_direction() should return 0, 1, or a negative error value.
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: Add STM32 MDMA driver
From: Pierre Yves MORDRET @ 2017-04-26 12:35 UTC (permalink / raw)
To: Vinod Koul, M'boumba Cedric Madianga
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, linux-kernel@vger.kernel.org,
Pierre Yves MORDRET, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170406070805.GG4094@localhost>
On 04/06/2017 09:08 AM, Vinod Koul wrote:
> On Mon, Mar 13, 2017 at 04:06:39PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds the driver for the STM32 MDMA controller.
>
> Again pls do describe the controller
OK. I will add a more detail description with V2
>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/dmaengine.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/dmapool.h>
>> +#include <linux/err.h>
>> +#include <linux/init.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/list.h>
>> +#include <linux/log2.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_dma.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/sched.h>
>
> why do you need sched.h, i am sure many of these may not be required, pls
> check
Correct ! not needed. I'll get rid of it in V2
>
>> +static int stm32_mdma_get_width(struct stm32_mdma_chan *chan,
>> + enum dma_slave_buswidth width)
>> +{
>> + switch (width) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + return STM32_MDMA_BYTE;
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + return STM32_MDMA_HALF_WORD;
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + return STM32_MDMA_WORD;
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return STM32_MDMA_DOUBLE_WORD;
>
> IIUC we can do this with ffs()
I don't believe we can do that. This function translates DMA_SLAVE enum
into internal register representation.
>
>
>> + default:
>> + dev_err(chan2dev(chan), "Dma bus width not supported\n");
>> + return -EINVAL;
>> + }
>> +}
>> +
>> +static enum dma_slave_buswidth stm32_mdma_get_max_width(u32 buf_len, u32 tlen)
>> +{
>> + enum dma_slave_buswidth max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
>> +
>> + while ((buf_len <= max_width || buf_len % max_width ||
>> + tlen < max_width) && max_width > DMA_SLAVE_BUSWIDTH_1_BYTE)
>> + max_width = max_width >> 1;
>
> 1. this is hard to read
> 2. sound like this can be optimized :)
>
Ok. I will revise the check if improvements can be done
>> +
>> + return max_width;
>> +}
>> +
>> +static u32 stm32_mdma_get_best_burst(u32 buf_len, u32 tlen, u32 max_burst,
>> + enum dma_slave_buswidth width)
>> +{
>> + u32 best_burst = max_burst;
>> + u32 burst_len = best_burst * width;
>> +
>> + if (buf_len % tlen)
>> + return 0;
>> +
>> + while ((tlen < burst_len && best_burst > 1) ||
>> + (burst_len > 0 && tlen % burst_len)) {
>> + best_burst = best_burst >> 1;
>> + burst_len = best_burst * width;
>
> same thing here too
Ok. I will revise the check if improvements can be done
>
>> +
>> + return (best_burst > 1) ? best_burst : 0;
>> +}
>> +
>> +static int stm32_mdma_disable_chan(struct stm32_mdma_chan *chan)
>> +{
>> + struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
>> + u32 ccr, cisr, id, reg;
>> + int ret;
>> +
>> + id = chan->id;
>> + reg = STM32_MDMA_CCR(id);
>> +
>> + /* Disable interrupts */
>> + stm32_mdma_clr_bits(dmadev, reg, STM32_MDMA_CCR_IRQ_MASK);
>> +
>> + ccr = stm32_mdma_read(dmadev, reg);
>> + if (ccr & STM32_MDMA_CCR_EN) {
>> + stm32_mdma_clr_bits(dmadev, reg, STM32_MDMA_CCR_EN);
>> +
>> + /* Ensure that any ongoing transfer has been completed */
>> + ret = readl_relaxed_poll_timeout_atomic(
>
> why not simple readl
When Channel enable(CCR_EN) is reset by SW, it is recommended to wait
for the CTCIF (Channel Transfer Complete interrupt flag) = 1, in order
to ensure that any ongoing buffer transfer has been completed, before
reprogramming the channel.
Moreover since this function might be called under interruption context
(a DMA Client may call dmaengine_terminate_all() for instance) function
cannot allow sleep. Timeout is for cases when IP is stuck and channel
cannot be disabled
>> +static void stm32_mdma_set_dst_bus(struct stm32_mdma_device *dmadev, u32 *ctbr,
>> + u32 dst_addr)
>> +{
>> + u32 mask;
>> + int i;
>> +
>> + /* Check if memory device is on AHB or AXI */
>> + *ctbr &= ~STM32_MDMA_CTBR_DBUS;
>> + mask = dst_addr & 0xF0000000;
>> + for (i = 0; i < dmadev->nr_ahb_addr_masks; i++) {
>> + if (mask == dmadev->ahb_addr_masks[i]) {
>> + *ctbr |= STM32_MDMA_CTBR_DBUS;
>> + break;
>> + }
>> + }
>> +}
>> +
>> +static void stm32_mdma_set_src_bus(struct stm32_mdma_device *dmadev, u32 *ctbr,
>> + u32 src_addr)
>> +{
>> + u32 mask;
>> + int i;
>> +
>> + /* Check if memory device is on AHB or AXI */
>> + *ctbr &= ~STM32_MDMA_CTBR_SBUS;
>> + mask = src_addr & 0xF0000000;
>> + for (i = 0; i < dmadev->nr_ahb_addr_masks; i++) {
>> + if (mask == dmadev->ahb_addr_masks[i]) {
>> + *ctbr |= STM32_MDMA_CTBR_SBUS;
>> + break;
>> + }
>> + }
>
> these too look awfully same..
Ok. I will create a common function then.
>
>> +static int __init stm32_mdma_init(void)
>> +{
>> + return platform_driver_probe(&stm32_mdma_driver, stm32_mdma_probe);
>> +}
>> +
>> +subsys_initcall(stm32_mdma_init);
>
> why subsys?
>
subsys_initcall level is to ensure MDMA is going to be probed before its
clients
>> --
>> 1.9.1
>>
>
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: mdio: Clarify binding document
From: Roger Quadros @ 2017-04-26 13:09 UTC (permalink / raw)
To: Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: andrew-g2DYL2Zd6BY, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
tony-4v6yS6AI5VpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
jsarha-l0cyMroinI0, linux-omap-u79uwXL29TY76Z2rM5mHXA,
lars-Qo5EllUWu/uELgA04lAiVw, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20170425183308.26107-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 25/04/17 21:33, Florian Fainelli wrote:
> The described GPIO reset property is applicable to *all* child PHYs. If
> we have one reset line per PHY present on the MDIO bus, these
> automatically become properties of the child PHY nodes.
>
> Finally, indicate how the RESET pulse width must be defined, which is
> the maximum value of all individual PHYs RESET pulse widths determined
> by reading their datasheets.
>
> Fixes: 69226896ad63 ("mdio_bus: Issue GPIO RESET to PHYs.")
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/mdio.txt | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
> index 4ffbbacebda1..96a53f89aa6e 100644
> --- a/Documentation/devicetree/bindings/net/mdio.txt
> +++ b/Documentation/devicetree/bindings/net/mdio.txt
> @@ -3,13 +3,17 @@ Common MDIO bus properties.
> These are generic properties that can apply to any MDIO bus.
>
> Optional properties:
> -- reset-gpios: List of one or more GPIOs that control the RESET lines
> - of the PHYs on that MDIO bus.
> -- reset-delay-us: RESET pulse width in microseconds as per PHY datasheet.
> +- reset-gpios: One GPIO that control the RESET lines of all PHYs on that MDIO
> + bus.
> +- reset-delay-us: RESET pulse width in microseconds.
>
> A list of child nodes, one per device on the bus is expected. These
> should follow the generic phy.txt, or a device specific binding document.
>
> +The 'reset-delay-us' indicates the RESET signal pulse width in microseconds and
> +applies to all PHY devices. It must therefore be appropriately determined based
> +on all PHY requirements (maximum value of all per-PHY RESET pulse widths).
> +
> Example :
> This example shows these optional properties, plus other properties
> required for the TI Davinci MDIO driver.
> @@ -21,7 +25,7 @@ required for the TI Davinci MDIO driver.
> #size-cells = <0>;
>
> reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> - reset-delay-us = <2>; /* PHY datasheet states 1us min */
> + reset-delay-us = <2>;
>
> ethphy0: ethernet-phy@1 {
> reg = <1>;
>
--
cheers,
-roger
--
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
^ permalink raw reply
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Gregory CLEMENT @ 2017-04-26 13:12 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <CACRpkdYYRe4A+Zj+fDpC9SA1pgaVSgewYGB_vCNoWNRXWTtTGQ@mail.gmail.com>
Hi Linus,
On mer., avril 26 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Apr 26, 2017 at 11:23 AM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>> On lun., avril 24 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>>> + spin_lock_irqsave(&info->irq_lock, flags);
>>>> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
>>>> + /* Manage only the interrupt that was enabled */
>>>> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
>>>> + spin_unlock_irqrestore(&info->irq_lock, flags);
>>>> + while (status) {
>>>> + u32 hwirq = ffs(status) - 1;
>>>> + u32 virq = irq_find_mapping(d, hwirq +
>>>> + i * GPIO_PER_REG);
>>>> +
>>>> + generic_handle_irq(virq);
>>>> + status &= ~BIT(hwirq);
>>>> + }
>>>
>>> You hae a problem here is a new IRQ appears while you are inside
>>> of this loop. You need to re-read the status register for each iteration
>>> (and &= with the IRQ_EN I guess).
>>
>> If a new IRQ appears during the loop, then the irq handler will be
>> called again because the cause of this new IRQ won't have been acked
>> yet. So I think we're fine here.
>
> That *might* be true. It is true if the CPU gets a level IRQ from the
> GPIO controller. But hardware dealing with edge IRQs can be very
> quirky here, and just send a pulse on the line to the CPU if the
> CPU-bound IRQ is also just edge triggered. And then that
> pulse would potentially be missed while dealing with the current
> IRQ in this handler. (And exactly this happened to us on other
> hardware.)
OK thanks for sharing your experience, you convinced me, I am going to
send a new version of the patch with this fix.
>
> But anyway: why let the irq handler be called again if you can avoid
> it?
> You would avoid a double context switch by just checking it again
> in the loop before exiting the handler. And that can be really nice
> for latency-sensitive stuff.
I wanted to avoid an uncached access in each loop if it was not
necessary. But as we finally need it, I will do it.
Gregory
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] NFC: trf7970a: Correct register settings for 27MHz clock
From: Geoff Lansberry @ 2017-04-26 13:48 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
sameo-VuQAYsv1563Yd54FQh9/CA
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfc-hn68Rpc1hR1g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA, mgreer-luAo+O/VEmrlveNOaEYElw,
justin-R+k406RtEhcAvxtiuMwx3w, colin.king-Z7WLFzj8eWMS+FvcfC7Uqw,
Geoff Lansberry
In prior commits the selected clock frequency does not propagate
correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL
register.
Also fixes a bug that causes the device tree property check to always
pass.
Signed-off-by: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
---
drivers/nfc/trf7970a.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 2d1c8ca..c278b0e 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -2071,7 +2071,7 @@ static int trf7970a_probe(struct spi_device *spi)
}
of_property_read_u32(np, "clock-frequency", &clk_freq);
- if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
+ if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) &&
(clk_freq != TRF7970A_13MHZ_CLOCK_FREQUENCY)) {
dev_err(trf->dev,
"clock-frequency (%u Hz) unsupported\n",
@@ -2079,6 +2079,13 @@ static int trf7970a_probe(struct spi_device *spi)
return -EINVAL;
}
+ if (clk_freq == TRF7970A_27MHZ_CLOCK_FREQUENCY) {
+ trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
+ dev_dbg(trf->dev, "trf7970a configured for 27MHz crystal\n");
+ } else {
+ trf->modulator_sys_clk_ctrl = 0;
+ }
+
if (of_property_read_bool(np, "en2-rf-quirk"))
trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Mark Brown @ 2017-04-26 13:55 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Sudeep Holla, Viresh Kumar, Rafael Wysocki, ulf.hansson,
Kevin Hilman, Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel, linux-pm, linux-kernel, Vincent Guittot, robh+dt,
lina.iyer, devicetree
In-Reply-To: <9cd9287c-392b-d3ca-db7d-75c49287448e@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
On Wed, Apr 26, 2017 at 10:02:39AM +0530, Rajendra Nayak wrote:
> > On 17/04/17 06:27, Viresh Kumar wrote:
> >>> If we are looking this power-domains with performance as just some
> >>> *advanced regulators*, I don't like the complexity added.
> + Mark
> I don;t see any public discussions on why we ruled out using regulators to
> support this but maybe there were some offline discussions on this.
> Mark, this is a long thread, so just summarizing here to give you the context.
> At qualcomm, we have an external M3 core (running its own firmware) which controls
> a few voltage rails (including AVS on those). The devices vote for the voltage levels
> (or performance levels) they need by passing an integer value to the M3 (not actual
> voltage values). Since that didn't fit well with the existing regulator apis it was
As I'm getting fed up of saying: if the values you are setting are not
voltages and do not behave like voltages then the hardware should not be
represented as a voltage regulator since if they are represented as
voltage regulators things will expect to be able to control them as
voltage regulators. This hardware is quite clearly providing OPPs
directly, I would expect this to be handled in the OPP code somehow.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/9] pinctrl: Renesas RZ/A1 pin and gpio controller
From: jmondi @ 2017-04-26 14:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdUy3wo9x=nkpdSVSt34q5yaARc4+kFDC592V2LF7Cxzrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Wed, Apr 26, 2017 at 02:21:34PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, Apr 5, 2017 at 4:07 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> > Add combined gpio and pin controller driver for Renesas RZ/A1
> > r7s72100 SoC.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
>
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-rza1.c
>
> > +/*
> > + * Keep this up-to-date with pinconf-generic.h: it performs packing of
> > + * pin conf flags and argument during pinconf_generic_parse_dt_config();
> > + * we simply discard pinconf argument here
> > + */
> > +#define PIN_CONF_UNPACK(pinconf) ((pinconf) & 0xffUL)
>
> Perhaps this should be moved to pinconf-generic.h, to make sure it stays
> up-to-date?
>
Not sure, I'm discarding the argument of the configuration flag with
this macro...
I would keep this internal to this driver, or make two of them, one to
retrieve the flag, and one to retrieve argument..
> > +static inline int rza1_get_bit(struct rza1_port *port, unsigned int reg,
>
> I'd use "unsigned int" as the return type.
> It doesn't matter much as register values are 16-bit, but people might copy
> from this driver when writing their own.
>
> > + unsigned int bit)
> > +{
> > + void __iomem *mem = RZA1_ADDR(port->base, reg, port->id);
> > +
> > + return ioread16(mem) & BIT(bit);
> > +}
>
> > +static inline int rza1_pin_get_direction(struct rza1_port *port,
> > + unsigned int pin)
> > +{
> > + unsigned long irqflags;
> > + int input;
> > +
> > + spin_lock_irqsave(&port->lock, irqflags);
> > + input = rza1_get_bit(port, RZA1_PM_REG, pin);
> > + spin_unlock_irqrestore(&port->lock, irqflags);
> > +
> > + return input;
>
> return !!input;
>
> gpio_chip.get_direction() should return 0, 1, or a negative error value.
>
> > +}
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
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
^ permalink raw reply
* Re: [PATCH] NFC: trf7970a: Correct register settings for 27MHz clock
From: walter harms @ 2017-04-26 14:34 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, sameo, kernel-janitors, linux-kernel, linux-nfc,
devicetree, mgreer, justin, colin.king
In-Reply-To: <1493214513-12245-1-git-send-email-geoff@kuvee.com>
Am 26.04.2017 15:48, schrieb Geoff Lansberry:
> In prior commits the selected clock frequency does not propagate
> correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL
> register.
> Also fixes a bug that causes the device tree property check to always
> pass.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
> drivers/nfc/trf7970a.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 2d1c8ca..c278b0e 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -2071,7 +2071,7 @@ static int trf7970a_probe(struct spi_device *spi)
> }
>
> of_property_read_u32(np, "clock-frequency", &clk_freq);
> - if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
> + if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) &&
> (clk_freq != TRF7970A_13MHZ_CLOCK_FREQUENCY)) {
> dev_err(trf->dev,
> "clock-frequency (%u Hz) unsupported\n",
> @@ -2079,6 +2079,13 @@ static int trf7970a_probe(struct spi_device *spi)
> return -EINVAL;
> }
>
> + if (clk_freq == TRF7970A_27MHZ_CLOCK_FREQUENCY) {
> + trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
> + dev_dbg(trf->dev, "trf7970a configured for 27MHz crystal\n");
> + } else {
> + trf->modulator_sys_clk_ctrl = 0;
> + }
> +
I am a fan of defensive programming and would move do:
trf->modulator_sys_clk_ctrl = 0;
if (clk_freq == TRF7970A_27MHZ_CLOCK_FREQUENCY) {
trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
dev_dbg(trf->dev, "trf7970a configured for 27MHz crystal\n");
}
perhaps using a switch/case here is appropriate IMHO a border case for 2 case
but would make the init code more clear.
just my 2 cents,
re,
wh
> if (of_property_read_bool(np, "en2-rf-quirk"))
> trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
>
^ permalink raw reply
* Re: [PATCH v2 2/4] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Linus Walleij @ 2017-04-26 14:42 UTC (permalink / raw)
To: Benjamin Henrion
Cc: Nandor Han, Greg KH, David S. Miller, Geert Uytterhoeven,
Mauro Carvalho Chehab, Daniel Vetter, Alexandre Courbot,
Rob Herring, Mark Rutland, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Semi Malinen
In-Reply-To: <CANjd3ndZkVi5OA0eqDewrpqVLQpT11QbVOA98F=ghMhcwPu2hQ@mail.gmail.com>
On Tue, Apr 25, 2017 at 9:07 AM, Benjamin Henrion <zoobab@gmail.com> wrote:
> I doubt you will be able to convince the majority of people toggling
> GPIOs via a simple shell script to switch to write a complex C
> program. Not to mention cross compilation and the libraries
> dependencies here.
I do not need to convince anyone, I'm not into politics.
The way to attract users to the character device is by offering better
features... so we smack in the following goodies:
- Need a userspace ABI? No more need to select CONFIG_GPIO_SYSFS!
The chardev is always there for any gpio chip in newer kernels!
Board vendors would have to actively delete core code to disable it!
- Need open drain? The chardev will support that, the sysfs will never.
- Need to set/get multiple lines with a single context switch? Chardev
does this. Also the set operation will turn into a single register write
if your driver implements .set_multiple()
- All future needs: line biasing? Schmitt triggers? Drive strengths?
All that will use the character device, and the sysfs ABI will never
support any of it.
> Is there some good cli tools to access the new char device? If they
> are shipped with most distros, that would reduce the pain.
I have those that come with the kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio
Then libgpiod as mentioned:
https://github.com/brgl/libgpiod/tree/master/src/tools
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803
From: Mark Brown @ 2017-04-26 14:45 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-9-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
On Mon, Apr 17, 2017 at 07:57:43PM +0800, Icenowy Zheng wrote:
> 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: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver
From: Andy Shevchenko @ 2017-04-26 15:04 UTC (permalink / raw)
To: Eugeniy Paltsev
Cc: devicetree@vger.kernel.org, vinod.koul@intel.com,
Alexey.Brodkin@synopsys.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linux-snps-arc@lists.infradead.org
In-Reply-To: <1493143941.24567.196.camel@linux.intel.com>
On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> On Tue, 2017-04-25 at 15:16 +0000, Eugeniy Paltsev wrote:
> > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > > On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote:
> > > Descriptor is active until terminate_all() is called or new
> > > descriptor
> > > is supplied. So, the caller has a quite time to check on it.
> > >
> > > So, what's wrong on it by your opinion?
> >
> > Hmm, this looks OK. (In my example (hsu/hsu.c driver) error
> > descriptors
> > are not freed even after terminate_all is called)
>
> If it's active it will be freed.
> Otherwise caller should check somewhere that descriptor fails.
>
> But actually this is fragile and we need to monitor failed
> descriptors.
> Thanks for reporting.
>
> >
> > > Of course, if you want to keep by some reason (should be stated
> > > what
> > > the reason in comment) erred descriptors, you can do that.
> >
> > So, I'll create desc_error list and store failed descriptors in this
> > list until terminate_all() is called.
> > Is it OK implementation?
>
> Nope, we need to amend virt-chan API for that. I'm on it. Will send a
> series soon.
I have to correct what I wrote before.
We have two options:
a) one I proposed above;
b) move descriptor to complete list and call complete callback with
result.
So, it looks like the b) variant is what is done already in 4 (did I
calculate correctly?) drivers and respective users.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v5 00/10] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, 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.
The basical part of AXP803 MFD driver is already applied, according to Lee.
Thus this patchset is now still two parts, but a bit different to older
revisions:
- Part1: from PATCH 1/10 to PATCH 5/10, which focus on enabling AXP803 in
the device tree: the RSB bus, 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/10 to PATCH 10/10, 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 RSB device nodes, which is used for the communication between
A64 and AXP803.
PATCH 2 adds device tree binding of A64 R_INTC.
PATCH 3 really adds support for A64 R_INTC in NMI driver.
PATCH 4 adds R_INTC node in A64 device tree.
PATCH 5 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.
PATCH 6 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)
PATCH 7 enables the AXP803 regulator cell in MFD driver.
PATCH 8 adds a DTSI file for AXP803, like other older AXP PMICs.
PATCH 9 enables AXP803 regulators in Pine64 device tree.
PATCH 10 enables Wi-Fi for Pine64.
Icenowy Zheng (10):
arm64: allwinner: a64: enable RSB on A64
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 | 27 ++++
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, 501 insertions(+), 25 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ permalink raw reply
* [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
Add it and its pinmux.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Changes in v2:
- Removed bonus properties in pio node.
- Added Chen-Yu's ACK.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c7f669f5884f..05ec9fc5e81f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -422,6 +422,25 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+ r_rsb_pins: rsb@0 {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ };
+ };
+
+ r_rsb: rsb@1f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu 6>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
};
--
2.12.2
^ permalink raw reply related
* [PATCH v5 02/10] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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>
---
.../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
^ permalink raw reply related
* [PATCH v5 03/10] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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
^ permalink raw reply related
* [PATCH v5 04/10] arm64: allwinner: a64: add NMI (R_INTC) controller on A64
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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 05ec9fc5e81f..a6566d292934 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -403,6 +403,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
^ permalink raw reply related
* [PATCH v5 05/10] arm64: allwinner: a64: add AXP803 node to Pine64 device tree
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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>
---
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 c680ed385da3..3e1b44292534 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -95,6 +95,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>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
* [PATCH v5 06/10] regulator: axp20x-regulator: add support for AXP803
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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, ®);
+
+ 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, ®);
+ case AXP806_ID:
+ regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
+
+ 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
^ permalink raw reply related
* [PATCH v5 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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
^ permalink raw reply related
* [PATCH v5 08/10] arm64: allwinner: a64: add DTSI file for AXP803 PMIC
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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
^ permalink raw reply related
* [PATCH v5 09/10] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Lee Jones, Liam Girdwood
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170426152023.41567-1-icenowy-h8G6r0blFSE@public.gmane.org>
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>
---
.../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 3e1b44292534..abc1879e91f2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -106,6 +106,115 @@
};
};
+#include "axp803.dtsi"
+
+®_aldo1 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vcc-csi";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pl";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc1sw {
+ regulator-name = "vcc-phy";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vcc-dram";
+};
+
+®_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-sys";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-hdmi";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-mipi";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avdd-csi";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+};
+
+®_eldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "cpvdd";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vdd-1v8-csi";
+};
+
+®_fldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vcc-1v2-hsic";
+};
+
+®_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpus";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox