* Re: [PATCH net-next v4 1/5] dt-bindings: net: dsa: add Mediatek MT7530 binding
From: Florian Fainelli @ 2017-04-07 19:45 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w, andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Landen.Chao-NuS5LvNUpcJWk0Htik3J/w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, objelf-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1491554709-9723-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 04/07/2017 01:45 AM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add device-tree binding for Mediatek MT7530 switch.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
Florian
--
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 net-next v4 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch
From: Florian Fainelli @ 2017-04-07 19:45 UTC (permalink / raw)
To: sean.wang, andrew, vivien.didelot, matthias.bgg, robh+dt,
mark.rutland
Cc: devicetree, netdev, linux-kernel, linux-mediatek, davem,
Landen.Chao, keyhaede, objelf
In-Reply-To: <1491554709-9723-6-git-send-email-sean.wang@mediatek.com>
On 04/07/2017 01:45 AM, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
> Mediatek router platforms such as MT7623A or MT7623N platform which
> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
> Among these ports, The port from 0 to 4 are the user ports connecting
> with the remote devices while the port 5 and 6 are the CPU ports
> connecting into Mediatek Ethernet GMAC.
>
> For port 6, it can communicate with the CPU via Mediatek Ethernet GMAC
> through either the TRGMII or RGMII which could be controlled by phy-mode
> in the dt-bindings to specify which mode is preferred to use. And for
> port 5, only RGMII can be specified. However, currently, only port 6 is
> being supported in this DSA driver.
>
> The driver is made with the reference to qca8k and other existing DSA
> driver. The most of the essential callbacks of the DSA are already
> support in the driver, including tag insert for user port distinguishing,
> port control, bridge offloading, STP setup and ethtool operation to allow
> DSA to model each user port into a standalone netdevice as the other DSA
> driver had done.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: Landen Chao <Landen.Chao@mediatek.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797
From: Stephen Boyd @ 2017-04-07 19:41 UTC (permalink / raw)
To: Mars Cheng
Cc: Matthias Brugger, Rob Herring, Marc Zyngier, Michael Turquette,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel, linux-mediatek, devicetree, wsd_upstream,
linux-clk, Kevin-CW Chen
In-Reply-To: <1491521747.17643.6.camel@mtkswgap22>
On 04/07, Mars Cheng wrote:
> Hi Stephen
>
> On Thu, 2017-04-06 at 13:08 -0700, Stephen Boyd wrote:
> > On 03/19, Mars Cheng wrote:
> > > From: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> > >
> > > Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> > > and subsystem clocks
> > >
> > > Signed-off-by: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> > > Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> > > Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
> >
> > Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > Looks fine to me except for the one comment below. Did you want
> > me to merge it into clk tree?
>
> To prevent another run, I really like you to merge it.
> However, I also want to make the patch set more cleaner.
> So I will send v4 later. :-)
Ok I'll merge v4 patch then.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 0/3] clk: Add support for IDT 5P49V5935
From: Stephen Boyd @ 2017-04-07 19:40 UTC (permalink / raw)
To: Alexey Firago
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-1-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 04/07, Alexey Firago wrote:
> This series adds support for IDT VersaClock 5P49V5935 programmable clock
> generator to the existing clk-versaclock5 driver. Driver is also updated to
> simplify addition of support for more VersaClock 5 models.
>
> Patches were verified on Avnet UltraZed-EG board with IO Carrier Card.
>
> Changes in V2:
> - Introduce vc5_chip_info structure describing chip features
> - Set vc5_chip_info for the supported chips using clk_vc5_of_match[].data
> - Add 5P49V5935 support using vc5_chip_info approach
> - Fix idx comparison in vc5_of_clk_get ('>' to '>=')
>
> Changes in V3:
> - Change type of clk_fod_cnt and clk_out_cnt to unsigned int
> - Add missed 'const' to vc5_chip_info instance declaration
> - Use of_device_get_match_data() to initialize vc5_chip_info on probe
>
> Changes in V4:
> - Add 'const' to vc5_chip_info.flags
Could any Reviewed-by tags get carried over? I'll wait for Marek
to resend them I guess.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 net-next v4 1/5] dt-bindings: net: dsa: add Mediatek MT7530 binding
From: Andrew Lunn @ 2017-04-07 19:38 UTC (permalink / raw)
To: sean.wang
Cc: f.fainelli, vivien.didelot, matthias.bgg, robh+dt, mark.rutland,
devicetree, netdev, linux-kernel, linux-mediatek, davem,
Landen.Chao, keyhaede, objelf
In-Reply-To: <1491554709-9723-2-git-send-email-sean.wang@mediatek.com>
On Fri, Apr 07, 2017 at 04:45:05PM +0800, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add device-tree binding for Mediatek MT7530 switch.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch
From: Andrew Lunn @ 2017-04-07 19:37 UTC (permalink / raw)
To: sean.wang
Cc: f.fainelli, vivien.didelot, matthias.bgg, robh+dt, mark.rutland,
devicetree, netdev, linux-kernel, linux-mediatek, davem,
Landen.Chao, keyhaede, objelf
In-Reply-To: <1491554709-9723-6-git-send-email-sean.wang@mediatek.com>
On Fri, Apr 07, 2017 at 04:45:09PM +0800, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
> Mediatek router platforms such as MT7623A or MT7623N platform which
> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
> Among these ports, The port from 0 to 4 are the user ports connecting
> with the remote devices while the port 5 and 6 are the CPU ports
> connecting into Mediatek Ethernet GMAC.
>
> For port 6, it can communicate with the CPU via Mediatek Ethernet GMAC
> through either the TRGMII or RGMII which could be controlled by phy-mode
> in the dt-bindings to specify which mode is preferred to use. And for
> port 5, only RGMII can be specified. However, currently, only port 6 is
> being supported in this DSA driver.
>
> The driver is made with the reference to qca8k and other existing DSA
> driver. The most of the essential callbacks of the DSA are already
> support in the driver, including tag insert for user port distinguishing,
> port control, bridge offloading, STP setup and ethtool operation to allow
> DSA to model each user port into a standalone netdevice as the other DSA
> driver had done.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: Landen Chao <Landen.Chao@mediatek.com>
Hi Sean
This is looking good now. Thanks
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v11 01/10] devicetree: power: Add battery.txt
From: Liam Breck @ 2017-04-07 19:23 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring
Cc: Andrew F. Davis, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren
In-Reply-To: <20170320094335.19224-2-liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
[+CC Tony Lindgren]
Rob & Sebastian & Tony & Andrew,
With this binding we allow a DT to hard-code battery characteristics.
But mainline dts files for boards & boxes really should NOT include
immutable battery properties unless the battery is inseparable from
the electronics. We want to prevent unpredictable behavior due to
incorrect DT properties after a user changes a battery to a different
type.
It's OK for device vendors to hard-code battery characteristics in DT,
but mainline dts is another matter.
If this is agreed, how should we document it?
On Mon, Mar 20, 2017 at 2:43 AM, Liam Breck <liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org> wrote:
> From: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>
> Documentation of static battery characteristics that can be defined
> for batteries which cannot self-identify. This information is required
> by fuel-gauge and charger chips for proper handling of the battery.
>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> Signed-off-by: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
> ---
> .../devicetree/bindings/power/supply/battery.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> new file mode 100644
> index 0000000..53a68c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> @@ -0,0 +1,43 @@
> +Battery Characteristics
> +
> +The devicetree battery node provides static battery characteristics.
> +In smart batteries, these are typically stored in non-volatile memory
> +on a fuel gauge chip. The battery node should be used where there is
> +no appropriate non-volatile memory, or it is unprogrammed/incorrect.
> +
> +Required Properties:
> + - compatible: Must be "simple-battery"
> +
> +Optional Properties:
> + - voltage-min-design-microvolt: drained battery voltage
> + - energy-full-design-microwatt-hours: battery design energy
> + - charge-full-design-microamp-hours: battery design capacity
> +
> +Battery properties are named, where possible, for the corresponding
> +elements in enum power_supply_property, defined in
> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h#n86
> +
> +Batteries must be referenced by chargers and/or fuel-gauges
> +using a phandle. The phandle's property should be named
> +"monitored-battery".
> +
> +Example:
> +
> + bat: battery {
> + compatible = "simple-battery";
> + voltage-min-design-microvolt = <3200000>;
> + energy-full-design-microwatt-hours = <5290000>;
> + charge-full-design-microamp-hours = <1430000>;
> + };
> +
> + charger: charger@11 {
> + ....
> + monitored-battery = <&bat>;
> + ...
> + };
> +
> + fuel_gauge: fuel-gauge@22 {
> + ....
> + monitored-battery = <&bat>;
> + ...
> + };
> --
> 2.9.3
>
--
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 6/9] ASoC: add snd_soc_get_dai_id()
From: Rob Herring @ 2017-04-07 19:16 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87h92nbdgy.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Mar 20, 2017 at 8:59 PM, Kuninori Morimoto
<kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi Rob
>
> Thank you for your review
>
>> > +{
>> > + struct device_node *node;
>> > + struct device_node *endpoint;
>> > + int i, id;
>> > +
>> > + node = of_graph_get_port_parent(ep);
>> > +
>> > + i = 0;
>> > + id = -1;
>> > + for_each_endpoint_of_node(node, endpoint) {
>> > + if (endpoint == ep)
>> > + id = i;
>>
>> I don't see how this works when you have 1 DAI controller with
>> multiple endpoints versus multiple DAI controllers with a single
>> endpoint each. All the IDs will be 0 in the latter case.
>
> It support 1:1 endpoint pattern only.
Then the endpoint id is always 0 and this function is pointless.
Rob
--
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 v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-07 18:48 UTC (permalink / raw)
To: Dan Williams
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS,
linux-arm-kernel@lists.infradead.org, Gustavo Padovan,
Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer, Satish Patel,
netdev, devicetree@vger.kernel.org
In-Reply-To: <1491584978.2136.21.camel@redhat.com>
On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing
>> AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed
>> for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> Is there no way to put the TI-specific stuff into a TI UART module
> rather than building it into the generic one?
In case it's not clear, all of HCI_LL is the TI specific part, not
just what I'm adding. So you are talking about putting each UART BT
protocol into a separate module. I'd assume that is doable, but seems
orthogonal to this patch set. I'd also assume there was some reason
that was not done already.
Rob
^ permalink raw reply
* Re: [PATCH v3] regulator: Add driver for voltage controlled regulators
From: Matthias Kaehlcke @ 2017-04-07 18:44 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Anderson, Brian Norris
In-Reply-To: <20170406182136.yrwdoyqeuz4qxc6d-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi Mark,
Thanks for the review!
El Thu, Apr 06, 2017 at 07:21:36PM +0100 Mark Brown ha dit:
> On Fri, Mar 31, 2017 at 01:50:35PM -0700, Matthias Kaehlcke wrote:
>
> > +- compatible : must be "vctrl-regulator".
> > +- regulator-min-microvolt : smallest voltage consumers may set
> > +- regulator-max-microvolt : largest voltage consumers may set
> > +- ctrl-regulator: : the name of the regulator supplying the control
> > + voltage.
>
> This looks good except for this bit where we read the regulator name out
> of the DT, that's generally a sign of bad practice for things that are
> less simple passives than things like this or fixed voltage regulators.
> As with the supplies for fixed voltage regulators just pick a name for
> the supply (ctrl seems fine to me) and use that, neither option is
> perfect but at elast this less typing for everyone and it's consistent
> with what other similar things are already doing.
Sounds good, I will send out an updated version shortly.
Matthias
--
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
* [PATCH v2 11/11] arm64: allwinner: a64: enable Wi-Fi for Pine64
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
The Wi-Fi modules of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).
Add device node for it.
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 7da074f95065..9d90bb32aa87 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -64,6 +64,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 */
+ };
};
&ehci1 {
@@ -91,6 +96,17 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dldo4>;
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ non-removable;
+ bus-width = <4>;
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
2.12.2
^ permalink raw reply related
* [PATCH v2 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-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 2132d8e6cb3d..7da074f95065 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
* [PATCH v2 09/11] arm64: allwinner: a64: add DTSI file for AXP803 PMIC
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-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>
---
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..f0e53a7fffbd
--- /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_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_dc1sw: dc1sw {
+ regulator-name = "dc1sw";
+ };
+
+ reg_aldo1: aldo1 {
+ regulator-name = "aldo1";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-name = "aldo2";
+ };
+
+ reg_aldo3: aldo3 {
+ regulator-name = "aldo3";
+ };
+
+ 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 v2 08/11] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-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>
---
drivers/mfd/axp20x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 2268a6a9aa2c..08b9bbd5bd71 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -839,6 +839,8 @@ static struct mfd_cell axp803_cells[] = {
.name = "axp20x-pek",
.num_resources = ARRAY_SIZE(axp803_pek_resources),
.resources = axp803_pek_resources,
+ }, {
+ .name = "axp20x-regulator",
}
};
--
2.12.2
^ permalink raw reply related
* [PATCH v2 07/11] regulator: axp20x-regulator: add support for AXP803
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-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>
---
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..2ed15e4a7a82 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 AXP806 and AXP803
+ * 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 v2 06/11] dt-bindings: add AXP803's regulator info
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
AXP803 have the most regulators in currently supported AXP PMICs.
Add info for the regulators in the dt-bindings document.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
Changes in v2:
- Place AXP803 regulators before AXP806/809 ones.
Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 334fb19ce605..50e381cdbf44 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -90,6 +90,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
DRIVEVBUS : Enable output : drivevbus-supply : external regulator
+AXP803 regulators, type, and corresponding input supply names:
+
+Regulator Type Supply Name Notes
+--------- ---- ----------- -----
+DCDC1 : DC-DC buck : vin1-supply
+DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
+DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
+DCDC4 : DC-DC buck : vin4-supply
+DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
+DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
+DC1SW : On/Off Switch : : DCDC1 secondary output
+ALDO1 : LDO : aldoin-supply : shared supply
+ALDO2 : LDO : aldoin-supply : shared supply
+ALDO3 : LDO : aldoin-supply : shared supply
+DLDO1 : LDO : dldoin-supply : shared supply
+DLDO2 : LDO : dldoin-supply : shared supply
+DLDO3 : LDO : dldoin-supply : shared supply
+DLDO4 : LDO : dldoin-supply : shared supply
+ELDO1 : LDO : eldoin-supply : shared supply
+ELDO2 : LDO : eldoin-supply : shared supply
+ELDO3 : LDO : eldoin-supply : shared supply
+FLDO1 : LDO : fldoin-supply : shared supply
+FLDO2 : LDO : fldoin-supply : shared supply
+LDO_IO0 : LDO : ips-supply : GPIO 0
+LDO_IO1 : LDO : ips-supply : GPIO 1
+RTC_LDO : LDO : ips-supply : always on
+
AXP806 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--
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
^ permalink raw reply related
* [PATCH v2 05/11] arm64: allwinner: a64: add AXP803 node to Pine64 device tree
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-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..2132d8e6cb3d 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 = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
* [PATCH v2 04/11] mfd: axp20x: support AXP803 variant
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
via RSB bus. The PMIC itself is like AXP288, but with RSB support and
dedicated VBUS and ACIN.
Add support for it in the axp20x mfd driver.
Currently only power key function is supported.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
Changes in v2:
- Share regmap configs with AXP288.
- Place AXP803 bits before AXP806/809.
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
3 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a732cb50bcff..fd5c7267b136 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+ { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 5ba3b04cc9b1..2268a6a9aa2c 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+ "AXP803",
"AXP806",
"AXP809",
};
@@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
};
+/* AXP288 ranges are shared with the AXP803, as they cover the same range */
static const struct regmap_range axp288_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
@@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
},
};
+static struct resource axp803_pek_resources[] = {
+ {
+ .name = "PEK_DBR",
+ .start = AXP803_IRQ_PEK_RIS_EDGE,
+ .end = AXP803_IRQ_PEK_RIS_EDGE,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .name = "PEK_DBF",
+ .start = AXP803_IRQ_PEK_FAL_EDGE,
+ .end = AXP803_IRQ_PEK_FAL_EDGE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static struct resource axp809_pek_resources[] = {
{
.name = "PEK_DBR",
@@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
};
+static const struct regmap_irq axp803_regmap_irqs[] = {
+ INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
+ INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
+ INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
+ INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
+ INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
+ INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
+ INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
+ INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
+ INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
+ INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
+ INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
+ INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
+ INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
+ INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
+ INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
+ INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
+ INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
+ INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
+ INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
+ INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
+ INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
+ INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
+ INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
+ INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
+ INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
+ INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
+};
+
static const struct regmap_irq axp806_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
@@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
};
+static const struct regmap_irq_chip axp803_regmap_irq_chip = {
+ .name = "axp803",
+ .status_base = AXP20X_IRQ1_STATE,
+ .ack_base = AXP20X_IRQ1_STATE,
+ .mask_base = AXP20X_IRQ1_EN,
+ .mask_invert = true,
+ .init_ack_masked = true,
+ .irqs = axp803_regmap_irqs,
+ .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
+ .num_regs = 6,
+};
+
static const struct regmap_irq_chip axp806_regmap_irq_chip = {
.name = "axp806",
.status_base = AXP20X_IRQ1_STATE,
@@ -769,6 +834,14 @@ static struct mfd_cell axp288_cells[] = {
},
};
+static struct mfd_cell axp803_cells[] = {
+ {
+ .name = "axp20x-pek",
+ .num_resources = ARRAY_SIZE(axp803_pek_resources),
+ .resources = axp803_pek_resources,
+ }
+};
+
static struct mfd_cell axp806_cells[] = {
{
.id = 2,
@@ -855,6 +928,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
axp20x->irq_flags = IRQF_TRIGGER_LOW;
break;
+ case AXP803_ID:
+ axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
+ axp20x->cells = axp803_cells;
+ axp20x->regmap_cfg = &axp288_regmap_config;
+ axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
+ break;
case AXP806_ID:
axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
axp20x->cells = axp806_cells;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index dc8798cf2a24..cde56cfe8446 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -20,6 +20,7 @@ enum axp20x_variants {
AXP221_ID,
AXP223_ID,
AXP288_ID,
+ AXP803_ID,
AXP806_ID,
AXP809_ID,
NR_AXP20X_VARIANTS,
@@ -234,7 +235,7 @@ enum axp20x_variants {
#define AXP22X_TS_ADC_L 0x59
#define AXP22X_BATLOW_THRES1 0xe6
-/* AXP288 specific registers */
+/* AXP288/AXP803 specific registers */
#define AXP288_POWER_REASON 0x02
#define AXP288_BC_GLOBAL 0x2c
#define AXP288_BC_VBUS_CNTL 0x2d
@@ -475,6 +476,43 @@ enum axp288_irqs {
AXP288_IRQ_BC_USB_CHNG,
};
+enum axp803_irqs {
+ AXP803_IRQ_ACIN_OVER_V = 1,
+ AXP803_IRQ_ACIN_PLUGIN,
+ AXP803_IRQ_ACIN_REMOVAL,
+ AXP803_IRQ_VBUS_OVER_V,
+ AXP803_IRQ_VBUS_PLUGIN,
+ AXP803_IRQ_VBUS_REMOVAL,
+ AXP803_IRQ_BATT_PLUGIN,
+ AXP803_IRQ_BATT_REMOVAL,
+ AXP803_IRQ_BATT_ENT_ACT_MODE,
+ AXP803_IRQ_BATT_EXIT_ACT_MODE,
+ AXP803_IRQ_CHARG,
+ AXP803_IRQ_CHARG_DONE,
+ AXP803_IRQ_BATT_CHG_TEMP_HIGH,
+ AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
+ AXP803_IRQ_BATT_CHG_TEMP_LOW,
+ AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
+ AXP803_IRQ_BATT_ACT_TEMP_HIGH,
+ AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
+ AXP803_IRQ_BATT_ACT_TEMP_LOW,
+ AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
+ AXP803_IRQ_DIE_TEMP_HIGH,
+ AXP803_IRQ_GPADC,
+ AXP803_IRQ_LOW_PWR_LVL1,
+ AXP803_IRQ_LOW_PWR_LVL2,
+ AXP803_IRQ_TIMER,
+ AXP803_IRQ_PEK_RIS_EDGE,
+ AXP803_IRQ_PEK_FAL_EDGE,
+ AXP803_IRQ_PEK_SHORT,
+ AXP803_IRQ_PEK_LONG,
+ AXP803_IRQ_PEK_OVER_OFF,
+ AXP803_IRQ_GPIO1_INPUT,
+ AXP803_IRQ_GPIO0_INPUT,
+ AXP803_IRQ_BC_USB_CHNG,
+ AXP803_IRQ_MV_CHNG,
+};
+
enum axp806_irqs {
AXP806_IRQ_DIE_TEMP_HIGH_LV1,
AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
2.12.2
^ permalink raw reply related
* [PATCH v2 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
bus.
Add a compatible for it.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Changes in v2:
- Place AXP803 before AXP806/809.
- Added Chen-Yu's ACK.
Documentation/devicetree/bindings/mfd/axp20x.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index b41d2601c6ba..334fb19ce605 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,12 +6,13 @@ axp202 (X-Powers)
axp209 (X-Powers)
axp221 (X-Powers)
axp223 (X-Powers)
+axp803 (X-Powers)
axp809 (X-Powers)
Required properties:
- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
- "x-powers,axp809"
+ "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
+ "x-powers,axp806", "x-powers,axp809"
- reg: The I2C slave address or RSB hardware address for the AXP chip
- interrupt-parent: The parent interrupt controller
- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
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
^ permalink raw reply related
* [PATCH v2 02/11] arm64: allwinner: a64: add NMI controller on A64
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
Allwinner A64 SoC features a NMI controller, which is usually connected
to the AXP PMIC.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
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..53c18ca372ea 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>;
};
+ nmi_intc: interrupt-controller@01f00c0c {
+ compatible = "allwinner,sun6i-a31-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01f00c0c 0x38>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
r_ccu: clock@1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
--
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
^ permalink raw reply related
* [PATCH v2 01/11] arm64: allwinner: a64: enable RSB on A64
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170407183441.58750-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
--
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 v2 00/11] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-07 18:34 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, 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.
This patchset can be splitted into two big parts:
- Part1: PATCH 1/11 to PATCH 5/11, which are enabling the MFD (and the
power key functionality) of AXP803.
- Part2: PATCH 6/11 to PATCH 11/11, which are enabling the regulator
function of the AXP803 PMIC. Finally Wi-Fi function is added
as a usage of regulators function.
PATCH 1 and 2 added RSB and NMI device nodes, which are used for the
communication between A64 and AXP803.
PATCH 3 adds basical devicetree binding for AXP803.
PATCH 4 adds support for the AXP803 variant in axp20x-rsb mfd driver.
PATCH 5 enabled the AXP803 MFD in Pine64 device tree.
PATCH 6 adds devicetree binding for the regulators in AXP803.
PATCH 7 adds support for the regulators in AXP803 in the axp20x-regulator
driver.
PATCH 8 enabled the regulator MFD cell in AXP803.
PATCH 9 adds a DTSI file for AXP803, just like what have been done for other
AXPs.
PATCH 10 enabled the regulators on Pine64.
PATCH 11 enabled Wi-Fi support on Pine64, which required DLDO4 and ELDO1
regulators.
Icenowy Zheng (11):
arm64: allwinner: a64: enable RSB on A64
arm64: allwinner: a64: add NMI controller on A64
dt-bindings: add device tree binding for X-Powers AXP803 PMIC
mfd: axp20x: support AXP803 variant
arm64: allwinner: a64: add AXP803 node to Pine64 device tree
dt-bindings: add AXP803's regulator info
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
Documentation/devicetree/bindings/mfd/axp20x.txt | 32 ++++-
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/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 81 +++++++++++
drivers/regulator/axp20x-regulator.c | 151 ++++++++++++++++++---
include/linux/mfd/axp20x.h | 77 ++++++++++-
8 files changed, 631 insertions(+), 24 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ permalink raw reply
* Re: [PATCH V3 0/5] iommu/arm-smmu: Add runtime pm/sleep support
From: Jordan Crouse @ 2017-04-07 18:01 UTC (permalink / raw)
To: Stephen Boyd
Cc: Will Deacon, Mark Rutland, devicetree@vger.kernel.org,
Mathieu Poirier, linux-arm-msm, iommu@lists.linux-foundation.org,
Rob Herring, linux-clk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170404193914.GF18246@codeaurora.org>
On Tue, Apr 04, 2017 at 12:39:14PM -0700, Stephen Boyd wrote:
> On 04/03, Will Deacon wrote:
> > On Fri, Mar 31, 2017 at 10:58:16PM -0400, Rob Clark wrote:
> > > On Fri, Mar 31, 2017 at 1:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Thu, Mar 09, 2017 at 09:05:43PM +0530, Sricharan R wrote:
> > > >> This series provides the support for turning on the arm-smmu's
> > > >> clocks/power domains using runtime pm. This is done using the
> > > >> recently introduced device links patches, which lets the symmu's
> > > >> runtime to follow the master's runtime pm, so the smmu remains
> > > >> powered only when the masters use it.
> > > >
> > > > Do you have any numbers for the power savings you achieve with this?
> > > > How often do we actually manage to stop the SMMU clocks on an SoC with
> > > > a handful of masters?
> > > >
> > > > In other words, is this too coarse-grained to be useful, or is it common
> > > > that all the devices upstream of the SMMU are suspended?
> > >
> > > well, if you think about a phone/tablet with a command mode panel,
> > > pretty much all devices will be suspended most of the time ;-)
> >
> > Well, that's really what I was asking about. I assumed that periodic
> > modem/radio transactions would keep the SMMU clocked, so would like to get a
> > rough idea of the power savings achieved with this coarse-grained approach.
>
> Sometimes we distribute SMMUs to each IP block in the system and
> let each one of those live in their own clock + power domain. In
> these cases, the SMMU can be powered down along with the only IP
> block that uses it. Furthermore, sometimes we put the IP block
> and the SMMU inside the same power domain to really tie the two
> together, so we definitely have cases where all devices (device?)
> upstream of the SMMU are suspended. And in the case of
> multimedia, it could be very often that something like the camera
> app isn't open and thus the SMMU dedicated for the camera can be
> powered down.
>
> Other times we have two SMMUs in the system where one is
> dedicated to GPU and the other is "everything else". Even in
> these cases, we can suspend the GPU one when the GPU is inactive
> because it's the only consumer. The other SMMU might not be as
> fine grained, but I think we still power it down quite often
> because the consumers are mostly multimedia devices that aren't
> active when the display is off.
And just to confuse things even further: with per-instance pagetables we have an
interest in forcing the SMMU clocks *on* because we don't know when the GPU
might try to hit the registers to switch a pagetable and if somebody in the
pipeline is actively trying to do power management at the same time hilarity
will ensue.
The alternative to pm_runtime is the downstream driver that probes the SMMU
clocks from DT and frobs them itself. I think we can agree that is far less
reasonable.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Dan Williams @ 2017-04-07 17:09 UTC (permalink / raw)
To: Rob Herring, Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
In-Reply-To: <20170407143516.9945-1-robh@kernel.org>
On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> Turns out that the LL protocol and the TI-ST are the same thing
> AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed
> for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
>
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.
Is there no way to put the TI-specific stuff into a TI UART module
rather than building it into the generic one?
Dan
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> ---
> v2:
> - Use IS_ENABLED() to fix module build
>
> drivers/bluetooth/hci_ll.c | 261
> ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 260 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 02692fe30279..77648adfd5c9 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -34,20 +34,23 @@
> #include <linux/sched.h>
> #include <linux/types.h>
> #include <linux/fcntl.h>
> +#include <linux/firmware.h>
> #include <linux/interrupt.h>
> #include <linux/ptrace.h>
> #include <linux/poll.h>
>
> #include <linux/slab.h>
> -#include <linux/tty.h>
> #include <linux/errno.h>
> #include <linux/string.h>
> #include <linux/signal.h>
> #include <linux/ioctl.h>
> +#include <linux/serdev.h>
> #include <linux/skbuff.h>
> +#include <linux/ti_wilink_st.h>
>
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> +#include <linux/gpio/consumer.h>
>
> #include "hci_uart.h"
>
> @@ -76,6 +79,12 @@ struct hcill_cmd {
> u8 cmd;
> } __packed;
>
> +struct ll_device {
> + struct hci_uart hu;
> + struct serdev_device *serdev;
> + struct gpio_desc *enable_gpio;
> +};
> +
> struct ll_struct {
> unsigned long rx_state;
> unsigned long rx_count;
> @@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
>
> hu->priv = ll;
>
> + if (hu->serdev)
> + serdev_device_open(hu->serdev);
> +
> return 0;
> }
>
> @@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
>
> kfree_skb(ll->rx_skb);
>
> + if (hu->serdev) {
> + struct ll_device *lldev =
> serdev_device_get_drvdata(hu->serdev);
> + gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +
> + serdev_device_close(hu->serdev);
> + }
> +
> hu->priv = NULL;
>
> kfree(ll);
> @@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct
> hci_uart *hu)
> return skb_dequeue(&ll->txq);
> }
>
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int read_local_version(struct hci_dev *hdev)
> +{
> + int err = 0;
> + unsigned short version = 0;
> + struct sk_buff *skb;
> + struct hci_rp_read_local_version *ver;
> +
> + skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0,
> NULL, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb)) {
> + bt_dev_err(hdev, "Reading TI version information
> failed (%ld)",
> + PTR_ERR(skb));
> + err = PTR_ERR(skb);
> + goto out;
> + }
> + if (skb->len != sizeof(*ver)) {
> + err = -EILSEQ;
> + goto out;
> + }
> +
> + ver = (struct hci_rp_read_local_version *)skb->data;
> + if (le16_to_cpu(ver->manufacturer) != 13) {
> + err = -ENODEV;
> + goto out;
> + }
> +
> + version = le16_to_cpu(ver->lmp_subver);
> +
> +out:
> + if (err) bt_dev_err(hdev, "Failed to read TI version info:
> %d", err);
> + kfree_skb(skb);
> + return err ? err : version;
> +}
> +
> +/**
> + * download_firmware -
> + * internal function which parses through the .bts firmware
> + * script file intreprets SEND, DELAY actions only as of now
> + */
> +static int download_firmware(struct ll_device *lldev)
> +{
> + unsigned short chip, min_ver, maj_ver;
> + int version, err, len;
> + unsigned char *ptr, *action_ptr;
> + unsigned char bts_scr_name[40]; /* 40 char long bts
> scr name? */
> + const struct firmware *fw;
> + struct sk_buff *skb;
> + struct hci_command *cmd;
> +
> + version = read_local_version(lldev->hu.hdev);
> + if (version < 0)
> + return version;
> +
> + chip = (version & 0x7C00) >> 10;
> + min_ver = (version & 0x007F);
> + maj_ver = (version & 0x0380) >> 7;
> + if (version & 0x8000)
> + maj_ver |= 0x0008;
> +
> + snprintf(bts_scr_name, sizeof(bts_scr_name),
> + "ti-connectivity/TIInit_%d.%d.%d.bts",
> + chip, maj_ver, min_ver);
> +
> + err = request_firmware(&fw, bts_scr_name, &lldev->serdev-
> >dev);
> + if (err || !fw->data || !fw->size) {
> + bt_dev_err(lldev->hu.hdev, "request_firmware
> failed(errno %d) for %s",
> + err, bts_scr_name);
> + return -EINVAL;
> + }
> + ptr = (void *)fw->data;
> + len = fw->size;
> + /* bts_header to remove out magic number and
> + * version
> + */
> + ptr += sizeof(struct bts_header);
> + len -= sizeof(struct bts_header);
> +
> + while (len > 0 && ptr) {
> + bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d
> ",
> + ((struct bts_action *)ptr)->size,
> + ((struct bts_action *)ptr)->type);
> +
> + action_ptr = &(((struct bts_action *)ptr)->data[0]);
> +
> + switch (((struct bts_action *)ptr)->type) {
> + case ACTION_SEND_COMMAND: /* action send */
> + bt_dev_dbg(lldev->hu.hdev, "S");
> + cmd = (struct hci_command *)action_ptr;
> + if (cmd->opcode == 0xff36) {
> + /* ignore remote change
> + * baud rate HCI VS command */
> + bt_dev_warn(lldev->hu.hdev, "change
> remote baud rate command in firmware");
> + break;
> + }
> + if (cmd->prefix != 1)
> + bt_dev_dbg(lldev->hu.hdev, "command
> type %d\n", cmd->prefix);
> +
> + skb = __hci_cmd_sync(lldev->hu.hdev, cmd-
> >opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb)) {
> + bt_dev_err(lldev->hu.hdev, "send
> command failed\n");
> + goto out_rel_fw;
> + }
> + kfree_skb(skb);
> + break;
> + case ACTION_WAIT_EVENT: /* wait */
> + /* no need to wait as command was
> synchronous */
> + bt_dev_dbg(lldev->hu.hdev, "W");
> + break;
> + case ACTION_DELAY: /* sleep */
> + bt_dev_info(lldev->hu.hdev, "sleep command
> in scr");
> + mdelay(((struct bts_action_delay
> *)action_ptr)->msec);
> + break;
> + }
> + len -= (sizeof(struct bts_action) +
> + ((struct bts_action *)ptr)->size);
> + ptr += sizeof(struct bts_action) +
> + ((struct bts_action *)ptr)->size;
> + }
> +
> +out_rel_fw:
> + /* fw download complete */
> + release_firmware(fw);
> + return err;
> +}
> +
> +static int ll_setup(struct hci_uart *hu)
> +{
> + int err, retry = 3;
> + struct ll_device *lldev;
> + struct serdev_device *serdev = hu->serdev;
> + u32 speed;
> +
> + if (!serdev)
> + return 0;
> +
> + lldev = serdev_device_get_drvdata(serdev);
> +
> + serdev_device_set_flow_control(serdev, true);
> +
> + do {
> + /* Configure BT_EN to HIGH state */
> + gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> + msleep(5);
> + gpiod_set_value_cansleep(lldev->enable_gpio, 1);
> + msleep(100);
> +
> + err = download_firmware(lldev);
> + if (!err)
> + break;
> +
> + /* Toggle BT_EN and retry */
> + bt_dev_err(hu->hdev, "download firmware failed,
> retrying...");
> + } while (retry--);
> +
> + if (err)
> + return err;
> +
> + /* Operational speed if any */
> + if (hu->oper_speed)
> + speed = hu->oper_speed;
> + else if (hu->proto->oper_speed)
> + speed = hu->proto->oper_speed;
> + else
> + speed = 0;
> +
> + if (speed) {
> + struct sk_buff *skb = __hci_cmd_sync(hu->hdev,
> 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
> + if (!IS_ERR(skb)) {
> + kfree_skb(skb);
> + serdev_device_set_baudrate(serdev, speed);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct hci_uart_proto llp;
> +
> +static int hci_ti_probe(struct serdev_device *serdev)
> +{
> + struct hci_uart *hu;
> + struct ll_device *lldev;
> + u32 max_speed = 3000000;
> +
> + lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device),
> GFP_KERNEL);
> + if (!lldev)
> + return -ENOMEM;
> + hu = &lldev->hu;
> +
> + serdev_device_set_drvdata(serdev, lldev);
> + lldev->serdev = hu->serdev = serdev;
> +
> + lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev,
> "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(lldev->enable_gpio))
> + return PTR_ERR(lldev->enable_gpio);
> +
> + of_property_read_u32(serdev->dev.of_node, "max-speed",
> &max_speed);
> + hci_uart_set_speeds(hu, 115200, max_speed);
> +
> + return hci_uart_register_device(hu, &llp);
> +}
> +
> +static void hci_ti_remove(struct serdev_device *serdev)
> +{
> + struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> + struct hci_uart *hu = &lldev->hu;
> + struct hci_dev *hdev = hu->hdev;
> +
> + cancel_work_sync(&hu->write_work);
> +
> + hci_unregister_dev(hdev);
> + hci_free_dev(hdev);
> + hu->proto->close(hu);
> +}
> +
> +static const struct of_device_id hci_ti_of_match[] = {
> + { .compatible = "ti,wl1831-st" },
> + { .compatible = "ti,wl1835-st" },
> + { .compatible = "ti,wl1837-st" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, hci_ti_of_match);
> +
> +static struct serdev_device_driver hci_ti_drv = {
> + .driver = {
> + .name = "hci-ti",
> + .of_match_table = of_match_ptr(hci_ti_of_match),
> + },
> + .probe = hci_ti_probe,
> + .remove = hci_ti_remove,
> +};
> +#else
> +#define ll_setup NULL
> +#endif
> +
> static const struct hci_uart_proto llp = {
> .id = HCI_UART_LL,
> .name = "LL",
> + .setup = ll_setup,
> .open = ll_open,
> .close = ll_close,
> .recv = ll_recv,
> @@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
>
> int __init ll_init(void)
> {
> + serdev_device_driver_register(&hci_ti_drv);
> +
> return hci_uart_register_proto(&llp);
> }
>
> int __exit ll_deinit(void)
> {
> + serdev_device_driver_unregister(&hci_ti_drv);
> +
> return hci_uart_unregister_proto(&llp);
> }
^ permalink raw reply
* Re: [PATCH] of: change fixup of dma-ranges size to error
From: Rob Herring @ 2017-04-07 17:09 UTC (permalink / raw)
To: Frank Rowand, Robin Murphy, Sricharan
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <58E72123.4040607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ Robin, Sricharan
On Fri, Apr 7, 2017 at 12:18 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 04/06/17 15:41, Rob Herring wrote:
>> On Thu, Apr 6, 2017 at 1:37 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 04/06/17 07:03, Rob Herring wrote:
>>>> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>>>>
>>>>> of_dma_get_range() has workaround code to fixup a device tree that
>>>>> incorrectly specified a mask instead of a size for property
>>>>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>>>>> the workaround is no longer needed. Leave a data validation
>>>>> check in place, but no longer do the fixup. Move the check
>>>>> one level deeper in the call stack so that other possible users
>>>>> of dma-ranges will also be protected.
>>>>>
>>>>> The fix to the device tree was in
>>>>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>>>>
>>>> NACK.
>>>> This was by design. You can't represent a size of 2^64 or 2^32.
>>>
>>> I agree that being unable to represent a size of 2^32 in a u32 and
>>> a size of 2^64 in a u64 is the underlying issue.
>>>
>>> But the code to convert a mask to a size is _not_ design, it is a
>>> hack that temporarily worked around a device tree that did not follow
>>> the dma-ranges binding in the ePAPR.
>>
>> Since when is (2^64 - 1) not a size. It's a perfectly valid size in
>
> I did not say (2^64 -1) is not a size.
>
> I said that the existing code has a hack that converts what is perceived
> to be a mask into a size. The existing code is:
>
> @@ 110,21 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> size = dev->coherent_dma_mask + 1;
> } else {
> offset = PFN_DOWN(paddr - dma_addr);
>
> /*
> * Add a work around to treat the size as mask + 1 in case
> * it is defined in DT as a mask.
> */
> if (size & 1) {
> dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
> size);
> size = size + 1;
> }
>
> if (!size) {
> dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
> return;
> }
> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> }
>
> Note the comment that says "in case it is defined in DT as a mask."
>
> And as you stated in a review comment is 2015: "Also, we need a WARN
> here so DTs get fixed."
Indeed. I agree that "let me put a mask in the DT so Linux (at some
version) works" is wrong. I still think (2^32 - 1) and (2^64 - 1)
should be allowed to avoid growing #size-cells and because
#size-cells=3 doesn't work.
>> DT. And there's probably not a system in the world that needs access
>> to that last byte. Is it completely accurate description if we
>> subtract off 1? No, but it is still a valid range (so would be
>> subtracting 12345).
>>
>>> That device tree was corrected a year ago to provide a size instead of
>>> a mask.
>>
>> You are letting Linux implementation details influence your DT
>> thinking. DT is much more flexible in that it supports a base address
>> and size (and multiple of them) while Linux can only deal with a
>> single address mask. If Linux dealt with base + size, then we wouldn't
>
> No. of_dma_get_range() returns two addresses and a size from the
> dma-ranges property, just as it is defined in the spec.
>
> of_dma_configure() then interprets an odd size as meaning that the
> device tree incorrectly contains a mask, and then converts that mask
> to a size by adding one to it. Linux is _still_ using address and
> size at this point. It does _not_ convert this size into a mask,
> but instead passes size on into arch_setup_dma_ops().
It doesn't really matter where in the implementation, but at some
point we end up with only a mask in Linux was my point.
> The proposed patch is to quit accepting a mask as valid data in
> dma-ranges.
>
>
>> be having this conversation. As long as Linux only deals with masks,
>> we're going to have to have some sort of work-around to deal with
>> them.
>>
>>>> Well, technically you can for the latter, but then you have to grow
>>>> #size-cells to 2 for an otherwise all 32-bit system which seems kind
>>>> of pointless and wasteful. You could further restrict this to only
>>>> allow ~0 and not just any case with bit 0 set.
>>>>
>>>> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
>>>
>>> I examined all instances of property dma-ranges in in tree dts files in
>>> Linux 4.11-rc1. There are none that incorrectly specify mask instead of
>>> size.
>>
>> Okay, but there are ones for ranges at least. See ecx-2000.dts.
>
> The patch does not impact the ranges property. It only impacts the
> dma-ranges property.
Yes, I know. I'm only pointing out we have other cases of size=~0 to
avoid growing #size-cells.
>>> #size-cells only changes to 2 for the dma-ranges property and the ranges
>>> property when size is 2^32, so that is a very small amount of space.
>>>
>>> The patch does not allow for a size of 2^64. If a system requires a
>>> size of 2^64 then the type of size needs to increase to be larger
>>> than a u64. If you would like for the code to be defensive and
>>> detect a device tree providing a size of 2^64 then I can add a
>>> check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
>>> When that error triggers, the type of size can be changed.
>>
>> #size-cells > 2 is completely broken for anything but PCI. I doubt it
>
> Yes, that is what I said. The current code does not support #size-cells > 2
> for dma-ranges.
It's not just dma-ranges. It's everywhere with reg and ranges and any
code that parses those too. If someone needs to truly specify sizes of
2^64 in DT (for reg, ranges, or dma-ranges), they are SOL.
> #size-cells > 2 for dma-ranges will lead to a problem in
> of_dma_get_range(), which stuffs the value of the size into a u64.
> Clearly, a 3 cell size will not fit into a u64.
>
>
>> is easily fixed without some special casing (i.e. a different hack)
>> until we have 128-bit support. I hope to retire before we need to
>> support that.
>>
>> Rob
>>
>
> Can we get back to the basic premise of the proposed patch?
>
> The current code in of_dma_configure() contains a hack that allows the
> dma-ranges property to specify a mask instead of a size. The binding
> in the specification allows a size and does not allow a mask.
>
> The hack was added to account for one or more dts files that did not
> follow the specification. In the mail list discussion of the hack
> you said "Also, we need a WARN here so DTs get fixed."
>
> The hack was first present in Linux 4.1. The only in-tree dts that
> incorrectly contained a mask instead of a size in dma-ranges was
> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>
> That .dtsi was fixed by
> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree")
> The fix was present in Linux 4.6, May 15, 2016.
>
> I would like to remove the hack. I think that enough time has
> elapsed to allow this change.
If we have no cases of what I'm concerned about, then removing it is
fine. Is this a dependency for iommu series? Doesn't look like it to
me.
Rob
--
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
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